On Thu, Mar 06, 2003 at 05:27:54PM +1300, Nick Phillips wrote: > > As a result, the output of tr a-z A-Z may be either source code *or* > > object code, *depending on the intent of the party making this change*. > > else that the GPL doesn't permit distribution of. I'm happy to be > > generous and say that it's object code in this case. > I guess we have "source form", "object form" and "encoded or translated form". > The former is suitable for creation and editing, the second for direct use > in the intended function of the work, and the latter for neither -- rather > it is a form which may or may not be useful in any particular way (e.g. > reducing storage requirement), but it does retain the original meaning of > the source form. > Thinking about it a little further, I guess there are two subtypes of encoded > form; reversible and non-reversible. > Distribution of reversible encoded forms should be allowed (e.g. gzipped > tarballs), non-reversible probably not (e.g. obfuscation). You're free to create new classes of works that are neither source nor object if you choose, but if you do, the GPL gives you no rights to distribute them; just as saying that something is not software doesn't make it DFSG-compliant. Think of the case of an autoconf-generated configure script. This certainly fits certain definitions of "obfuscation", but it's also to our advantage to be able to distribute such a script because of its value as a form of "executable object code". The same applies to automake-generated Makefile.in files, despite the fact that these are not directly executable but rather represent a human-readable intermediary state. I think it's to our advantage to identify all GPL-covered works as either source or object, given the GPL's own definitions of these terms. -- Steve Langasek postmodern programmer
Attachment:
pgpOoBeJETCQd.pgp
Description: PGP signature