[Xapian-devel] Xapian license change
olly at survex.com
Tue May 22 06:47:01 BST 2012
On Thu, May 17, 2012 at 10:04:18AM +0200, Wichert Akkerman wrote:
> 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?
I'm rather too busy to at the moment, but I'm happy for others to work
on such a page (assuming it doesn't create a maintenance burden which
I end up shouldering, or spread misinformation which I then have to
spend time clearing up after).
> 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.
I guess you mean this:
That used to incorrect say "GPL" but I fixed in back in February.
>>> 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
>> 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:
> Looking at commit logs that means everything since November 13 2009 is
> already dual licensed.
Not quite. We've not been asking longer term contributors (who have
already given us permission to relicense their contributions) to
dual-license up front. This isn't a carefully thought out policy, there
just didn't seem a reason to do so.
It's a fairly subtle distinction, but for example a third party can't
just take code in Xapian written after a given date and use in under
MIT/X without investigating who wrote it. (This isn't some deliberate
masterminded policy, just a consequence of the above).
But we do have agreement from most of the longer term contributors that
we can relicense, and more recent contributors have dual licensed up
So the only copyrights which should be an issue are any on external code
we've brought in which isn't liberally licensed (which there isn't much
of) and these:
* BrightStation PLC.
* Ananova Ltd.
* Orange PCS Ltd.
> 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.
Buildbot keeps an updated summary (I'm not convinced the later columns
are actually useful, so I'd suggest just ignoring them):
A TODO list doesn't seem worth the effort it would take to maintain it
given that "git grep BrightStation" or similar can easily give you a
completely up to date list of the files concerned.
>> 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
> 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.
I'd rather avoid adding more build-time optional features. They're easier
to break if not everyone is building with them, and they're a pain for
packagers as they have to make a choice for their users. Forcing
packagers to make a *licensing* choice for users seems particularly
Perhaps as an intermediate stage it's OK, so --without-gpl might give
you a copyleft-free version, and slowly this evolve to disable less
and less until it has no effect. Currently you wouldn't get a usable
system from this though - in particular the matcher and all backends
still include BrightStation code.
>> * 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.
I think it's over-simplifying to say there isn't ANY difference.
Certainly the two cases aren't hugely different.
>> * 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?
I wasn't aiming to make an explicit proposal, but rather to highlight
the issues which need to be decided, and some options we have.
I think I'm the biggest single copyright holder in Xapian at this point,
but I'd rather not let that result in us just doing what I suggest here.
As Dan notes, this shouldn't be about people who want to use Xapian in
proprietary applications making demands, but I think only listening to
those using Xapian under the existing licence would give a rather
I don't think the relicensing itself is controversial. The use of GPL
is largely a historical accident - it was how BrightStation opened up
the code. I don't think I've heard anyone disagree with the plan to
relicense, and even the FSF don't advocate using the GPL in a case like
Xapian where there are alternatives under non-copyleft licences -
Using the ordinary GPL is not advantageous for every library. There
are reasons that can make it better to use the Lesser GPL in certain
cases. The most common case is when a free library's features are
readily available for proprietary software through other alternative
libraries. In that case, the library cannot give free software any
particular advantage, so it is better to use the Lesser GPL for that
Also, a big area for deploying of search currently is on web sites where
no distribution of the software occurs, which means that a lot of our
users don't actually fall under the GPL's copyleft provisions anyway.
And the choice of licence isn't wide open. For a start, it needs to be
both Free Software and Open Source. It should be something well known,
and definitely don't want to invent a new licence.
As Thomas Waldmann has pointed out, keeping GPLv2 compatibility is
desirable (because of existing GPLv2 users, such as moinmoin) - moving
to GPLv3+ or AGPL or the Apache licence would cause problems for some
existing users. To avoid that, either the new licence should be clearly
compatible with GPLv2, or else we should dual license (e.g. Apache +
GPLv2 would satisfy this requirement).
It would be good to be compatible with the PHP licence too, so the PHP
bindings can be packaged again (we can add an exception clause to cover
that if the chosen licence isn't inherently compatible).
More information about the Xapian-devel