[Xapian-devel] Xapian license change

[Wichert Akkerman]

Hi Olly,

there is a lot of information in your email that I was not able to find 
anywhere else. Perhaps it would be useful to create a relicensing-FAQ 
page on the wiki with this information?


On 05/17/2012 04:07 AM, Olly Betts wrote:
> What's best to work on depends on what your skills and interests are. 
> If anyone is seriously interested in contributing in this way, it 
> probably makes most sense to simply discuss what's best for you to 
> work on, either here, or on IRC. 

I don't know exactly how much time I can contribute and I certainly will 
not claim to be an expert on the underlying technology, but I am 
interested and willing to help.

>> As far as I can see several things would need to happen:
>>
>>   * a new license (or set of licenses) will need to be chosen
>>   * current copyright holders will need to sign off on the relicensing
>>   * dependencies on GPLed libraries (think getopt) will need to replaced
> Actually, GNU getopt is LGPL v2 or later (or at least so says the
> licensing boilerplate on the version we're using).

That helps. There was a wiki page which explicitly mentioned wanting to 
replace getopt with something like popt for licensing reasons, which is 
why I mentioned it.

>> Looking at older posts and the xapian website it seems that LGPL has
>> been suggested as an alternative license, but I can not find a clear
>> decision.
> I don't think we have a totally firm decision currently, but it is
> likely we'd go for either LGPL v2+ or MIT/X (with the latter probably
> being the favourite).  We currently ask for patches to be dual-licensed
> under GPL v2+ and MIT/X, as the latter should give us compatibility with
> any Free Software licence:
>
> http://trac.xapian.org/browser/trunk/xapian-core/HACKING#L1228

Looking at commit logs that means everything since November 13 2009 is 
already dual licensed.

>> Judging by the copyright statements in the sources (for xapian-core)
>> there are 18 copyright holders, which is a manageable list:
> Some of these are on code which is already under a liberal licence,
> so aren't a concern here.  Most of the rest have already agreed.
>
>> Does anyone have any idea how willing these copyright holders might be
>> to approve relicensing?
> The ones we don't have agreement from are:
>
>    * BrightStation PLC - it's not even clear who actually holds this
>      copyright now, and we've heard competing claims.  I discussed a
>      potential LGPL relicensing with one claimant, but it went nowhere
>      useful.  This is where the code Xapian has evolved from was
>      originally developed, so the oldest code (1999-2001) has this
>      copyright, and over time it has been gradually replaced, but there
>      is still a significant amount left.
>
>    * Ananova Ltd - Another old copyright (from 2001-2002).  I tried
>      talking to them about relicensing some years ago, but their lawyers
>      seemed more interested in trying to get me to retroactively sign an
>      employment contract which I'd refused to sign at the time due to an
>      unreasonable "no compete" clause.
>
>    * Orange PCS Ltd - From 2003 and only affects one file, which is also
>      (C) BrightStation and Ananova.  Orange bought Ananova, so it's
>      unlikely we'd get this relicensed either, but it doesn't really
>      matter as we'd need to replace this file anyway.

Do you have a list of the code still owned by those three, so that can 
be turned into a TODO list? A quick grep shows 100 files with a 
BrightStation PLC copyright but nothing more recent than 2001, which 
suggests that a lot of that code has already been replaced over time.

> There are some issues we haven't yet really reached a conclusion on that
> I can recall.
>
>    * If we go for MIT/X, are we happy to have LGPL dependencies?  This
>      came up in the context of some of the GSoC proposals this year, as
>      some of the machine learning libraries we might want to use are
>      LGPL.

Are those dependencies required or optional? If the intention is to 
allow give people using Xapian all the freedoms the MIT/X license 
provides over LGPL than requiring on LGPL dependencies is not desirable 
since those will still pull in the extra restrictions. If the extra 
dependencies are optional (for example a user may not be interested 
extra ML features) users can pick and choose.

>    * If LGPL dependencies are OK, what about bundled LGPL code (like
>      GNU getopt)?

I don't think bundling or not makes any difference. Shipping code under 
multiple licenses in a single deliverable is quite common. You just need 
to be careful in marking which license(s) apply everywhere.



>    * Exactly what are we aiming to relicense?
>
>      + xapian-core: We clearly want to have libxapian.so relicensed, but
>        the tools probably matter less, and the testsuite could easily
>        just remain GPL.
>
>      + xapian-bindings: Since I rewrote most of the SWIG interface file
>        to directly parse the C++ headers, there isn't actually a lot of
>        the older code left here, but there is still some.  It would be
>        good to sort out the PHP bindings in particular, so they can be
>        packaged again (currently GPL and PHP licences are apparently
>        incompatible due to the rather pointless naming restriction the
>        PHP licence imposes).
>
>      + xapian-omega: This can probably remain GPL.  I don't think it's
>        a top priority anyway.
>
>      + xapian-letor: New code, so easy to relicense.
>
>      There's also an argument for consistent licensing, as that's much
>      easier to understand and to explain to users.

Does that mean your proposal is to relicense everything except the 
xapian-core testsuite and xapian-omega?

Regards,
WIchert.