www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: ActiveMQ Artemis: Using LGPL licensed libraries at runtime
Date Fri, 25 Dec 2015 02:11:27 GMT

> On Dec 24, 2015, at 7:34 PM, Greg Stein <gstein@gmail.com> wrote:
> With my Director hat on, I'd say "no way, no how" to hosting any non-ALv2 components.
> And component A that *requires* (L)GPL component B means that downstreams users of A
need to be concerned about the LGPL. So again: nope.

This is now really confusing…     Let me try a different possible explanation/interpretation:

The artemis-native component/jar REQUIRES the LGPL libaio library in order for it to achieve
it’s desired performance levels.   If it’s not found, it pretty much disables itself and
Artemis degrades to using a different component/jar (based on NIO).     Thus, in order to
use the artemis-native component, it requires an LGPL library and thus downstream users of
artemis-native would need to be concerned about the LGPL.

camel-zeromq requires a LGPL library.  If that library is not found, it effectively disables
itself.  If the user doesn’t have any routes that use it (99% of the time) nothing would
matter, user doesn’t need to concern at all.   If a route does reference the camel-zeromq
component, it would fail, but there are alternatives such as using a bean or similar to obtain
the functionality.   It’s a small optional “plugin” into camel that would use a LGPL
library if available and there are Apache licensed alternatives if it’s not. (alternatives
are just not automatic)

I’m really kind of struggling to see how one is acceptable and the other is not.

As a *user*, I actually find the first case less acceptable. If I build/run Artemis on a Linux
that happens to have libaio installed already (for example, I install mysql which pulls it
in), Artemis will use it without me even knowing at all.  I *think* I’m running pure Apache
Licensed code in a JVM.  However, artemis-native happens to detect libaio, uses it, and now
my JVM is polluted with some LGPL that isn’t part of the JVM platform and isn’t something
I knew anything about or configured or anything.  If I build/run Artemis on a different Linux
box that doesn’t have it, then I do get the desired runtime.  (and I also then need to figure
out why my app performs very different on one box compared to the other despite using the
exact same configuration) I guess if Artemis was a C/C++ app or similar that generally “links”
with the /usr/lib stuff (Linux platform) when built and I’m expecting that sort of thing,
that would be one thing.  However, Artemis is presented as a “java” application so I personally
feel the JVM would be the “platform”.   Guess I’m kind of rambling now.   Maybe I need
a rambling.html page.  :-)    I really do not enjoy all this legal stuff… 


> Merry Xmas!
> -g
> On Thu, Dec 24, 2015 at 3:11 PM, Daniel Kulp <dkulp@apache.org> wrote:
> > On Dec 24, 2015, at 12:08 PM, Greg Stein <gstein@gmail.com> wrote:
> >
> > On Thu, Dec 24, 2015 at 8:20 AM, Daniel Kulp <dkulp@apache.org> wrote:
> >
> > >So Apache projects can use LGPL/category X libraries by default without even
letting the user know they are using the LGPL/category X libraries (not distributed, so nothing
>needs to go in LICENSE/NOTICE) and without the user having to even “opt in” to using
the LGPL/category X functionality?
> >
> > Yeup.
> >
> > The project is using what is available. It is not *imposing* a dependency.
> >
> > As long as there is a fallback, then no imposition occurs. We do not want to require/impose
a cat-X dependency.
> Can I take this one step further….    If an Apache project has a clearly optional and
seldom used component that depends on an LGPL library, can we have that as part of our “main”
repository and builds here at Apache?   I know of a couple of “extras” repositories that
are used to host those types of components.  If they could be moved right into the main repositories,
that would certainly make things easier for the project developers and users.
> And since I know you hate dealing with hypotheticals and like to have a concrete, project
specific example/question:  :-)
> Camel has an “extras” project that hosts such components.   One such component would
be the camel-zeromq component.   zeromq is licensed under LGPL.  However, the camel-zeromq
component is certainly NOT something that most camel users use (to answer the question:  "Will
the majority of users want to use my product without adding the optional components?”) and
is clearly optional considering there are 100’s of other components that are usable and
Camel is clearly usable for many many use cases without it.  Camel would never distribute
any of the zeromq libs, the user would need to have those available.   Thus, could that component
be moved directly into camel’s normal list of components and hosted in the main camel repository?
  There are a few other components (like hibernate, and jcifs, etc…) that would be similar.
> And then to take that question one step further:  what about the camel-virtualbox component
that builds against virtual box which would require compiling against a GPL library?  I assume
the answer to this one is “no" as the page at:
> http://www.apache.org/licenses/GPL-compatibility.html
> says:
> "We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors
to create a derivative work. We want to honor their license. Unless GPLv3 licensors relax
this interpretation of their own license regarding linking, our licensing philosophies are
fundamentally incompatible. This is an identical issue for both GPLv2 and GPLv3"
> I’m just trying to clarify this (and get it into the legal-discuss archives).   I really
don’t think the answers at http://www.apache.org/legal/resolved.html#prohibited  and #optional
are complete enough.   If the answers to the above are “yes, host them at Apache”, then
I really think there isn’t the need for some of the “extras” projects.    Maybe I’ll
try and submit a patch to help clarify those questions on resolved.html, but that kind of
word smithing isn’t really my strong suit.   :-)
> Happy Holidays!  Merry Christmas!  Happy New Year!     etc...
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

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

View raw message