Lawrence Rosen scripsit:
But what is it about the copyright law that leads you to believe that the degree of triviality to wrap a copyrighted work as a black box makes a difference in the definition of a derivative work?
For one thing, if the wrapper is too trivial we won't have sufficient originality to be a derivative work, and the work will just be a copy of the original.
Agreed. For example, Apple has taken the GNU chess program and added a different graphic front-end to make the Chess application run without using X11 under MacOS X. Are Apple's changes to GNU chess original enough to qualify as a derivative work?
I think John is correct: probably not.
Let's be candid about what behavior we want to affect by our reciprocal
licenses. I believe we want to make sure that changes, bug fixes and
enhancements to our software are returned to the commons. But we don't
want to discourage the use of our open source software in combination
with other software, proprietary or open. By distinguishing between
*derivative works* and *collective works* as the copyright law itself
does, we can better achieve this balance.
The sticky point is this:
It's settled that a binary is a derivative work of its source. It's obvious that a source tarball is a mere collective work, or "aggregation" as the GPL calls it.
If you pick a random source file from 100 projects and put them in a tarball, sure, there is no connection between them, that's mere aggregation.
But if you look at the ~100 files which comprise an apache-1.3.xx distribution (to pick a project for the sake of example), there are strong connections between these files in terms of header file dependencies, the presence of a unified build environment resulting from GNU autoconf and the resulting Makefiles, etc.
What, then, is the status of a binary compiled from the tarball? It evidently is a derivative of the collection; is it a derivative of the source works as well?
Larry says (in effect) no; Eben says yes. Infinite are the arguments of mages.
Above you said that "it's settled that a binary is a derivative work of its source".
Putting those sources into a tarball doesn't change the relationship between the source (or sources) and an executable compiled from them, any more than taking a backup of those sources would....
-- -Chuck
-- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
