Re: Re-Releasing PEAR packages under the BSD license

On Thu, Dec 14, 2006 at 01:05:57PM -0800, Justin Patrin wrote: > On 12/14/06, Sylvain Beucler <beuc@beuc.net> wrote: > >On Thu, Dec 14, 2006 at 12:40:05PM -0800, Justin Patrin wrote: > >> On 12/14/06, Sylvain Beucler <beuc@beuc.net> wrote: > >> >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ºoŒI°Ý‰í¹Oä > >> >…¨¡ > >> > > >> >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ÀÌ > >> >l)VPrÎg»âEÜÁX > >> > > >> >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. > >> > > >> > >> Please see > >> http://pear.php.net/manual/en/faq.licenses.php. If the > >> statements here are false then there is a problem. > > > > > >Hi, > > > >I had read it. I don't see statements related to compatibility with > >the GPL. > > > >There's one false statement: "The only limitation is that the original > >credits must stay in the sources". This is more or less true for mBSD, > >but not for the PHP license which adds other limitations as discussed. > > > > If this is the only false statement then PHP licensed packages should > be linkable from any open or closed source product, as the page says. > > >Can you return the favor and read my statements as well? > > > > I of course read your statements but I think we're working under > different assumptions here. I am assuming that the PHP license allows > linking. You are assuming either that it does not or that the > "compatibility" somehow negates this allowance for linking. The PHP License allows linking, but to link 2 pieces of software, both need to allow linking. To make it short, the GPL doesn't allow linking with incompatible code. Therefore I cannot link PHPL'd and GPL'd code. -- Sylvain