[Pipet Devel] Licensing issues

Jean-Marc Valin jean-marc.valin at hermes.usherb.ca
Wed Sep 6 21:03:18 EDT 2000

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

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

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 Valin
Universite de Sherbrooke - Genie Electrique
valj01 at gel.usherb.ca

More information about the Pipet-Devel mailing list