David,
Sorry for the slow reply to this one. I've just now crawled out of
the build-up of legal emails that I ignored during ApacheCon Europe.
Short answer: I didn't see any problem with the approach suggested in
this thread.
Long answer:
The big picture here is actually much less about legal requirements/
risk and more about consistency of the licensing aspect of the Apache
brand. That big, long, third-party licensing policy doc is primarily
trying to achieve one thing: a consistent theme to the licenses of
stuff that goes in an Apache product. While we do need to be careful
about how we link to GPL works, linking to an LGPL Java library poses
only a minimal risk that we would have to license our project code
under something other than the Apache License. Most of those "You
MUST NOT" and "You MAY"s were my attempt at placing bounds around
what a user has to deal with when they grab a product "off the shelf"
that has the "Apache" brand on it (don't get me started on my grocery
store metaphor...).
I give you the long answer for two reasons: a) to give you an
understanding for the ideas behind all those rules, and b) to make
sure I'm not misleading anyone into thinking that distributing an
LGPL library within an Apache product would cause us to all go to FSF
jail (or worse, JBoss jail!). The reason we don't distribute LGPL
jars in our products is because our users have come to associate the
Apache brand with (among other things) commercially-friendly
software, and the LGPL places restrictions on how they can license
software that links to the library, which most would consider not as
friendly as they would like.
Cliff
On Jul 3, 2006, at 10:55 PM, David Crossley wrote:
Hi Cliff, we are having a discussion on the Forrest dev
mailing list about how to cope with plugins where our
developers want to use third-party products from the
http://people.apache.org/~cliffs/3party.html#category-x
Re: plugins with some excluded licenses
http://marc.theaimsgroup.com/?t=115192023200002
Message-ID: 44A8E7F1.1020508 () apache ! org
Some background ...
Forrest has its main core and then a "plugins" system
to enable various extra optional functionality. We have
a growing list of plugins that we manage in our SVN.
When we make a release, we add the sources for all the
plugins.
The user can also use the plugin system to download
plugins that are not held in the Forrest SVN, e.g. from
their own development site.
So far we have managed to avoid using Category X third-party
products (e.g. supporting jars such as database connectivity)
in any of our plugins. However it was bound to happen.
Now we have a definite use case.
I hope that you can help. I am stumped about the best way forward.
-David
