mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@apache.org>
Subject Re: Status of dependency on LGPL'd library (Was: Re: [Legal] Why is this LGPL notice file in our SVN?)
Date Tue, 22 Jan 2008 16:21:52 GMT
On Jan 22, 2008 10:56 AM, Henri Yandell <bayard@apache.org> wrote:
>
> On Jan 22, 2008 5:24 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> >
> > On Jan 21, 2008 10:11 PM, Trustin Lee <trustin@gmail.com> wrote:
> > >
> > > On Jan 21, 2008 11:45 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> > > > On Jan 21, 2008 5:26 AM, Trustin Lee <trustin@gmail.com> 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 legal-discuss@a.o 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?
> > >
> > > Yes.  The functionality that depends on RXTX is completely optional.
> > >
> > > > 2) Does this submodule "communicate with RXTX solely through the Sun
> > > > Microsytems [sice] CommAPI interface version 2"?
> > >
> > > No, it directly imports gnu.* package.
> >
> > What a pity, as this would have changed the answer.  But given the
> > answers above, the answers to your two questions relative to the
> > current draft ASF Third Party Licensing policy is
> >
> > > > > 1) Do we need to move our submodule outside of the ASF or not?
> >
> > Yes.
>
> Why again?
>
> I've not figured out what differences there are between the rubys
> 3rdparty and the cliffs one, but I thought it was fine for code to
> depend on LGPL as it did not make our code LGPL.

I could quote from Cliff's draft, or you can simply read for yourself:

http://people.apache.org/~cliffs/3party.html#transition-examples-lgpl

> > > > > 2) Is there any way to distribute the submodule with the official
MINA
> > > > > release as of now?
> >
> > Not directly.  See the bullets relating to excluded licenses in the
> > section on Optional Add-ons in the following web page:
> >
> > http://people.apache.org/~rubys/3party.html#options-optional
>
> ? Again, I thought we could distribute our submodule, but not the LGPL
> code it depends on. To get that optional feature to work, the user
> would have to manually find the LGPL work (we'll supply a link) and go
> get it before they have that feature.

Again, Cliff's words:

http://people.apache.org/~cliffs/3party.html#options-optional

Tell me if you read them differently than I do, or have suggestions on
how the draft should change.

> Hen

- Sam Ruby

Mime
View raw message