Re: Re-Releasing PEAR packages under the BSD license

On 12/14/06, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

Justin Patrin wrote: On 12/14/06, Sylvain Beucler <beuc@beuc.net> wrote:

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 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.

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.

Would someone in the PEAR group or that helped to choose the PHP License as an ok license care to weigh in on this? If this, indeed, true, then we should probably remove the PHP License as an ok license and have any package that is PHP Licensed re-licensed with something else. It all comes down to semantics of what linking means. The PHP license is pretty much identical to the Apache license and you could indeed make a case for not allowing any GPL'ed software to be "linked to" from Apache either. See http://www.apache.org/licenses/LICENSE-1.1 The PHP license was chosen to match the Apache license because Apache and PHP are tied so closely to each other. This hair splitting over linking, derivation and aggregation has been going on since the beginning of time. My stance is that you can indeed ship PHP licensed PEAR components on the same cd or in the same tarball as GPL'ed code because I see it as an aggregate work. This changes if you take PEAR code, modify it and copy-paste it directly into your own work. Then it moves from aggregate to derived. But the intent of the PEAR components is to be used in aggregate form. The PHP license allows you to use it in derived form as well, of course, but then you should be choosing a license other than the GPL for the derived work. The FSF has a FAQ on aggregation here: http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation That text is heavily biased towards compiled software and they talk about executables and memory spaces which don't really apply in this case. If you don't consider using a PEAR component as aggregation then it logically follows that you also cannot have Apache call your code so you will have to stipulate that nobody can use your code from Apache. I think this is an extreme interpretation that pretty much nobody out there shares. In short, I don't see an issue here. Move along.

Aha, link vs. aggregate. I guess I was using the wrong or insufficient terminology there. Thanks much. -- Justin Patrin