Fwd: [gnu.org #323948] PHP license compatibility with GPL

I finally got a response from gnu.org about PHP license compatibility. I originally sent my message last December. ---------- Forwarded message ---------- From: Brett Smith via RT <licensing@fsf.org> Date: Jun 24, 2007 9:05 AM Subject: [gnu.org #323948] PHP license compatibility with GPL To: papercrane@reversefold.com Hello, Some months ago you asked use about compatibility between the GNU GPL and the PHP License. At that time our staff was overwhelmed with an important amont of requests, a situation which is now fixed. We also made sure to investigate all solutions to this issue, which took more time. You wrote:

I'd like to point out first of all that the "Various Licenses" page (http://www.gnu.org/philosophy/license-list.html) lists the PHP License 3.0 but the newest version is 3.01. It would be nice to know if this version of the license changes anything as a change was made regarding a clause that didn't apply to non-PHP extended code (this license is used by many projects written in PHP, such as PEAR packages).

This is now fixed. This particular change in the license has no effect on compatibility with the GNU GPL: http://lists.gnu.org/archive/html/savannah-hackers-public/2006-12/msg00023.html

It would also be nice to know why this license is not compatible and what the real restrictions are. It has been conjectured by several people that the "incompatibility" regard the use of the PHP name, but this seems like a technicality. As long as a derived work didn't violate this clause by using the PHP name wouldn't it not hit this problem?

Consider that the resulting combination of the PHPL'd code and the GPL'd will be under the GPL. The PHPL'd code can still be used under the PHP License, but the combination is a work under the GPL. To release a work under the GPL, you may not add any new restrictions or requirements, otherwise you are violating the license. This PHPL'd code introduces new requirements restricting the way the project can be named. A PEAR package under the PHP License says that combination of this package with another work cannot have "PHP" appear in their name (whether the package has something to do with PHP or not). As a result of this new requirement, it is not compatible with the GNU GPL v2. Note that the latest draft of the GNU GPL 3 is not compatible with the PHP License for the same reasons.

Lastly, I'd like clarification on "Incompatibility". It is my understanding that "Incompatible" licenses may be used together if one of the licenses specifically allows using the code in such a fashion. The LGPL, for instance, allows linking of open source code into commercial code, which would have violated the larger GPL. This would mean, to me, that any license is allowed for the code which links LGPL code, so the LGPL is "compatible" with any other license as long as the code is only linking to it (not modifying or distributing).

To be compatible, both licenses need to accept the link, and the GPL will not accept a link from any other license that imposes additional restrictions. Many GPL-incompatible licenses are free software, non-copyleft licenses like the PHP License. The PHP License accepts linking with other components, but the GNU GPL does not accept linking with the current PHP License due to its clauses 3 and 4.

It was our intention at PEAR to allow only licenses which allow linking of our code in any code. A question has come up on our mailing list of whether it is allowed to use a package licensed under the PHP license within a GPL licensed product. Since, to my understanding, the PHP license allows such linking, there is no license problem. Thank you very much, Justin Patrin

---

Apologies for the additional message. I meant to include this link to the PEAR website which explains our stand on licensing. http://pear.php.net/manual/en/faq.licenses.php

I'll quote the FAQ entry:

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.

The Apache License 1.1 license is incompatible with the GNU GPL, at least for the same reasons. The Apache License 2 uses a different wording: "6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file." The Apache License is incompatible with the GNU GPL, version 2, because of different, patents-related clauses. However it will be compatible with GPLv3 because of other changes in the license. The PHP License is still incompatible with the GNU GPL v3 because it didn't fix its trademark-style clauses, unlike Apache License 2.

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.

There is confusion in this text between "aggregation" (putting two independent components on the same medium) and "derivation" (when two components are linked together). In the case of Apache running a PHP script, we believe this is not a combination of two works into one program, because this is a general communication mecanism (like pipes and fork&exec), and Apache does not depend on a particular PHP script to work. Besides, the GNU GPL has an exception regarding system libraries, which for example allows to distribute GPL'd programs that run under Windows, or compiled with a proprietary compiler, without requiring you to distribute Windows or the compiler under the GNU GPL as well. However, when a PHP script calls a specific library to work, we believe this is a combination of two works into one program - the script works specifically with the library, using specific function names, and the library cannot be trivially replaced by another one. Therefore the licenses of the PHP script and the library needs to be compatible. If you have more questions, feel free to ask them. Best regards, -- Brett Smith Licensing Compliance Engineer, Free Software Foundation -- Justin Patrin