[Xapian-devel] Xapian license change

[Wichert Akkerman]

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):
>
> http://lcov.xapian.org/copyright.csv
>
> 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
> unhelpful.

Agreed.

>
> 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.

Wichert.