www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: Building ASL code requiring LGPL 3rd party
Date Thu, 31 Mar 2011 15:22:14 GMT
On Thu, Mar 31, 2011 at 10:09 AM, Smiley, David W. <dsmiley@mitre.org> wrote:
> In light of further clarifications (and apparent reversal of opinions) on ASF policy
by Ralph Goers and Greg Stein, I'm going to modify my patch so that the JTS using portion
of its capability is not required at build/test time (and of course runtime) unless the person
doing the build explicitly requests its use.  I'm not yet sure which particular means of
many possible I'll choose but I'll propose something within the Lucene/Solr community where
that choice is pertinent.

Just trying to catch up to this thread, I know its probably a little
off-topic for the legal discussion but I just wanted to give my
opinions on this as a committer that spends time working on the build

1. I don't particularly like the idea of an optional "build/test" time
thing. If we go down this slippery slope of allowing you to optionally
choose A, B, and C viral dependencies, this puts an unfair burden on
those of us maintaining the build system (see the
dev@lucene.apache.org mailing list for a lot of current discussions
involving how we can improve the build system to make releasing
easier). This means we have to be concerned with, does the build work
correctly if you choose any of the possible permutations of viral
choices: A=yes,B=no,C=no, A=no,B=yes,C=no, ...

In this particular example, I could imagine this getting complicated,
because we are trying to modularize lucene/solr itself: for example if
we add a spatial queryparser to the "query parser module", which
relies upon our spatial module with its viral choice, then this parser
module, too has to worry about whether or not you selected these viral
capabilities and whether it works correctly if you chose true or
false, and the same with higher level solr functionality that might
expose the queryparser and use the queries.

This is just me wearing my committer hat and trying to keep our
testing and build sane.

2. Thanks for alerting me to the fact that the "contrib/db" module has
a viral dependency. I don't like this, and with my PMC hat on, it
would be my opinion that we should remove this dependency completely.
I don't think lucene/solr should include viral dependencies.

Fortunately, someone already opened an issue about removing this
particular module: https://issues.apache.org/jira/browse/LUCENE-2981

3. I am not a spatial expert, but i wish effort would instead go into
creating an apache-licensed version of the particular calculations you
need instead of hacks. Has a jira issue been opened in the appropriate
project (SIS?) to impelement this calculation?.. As mentioned in (1)
above, introducing an "optional" thing might seem to be a short-term
workaround, but long-term will cause a lot of additional work and
complexity for the project as a whole.


To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message