gnustep-dev
[Top][All Lists]
Advanced

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

Re: GPLv2 licensing issues


From: Fred Kiefer
Subject: Re: GPLv2 licensing issues
Date: Thu, 10 Apr 2008 21:16:16 +0200
User-agent: Thunderbird 2.0.0.12 (X11/20080226)

I am still not sure whether this problem actually exists. As far as I understand the GPL it only transfers to libraries that are statically linked to it. GNUstep base, gui and back (normally) get linked dynamically and to my understanding this should not cause any problem. But I surely am no expert on this matter.

It also may be different for the objc runtime, again not sure how you normally link it in. And of course application linking with GPLv2 libraries will need a detailed inspection.

Fred

Hubert Chathi wrote:
It seems like not many people know about the licensing problem that we
have between GPLv2 and LGPLv3 (I didn't even know the problem existed
until a month ago), so here is a bit of an explanation of the problem:

Briefly, the GPLv2 says (among other things) that if you link against a
library, the complete work has to be redistributable under the terms of
the GPLv2, if you want to redistribute it.  So if application A is
licensed under the GPLv2, and links against library B, then the combined
work A+B must be redistributable under the terms of the GPLv2.  This
means that library B must be licensed under terms that are compatible
with the GPLv2.

Unfortunately, the LGPLv3 is incompatible with the GPLv2 [1] by itself,
since the LGPLv3 adds extra restrictions, which means that if library B
is licensed under the terms of the LGPLv3, then A+B is undistributable.

[1] http://www.gnu.org/licenses/license-list.html#LGPL

Unfortunately again, this is the situation that we have with many
GNUstep programs: Application foo.app is licensed under the GPLv2, and
the GNUstep libraries are licensed under the LGPLv3, which means that
binaries of foo.app cannot be distributed.

Fortunately, many programs that are licensed under the GPLv2 are
licensed with the option of using any later version of the GPL, and so
A+B is distributable binaries under the terms of the GPLv3, since the
LGPLv3 is compatible with GPLv3.

Of course, this does not work if the application is licensed under the
terms of the GPLv2 *only*.  While looking through the licenses for
various Debian packages, I found the following applications that are
licensed under the GPLv2:

- displaycalibrator.app (Gürkan said he would fix this)
- edenmath.app
- gtamsanalyzer.app
- a gworkspace.app links against xpdf, which is GPLv2 only
- popplerkit links against poppler (based on xpdf) which is GPLv2
- price.app (Riccardo has added an exception to allow linking to LGPLv3)
- rssreader.app (Günther indicated he would fix this)
- gshisen.app
- stepbill.app (based on xbill)
- terminal.app
- volumecontrol.app (Gürkan said he would fix this)

If you have a GNUstep program that is licensed under the terms of the
GPLv2 *only*, you should do one of the following (in no particular order):

- change the license to "GPLv2 or later"
- change the license to GPLv3 (or later)
- change the license to something completely different that the LGPLv3
  is compatible with (e.g. MIT, 3-clause BSD)
- add an exception that allows linking with the GNUstep libraries or
  LGPL'ed libraries (e.g. see for example
  http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface
  or http://price.sourceforge.net/exception.html






reply via email to

[Prev in Thread] Current Thread [Next in Thread]