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

[Chuck Swiger]

On Dec 3, 2007, at 12:33 PM, Chris Travers wrote:
> On Dec 3, 2007 12:09 PM, Chuck Swiger <chuck at codefab.com> wrote:
[ ...about GPL clause 2... ]
>> 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.

By all means-- it's an important point, and worth coming to a broad  
consensus including the perspective of the FSF if we can.

[ I find myself a bit skeptical of this hope, as prior attempts to  
discuss this with Eben Moglen or Brett Smith have not been especially  
productive, but YMMV, and Zak Greant has certainly been working hard  
to help both the FSF and OSI licensing groups. ]

> 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).

Yes, although it would have been NeXT and not Apple.

In that case, the Obj-C extensions involved a bunch of code changes to  
the GCC sources such as the precompiler and the addition of the Obj-C  
runtime library, and I think it was clear that these changes could not  
be separated out from GCC.  I believe that NeXT was fairly obliged by  
the GPL to release their changes in that case. [1]

[ ... ]
> 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).

For dynamic linking, I would agree.  Obviously, if you statically link  
in a library, the resulting binary is a derivative work of that library.

> 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.

If your references are just that, and one does not include content  
from these references in the article, then your article is clear not a  
derived work.  On the other hand, if you quote an entire paragraph or  
two from other papers, that's probably significant enough to qualify  
or at least require a more detailed analysis.

> 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).

Interesting!  I think I like this example, although the interaction of  
function calls is more significant and more creative than just a plain  
reference, because you exchange data-- possibly including complex  
structures defined in common header files.

> 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.


Note that the use of publicly published APIs generally cannot qualify  
as grounds for copyright infringement, under US law, anyway.  It's not  
clear whether the FSF considers the interface to GNU readline to be a  
published API, but the existence of a BSD-licensed readline by Jaromir  
Dolecek for NetBSD is suggestive that it is.

-- 
-Chuck

[1]: #import <std/disclaimer.h>