Chris Hostetter wrote:
: cooperate in any sane fashion, to no avail. He's not interested in
: changing the license, he's not even interested in any contributions.
Licensing issues are one of those things i'm always glad other people
understand and worry about -- because i don't want to -- so forgive me if
this is a silly question, but is there any reason Luke couldn't be
commited as a contrib module, without commiting the thinlet dependencies
(jars and what not) with a build.xml file that caused the entire contrib
module to be a NOOP unless the thinlet dependencies were detected in the
classpath (in the same way that the core build.xml skips the javacc tasks
if it's not installed)
that way the entire thing could be maintained in the lucene repository,
but people who wanted to use it owuld have to explicilty download the
thinlet dependencies.
Would that violate the thinlet license, or any apache policies regarding
other licenses?
No, this doesn't violate the license nor Apache policy, in fact this is
already used even in Lucene's contrib - e.g. the contrib/db requires you
to download Berkeley DB.
We could do this, but my feeling was always that such modules are
second-class citizens - they do not undergo as much testing as other
modules, and they lag behind the core, because of the additional effort
to install the dependencies.
Luke uses its own version of Thinlet, incompatible with the latest
public version, so I still would have to host this part.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
