gnustep-dev
[Top][All Lists]
Advanced

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

Re: Fwd: GPLv2 licensing issues


From: Hubert Chathi
Subject: Re: Fwd: GPLv2 licensing issues
Date: Thu, 10 Apr 2008 19:48:13 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

On Thu, 10 Apr 2008 18:12:17 -0500, "Stefan Bidigaray" <address@hidden> said:

> I think another good FAQ question to look at is: " *Can I release a
> program under the GPL which I developed using non-free tools?*

[...]

> However, if you link non-free libraries with the source code, that
> would be an issue you need to deal with. It does not preclude
> releasing the source code under the GPL, but if the libraries don't
> fit under the "system library" exception, you should affix an explicit
> notice giving permission to link your program with them. The FSF can
> give you advice on doing this.  "

Yes, I mentioned the possibility of adding an exception to the
applications' license in my original message.

> This one is also interesting: " *If I port my program to GNU/Linux,
> does that mean I have to release it as Free Software under the GPL or
> some other Free Software license?*

> In general, the answer is no—this is not a legal requirement. In
> specific, the answer depends on which libraries you want to use and
> what their licenses are. Most system libraries either use the GNU
> Lesser GPL<http://www.gnu.org/copyleft/lesser.html>, or use the GNU
> GPL plus an exception permitting linking the library with
> anything. These libraries can be used in non-free programs; but in the
> case of the Lesser GPL, it does have some requirements you must
> follow.  "

> Note how it says if the "library" has an exception, you're in the
> clear.  libobjc has that exception as Matt Rice pointed out.

That is an issue of the application's license being compatible with the
library's license, whereas the issue that I brought up is a question of
the library's license not being compatible with the application's
license.  There are two different compatibilities that need to be
satisfied.

> That said, this whole conversation is a little moot.  If the GPLv2 was
> this restrictive KDE, for example, would have never happened.  QT was
> originally licensed under a non-free license, obvious incompatible
> with the GPLv2 on which KDE used.  There are millions of other
> examples where this type of thing happens.

Mostly because people just covered their eyes and assumed that there was
nothing wrong.  However, KDE was kept out of Debian, for example, for a
long time because of this very issue.

> I still don't see the problem Hubert is seeing.  The GPL and LGPL
> where written exactly for this purpose.

The LGPLv2 was written to be compatible with the GPLv2, and the LGPLv3
was written to be compatible with the GPLv3.  However, the LGPLv3 is not
compatible with the GPLv2, which is even mentioned on the FSF's web page
which I referenced in my original mail.  (And the GPLv3 is not
compatible with the GPLv2, so you can't mix GPLv3 and GPLv2 code
together.)

> Heck, the FSF linking against non-free libraries when they first start
> releasing code, and they specifically made sure not to make GPL
> software able to link only against LGPL libraries.

Yes, the GPL has specific exceptions for linking against "major
components of the operating system" (as the GPLv2 calls it, and "System
Libraries" as the GPLv3 calls it).  In my reply to Nicola, I explain
that the GNUstep libraries may not fall under that exclusion, and even
so, if a program is licensed under the GPLv2, may still be prevented
from being distributed along with the GNUstep libraries.

Hubert
-- who finds it very ironic that proprietary programs have less legal
problems linking against LGPLv3 libraries than GPLv2 programs do




reply via email to

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