[Pipet Devel] Licensing issues

[J.W. Bizzaro]

In my opinion, we could license all of the parts to Piper under either the GPL
OR LGPL, providing we clarify what is meant by "linked".

GPL vs. LGPL:  As Jean-Marc mentioned, the LGPL ("lesser" or "library" GPL) is
meant to allow closed-source programs to "link" TO LGPL-licensed code.  The
GTK+ and GNOME libraries are both LGPL'd, which means a company like Applix
can use them for Applixware with no legal problems.  (The Qt library, however,
has recently been re-licensed under the GPL, which would force such a company
to use the alternative QPL and pay for it.)

Is Piper a library?  Well, sort of.  I believe applications like BlueBox,
ISYS, and OpenBSA will make use of Piper in such a way.  And, ISYS is
closed-source, which means the GPL might not work for them.  But, the fact
that the use of Piper by ISYS would take place through CORBA, is an issue.  Is
the use of CORBA considered "linking"?  Jean-Marc says no.  If not, GPL vs.
LGPL is irrelevant to us.

Neither the GPL or LGPL provides us with a good definition of "linking".  I
used to find this frustrating, since so much hinges on the definition. 
However, I now think this was intentional, because there is an enormous
continuum of "linking" examples out there.  It should thus be up to the author
to define or clarify what is meant by "linking" and how it applies to their
code.

The LGPL would cover "one end" for us, without having to specify that "CORBA
is not linking": It says that pretty much anything can link TO Piper.  But, we
would nonetheless be left to define what can be linked FROM Piper.  I say we
should put an exception in the license (either GPL or LGPL) for all programs,
etc., that are "linked" as "nodes".  The Linux kernel has the same exception
for device drivers.

Maybe I didn't answer the question that Jean-Marc proposed: GPL or LGPL?  I
just rephrased it :-)  If we all agree that the ONLY uses of Piper would be
via CORBA and nodes, then we should choose the ordinary GPL.

Vote?

Cheers.
Jeff

Jean-Marc Valin wrote:
> 
> With the latest issues/wars (depends on how you see it!) with the KDE/Qt
> licensing, I think it's now time to make sure not to end up with the same mess
> (no matter which side you are, the result is that it has hurt KDE a lot) with
> Piper.
> 
> This is mostly important for the PL (Overflow), because CORBA linking is not
> covered by the (L)GPL. Also, now's the time to change the Overflow (PL) license,
> because all the copyrights are owned by three people: Me, Dominic, and Brad. The
> three need to agree to change the license (should not be too hard!). If we wait
> too long and too many people contribute, it'll be too late (there are hundreds
> of copyright owners in the Linux kernel, changing license is now impossible).
> For now, the license is GPL, since at first, it was not meant to be a used as
> library.
> 
> I think we all agreed (do we?) that the basis sould be around the GPL/LGPL.
> Before I continue, here's my simple explanations on each.
> 
> You may link any software (be it a program or a library, OSS or not) to an LGPL
> library, while to may not link to a GPL library. (this is commonly known).
> 
> You CANNOT link either LGPL or GPL software (library or program) to a library
> that is not GPL-compatible (LGPL, GPL, and BSD are GPL-compatible, while the QPL
> is not). This is the clause that caused so much problem with KDE and that made
> it illegal, since libkdeui (which is LGPL) could not legally be linked to Qt,
> which was not GPL-compatible.
> 
> Now this is what I'd like to discuss:
> 
> 1. Should we allow non GPL-compatible nodes to be used (my opinion is yes)? If
> we want that, we need to provide with an exception to the GPL/LGPL that
> explicitly allows it (like KDE needed to have so it could be linked with Qt).
> The unclear part of this is would we be allowed to use *at the same time*
> non-GPL compatible nodes AND GPL nodes that don't provide the exception.
> 
> 2. (apart from clause 1) Should we release the PL as GPL or LGPL? The LGPL would
> be less restrictive, but would also allow any proprietary Piper-like system to
> use Overflow as it's processing layer. What do you think?
> 
> We'd also have to choose a license for the DL and BL. Right now, the DL has to
> be GPL, since it links with GPL code (libflowui is currently GPL) and it would
> be illegal to release it as LGPL.
> 
> So I hope we can get the situation straight will less pain than KDE.
> 
>         Jean-Marc



-- 
J.W. Bizzaro                                           jeff at bioinformatics.org
Director, Bioinformatics.org: The Open Lab     http://bioinformatics.org/~jeff
"Injustice anywhere is a threat to justice everywhere."
               -- Martin Luther King, Jr.
--