Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] GPL and code linkages



The usual IANAL applies... But I've grown to dislike that disclaimer
because even a lawyer can't definitively answer your question.  It
takes a judge (or possibly even a jury) in a courtroom, and two
different cases can decide differently based on the same language,
even once such a decision has been made...

On Sun, Dec 30, 2012 at 03:10:21AM -0500, MBR wrote:
> In traditional compiled code, linking object files together to form
> a single executable made them part of the same work, and if any
> object file was compiled from GPL'd source, then the source for all
> objects had to be under GPL-compatible licenses.  

Not exactly.  The GPL covers the use of source code distributed under
it, as well as derivative works.  The GPLv2 defines what a derivative
work is (as does copyright law):

 The "Program", below, refers to any such program or work, and a "work
 based on the Program" means either the Program or any derivative work
 under copyright law: that is to say, a work containing the Program or
 a portion of it, either verbatim or with modifications and/or
 translated into another language...

A compiled program is a derivative work, for instance.  A theme, or an
independent library which uses none of their code, is not.  The Drupal
people are wrong, and this is the nature of their mistake.  They have
very liberally interpreted what a derived work is, in direct
opposition to what the GPL states.  Recall that in the case of SCO vs.
Novell, it was ruled that using a library's API is not infringing
(i.e. it is not derivative)...  So any independent extension which
uses none of their code other than the names of functions in their API
is not a derivative work.

Then: the GPLv2 does not restrict you from taking two different pieces
of work under different licenses and combining them together for your
own use; it restricts you from DISTRIBUTING such a work under any
license other than the GPL.  Moreover, it contains clauses which
prohibit distribution of a work as a whole which contains pieces with
restrictions which would prevent it from being distributed under the
GPL.  But you can distribute them separately, under their respective
licenses.  The trick here is, what constitutes separate distribution?
It seems clear that statically linking your non-GPL library into your
program and distributing the resulting binary is prohibited.  But what
about a CD which contains the source code for both, but each in a
separate directory that contains their respective licenses?  Such a CD
is very arguably "a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language..."  This is a question you'd likely need a courtroom to
decide.  You're best off avoiding it if possible.

The Debian solution to this problem generally is to not provide the
actual object, but instead to provide a program which will fetch it
from its canonical distribution point, and then do whatever is
required with it (e.g. the nvidia driver, where they will fetch the
module and modprobe it into your running kernel).  Thus no clause of
the GPL is directly broken (though even then, a lawyer might argue
that this is equivalent to distribution--I expect that lawyer would
not win, but stranger things have happened).

> And how do the answers to these questions change if we're talking
> about GPL3 rather than GPL2?

As far as I can tell, the above is not altered.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org