Derivative/collective works and OSL

[Michael Poole]

John Cowan writes:

> Then if a tarball with multiple authors is a collective work, and if compiling
> source code to object code produces a copy rather than a derivative work,
> then the compiled executable is also a collective work by virtue of being a
> copy of a collective work.

At least in the US, a collective work requires that the components be
"separate and independent works in themselves."  If you ship an
executable that can only run when some library is present, it is
probably not an independent work.

> And if that is so, then the assumption of the GPL's authors that compiling and
> linking GPLed and non-GPLed code produces a work that can only be distributed
> under the GPL is flat wrong, for the executable is not "a work based on the
> Program" (derivative work) but is a "mere aggregation" (collective work).
> All die.  Oh, the embarrassment.

This is also not necessarily true.  Most dynamically linked libraries
are incorporated by reference in the application that uses them.  If
the only way to satisfiy that reference is by using a GPLed library,
or if you distribute it with a GPLed library[1], then the combination
is perhaps a compilation but not a collective work (as those terms are
defined in 17 USC 101).

[1]- Unless it is trivial to replace the GPLed library with a less
restrictively licensed implementation of the same ABI.

Michael Poole