When to evaluate dual licenses (was: license categories, was: I'm not supposed to use the ECL v2?)

[Chris Travers]

On Dec 3, 2007 12:09 PM, Chuck Swiger <chuck at codefab.com> wrote:

>
> ...however, this fails to consider the actual text of GPL(v2) clause
> #2, part of which reads:
>
> "These requirements apply to the modified work as a whole.  If
> identifiable sections of that work are not derived from the Program,
> and can be reasonably considered independent and separate works in
> themselves, then this License, and its terms, do not apply to those
> sections when you distribute them as separate works."
>
> If you distribute a binary which runs just fine by itself as a
> separate work, but which might optionally use a GPL'ed work like GNU
> readline via dynamic linking, then GPL clause 2 says that the terms of
> the GPL do not apply to that binary.


To be fair, I disagree with the FSF's characterizations of when a derivative
work exists.  I just figured that it is worth bringing up their pov.  That
was the reasoning they used to pressure Apple to release their Obj-C
extensions to the GCC (since it never went to court though, we don't know if
any lines were actually crossed by Apple).

>
>
> We've discussed this particular issue before in some detail in a
> thread here:
>
>
> http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12232:200701:eekjfkiiplhjdkoabfid
>
> Quoting myself:
>
> "I've even seen people claim that the only reason why proprietary
> software running on Linux can avoid being "forcibly relicensed under
> the GPL" is because GNU libc is under the LGPL.  They seem to forget
> that the original standard C library was written by Kernighan and
> Richie back around 1971, some twenty years before Roland McGrath
> started writing GNU libc circa 1992.
>
> Just because a program calls printf() does not mean that it becomes a
> derivative work of GNU libc when dynamically linked on a Linux
> platform, any more than that same exact same program source code
> becomes a derivative work of the original C library on a BSD platform,
> of Microsoft's Visual-C++ DLLs when dynamically linked on Windows, and
> so forth for every platform that supports an ANSI-C library."


For that matter, when you use the MySQL ODBC drivers to create a spreadsheet
in Excel pulling data from  a spreadsheet, Excel doesn't suddenly become a
derivative work of MySQL's client libraries.

My own thinking is that linking itself is never sufficient to imply
derivation even if there is a requirement that it use a given version of a
given library.  This would seem to me to be no different than using
out-of-process interfaces (for example, XML-based web service API's).
Consider the following:

An author writes a scientific article regarding element formation in stars.
They include references to other papers, not only as a whole, but to
specific paragraphs with a clear intent that the user goes, obtains, and
reads those other paragraphs as well.  Is that article a derivative of the
referenced sources?  Not by any reading of the statute I can come up with
(but IANAL).  However, this seems roughly analogous to out of process API
usage.

A few years later, a publisher gets the anthology rights to each of the
articles in question and puts them all in a book together.  Now, you just
have to jump forward and back to find your information and not switch
publications.  Is the new paper now a derivative of the older ones?  I still
don't think so.  But this seems to me to be pretty clearly equivalent to
function calls of libraries in process.  Because linkers often remove unused
elements of statically linked libraries, but only do so along purely
functional lines, that doesn't seem to suggest that it is any different in
this case regarding derivative works (because the transformation isn't
creative).

Secondly in terms of questions of expressive nonliteral content, it seems to
me that XML DTD's for web service API's contain a *lot* more expressive
content than linking maps.  However, this is not the FSF view.

Best Wishes,
Chris Travers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20071203/cfeddc5f/attachment.html>