On Jan 21, 2008 5:26 AM, Trustin Lee <[EMAIL PROTECTED]> wrote: > Hi, > > I know LGPL is somewhat an old topic, but it's still puzzling me, so > please bear with me a little bit. :) > > I am forwarding this thread to [EMAIL PROTECTED] just to be sure and > find out what MINA PMC has to do with the RXTX dependency. Here's > some background: > > * One of MINA's submodule depends on RXTX library (http://www.rxtx.org/). > * RXTX is LGPL'd with an exception clause. > (http://users.frii.com/jarvi/rxtx/license.html) > * We are using Maven so the generated tarball doesn't contain any RXTX > source code or binary (i.e. JAR). > * However, Maven 2 fetches the RXTX binary automatically when a user > enters 'mvn compile' command. > * We didn't tag any official release or publish any distributions yet. > (we have some Maven snapshots though) > * Another worthwhile read: http://tinyurl.com/28hmfj
Regarding that last link, that resolution was tabled. What it eventually evolved into can be found here: http://people.apache.org/~rubys/3party.html > Now the somewhat overlapping questions... > > 1) Do we need to move our submodule outside of the ASF or not? > 2) Is there any way to distribute the submodule with the official MINA > release as of now? Two questions first: 1) Can Mina meaningfully operate, possibly with a only a subset of functionality, without the presence of this dependency? 2) Does this submodule "communicate with RXTX solely through the Sun Microsytems [sice] CommAPI interface version 2"? > Thanks in advance for some clear answer! :) > Trustin - Sam Ruby > On Jan 21, 2008 6:25 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > > Trustin Lee wrote: > > > It's not a mistake. I think we had enough discussion: > > > > > > http://markmail.org/message/zpjhpxlj3hul3phx#query:+page:1+mid:zpjhpxlj3hul3phx+state:results > > > > > This discussion conclusions were pretty clear, I think : > > > > "I think that the last sentence is pretty clear to me : either you write > > your own interface, or you accept compilation errors (up to the user to > > download the LGPL lib interface), but you should not include any part of > > this LGPL project into the repo. > > > > Is that correct ? > > > > Emmanuel" > > > > "I believe so, yes. You absolutely cannot ship any LGPL code along with > > your releases. If users provide a version of that code themselves it's > > fine to have functionality that depends on it, although in general that > > sort of thing should be discouraged if possible. > > > > -garrett" > > > > > > So I think it's a mistake, IMHO.Someone misinterpreted the conclusion we > > reached in this thread. > > Doesn't 'LGPL code' here mean the source code (or binary) of the > LGPL'd library? If so, we are not distributing anything like that > (because we are using Maven and Maven will pull the JAR only when the > user wants to pull it.) If 'LGPL code' meant the code that uses > LGPL'd library, then we need to do something to fix this situation. > Just moving it out to somewhere like Google Code will work I guess. > > > > Please let me know if we need to add some notice statements in our > > > distribution. > > > > > http://people.apache.org/~cliffs/3party.html : > > > > > > "Category X: Excluded Licenses > > > > The following licenses must *not* apply to any software within an Apache > > product, whether in source > > <http://people.apache.org/%7Ecliffs/3party.html#define-source> or binary > > <http://people.apache.org/%7Ecliffs/3party.html#define-binary> form"" > > > > In any case, I don't see why we have a Notice Statement in the > > distribution for a LGPL product. And we should also remove the reference > > to this library from the mina-transport-serial pom.xml. > > > > > > > In > > > contrast, RXTX is available in the official Maven repository and very > > > stable and mature in what it's supposed to do. What we need to do is > > > to tell users that it is a LGPL'd library, and that's why > > > LICENSE.rxtx.txt is there. > > > > > There are two different things : > > - you can tell users they can use a LGPL library, on there own behalf, > > - but you can't distribute the code which does that. > > > > We have had the very same problem at Directory with BDB : the conclusion > > is that if we want to distribute a BDB backend, then it has to be done > > out of the ASF. > > > > Hope it helps, and that I'm not totally wrong... > > > > PS : in any case, the best to clarify this situation, as the chairman, > > would be to push this question to [EMAIL PROTECTED] I don't know if it has > > been > > done last year, but I think it should have ... > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 > > --------------------------------------------------------------------- > DISCLAIMER: Discussions on this list are informational and educational > only. Statements made on this list are not privileged, do not > constitute legal advice, and do not necessarily reflect the opinions > and policies of the ASF. See <http://www.apache.org/licenses/> for > official ASF policies and documents. > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
