Re: PHPNuke license
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
>> 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
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.