[copyleft-next] best way to describe the contents of "Corresponding Source"

Luis Villa luis at tieguy.org
Mon Aug 6 00:29:21 UTC 2012


On Sun, Aug 5, 2012 at 7:30 AM, Bradley M. Kuhn <bkuhn at 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


More information about the copyleft-next mailing list