Hi all I just read in bug-post 191 [ http://www.xapian.org/cgi-bin/bugzilla/show_bug.cgi?id=191 ] that there are some incompatibilities with the GPL (xapian) and PHP licenses, that makes it so you can't legally compile the two together. Richard B ends the discussion with saying that the future of the Xapian PHP bindings is looking bleak. These are devastating news to me, who has got a lot of apps running using the PHP bindings, and absolutely love Xapian! Does anyone know exactly what the outcome of this will be, and when a final decision will be made on the PHP bindings being or not being? If the final result is a negative one, could someone perhaps offer some pointers on how I can go about creating my own PHP bindings using SWIG? Alec
On Mon, Aug 20, 2007 at 08:57:24AM -0700, Alexander Lind wrote:> Does anyone know exactly what the outcome of this will be, and when a > final decision will be made on the PHP bindings being or not being?I haven't discussed this with Richard or Olly, but I believe we'll have to remove PHP bindings from the distribution in a fairly near future version, unless we can get legal advice that this isn't actually an issue for us.> If the final result is a negative one, could someone perhaps offer some > pointers on how I can go about creating my own PHP bindings using SWIG?IANAL, but I think you can just take the existing ones, providing you don't distribute them. (Because you are *not* required to *use* anything we distribute under the GPL, merely to redistribute under the GPL. However you need this to be true in any case, because the whole of Xapian is GPL licensed.) I stress: this needs a lawyer, and if you want to proceed on this, you should consult one for your territory. You'll need to do that even if you don't use code from our existing bindings, to make sure you aren't violating the *PHP* license by linking across to something that is GPL licensed (even assuming that you don't violate the GPL license by linking in the other direction). Alternatively, find or build yourself a Xapian application server, and talk HTTP to it from PHP. That has zero legal risk as far as anyone knows. J -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org
I think that the swig definitions (input files) are not derived from php. The automated production of the php bindings by swig does produce something that is a derivative of php. So the bindings may not be distributable but the recipe is. So as long as the recipe is followed on each target machine to produce the bindings and then compile them then there is no violation. However that standard solution to this problem is to wrte an intermediate linking library that does at runtime the sort of trick that this recipe was doing at compile time, so you invent a fake swig target that is rich enough for PHP and THEN write a glue layer that is dual licensed. As the bindings will be derived from this layer (and not php) and link with this layer there is no legal problem. If this path is followed it would make sense to build it into the swig php target!! You may need To write the 2 modules in that order so that the first layer (swig target) is clearly not derived from PHP. The second layer will then be derived from both and glue them together. The xapian bindings will be derived from the first layer and thus also not derived from PHP. We already have most of the new swig target, most of the swig targets are pretty similar. I wrote most of the current php target in swig, and it's barely if at all derived from php, although it has knowledge of the zend engine and object model and this counts. But there is little enough to re-write if you want to follow this path. It may be worth brining this problem up on the swig mailing list, as they are in the best position to sole this generally, perhaps even quickly. It may just require a change of compilation pattern; for many swig targets (I recall) use a libswig.* If the libswig-php or libswig-perl had the run-time derived code and was BSD licensed (or something very free) fr the binary, then that's the problem solved, and it would make swig more "useful" although whether that is more desirable than pressuring php to change their license I will leave for others to advocate. sam Sam -----Original Message----- From: "Alexander Lind" <malte@webstay.org> To: xapian-discuss@lists.xapian.org Sent: 20/08/07 18:05 Subject: Re: [Xapian-discuss] PHP bindings license problem James Aylett wrote:> On Mon, Aug 20, 2007 at 08:57:24AM -0700, Alexander Lind wrote: > >> Does anyone know exactly what the outcome of this will be, and when a >> final decision will be made on the PHP bindings being or not being? >> > > I haven't discussed this with Richard or Olly, but I believe we'll > have to remove PHP bindings from the distribution in a fairly near > future version, unless we can get legal advice that this isn't > actually an issue for us. >I am very sad to hear that. Do you know of any lawyer that would be proficient to give you this advice? If we can find out how much the advice will cost, perhaps we can find a way to take care of the cost for you. Unless you think its a completely lost cause of course. Would be good to hear what you all think about it when you have discussed it.> >> If the final result is a negative one, could someone perhaps offer some >> pointers on how I can go about creating my own PHP bindings using SWIG? >> > > IANAL, but I think you can just take the existing ones, providing you > don't distribute them. (Because you are *not* required to *use* > anything we distribute under the GPL, merely to redistribute under the > GPL. However you need this to be true in any case, because the whole > of Xapian is GPL licensed.) >Old bindings I can just keep using, sure, but what about new releases of Xapian? If I create the bindings myself using SWIG, and I only use them without redistributing them, I should be alright. So my question is, is it hard to create the bindings with SWIG?> I stress: this needs a lawyer, and if you want to proceed on this, you > should consult one for your territory. You'll need to do that even if > you don't use code from our existing bindings, to make sure you aren't > violating the *PHP* license by linking across to something that is GPL > licensed (even assuming that you don't violate the GPL license by > linking in the other direction). >I've asked in the php mailing list, but I doubt this would be the case. IANAL, so I could be wrong I suppose.> Alternatively, find or build yourself a Xapian application server, and > talk HTTP to it from PHP. That has zero legal risk as far as anyone > knows. >It would be very sad to have to resort to that, assuming such a solution would be a lot slower than using the bindings. Thanks for the advice anyhow. Alec> J > >_______________________________________________ Xapian-discuss mailing list Xapian-discuss@lists.xapian.org http://lists.xapian.org/mailman/listinfo/xapian-discuss
-----Original Message----- From: "Alexander Lind" <malte@webstay.org> To: "Sam Liddicott" <sam@liddicott.com> Cc: xapian-discuss@lists.xapian.org Sent: 20/08/07 20:54 Subject: Re: [Xapian-discuss] PHP bindings license problem>Thanks for this information. Are you the person that has >been in charge of creating the xapian bindings with swig?No. I rewrote the php target for swig. I had something to do with the php xapian bindings but my ropey contribution is long since superceded. Others have also improved my swig work.>I am not very familiar with swig (I know roughly what it can >be used for, and that's about it). But if I understand you >correctly, you are saying there are 2 technical solutions to >the problem: > >1. Make an abstraction layer to be used in the compilation >process of the bindings(?). This will separate the Xapian >code from any PHP derived code, and hence solve the problem.Yes. Care must be taken to get the solution right. It is solving a legal problem (or a rights problem) by writing code.>2. Get the swig team to change the compilation pattern of >their php library(?) What exactly is it that should be bsd-licensed here?Of all their libraries. All swig targets have a set of target-specific code which could be split into a separate library. If a libswig-php sits between the generated swig code and the target php (or perl, java, chicken, python etc) then IF libswig-XXX can be freely licensed so as to satisfy the target system (php etc) and the system originating the bindings then swig has solved the problem.>Can you please tell me exactly what I should ask the swig >people to do to fix the issue?forward this message. sam Cheers Alec Sam Liddicott wrote:> I think that the swig definitions (input files) are not derived from php. > > The automated production of the php bindings by swig does produce something that is a derivative of php. > > So the bindings may not be distributable but the recipe is. > > So as long as the recipe is followed on each target machine to produce the bindings and then compile them then there is no violation. > > However that standard solution to this problem is to wrte an intermediate linking library that does at runtime the sort of trick that this recipe was doing at compile time, so you invent a fake swig target that is rich enough for PHP and THEN write a glue layer that is dual licensed. > > As the bindings will be derived from this layer (and not php) and link with this layer there is no legal problem. > > If this path is followed it would make sense to build it into the swig php target!! > > You may need To write the 2 modules in that order so that the first layer (swig target) is clearly not derived from PHP. The second layer will then be derived from both and glue them together. The xapian bindings will be derived from the first layer and thus also not derived from PHP. > > We already have most of the new swig target, most of the swig targets are pretty similar. > > I wrote most of the current php target in swig, and it's barely if at all derived from php, although it has knowledge of the zend engine and object model and this counts. But there is little enough to re-write if you want to follow this path. > > It may be worth brining this problem up on the swig mailing list, as they are in the best position to sole this generally, perhaps even quickly. It may just require a change of compilation pattern; for many swig targets (I recall) use a libswig.* If the libswig-php or libswig-perl had the run-time derived code and was BSD licensed (or something very free) fr the binary, then that's the problem solved, and it would make swig more "useful" although whether that is more desirable than pressuring php to change their license I will leave for others to advocate. > > sam > > Sam > > > > -----Original Message----- > From: "Alexander Lind" <malte@webstay.org> > To: xapian-discuss@lists.xapian.org > Sent: 20/08/07 18:05 > Subject: Re: [X
On 2007-08-20 20:06:48 +0100, Sam Liddicott wrote:> However that standard solution to this problem is to wrte an > intermediate linking library that does at runtime the sort of trick > that this recipe was doing at compile time, so you invent a fake swig > target that is rich enough for PHP and THEN write a glue layer that is > dual licensed.i wouldnt rely on that. afaik the GPL is about running the code in the same memory space as the GPL code. even with your intermediate layer it would be still in the same memory space as the GPL code. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Funny, though, the GPL doesn't mention memory space. It all hinges on whether or not your code can be considered a derived work. The so-called linker exception for LGPL allows you to derive your work somewhat from the LGPL product only enough to be able to link, without fulfilling the other GPL obligations. In this case the xapian code will be linking to a dual license module which we or a friendly power can permit by granting additional freedoms. Granting additional freedom is something that can be done by the copyright holders