[Xapian-devel] Xapian license change

[Olly Betts]

On Mon, Jul 23, 2012 at 04:01:29PM +0200, Wichert Akkerman wrote:
> 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.

Nothing beyond copyright.csv.

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

I think of it more as a list of "tainted files" that need to be dealt
with, either by wholesale replacement, or by careful research into the
VCS code history.

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

I've been encouraging substantial new code being put in new files where
it's feasible.

Trying to manage comment blocks tracking licensing of small chunks of
code doesn't sound very appealing - it seems a lot of work, and likely
to lead to at least some errors.  And if we have to audit the code
history to verify what the comments tell us, I feel we might as well
just use the code history alone.

I suspect in many cases where existing code is being modified, the new
code can't really be usefully disentangled anyway.

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

Well, I think this thread actually gives those interested a chance to
have their say.  It's going to be somewhat biased towards those using
Xapian already, but it's hard to avoid that really without spamming
a lot of tangentially related places.  So we can probably proceed on the
assumption that those who care have made their views known, or are happy
with what's been suggested.

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

Indeed.  MIT/X seems a good candidate, especially as we're currently
requiring submitted patches to be dual licensed under it, and a few files
are already explicitly MIT/X only.

Cheers,
    Olly