Re: GPLv2 licensing issues
On 10 Apr 2008, at 18:51, Hubert Chathi wrote: 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 Presumably, distributing binaries linked against earlier, pre-LGPLv3 GNUstep libraries is acceptable too (whether or not anyone likes the idea); I guess the licence change wasn't propagated back through the SCM history to retroactively apply to earlier revisions of GNUstep. Thanks, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
Graham J. Lee wrote: > Presumably, distributing binaries linked against earlier, pre-LGPLv3 GNUstep > libraries is acceptable too (whether or not anyone likes the idea); I guess > the licence change wasn't propagated back through the SCM history to > retroactively apply to earlier revisions of GNUstep. Yes, that's another option, though not a very desirable one. Even if the license change was propagated back, earlier versions of GNUstep were already released under LGPLv2.1, and so the old license can still be used. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Thu, 10 Apr 2008 21:16:16 +0200 Fred Kiefer <[EMAIL PROTECTED]> wrote: > 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. I believe that the FSF doesn't draw any distinction between static and dynamic linking. And I think that's probably the best way to treat the matter; otherwise, you have a fairly trivial workaround to link proprietary software against GPLed software. > 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. I don't know if the exact method of linking does (or should) matter. -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: GPLv2 licensing issues
> 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. From http://www.gnu.org/licenses/gpl-faq.html: > I'm writing a Windows application with Microsoft Visual C++ (or Visual Basic) > and I will be releasing it under the GPL. Is dynamically linking my program > with the Visual C++ (or Visual Basic) run-time library permitted under the > GPL? > >The GPL permits this because that run-time library normally accompanies > the compiler or interpreter you are using. The run-time libraries here are > “System Libraries” as GPLv3 defines them, and as such they are not considered > part of the Corresponding Source. GPLv2 has a similar exception in section 3. It seems that GNUstep core falls exactly under the same exceptions; libobjc, gnustep-base and gnustep-gui are the run-time "system libraries" for Objective-C on a GNU system. It's still a good idea to update the GPL/LGPL versions of all software though. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Fri, 11 Apr 2008 00:01:54 +0200 (CEST) "Nicola Pero" <[EMAIL PROTECTED]> wrote: > From http://www.gnu.org/licenses/gpl-faq.html: > > > I'm writing a Windows application with Microsoft Visual C++ (or > > Visual Basic) and I will be releasing it under the GPL. Is > > dynamically linking my program with the Visual C++ (or Visual > > Basic) run-time library permitted under the GPL? > > > >The GPL permits this because that run-time library normally > > accompanies the compiler or interpreter you are using. The run-time > > libraries here are “System Libraries” as GPLv3 defines them, and as > > such they are not considered part of the Corresponding Source. > > GPLv2 has a similar exception in section 3. > > It seems that GNUstep core falls exactly under the same exceptions; > libobjc, gnustep-base and gnustep-gui are the run-time "system > libraries" for Objective-C on a GNU system. That's true, except that: - libobjc, gnustep-base, gnustep-gui, etc. are not always "system libraries" (the GPLv2 uses different terminology, and is less well defined), if it is distributed separately from the system. So, for example, it would prevent someone from keeping a, say, Slackware repository of just the GNUstep libraries plus, say PopplerKit. - the GPLv2's version of that clause is a bit fuzzy, because it has a funny clause that says that the clause doesn't apply if "that component itself accompanies the executable". That is, the most straightforward interpretation of that means that, even if that clause applied, you could not distribute the GNUstep libraries *together with*, say, EdenMath. You could distribute them separately, but not together in, say, a LiveCD. Or Debian. -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
Hubert Chathi wrote: 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. [...] 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: [...] - terminal.app If the GPL2/LGPL3 problems are real, this is problematic for Terminal. The vt100 parsing code is based on the terminal/console handling from the linux kernel and is, for all practical purposes, impossible to relicense. - Alexander Malmberg ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Fri, 11 Apr 2008 01:13:32 +0200, Alexander Malmberg <[EMAIL PROTECTED]> said: > Hubert Chathi wrote: >> 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. > [...] >> 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: > [...] >> - terminal.app > If the GPL2/LGPL3 problems are real, this is problematic for > Terminal. The vt100 parsing code is based on the terminal/console > handling from the linux kernel and is, for all practical purposes, > impossible to relicense. Crap. I was hoping that poppler/xpdf was the only truly problemmatic case. Would it be feasible to steal code from xterm instead? There's also iTerm that the Étoilé people have started work porting, which is licensed under GPLv2 or later. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Thu, 10 Apr 2008 19:11:22 -0400, Hubert Chathi <[EMAIL PROTECTED]> said: > On Fri, 11 Apr 2008 01:13:32 +0200, Alexander Malmberg > <[EMAIL PROTECTED]> said: >> Hubert Chathi wrote: >>> - terminal.app >> If the GPL2/LGPL3 problems are real, this is problematic for >> Terminal. The vt100 parsing code is based on the terminal/console >> handling from the linux kernel and is, for all practical purposes, >> impossible to relicense. > Crap. I was hoping that poppler/xpdf was the only truly problemmatic > case. Would it be feasible to steal code from xterm instead? There's > also iTerm that the Étoilé people have started work porting, which is > licensed under GPLv2 or later. I also found rote, which is a terminal emulation library licensed under the LGPL: http://rote.sourceforge.net/ I don't know how good it is, but it may be worth looking into. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
Hmm... I just got to this portion of the FAQ: http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility And it seems that if you have a LGPLv3 library you cannot like a GPLv2 only program to it. I guess I'm more confused now. I've always had the understanding that GPL software can be dynamically linked against software under any license, however this goes against that understanding. This seems like something that needs to be escalated to the FSF for clarification... unless there's a lawyer in our midst! Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Thu, 10 Apr 2008 18:41:20 -0500 "Stefan Bidigaray" <[EMAIL PROTECTED]> wrote: > Hmm... I just got to this portion of the FAQ: > http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility Ah, thanks. That's a very helpful table. > And it seems that if you have a LGPLv3 library you cannot like a > GPLv2 only program to it. I guess I'm more confused now. I've > always had the understanding that GPL software can be dynamically > linked against software under any license, however this goes against > that understanding. No, GPLed software can be linked against libraries whose license is compatible with the GPL, since the GPL requires that the combined work be distributable under the terms of the GPL. In particular, this means that the license of any software that the application links against cannot have any more requirements other than what is included in the GPL. However the LGPLv3 has additional requirements above what the GPLv2 has (e.g. the anti-DRM stuff). That causes the LGPLv3 to be incompatible with the GPLv2. (There are other licenses that are incompatible with the GPLv2, such as the Apache license.) -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
I think we aren't going to get anywhere this way! I mentioned it on a previous e-mail, the issue needs to be escalated to and clarified by the FSF. They designed the licenses and know more than anyone else what are the restrictions. Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Thu, 10 Apr 2008 21:16:48 -0500 "Stefan Bidigaray" <[EMAIL PROTECTED]> wrote: > I think we aren't going to get anywhere this way! I mentioned it on a > previous e-mail, the issue needs to be escalated to and clarified by > the FSF. They designed the licenses and know more than anyone else > what are the restrictions. I'm not sure what needs to be clarified. The compatibility table in the GPL FAQ, written by the FSF, says that you can't link a GPLv2'd application against a LGPLv3'd library, which is exactly the case we have. It seems that the FSF has already clarified the issue for us. -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
Thanks for raising the issue, and the summary. В Thu, 10 Apr 2008 13:51:08 -0400, Hubert Chathi написа: > or http://price.sourceforge.net/exception.html I am not sure that such an exception is sufficient to eliminate the incompatibility problem -- in fact, I fear that it may not have a legal effect. Riccardo, have you contacted [EMAIL PROTECTED] about this? > - popplerkit links against poppler (based on xpdf) which is GPLv2 The case with poppler is absolutely hopeless, IMHO. The poppler people cannot relicense (even if they want), because poppler was forked off xpdf quite some time ago. Even if the xpdf people relicense, the new license will not apply retroactively to the code base of xpdf at the time the fork happened. This is a major concern also for GNOME (Evince), and it was mentioned on the GTK+ list when they were discussing switching GTK+ and GLib to LGPLv3+. So, until GNU PDF (one of the reasons that this project started is precisely the unavoidable licensing problems with xpdf/poppler) is ready and new applications are (re)written, we'll have to kiss Vindaloo/the PopplerKit stack goodbye. > -- who finds it very ironic that proprietary programs have less legal > problems linking against LGPLv3 libraries than GPLv2 programs do Actually, what is ironic is that after all these years, people still do not understand the copyleft mechanism. Such problems are inevitable if one does the mistake to license a program without "or later". В Thu, 10 Apr 2008 21:16:48 -0500, Stefan Bidigaray написа: > I mentioned it on a previous e-mail, the issue needs to be escalated to > and clarified by the FSF. As Hubert explained, there is nothing to clarify. Linking a GPLv2 only app with a LGPLv3 library doesn't violate the license of the library, but the license of the app. The combined object code must be distributable under GPLv2, which is what GPLv2 requires -- and this is impossible. It will always be impossible, because that's inherently the nature of copyleft. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
В Fri, 11 Apr 2008 09:08:52 +, Yavor Doganov написа: >> I mentioned it on a previous e-mail, the issue needs to be escalated to >> and clarified by the FSF. > > As Hubert explained, there is nothing to clarify. Actually, this particular problem is one of the main reasons why the relicensing of major libraries like GNU Libc and GnuTLS was put on hold (for at least a year, AFAIK) -- to allow a longer period during which people can upgrade smoothly to GPLv3 and LGPLv3. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
Hi! On 11.04.2008, at 01:48, Hubert Chathi wrote: Yes, I mentioned the possibility of adding an exception to the applications' license in my original message. Why can't the GNUstep framework add the exception similar to the one in libobjc, so that applications can all link to it? I don't see the conceptual difference between a runtime library like libobjc and such a fundamental framework like GNUstep... It's good that you started that discussion on the GNUstep list. :-) Best regards, Günther ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Thu, Apr 10, 2008 at 9:28 PM, Hubert Chathi <[EMAIL PROTECTED]> wrote: > I'm not sure what needs to be clarified. The compatibility table in > the GPL FAQ, written by the FSF, says that you can't link a GPLv2'd > application against a LGPLv3'd library, which is exactly the case we > have. It seems that the FSF has already clarified the issue for us. When I mentioned that I guess I should have been a little more clear. GNUstep needs to find what the way forward is! Is an exception to the LGPLv3 the correct solution? Is it even possible? Will it help? Etc... At this point the problem has been identified, and there's actually been an example of why some libraries have not yet moved to version 3 of the (L)GPL. Now the question is, what are we going to do? Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
Hubert Chathi wrote: On Thu, 10 Apr 2008 21:16:48 -0500 "Stefan Bidigaray" <[EMAIL PROTECTED]> wrote: I think we aren't going to get anywhere this way! I mentioned it on a previous e-mail, the issue needs to be escalated to and clarified by the FSF. They designed the licenses and know more than anyone else what are the restrictions. I'm not sure what needs to be clarified. The compatibility table in the GPL FAQ, written by the FSF, says that you can't link a GPLv2'd application against a LGPLv3'd library, which is exactly the case we have. It seems that the FSF has already clarified the issue for us. Yes, you are right this table Stefan send a link to (http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility) makes it quite clear. Our case it the one in the bottom left corner. We either need to get all the applications to upgrade their license or find a clause to be put into the GNUstep libraries to give a special exception when linked with GPLv2 applications. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
Günther Noack wrote: Why can't the GNUstep framework add the exception similar to the one in libobjc, so that applications can all link to it? Isn't "LGPLv3 or later + exception" kind-of the same thing as "LGPLv2 or later"? If so, why change in the first place? - Alexander Malmberg ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Fri, 11 Apr 2008 09:08:52 + (UTC), Yavor Doganov <[EMAIL PROTECTED]> said: > Thanks for raising the issue, and the summary. В Thu, 10 Apr 2008 > 13:51:08 -0400, Hubert Chathi написа: >> or http://price.sourceforge.net/exception.html > I am not sure that such an exception is sufficient to eliminate the > incompatibility problem -- in fact, I fear that it may not have a > legal effect. Riccardo, have you contacted [EMAIL PROTECTED] about > this? What problems do you see with it? The text is more-or-less copied from the http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface (minus explanatory preamble and postamble). -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
All, I've written Brett Smith at the FSF to ask about exceptions or any possible solutions to the issues we're discussing. I will post relevant points when he replies to my email. Thanks, GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Hubert Chathi <[EMAIL PROTECTED]> To: gnustep-dev@gnu.org Sent: Friday, April 11, 2008 6:42:15 PM Subject: Re: GPLv2 licensing issues On Fri, 11 Apr 2008 09:08:52 + (UTC), Yavor Doganov <[EMAIL PROTECTED]> said: > Thanks for raising the issue, and the summary. В Thu, 10 Apr 2008 > 13:51:08 -0400, Hubert Chathi написа: >> or http://price.sourceforge.net/exception.html > I am not sure that such an exception is sufficient to eliminate the > incompatibility problem -- in fact, I fear that it may not have a > legal effect. Riccardo, have you contacted [EMAIL PROTECTED] about > this? What problems do you see with it? The text is more-or-less copied from the http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface (minus explanatory preamble and postamble). -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
Here is the email I sent... Brett, We're having some issues after the move to LGPLv3. Specifically there are some applications which are GPLv2 only. Wouldit be possible to get an exception for GNUstep which would allow this. Alternatively, would it be possible for GNUstep to be considered a"System Library" so that the exception for that applies.I amstarting to wonder to myself if we didn't move too hastily when movingGNUstep to GPL v3 of the license. Currently this is being discussed at length on the GNUstep-discusslist which is hosted by the FSF. Please make any comments you feelrelevant there if you can. I would like to discuss exceptionsthat we can consider or any other possible solutions. My cell phoneis (240)274-9630 and my home phone is (301)362-9640. We might consider the following, if possible: /* As a special exception, if you link this library with files compiled with GCC to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. */ This was taken from libobjc. Please let me know. Later, GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Gregory John Casamento <[EMAIL PROTECTED]> To: Hubert Chathi <[EMAIL PROTECTED]>; gnustep-dev@gnu.org Sent: Friday, April 11, 2008 7:14:57 PM Subject: Re: GPLv2 licensing issues All, I've written Brett Smith at the FSF to ask about exceptions or any possible solutions to the issues we're discussing. I will post relevant points when he replies to my email. Thanks, GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Hubert Chathi <[EMAIL PROTECTED]> To: gnustep-dev@gnu.org Sent: Friday, April 11, 2008 6:42:15 PM Subject: Re: GPLv2 licensing issues On Fri, 11 Apr 2008 09:08:52 + (UTC), Yavor Doganov <[EMAIL PROTECTED]> said: > Thanks for raising the issue, and the summary. В Thu, 10 Apr 2008 > 13:51:08 -0400, Hubert Chathi написа: >> or http://price.sourceforge.net/exception.html > I am not sure that such an exception is sufficient to eliminate the > incompatibility problem -- in fact, I fear that it may not have a > legal effect. Riccardo, have you contacted [EMAIL PROTECTED] about > this? What problems do you see with it? The text is more-or-less copied from the http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface (minus explanatory preamble and postamble). -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On 12 Apr 2008, at 01:10, Gregory John Casamento wrote: Here is the email I sent... Brett, We're having some issues after the move to LGPLv3. Specifically there are some applications which are GPLv2 only. Wouldit be possible to get an exception for GNUstep which would allow this. Alternatively, would it be possible for GNUstep to be considered a"System Library" so that the exception for that applies.I amstarting to wonder to myself if we didn't move too hastily when movingGNUstep to GPL v3 of the license. Currently this is being discussed at length on the GNUstep- discusslist which is hosted by the FSF. Please make any comments you feelrelevant there if you can. I would like to discuss exceptionsthat we can consider or any other possible solutions. My cell phoneis (240)274-9630 and my home phone is (301)362-9640. We might consider the following, if possible: /* As a special exception, if you link this library with files compiled with GCC to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. */ That doesn't really look like a good exception for us. After all, if we want to give that sort of exception, why are we using LGL 3 at all? Presumably we *want* to include the new clauses designed for DRM freedom. That rather seemed to be a major point of moving to LGPL3. There should be some sort of cost-benefit analysis of the various options... For instance, if we just stick to the LGPL3 then a few apps will be unable to be distributed with new versions of the GNUstep libraries ... but how many apps are we talking about, and how big an issue is if if that happens? If those few apps are actually critical to us, why not have an exception for just those specific apps? (maybe only for a limited length of time to allow them to move beyond GPL2, or maybe an indefinite length of time if we think they can never move forward). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
Hubert Chathi wrote: Crap. I was hoping that poppler/xpdf was the only truly problemmatic case. Would it be feasible to steal code from xterm instead? There's also iTerm that the Étoilé people have started work porting, which is licensed under GPLv2 or later. I also found rote, which is a terminal emulation library licensed under the LGPL: http://rote.sourceforge.net/ Possible? Certainly. The terminal emulation is somewhat factored out already, so all you need to do is implement the TerminalParser protocol (with some practical caveats). However, I'm not at all happy about the idea of replacing the current linux kernel based terminal emulation code. When I started writing Terminal.app, I looked around a bit to decide whether to write my own terminal emulation, or borrow from some other project. I found that all the terminal emulators I tested (xterm, xiterm, rvxt, gnome's, kde's, etc.) failed at one point or the other (i.e. they'd mess up handling complex curses applications, with screen corruption or incorrect rendering or whatever as a result). The one "terminal" that never gave me any trouble was the linux console, so I swiped the terminal emulation code from that. It's been nearly six years since then, and I think experience has shown that that was a very good idea. The terminal emulation part of Terminal.app has worked flawlessly. In fact, I can't recall ever finding or receiving a report about any problem related to that part of Terminal.app, ever. I daresay that it's rare for anything software related to work that well. Replacing that code (for non-technical reasons, even!) is not tempting at all. - Alexander Malmberg ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Fri, 11 Apr 2008 18:31:44 +0200, Fred Kiefer <[EMAIL PROTECTED]> said: > Yes, you are right this table Stefan send a link to > (http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility) makes it > quite clear. Our case it the one in the bottom left corner. We either > need to get all the applications to upgrade their license or find a > clause to be put into the GNUstep libraries to give a special > exception when linked with GPLv2 applications. Just a thought that came to me, that I thought I'd throw out: one possibility is to dual-license the GNUstep libraries under bath GPLv2 and LGPLv3 or later. This would allow us to keep GPLv2 applications (the two big ones that I know of that we would have trouble relicensing are Terminal.app (due to the Linux terminal emulation code) and PopplerKit (due to the xpdf code)), while keeping the anti-DRM clauses of the version 3 licenses for proprietary applications. -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
В Fri, 11 Apr 2008 18:42:15 -0400, Hubert Chathi написа: > On Fri, 11 Apr 2008 09:08:52 + (UTC), Yavor Doganov <[EMAIL PROTECTED]> >>> or http://price.sourceforge.net/exception.html > > What problems do you see with it? IMVHO such an exception *might* fix one side of the problem, but the resulting combined work still violates LGPLv3, which in turn is GPLv3 with additional permissions. Typically, exceptions like this one (or the most famous "OpenSSL exception") only work in cases when the requirement of the other license is and can be fulfilled in the combined work. It is impossible to do this simultaneously for our case, when: 1) App's license says you must do foo 2) Lib's license says you must do bar These are two contradicting requirements. So the only way for a GPL'ed program to link with an LGPLv3'ed library is to apply the terms of the GPLv3, which is possible when the App's license is: 1) GPLv2 or later 2) Dual license GPLv2 and GPLv3 (I think Qt does this) 3) GPLv3 (or later) In all these cases, the combination falls under GPLv3. Of course, I'm eager to know what the licensing folks will say. (Also, I think that it's out of the question to consider GNUstep as "system libraries" -- according to Brett openssl is not a system library, and I don't think that anyone will argue that openssl is much much closer to being a system library than the GNUstep libs are.) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Mon, Apr 14, 2008 at 7:07 AM, Yavor Doganov <[EMAIL PROTECTED]> wrote: > В Fri, 11 Apr 2008 18:42:15 -0400, Hubert Chathi написа: > > > On Fri, 11 Apr 2008 09:08:52 + (UTC), Yavor Doganov <[EMAIL PROTECTED]> > > >>> or http://price.sourceforge.net/exception.html > > > > > What problems do you see with it? > > IMVHO such an exception *might* fix one side of the problem, but the > resulting combined work still violates LGPLv3, which in turn is GPLv3 > with additional permissions. > YAVHO but I thoght that the (l)gplv2 conflicted with the (l)gplv3 and not the other way around due to the no additional requirements portion of the (l)gplv2 and the additional requirements of the (l)gplv3 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
В Mon, 14 Apr 2008 07:41:36 -0700, Matt Rice написа: > but I thoght that the (l)gplv2 conflicted with the (l)gplv3 and not the > other way around I don't think so: , http://www.gnu.org/licenses/license-list.html | GNU General Public License (GPL) version 2 | | Please note that GPLv2 is, by itself, not compatible with GPLv3. | However, most software released under GPLv2 allows you to use the | terms of later versions of the GPL as well. When this is the case, | you can use the code under GPLv3 to make the desired combination. | | | GNU Lesser General Public License (LGPL) version 3 | | This is the latest version of the LGPL: a free software license, but | not a strong copyleft license, because it permits linking with | non-free modules. It is compatible with GPLv3. We recommend it for | special circumstances only. | | Please note that LGPLv3 is not compatible with GPLv2 by itself. | However, most software released under GPLv2 allows you to use the | terms of later versions of the GPL as well. When this is the case, | you can use the code under GPLv3 to make the desired combination. ` See also http://www.gnu.org/licenses/rms-why-gplv3.html, specifically the third paragraph. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Mon, 14 Apr 2008 14:07:16 + (UTC), Yavor Doganov <[EMAIL PROTECTED]> said: > В Fri, 11 Apr 2008 18:42:15 -0400, Hubert Chathi написа: >> On Fri, 11 Apr 2008 09:08:52 + (UTC), Yavor Doganov >> <[EMAIL PROTECTED]> or http://price.sourceforge.net/exception.html >> >> What problems do you see with it? > IMVHO such an exception *might* fix one side of the problem, but the > resulting combined work still violates LGPLv3, which in turn is GPLv3 > with additional permissions. I don't think that the combined work still violations LGPLv3, because section 4 of the LGPLv3 allows you to release the combined works under any license that you choose, provided that you do certain things, and the library itself can still be distributed under the LGPLv3. The exception allows the library to be distributed under the LGPLv3, so it should be fine AFAICT. [...] > (Also, I think that it's out of the question to consider GNUstep as > "system libraries" -- according to Brett openssl is not a system > library, and I don't think that anyone will argue that openssl is much > much closer to being a system library than the GNUstep libs are.) Agreed. (Actually, the OpenSSL people seem to think that OpenSSL should be considered a system library, as that's what they say in their FAQ. But it's definitely an issue that's not entirely clear.) -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
В Mon, 14 Apr 2008 14:32:43 -0400, Hubert Chathi написа: > I don't think that the combined work still violations LGPLv3, because > section 4 of the LGPLv3 allows you to release the combined works under > any license that you choose, provided that you do certain things, and > the library itself can still be distributed under the LGPLv3. The > exception allows the library to be distributed under the LGPLv3, so it > should be fine AFAICT. I believe that GPL'ed applications linking with LGPL'ed libraries actually use the libraries under GPL (using the direct upgrade clause, which is basically what makes LGPL fully compatible with GPL). That is why it is possible to link a GPLv3 program with LGPLv2.1 library, because GPLv3 is one of the upgrade options of LGPLv2.1, and not because the GPLv3 program must follow section 6 of LGPLv2.1. The reverse (our case) is not possible, since LGPLv3 talks about installation instructions and other things which are not present in GPLv2. It might be possible to allow such combination with exceptions both for the app's and the library's license, but it won't help at all for Terminal and PopplerKit. Also, such an exception to GNUstep is likely to wipe out the benefits of LGPLv3 and render the license upgrade more or less moot. OTOH, if the copyright holders of the GPLv2-only apps are available to relicense their apps to "GPLv2 only plus (IMVHO rather dubious) exception", they may as well just upgrade the license. The problem we have is for apps that cannot be relicensed, and no gymnastics with GNUstep's license is likely to solve that, except downgrading to LGPLv2.1. (Little bit off-topic: When Emacs was about to be upgraded to GPLv3, RMS asked to check all libraries it links against. The compatibility matrix was not published (I think) back then, and this compatibility matter was even fuzzier. There was a concern about cairo, which was under LGPLv2 only [1], but newer versions are under LGPLv2.1 only (later it was found out that there is no problem with LGPLv2 as well). Notice [2] which clearly shows which criterion applies when considering whether the result of the combination is distributable. [1] http://article.gmane.org/gmane.emacs.devel/74038 [2] http://article.gmane.org/gmane.emacs.devel/74065 ) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
В Sun, 13 Apr 2008 21:30:52 -0400, Hubert Chathi написа: > Just a thought that came to me, that I thought I'd throw out: one > possibility is to dual-license the GNUstep libraries under bath GPLv2 > and LGPLv3 or later. This would allow us to keep GPLv2 applications > (the two big ones that I know of that we would have trouble relicensing > are Terminal.app (due to the Linux terminal emulation code) and > PopplerKit (due to the xpdf code)), while keeping the anti-DRM clauses > of the version 3 licenses for proprietary applications. At first sight it appears that this approach should work provided that other dependent libraries remain under compatible licenses (i.e. it won't work if FreeType is upgraded from GPLv2 or later to GPLv3 or later). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Fri, 11 Apr 2008 16:14:57 -0700 (PDT), Gregory John Casamento <[EMAIL PROTECTED]> said: > All, I've written Brett Smith at the FSF to ask about exceptions or > any possible solutions to the issues we're discussing. I will post > relevant points when he replies to my email. Any news on this? Have the developers reached a consensus on what to do with the licensing issues? Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
The FSF has offered to give a temporary exception, but it's tentative at the moment. I will get back with more information soon. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Hubert Chathi <[EMAIL PROTECTED]> To: gnustep-dev@gnu.org Sent: Wednesday, April 30, 2008 6:58:17 PM Subject: Re: GPLv2 licensing issues On Fri, 11 Apr 2008 16:14:57 -0700 (PDT), Gregory John Casamento <[EMAIL PROTECTED]> said: > All, I've written Brett Smith at the FSF to ask about exceptions or > any possible solutions to the issues we're discussing. I will post > relevant points when he replies to my email. Any news on this? Have the developers reached a consensus on what to do with the licensing issues? Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On 30 Apr 2008, at 23:58, Hubert Chathi wrote: On Fri, 11 Apr 2008 16:14:57 -0700 (PDT), Gregory John Casamento <[EMAIL PROTECTED] > said: All, I've written Brett Smith at the FSF to ask about exceptions or any possible solutions to the issues we're discussing. I will post relevant points when he replies to my email. Any news on this? Have the developers reached a consensus on what to do with the licensing issues? On a related note, was any progress made in getting a broader exemption on the GNU libobjc license? As of last night, I have clang/ llvm compiling simple Objective-C programs targeting the GNU Objective- C runtime, but the GPL exemption only applies to programs compiled with GCC and so any code compiled in this way is GPL'd, which is something I definitely do not want for my own code. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
