The definition of 'Complete Corresponding Source Code' in GPLv3
Discussion Draft 1 was a significant change from the GPLv2 definition.
It gives an expansive list of verbs (which was later pared down in
response to some criticism that it was *too* expansive) in place of
the quasi-tautological formula in GPLv2. "Scripts" are mentioned and
are assumed to be a form of "source code" (itself a defined term). The
"keys" provision treated certain "encryption or authorization keys"
something that was not "source code" but which was a categorically
different part of Complete Corresponding Source Code.
From discussions with Bradley, I have learned of the significance of
the words "scripts used to control compilation and installation of the
executable" in the context of GPLv2 enforcement. I have gathered that
failure to provide scripts, or the equivalent, satisfying this
definition is a common problem in such enforcement.
I believe Bradley sees the Installation Information requirements of
present-day GPLv3 as a descendant, of sorts, of the "scripts used to
control compilation and installation of the executable" wording in
GPLv2, which is interesting.
Now, here again is the beginning of the definition of Corresponding
Source in present-day GPLv3:
The 'Corresponding Source' for a work in object code form
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities.
Note that scripts to control 'installation' and 'running' are one
category of source code that is part of Corresponding Source. But note
also that a separate section of GPLv3 details 'Installation
Information' requirements which apply only to conveying of object code
in 'User Products'.
I do not see how one can read the GPLv3 Corresponding Source
definition such that "scripts to control" the activities of
installation and running include "Installation Information". The fact
that Installation Information is limited to User Products makes clear
that Installation Information is information that is *additional* to
Corresponding Source. Any alternate reading seems to suggest that
GPLv3 has two Installation Information requirements: one which is
quite detailed and applies only in the User Product context, and the
other which is vaguer and which applies in all (or all other)
contexts. As a matter of common sense, plain reading, and historical
evidence, this cannot be a correct reading of GPLv3.
This brings us to the current copyleft-next definition. I quote the
beginning of it:
"Corresponding Source" of a Covered Work in Object Code
form means (i)
the Source Code of the Covered Work; (ii) all scripts, instructions
and information known to you necessary for a skilled developer to
build, compile, generate and modify the Covered Work; [....]
Note that this is different from GPLv3 in the following sense: it does
not treat "scripts, instructions and information known to you" as a
form of "Source Code". Clause (i) has the quasi-tautological flavor of
GPLv2 and its ancestors. Clause (ii) is the descendant of the "scripts
used to control compilation and installation of the executable"
language of GPLv2, as well as the descendant of the 'expansive set of
verbs' approach in the basic definition of Corresponding Source in GPLv3.
Now, here's what I think happened. By keeping (i) and (ii) separate
(in a way in which they are not separate in GPLv3, but sort of are in
GPLv2), and by broadening (ii) to refer not merely to "scripts", I
believe an interesting problem was created. My argument above that
GPLv3's definition of Corresponding Source cannot possibly be read to
imply a sort of stealth general Installation Information requirement
is not relevant to copyleft-next, because copyleft-next has this
"source code vs. other information" separation built into the
definition, and also copyleft-next did away with the explicit
Installation Information provisions altogether.
However, as Luis Villa pointed out, this all permits the copyleft-next
definition (when it had the verbs "install and run", which Bradley
wants to restore) to be read as *having* something like an
Installation Information requirement in some non-specific sense,
particularly because broader words than merely "scripts" are used. And
this reading by Luis appears to be justified since Bradley seems to be
either saying that this is how the definition *must* be read, or that
this is how it reasonably *can* be read. (And Bradley had some part in
drafting the current version.)
In other words, we created a situation in which "install and run"
arguably meant more in copyleft-next than it possibly can in GPLv3. We
don't have the Installation Information provisions and the GPLv3
limitation of 'things other than conventional source code' to
"scripts" to make clear that such a broad reading of "install and
would be preposterous.
That is why I deleted "install and run".
I may have more to say on this but I'll leave it at that for now.