couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dean Landolt" <>
Subject Re: [ RE: Using a GPL library with Apache CouchDB]
Date Sun, 20 Jul 2008 16:56:40 GMT
> > I am still curious to know if the "linking" aspect applies to "import
> xapian".
> IMHO the linking aspect applies to "import xapian" and in general to any
> kind of approach where the Xapian interfaces would have to be known from
> CouchDb ASF provided code for an integration to work.
> I would see establishing some kind of hard linkage and dependency between
> the two technologies as "linking".
> But I tend to consider linking in a technology neutral way, beyond the
> interpretation of what linking means for the FSF or what it means a
> specific
> programming language, so take my words lightly.

Linking and interfacing with an API *are* different, or there'd be no need
for the Affero GPL...

With a modified BSD bridge like pyndexter it all becomes moot. If couch
distributes an ASL or compatible reference indexer and the pyndexter bridge,
if someone wants to use Xapian (in python) they'd have to
*easy_install*xapian before they can
*import *xapian (first they'd actually have to apt-get install xapian-core
too). That's up to the end user but has nothing to do with couch. It's easy
and everybody wins -- couch isn't distributing the bindings and there's no

Even better, as someone mentioned, would be an Erlang FTI implementation to
distribute with couch, but that's a pipedream for now. Hyper Estraier, as an
LGPL work, *could* have bindings shipped with couch, but it's just as simple
to install these bindings as with xapian (in python at least) so it's not
even necessary. And then there's Lucene (and CLucene). There are options
a'plenty, and on top of it all indexing could work out of the box with
pyndexter's (comparitively slow) pure-python implementation.

So as soon as there's agreement on the index and query APIs I could wire
pyndexter to them and we'd be in business.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message