best way to describe the contents of "Corresponding Source"
by Luis Villa
On Sun, Aug 5, 2012 at 7:30 AM, Bradley M. Kuhn <bkuhn(a)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
11 years, 5 months
Some initial comments on the copyleft-next draft
by Richard Fontana
Hi,
During the past two weeks I've been working on modifying a document that
started out as the text of the GNU GPLv3 but which is now quite
different. I've had gracious help from several other people, but so far
it's fair to say that most of the *policy* decisions underlying the
various changes have come from me (IOW you can blame me for almost
anything in the draft thus far if you disagree with it). I thought I'd
provide a summary description of the more interesting aspects of what's
been done.
I deleted the following elements:
* The Preamble and the 'How to Apply' appendix
* The patent-related provisions that were introduced to GNU GPLv3 in the
wake of the Microsoft/Novell deal of late 2006
* The old requirement to preserve legal notices in user interfaces
* The acceptance provision (proposed by James Vasile)
I removed the so-called 'anti-Tivoization' provisions of GNU GPLv3
section 6 out of vanilla copyleft-next and into a separate document
currently called "dl-supp". I also added a separate document called
"ws-supp" containing substantially similar text to the first half of the
GNU AGPLv3 section 13. I don't think I really explained this in the
commit logs so I'll go into that a bit here. The idea is that the
vanilla version of copyleft-next won't have an 'Affero clause' (much as
GNU GPLv3 doesn't) and, unlike GNU GPLv3, it won't have
'anti-Tivoization' provisions. Only the *initial* licensor (someone
who's starting a new work from scratch) can choose to supplement
copyleft-next with one of those "supp" documents. Currently, vanilla
copyleft-next is incompatible with {copyleft-next + dl-supp} and
{copyleft-next + ws-supp} (much like "GNU GPLv2-only" is incompatible
with GNU GPL3) (i.e. there's nothing corresponding to GPLv3/AGPLv3
cross-compatibility), though this is just because I deferred thinking
about whether there should be compatibility or not.
I added a provision similar to Apache License 2.0 section 5 which is
something like a built-in "inbound=outbound" contributor agreement for
projects. (While I like this Apache feature very much it is a bit
awkward in copyleft-next in its current form.)
I added a provision to the basic copyleft clause that is designed to
remove the copyleft requirement if the licensor separately offers a
proprietary commercial version of essentially the same software. Maybe
this isn't worthwhile, but it was something I'd wanted to experiment
with trying to implement for a long time.
I added a provision making copyleft-next relicensable under GNU
GPLvn/AGPLv (the importance of this was impressed on me by Mike
Linksvayer and it also addresses the FSF's reasonable concerns about GNU
GPL derivatives).
I added a "no trademark rights granted" clause (similar to what's in MPL
and the Apache License 2.0).
The old additional terms section has been drastically simplified and
combined into the 'no-further-restrictions' section.
I won't go into detail about the remainder of the changes in this
message but I'd describe them generally as aimed at substantial
simplification and normalization of language and structure. To take one
example, the patent license grant of GNU GPLv3 is essentially the same
but it is presented very differently: it now accompanies the basic
copyright license grant in the 'basic permissions' section early in the
license (this is more like how other free software/open source licenses
with patent license grants are structured, and I think it may be easier
to understand).
I consider nothing of what I've done to be necessary or above criticism,
but I think it gives you a sense of the direction I'm generally going in.
This might be the most lightly trafficked mailing list in the entire
legal history of free and open source software, but I'd be happy if it
could serve as a forum for discussing, suggesting or criticizing ideas,
and also as one way of submitting patches against the license draft.
For those who don't know, currently I've been hosting the repository at
https://gitorious.org/copyleft-next and mirroring at github
https://github.com/richardfontana/copyleft-next
There's an IRC channel #copyleft-next on Freenode though so far the only
discussion there has been bcotton and I talking about today's weather in
Massachusetts. :-)
- Richard
11 years, 5 months