[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

php5-xapian: PHP licence vs GPL



Hi,

For reference, this is #513796 in the BTS.

To summarise, php5-xapian wraps the GPLv2+ licensed Xapian library for
PHP v3.01 licensed PHP5.  The two licences are regarded as incompatible
due to the restriction on names containing "PHP" in clause 4 of the PHP
licence.  The build process doesn't link against PHP (on Linux), though
it does use PHP API header files.

PHP is a rather noisy search term (since lots of URLs end ".php") but my
research of past debian-legal discussion eventually found this from
Steve Langasek:

    There are several other PHP extensions in circulation that use GPLed
    libraries, some of them distributed with the PHP source itself.  (The
    readline extension is one example.)  Binaries for these modules can't be
    distributed in Debian, but that doesn't mean you can't write a PHP
    extension for a GPL library and distribute it on your own.

http://article.gmane.org/gmane.linux.debian.devel.legal/7867

Also, note that Xapian upstream don't control the copyright of all the
code, so aren't able to add a special exception to the licence to allow
for the PHP naming restriction.  And it seems from past debian-legal
discussion that PHP upstream are rather attached to this clause (though
it seems to me a trademark would achieve the intended ends much better
as a licence clause only has power over software derived from PHP
itself).  So I don't see relicensing as a plausible route for fixing
this problem.

So my questions are:

* Is the quote above an accurate summary of the currently accepted
  interpretation?  (That mail is from 2003 so perhaps things have
  changed since).

* If so, is there anything which can be done other than removing
  php5-xapian from the archive?

* Assuming php5-xapian must be removed from the archive, can the
  xapian-bindings source package (which builds bindings for python,
  ruby, etc too) continue to include (now unused) source code for it, or
  do I need to prepare a special "dfsg" version of the upstream source
  tarball without this code?  (I notice Steve says "binaries for these
  modules", which hints that source may be OK).

Cheers,
    Olly


Reply to: