John Goerzen said: > On Wed, Mar 05, 2003 at 12:16:23PM -0500, Branden Robinson wrote: >> > If a court looks at this, and sees "object code", can we really know >> in advance if they would use the normal definition or this "liberal" >> one? I suspect they would use the normal one, which is another >> problem. >> >> What if we had a license like the GPL that used "source form" instead >> of "source code", "transformed form" instead of "object code" and >> "executable form", and "Work" instead of "Program"? > > That would make all the difference, I think. > > Of course, to the people pondering that change, the ramifications of the > more generalized term should be carefully considered.
What sort of transformations are permitted? There are transformations that should be allowed without making the switch from "source" to "object/executable" form. For example, source.c.gz (gzip-compressed source file) It has been transformed, is clearly derived from the (C) C-source file, is not the preferred form for modification, etc. But is considered equivalent to source since most developers can just gunzip it. Could you imagine an author who said you couldn't distribute source.tar.gz, since it's not the "preferred form for modification", but rather the "preferred form of distribution of the preferred form for modification" (see the difference?) > >> > If the license iteself defined object form that way, that'd be one >> thing. (It'd be confusing, but we could evaluate it only one way.) >> > But it doesn't define "object code" at all. >> >> The FSF does provide a hint, by saying "object code or executable >> form" in two places. They probably figured an expert witness or two >> would be able to dispose of the issue should it ever reach court. > > True, but my output of tr is neither object nor executable, so I don't > think it helps with this particular example. Well, since the FDL has taken the term "transparent", how about if we call the output of tr (or gzip or indent) as "translucent forms". These are derived work that can be mechanically derived from the source form, and can be mechanically transformed back to the source form (or near equivalent) This does not cover compiling, since even by disassembling the .o file, you can't get back the comments, short-term variable names (if any variable names), etc. --Joe
