Re: license question?

From: Chris Smith (cdsmith_at_twu.net)
Date: 10/14/04 

Date: Thu, 14 Oct 2004 09:41:04 -0600

xarax wrote:
> > You can include a LGPL library in your commercial prduct, and still
> > distribute
> > it closed-source, as long as you keep the library itself open. You can not
> > include any full GPL product in an application that is not itself full GPL
>
> But be VERY CERTAIN that your usage of the LGPL library
> is only via dynamic calls. Static linking will contaminate
> your product and make it also LGPL.
>
> GNU licenses (all variants) are extremely viral; attempting
> to convert your hard work into effectively public domain.

I can only speak to the traditional interpretation since I am not a
lawyer. Courts may always interpret things differently. However, the
way these licenses were initially supposed to work is a bit different
from what you say. Specifically, your comments about the LGPL actually
apply to the GPL, and the LGPL is more permissive.

The problem with linking in the GPL is that parts of the library are
actually included into the resulting binary by the compiler or linker.
In traditional C environments, the concern is mainly about stuff defined
in header files and about function names from the library, as well as
the code itself in case of static linking. In Java (since this was
posted to comp.lang.java.programmer) the concern could be raised with
regard to identifier names being taken from the library, and also the
inclusion of constant values from public compile-time constant fields of
library classes. Because it's unclear whether this causes the
application to become a derived work, the LGPL was introduced
specifically to disclaim any responsibility on your part of complying
with GPL terms for application code merely because of linking and header
files.

Arguably, even a GPL library allows certain forms of dynamic linking
from a non-GPL work. These days, though the intent of the author is
pretty clear when that author chooses to use the GPL for a library, and
it's at best exploitation to disrespect those wishes, and at worst a
violation of the license. It's interesting to note that about ten years
ago, that wasn't the case, and the general consensus among free software
developers was still that linking did not cause an application to become
a derived work; the LGPL was introduced only to make people more
comfortable using a library. That has changed not because of a change
in the text of the license, but because the surrounding politics are
different... now we have MySQL, Eric Raymond, and a surrounding crowd of
people who want to believe that the GPL allows them certain openings for
profit, and their wishes have changed the consensus opinion. It's up to
courts and lawyers whether the old or new view is correct.

Some unfortunate gray areas still arise, though, even when you try to
respect an author's wishes. One example: I've discussed, with MySQL and
an attorney, what would happen if an application -- written using the
generic JDBC API -- were to end up deployed with MySQL's GPLed JDBC
drivers. MySQL chose to leave me with the impression that they would
sue anyone writing JDBC code if their profits looked short some quarter
(almost reminds me of DirectTV); but the attorney was fairly certain
that a product can't become a derivative work because of the way it's
used by an end-user. Again, it's up to you to make an interpretation
with the help of an attorney.

> I would suggest looking at other license models that
> are less socialistic in nature.

Not necessarily. Play it safe, certainly, and don't push the license to
the extremes, but an LGPL library specifically allows the use that's
wanted here. It's probably pretty safe to use it that way. After all,
it takes an upset author to sue over use of code. 

-- 
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Relevant Pages

  • Re: license question?
    ... Under the circumstances I tend to avoid even LGPL ... -the users of my libraries will see it the same way. ... then someone would try to exploit the code under the license ... But static linking doesn't comtaminate anything. ...
    (comp.lang.java.programmer)
  • Re: license question?
    ... Under the circumstances I tend to avoid even LGPL ... -the users of my libraries will see it the same way. ... then someone would try to exploit the code under the license ... But static linking doesn't comtaminate anything. ...
    (comp.os.linux.misc)
  • Re: GPL encumbrance problems
    ... It doesn't matter *which* of GPL, ... This is the LGPL dynamically linked case: ... static linking. ... In the case of dynamic linking, it ...
    (Fedora)
  • Re: Smalltalk and the GPL
    ... Smalltalk code into an image would constitute "linking" in the GPL ... IANAL, but I know the GPL and LGPL pretty well (especially v2, I still ... However, note that the GPL/LGPL are distribution licenses, and so they ...
    (comp.lang.smalltalk)
  • Re: license question?
    ... >> You can include a LGPL library in your commercial prduct, ... >> include any full GPL product in an application that is not itself full GPL ... The problem with linking in the GPL is that parts of the library are ... violation of the license. ...
    (comp.os.linux.misc)