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" as 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 means all 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 run" 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.
- RF