Possible license conflict with the PHP bindings

[Fabrice Colin]

Current status

We believe it's OK to distribute the source code to the PHP bindings, but distributing binaries is problematic. So for example, the PHP bindings are disabled in the Debian packages (it's pretty easy to build your own php-xapian binary package, but you probably can't safely distribute it).

The ways this situation could be resolved that we can see are:

• PHP gets relicensed without the problematic clause which restricts the names you can use for derived works, which is the assumed incompatibility. This clause doesn't really achieve what they're aiming for since it only applies to derived works - if I create a work not derived from the PHP source, the PHP licence doesn't apply and I can use PHP in its name - even if it's written in PHP (e.g. phpBB, PHP-Nuke, CakePHP). A trademark on PHP would be a more appropriate option for protecting the name. Looking at past licensing discussions between Debian and the PHP developers, this isn't likely to happen.

• We can get legal assurance that the problematic PHP licence clause is compatible with the GPL. The FSF have stated that it's incompatible with GPLv2, but I never found a clear statement that this was still the case with GPLv3 (GPLv3 7c allows requiring that modified versions of such material be marked in reasonable ways as different from the original version, so if the PHP naming restriction is "reasonable" then the licences appear to be compatible). I emailed the FSF licensing people seeking to clarify this, but they never replied.

• We add an exception to Xapian's licence which explicitly allows linking with PHP. This isn't going to happen because some of the Xapian copyright holders have no interest in doing so.

• We eliminate the code we can't relicense from Xapian, and release it under a licence compatible with the PHP licence. This is probably going to happen eventually, as we've agreed a more liberal licence is appropriate and the older code is gradually getting replaced as the codebase evolves, but it's not likely to happen overnight. But I suspect this is how this issue will eventually get resolved.

How to build your own php5-xapian binary package

On Debian or Ubuntu:

sudo apt-get build-dep xapian-bindings
sudo apt-get install php5-dev php5-cli devscripts
apt-get source xapian-bindings
cd xapian-bindings-1.2.*
rm debian/control debian/*-stamp
env PHP_VERSIONS=5 debian/rules maint
debuild -e PHP_VERSIONS=5 -us -uc
cd ..

And to install the built package:

sudo dpkg -i php5-xapian_*.deb

---

Original description:

I am reporting this on behalf of Adel Gadllah <adel.gadllah@…>, who is looking into packaging the bindings for Fedora 7.

The PHP license and the GPL aren't compatible but xapian-bindings links PHP licenced and GPL licensed code.

Quotes from the conversation on IRC with Fedora developers : "the problem i'm seeing is that xapian-bindings has bits of code that are GPLv2+ and PHP" "and it is merging them together into one .cc file and compiling _that_" "except, the GPLv2 and PHP are incompatible" "BOOM" "tell upstream that they can't compile PHP code with GPL* code"

We need this solved first before continuing with building the other bindings in Fedora.

Fabrice

[Richard Boulton]

Argh!

Firstly, what are the "bits of code which are PHP" which are being compiled by xapian-bindings? Is this just a reference to the PHP header files which are being pulled in?

However, if the GPL and the PHP license aren't compatible, it doesn't matter whether we compile into a single file, or compile code in separate files separately and then link them - either option produces a binary which can't be distributed without breaching the terms of the GPL, as I understand it.

There's no real way we can change the Xapian license, and I assume there is no way to change the PHP license, so I don't actually see any way that this issue _can_ be resolved.

Unless I'm missing something, perhaps you'd be best to just disable the PHP bindings in your distribution.

[Adel Gadllah]

Disable the PHP bindings in Fedora would work for Fedora but that does not change the fact that xapian violates the PHP License. (So a solution _has_ to be found). Mysql has hit a similar problem in the past and they solved it by adding a exeption to the GPL. Let me quote some parts from the /usr/share/doc/mysql-5.0.37/EXCEPTIONS-CLIENT file:

---

"We want specified Free/Libre and Open Source Software ("FLOSS") applications to be able to use specified GPL-licensed MySQL client libraries (the "Program") despite the fact that not all FLOSS licenses are compatible with version 2 of the GNU General Public License (the "GPL")." and Later:

2. *FLOSS License List*

.. PHP License 3.0 ..

---

So this problem can be solved by adding a similar exception to the xapian license. (In our case adding doing a s/FLOSS licenses/PHP License/g to the quoted paragraph should be enough). This would solve the license violation in xapian and also make it shipable in Fedora.

[Adel Gadllah]

as for the files: The files in xapian-bindings-1.0.2/php/php4 and xapian-bindings-1.0.2/php/php5 link against the php libs (which are PHP licensed).

[Adel Gadllah]

correcting my self linking agains both xapian (GPL) and php libs (PHP).

[Richard Boulton]

(My suggestion of disabling for fedora was just to allow you to get on with packaging the other bits. I agree that we need a further fix if the problem is genuine - I haven't had time to investigate yet.)

Unfortunately, to add an exception to the xapian license for PHP requires a change in the xapian licnse that all copyright holders would need to approve. But, we're not in touch with all copyright holders, and one is a reasonably uncooperative commercial competitor, so this is unlikely to happen.

Currently, I think the future for xapian PHP bindings is pretty bleak.

[Sungsoo Kim]

I have looked up which files are using PHP license in the Xapian package and found the following files in the source directory.

xapian-bindings-1.0.2/php/php4/php_xapian.h xapian-bindings-1.0.2/php/php4/xapian_wrap.cc xapian-bindings-1.0.2/php/php5/php_xapian.h xapian-bindings-1.0.2/php/php5/xapian_wrap.cc

These files seems to have been generated by SWIG. I am wondering if the PHP license texts in those files were inserted automatically by SWIG or by the Xapian developers' hands.

We know GPL and PHP license are not compatible. (I will not mention here why they are not.) Therefore we need to merge Xapian's license into one. I am wondering why don't change PHP license in those files into GPL?

Does every program written in PHP or php module have to follow PHP license? No, it's totally separate one. I am not a lawyer. As I am much interested in GPL and other licenses for open source, I am studying this case.

Sungsoo Kim

[Olly Betts]

Just a correction to what Adel said in comments #3 and #4 - these files aren't linked against PHP libraries on Unix platforms (there PHP_LIBS is always empty - it's only used under Windows, and may not actually be useful there since apparently you can't build PHP with mingw and the MSVC build uses separate makefiles currently).

But there may well be licensing issues with using what amounts to a GPL-licensed plugin (the Xapian PHP module) with a non-GPL program (PHP).

(Also, this isn't Linux specific, so updating Platform and OS).

[Olly Betts]

Part of the issue is that SWIG inserts the PHP 2.02 licence boilerplate automatically into the generated C++ sources. I don't think there's a good reason for this, but the SWIG developer who contributed that code isn't easily contactable, so this might take a while to sort out...

[Olly Betts]

SWIG 1.3.32 no longer inserts the PHP 2.02 licence boilerplate into the wrapper files it generates, which is certainly an improvement to this situation.

So the PHP bindings don't link in any PHP licensed code, but they do compile against PHP licensed headers. I'm not a lawyer, but I think this is the only remaining potential problem.

Loading the GPL Xapian PHP module into the PHP-licensed PHP interpreter would appear to be OK, since the result never gets distributed.

This isn't specific to 1.0.2, so updating "version".