Possible license conflict with the PHP bindings

[fabrice.colin]

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]

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]

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

[xingshou]

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]

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]

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]

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