[Xapian-devel] Xapian license change

Dan Colish dcolish at gmail.com
Mon Jul 23 15:39:38 BST 2012


On Monday, July 23, 2012 at 7:01 AM, 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.
> 
> 
There is an audit tool under xapian-maintainer-tools which could be extended to give more information about the files where copyrights are found. It does output license_classes.csv which gives an estimate about how licensable a file is.
  
> 
> > 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.
> 
> 
> _______________________________________________
> Xapian-devel mailing list
> Xapian-devel at lists.xapian.org (mailto:Xapian-devel at lists.xapian.org)
> http://lists.xapian.org/mailman/listinfo/xapian-devel






More information about the Xapian-devel mailing list