On Sun, Aug 5, 2012 at 7:30 AM, Bradley M. Kuhn bkuhn@ebb.org wrote:
Luis Villa wrote at 22:57 (EDT) on Friday:
That should be "any scripts..." not just "scripts", no?
What is the point of adding 'any'?
In this context, "any" would typically be read to mean '"every", with the additional implication that "every" was not used because there might not be such scripts. So long as no other part of the language does not explicitly require such a script to exist (which is currently the case), it is essentially the same as your proposed "all," because both "any" and "all" permit the case where no such scripts exist.
I suggested this because Richard's original language, without either "any" or "all", was ambiguous as to whether or not the scripts were required, and my sense is that "any" (i.e., permitting there to be no scripts existing) was what was intended.
If instead the license is intended to require that such scripts exist (which is perfectly reasonable) neither "any" nor "all" does that with 100% clarity. It would be much better to say something like "and must include the scripts and instructions necessary..." Or perhaps, better integrated into the rest of the definition
"Corresponding Source" of a work means all the Source Code needed to build, compile, generate, modify, install, and run the work (to the extent those activities are meaningful for the work), * including scripts, instructions and configuration files that can be used [are used?] to perform those activities.*
Obviously "are used" is extremely strong, as it prohibits having parallel build systems (one that can be used internally and one used by GPL licensees).
I dislike "know-how" because it is insanely vague. Much better to list the things (like configuration files) that might contain such know-how.
I've never been sure what "control" means in this context. Given that "perform" is probably broad enough to completely encompass "control," and given how comprehensive the list of tasks is now (it's arguably impossible to "perform" a build without some form of control) I'd be inclined to replace "control and perform" with simply "perform," or else give a more specific definition of "control" (e.g, by reference to configuration files.)
I actually think "scripts used to control compilation and installation of the executable" is effectively the same as what I wrote in my original patch, but I've seen weasely lawyers argue otherwise to defend their GPL-violating clients, so I think we need as much text in there as possible. We should keep adding verbs until we can't think of any more.
I'm not necessarily against adding more verbs (especially in the first group (build, compile, etc.)) but I think the license is stronger when the drafters can clearly explain and describe what each verb they put in means :) Control has always been problematic this way because in common parlance scripts don't "control" - they perform or act, and configuration files or command-line options control. So I like the simple "perform" because it makes clear that the goal is to do that first set of actions, instead of burying it in other verbs.
[Building on that last sentence, here's a radical rewriting of the sentence at issue, though I'm not 100% sure it works:
"Corresponding Source" of a work means the Source Code of all materials needed to enable You to generate, install, and run the Received Work, including [but not limited to] scripts, instructions, and configuration files."
I like this because it puts the emphasis on enabling the recipient's rights; if the recipient can't generate/install/run the work, then by definition they are not enabled and the requirement is not satisfied.
I like "generate" because again it focuses on the outcome (that the work is generated from the Corresponding Source) rather than specific technical means of achieving that end (building, compiling).
I put [but not limited to] in brackets because, while commonly used, it probably shouldn't be: http://www.adamsdrafting.com/2007/04/02/including-without-limitation/
I don't like that this makes it theoretically impossible for a Distributor to know, a priori, if they are in compliance, since they don't know who "You" will be, or what capabilities You will have, but obviously that can be read as a feature and not a bug. :)
]
Luis
On 08/05/2012 08:29 PM, Luis Villa wrote: [re an earlier patch submitted by Bradley that used the term "know-how" undefined in the Corresponding Source definition]:
I dislike "know-how" because it is insanely vague. Much better to list the things (like configuration files) that might contain such know-how.
My own reaction had been that in my experience "know-how" was typically a defined term in commercial agreements. However, I'm just noting here that in the past day I've seen two different agreements (essentially contracts of adhesion) in which "know-how" was used undefined.
- RF
On Tue, Sep 4, 2012 at 8:03 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/05/2012 08:29 PM, Luis Villa wrote: [re an earlier patch submitted by Bradley that used the term "know-how" undefined in the Corresponding Source definition]:
I dislike "know-how" because it is insanely vague. Much better to list the things (like configuration files) that might contain such know-how.
My own reaction had been that in my experience "know-how" was typically a defined term in commercial agreements. However, I'm just noting here that in the past day I've seen two different agreements (essentially contracts of adhesion) in which "know-how" was used undefined.
NDAs, I assume? It's fairly common there. "Make the license more like an NDA" is not the strongest drafting advice I've ever heard, though ;)
Luis
On 09/04/2012 11:44 PM, Luis Villa wrote:
On Tue, Sep 4, 2012 at 8:03 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/05/2012 08:29 PM, Luis Villa wrote: [re an earlier patch submitted by Bradley that used the term "know-how" undefined in the Corresponding Source definition]:
I dislike "know-how" because it is insanely vague. Much better to list the things (like configuration files) that might contain such know-how.
My own reaction had been that in my experience "know-how" was typically a defined term in commercial agreements. However, I'm just noting here that in the past day I've seen two different agreements (essentially contracts of adhesion) in which "know-how" was used undefined.
NDAs, I assume? It's fairly common there. "Make the license more like an NDA" is not the strongest drafting advice I've ever heard, though ;)
Oh, I wasn't thinking of NDAs but I suppose you're right, it's common there too.
- RF
Luis Villa wrote:
That should be "any scripts..." not just "scripts", no?
On Sun, Aug 5, 2012 at 7:30 AM, Bradley M. Kuhn bkuhn@ebb.org wrote:
What is the point of adding 'any'?
Luis Villa wrote on 6 August:
In this context, "any" would typically be read to mean '"every", with the additional implication that "every" was not used because there might not be such scripts. So long as no other part of the language does not explicitly require such a script to exist (which is currently the case), it is essentially the same as your proposed "all," because both "any" and "all" permit the case where no such scripts exist.
I suggested this because Richard's original language, without either "any" or "all", was ambiguous as to whether or not the scripts were required, and my sense is that "any" (i.e., permitting there to be no scripts existing) was what was intended.
What an amazing bit of lawyer's sophistry. RMS' clearly intended in GPLv2 that scripts and instructions should be provided in all cases.
It's therefore obviously a mistake to harm the language by adding any, and what your argument above indicates is that the lack of "any" in GPLv2's wording means that the scripts need to be provided even if they don't exist yet if "control[ling] compilation and installation" is impossible without scripts.
As you well know, Luis, violators seek this kind of sophistry to seek to withhold scripts. Such is a license violation in my view. We definitely need good detail in copyleft-next's Corresponding Source definition to make it more difficult for violators to even make these arguments anymore and waste our time with their sophistry.
It's not that these silly arguments are right: even the violator-defending lawyers usually know they're making specious arguments. But, the company is usually quite wealthy and can afford to pay lawyers to burn the time of the small non-profits that stand up to defend copyleft. So, they waste our time by making up these silly arguments to avoid complying. We need copyleft-next to make it harder for violation-defending lawyers to do this.
I dislike "know-how" because it is insanely vague.
Is that *really* the only reason you're arguing against know-how?
Much better to list the things (like configuration files) that might contain such know-how.
I think copyleft-next needs the biggest laundry list here we can think of. What's the harm in doing both: having know-how in there along with everything else that's already there?
I'm not necessarily against adding more verbs (especially in the first group (build, compile, etc.))
Great. My merge request (describe below) offers them back.
but I think the license is stronger when the drafters can clearly explain and describe what each verb they put in means :)
The problem is, as you well know, is that violators pay their lawyers to come up with silly mis-readings of the license merely to avoid complying.
Anyway, I notice that since I last posted on this thread, there's been lots of changes to the Corresponding Source source definition. I've got a lot of issues and concerns, that I've put together into a single merge request: https://gitorious.org/copyleft-next/copyleft-next/merge_requests/18
Each change is done as single commits on this branch: https://gitorious.org/~bkuhn/copyleft-next/bkuhn-copyleft-next-proposals
and I was careful not to refill the paragraph so that Fontana can cherry-pick if he wants.
copyleft-next@lists.fedorahosted.org