[Xapian-devel] Xapian license change
wichert at wiggy.net
Mon Jul 23 15:01:29 BST 2012
On 05/22/2012 07:47 AM, Olly Betts wrote:
> 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).
I will try to write a draft and send that here first before adding
something to the wiki.
[.. snip ..]
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.
Doesn't that assume the entire file is copyrighted by BrightStation. If
80% of their original contribution has been replaced the effort will be
less that you might think based on that list if I understand you
correctly. It does make it hard to figure out what code exactly is
copyrighted by who - perhaps you may need a policy that says that
replacing code with an older license policy must be in a different file,
but that would make things hard to maintain. Perhaps comment blocks?
>> 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
> biased sample.
Do you have a proposal for how a decision can be made?
[.. snip snip ..]
> 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).
MIT / BSD would fit those requirements and they're pretty simple.
More information about the Xapian-devel