Re: Re-Releasing PEAR packages under the BSD license

From: Date: Thu, 14 Dec 2006 20:32:35 +0000
Subject: Re: Re-Releasing PEAR packages under the BSD license
References: 1 2 3 4 5 6  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-45234@lists.php.net to get a copy of this message
On Thu, Dec 14, 2006 at 11:39:28AM -0800, Justin Patrin wrote: > On 12/14/06, Sylvain Beucler <beuc@beuc.net> wrote: > >On Thu, Dec 14, 2006 at 11:54:48AM +0100, Christian Weiske wrote: > >> Sylvain, > >> > >> > Currently I'm a bit unsure about whether I can or cannot use packages > >> > under the PHP license in my application. > >> > >> You can use the packages without problems in your application, since GPL > >> is more strict than the PHP license is. The other way round would not > >work. > > > >Hi, > > > >I don't think so. > > > >I think both licenses have requirements, but the PHP License > >requirements are not a subset of the requirements of the GPL. This is > >independant to whether the GPL has more or less requirements than the > >PHP License. > > > >This extra requirements of the PHP License are related to the use of > >the name 'PHP'. This is not in the GPL, so licenses are incompatible > >IMHO. > > > > So? I honestly don't see what the problem here is. Just don't use the > name "PHP" in the name of your project. That clause doesn't kick in > and you have no problems. IMO this requirement will nonetheless still apply to the combined work (my proj + pear package). Since I cannot add additional requirements to a GPL'd app, then I'm violating the GPL. I didn't invent that, you can check the links I mentioned - among others this one: http://gplv3.fsf.org/wiki/index.php/PHP_license%2C_version_3.01 > >The modified BSD's requirements are a subset of the GPL, so both > >licenses are compatible. > > > > > >Incompatible means I cannot combine the two kinds of work. > >You can use GPL'd code with (compatible) mBSD'd code - the resulting > >work will be under the GPL, be it in one way or another. > >But you cannot legally combine GPL'd code with incompatible code > >(hence why incompatible licenses are referenced at > > >>http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses). > > > >This link has some more information about it: > >http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible > > > > > >All in all, I don't think I can't legally use HTML_QuickForm in Savane > >:/ > > > > I think you're confusing 2 issues here. The licenses have 2 different > use-cases. > 1) You link/use some code from something in your application. > 2) You modify or directly incorporate some code from something in your > application. > > If you do 2) with incompatible licenses you're SOL. You can't do that. > > However, if you do 1) with "so-called" incompatible licenses you're > ok. For example, all PEAR libraries are licensed with licenses such > that you can "link" them to closed source applications without > licensing your application under the same license. This is exactly > what the LGPL is for and this is why we don't accept GPL or other > licenses than what we have listed. > > Summary: > require_once 'HTML/QuickForm.php'; > is perfectly valid in your application, whatever license you put to > your code, be it GPL, LGPL, PHP, closed/commercial, or OpenSSL. This > constitutes linking another package's code into yours, not modifying > it. I don't think so. When I combine 2 pieces of code, even if I just link them (or include()) them, this is still a derived work, and license compatibility still apply. If I could combine incompatible license just because I don't modify the 'inside' of the code, then I could use a GPL'd library even in proprietary software. The LGPL is specially written to allow such external linking - that would not be necessary if linking were legally possible without explicit permission. Linking = derived version I don't know why the FSF would write an OpenSSL replacement (http://www.gnu.org/software/gnutls/), and why Debian would deem GPL+OpenSSL not legally distributable (http://ftp-master.debian.org/REJECT-FAQ.html) if I could freely link with OpenSSL. This pages explains the problem pretty well: http://www.gnome.org/~markmc/openssl-and-the-gpl.html The series of questions about GPL'd plug-ins offers some explanations on the distinction between linking and fork+exec (which is not affected by license compatibilities): http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins Therefore I cannot use PEAR packages under the PHP license in a GPL'd app because the two licenses are incompatible due to details (not major differences), and currently this prevents me from using these packages. I do think that using the modified BSD instead, which is not hard and changes nothing from PEAR developers' point of view, would make the situation cleaner. I'll add a bit of background about me: I'm doing basic legal checks on a regular basis for a couple years now, for new projects that are submitted at Savannah.gnu.org. Every incoming project is checked for such issues. I think that I had to cope with license incompatibilies often enough to grasp the basics, and I had to discuss with licensing@fsf.org several times to make decisions in corner cases. I'm still not a lawyer, but if I take the time to bug you about it, this means I am pretty sure there's an issue. This was already discussed following such a project submission review: http://www.zend.com/lists/pear-dev/200410/msg00039.html It was acknowledged that there was an issue, and the proposed solution was to add an exception to the GPL'd code - which I can't in this case, because I'm not the copyright holder, and also because that would make my code incompatible with other GPL'd libs (that doesn't come with such an exception). I don't think I'm proposing something radically different than what is currently done, so please take a bit of time to consider it. -- Sylvain

« previous php.pear.dev (#45234) next »