[Xapian-discuss] PHP bindings license problem

[Sam Liddicott]

-----Original Message-----
From: "Alexander Lind" <malte at webstay.org>
To: "Sam Liddicott" <sam at liddicott.com>
Cc: xapian-discuss at 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 at webstay.org>
> To: xapian-discuss at lists.xapian.org
> Sent: 20/08/07 18:05
> Subject: Re: [X