[Xapian-devel] Xapian license change
olly at survex.com
Tue Jul 24 05:25:07 BST 2012
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):
>> 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
I've been encouraging substantial new code being put in new files where
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.
More information about the Xapian-devel