[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Defining 'preferred form for making modifications'




On Wednesday, Jun 25, 2003, at 00:16 US/Eastern, Thomas Bushnell, BSG wrote:

Anthony DeRobertis <asd@suespammers.org> writes:

Well, "The source code for a work means the preferred form of the work
for making modifications to it. For an executable work, complete
source code means all the source code for all modules it contains,
plus any associated interface definition files, plus the scripts used
to control compilation and installation of the executable." (GPL 3)

To be source code for the new version, the C original would have to:
	a) be a form of the (new) work
	b) be a the form that modifications would be made to
	c) it must be possible to transform the source code form into the
	   object or executable form [implied by (b) and GPL 3(a)]

There is nowhere any requirement in the GPL that source can be
automatically compiled, and in cases like the ones under
consideration, it cannot be.

Well, for executable works, we have things like "For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." (GPL 3) and "Accompany it with the complete corresponding machine-readable source code..." (GPL 3a)

Also, all of GPL 3 is about the "Program (or a work based on it, under Section 2) in object code or executable form." If there is manual editing sufficient to create a derivative work (e.g., non-trivial edits of a creative nature), it is a "work based on [the program]", not a form of the program.

So, I think (c) is very strongly supported.


GPL 3(a) says nothing about automatic transformation; it speaks of the
"corresponding" source, but nothing says that the corresponding source
must be automatically translatable.

Not automatic, but nearly so. Typing a bunch of cc commands is, I think, OK; as is ./configure or maybe even editing a .h file to set defines.

Also, please remember arguing against automatic translation is very much a two-edged sword: If the corresponding source doesn't have to be automatically translatable to the object or executable form, then the corresponding source requirement becomes much weaker. Beware creating that loophole.


I think it's silly to say that translation to assembly is any
different than translation to C, Pascal, Fortran, COBOL, BASIC,
Intercal, etc., from a legal standpoint: If it's just an automated
translation, it's clearly "object" form under the GPL, and the
preferred form is still the original. If it's a largely manual
translation, it's now the preferred form, object or not.

It seems to me that if you are right, then there is no way to enforce
the GPL: because then someone could simply modify the object file in
some interesting and useful way (say, to change a string constant,
usually pretty easy), and then claim that the C code isn't source at
all, and thus need not be distributed.

No. Not at all! Changing a string constant is nowhere near the kind of change I'd demand for considering the object file source. That's clearly just an attempt to subvert the license, and I think any reasonable person would see through that.

Note how I speak of a "largely manual translation" above. That means that if we went through the exercise of of extracting all the copyrightable elements from both the C and the assembly versions, there would be significant, protectable differences, probably so much so that it'd be unreasonable to attempt to modify the assembly version through the C version.



Reply to: