Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <64a10fff0807180735n36d41287h29ed9085e012c@mail.gmail.com>
Date: Fri, 18 Jul 2008 10:35:42 -0400
From: "Dean Landolt" <dean@deanlandolt.com>
To: couchdb-user@incubator.apache.org
Subject: Re: the search api?
In-Reply-To: <e2111bbb0807180614v2ae7933dgd5c6dd6f81b660@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_40755_3785335.1216391742300"
References: <64a10fff0807171357v152ee252v4637472bebeb74a3@mail.gmail.com>
	 <e2111bbb0807171412k517f4bbeq8024b51b62ce0184@mail.gmail.com>
	 <64a10fff0807171436m6928c207u8e4046e55cf7207a@mail.gmail.com>
	 <20080717221852.GF2986@bytesexual.org>
	 <e2111bbb0807171536x4a76a93cl4835dbf39de1c54a@mail.gmail.com>
	 <20080718124244.GH2986@bytesexual.org>
	 <e2111bbb0807180614v2ae7933dgd5c6dd6f81b660@mail.gmail.com>

------=_Part_40755_3785335.1216391742300
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Fri, Jul 18, 2008 at 9:14 AM, Paul Davis <paul.joseph.davis@gmail.com>
wrote:

> Noah,
>
> See, that's the kicker. I don't by any means want to distribute the
> bindings. But by virtue of the GPL, if you're code uses, say for
> instance, the Xapian bindings you're code must be released under the
> GPL. Ie, by mere virtue of having "import xapian" in your python
> script it would have to be released under the GPL.


I'm no IP expert (though I do waste exhorbenant amounts of time studying
it), but I don't believe that's what puts you on the hook for
*distribution*(the key phrase to the spell of the GPL). You're not
responsible for how the
*xapian* egg got into site-packages, and even if you were (say you had it as
a requirement in your setup.py script), you're still not distributing. Only
if you include the package that links to the xapian binary as part of your
distribution would you be on the hook.

It wasn't until I put that one together that I realized how much I
> dislike the GPL.


It's not all bad. But yeah, I'd been on the fence for about this for a
while, but I'm starting to feel the same way.

As to the erlang FTI idea, I'd be all for this too. Keeping as much in
> erlang as possible seems like a good idea to me. It just so happens
> that one of the short examples in Programming Erlang is about creating
> such a beast. Granted its small and trivial, but its a place to start
> from.


Small and trivial's all I'd even want (the simple FTI implementation in
pyndexter is what turned me on to it -- it was easy to just get started with
and see results). But still, the lack of a dead-simple api in couch makes
toying around with it nothing more than mental masturbation for now. Which
is fine by me.


> Now, if anyone wants to go and implement a decent stemmer and
> all the other whizbang features that people expect from a FTI, I'd
> probably jump on board with that.


Luckily stemming (in English at least) is just about picking a known
algorithm (and implementing, presumably). That would be a great exercise for
learning Erlang -- something I'd be interesting in taking on when I do take
that leap (not for at least 6 months I'd imagine).

------=_Part_40755_3785335.1216391742300--