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 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
В 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
В 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
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
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 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
Fwd: GPLv2 licensing issues
doh -- Forwarded message -- From: Matt Rice [EMAIL PROTECTED] Date: Thu, Apr 10, 2008 at 12:35 PM Subject: Re: GPLv2 licensing issues To: Fred Kiefer [EMAIL PROTECTED] On Thu, Apr 10, 2008 at 12:16 PM, 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. http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. 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. libobjc contains an exception /* 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. */ ___ 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: Fwd: GPLv2 licensing issues
On Thu, 10 Apr 2008 12:40:34 -0700, Matt Rice [EMAIL PROTECTED] said: On Thu, Apr 10, 2008 at 12:16 PM, 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. http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. Yup, and the next paragraph: If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fwd: GPLv2 licensing issues
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?* Which programs you used to edit the source code, or to compile it, or study it, or record it, usually makes no difference for issues concerning the licensing of that source code. 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. 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 GPLhttp://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 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. I still don't see the problem Hubert is seeing. The GPL and LGPL where written exactly for this purpose. 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. 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 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: Fwd: GPLv2 licensing issues
On Thu, 10 Apr 2008 18:12:17 -0500, Stefan Bidigaray [EMAIL PROTECTED] 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 GPLhttp://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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
