RE: Clarifying some licensing issues for Apache developers

["Howard M. Lewis Ship" <hl...@comcast.net>]

This does represent some additional work for us (Tapestry).

We currently rely on OGNL (which uses a BSD-like license) and Javassist (dual MPL/LGPL).

To be clear: it is acceptible for ASL 2.0 code to have dependencies upon other libraries (now
including LGPL). However, we are not allowed to *bundle* those dependencies in our distribution.

This is good news and bad. I want to integrate HiveMind with Hibernate, and this appears to be
allowable (as I understood ASL 1.1, it did not used to be). However, we can't include the (in this
instance) Hibernate jars with our code.

I do have an issue: since we will be using Ant to dynamically download libraries, it may *appear*
that such libraries are ASL, since we would likely not download license files with the JARs.

Is that not worse?  It's less of an issue for Maven, since those downloads go into an entirely
seperate structure.

Is it not the purpose of the README to identify dependencies? We have faithfully redistributed the
licenses in the same directory as the JARs for some time now.

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components 
http://howardlewisship.com


> -----Original Message-----
> From: Brian Behlendorf [mailto:brian@collab.net] 
> Sent: Tuesday, March 09, 2004 2:00 PM
> To: committers@apache.org
> Subject: Clarifying some licensing issues for Apache developers
> 
> 
> 
> It seems worthwhile to state something that probably most 
> people are aware
> of, but a few recent incidents suggest is worth repeating.  
> Followups are
> being directed to licensing@apache.org, a list that is 
> private to Apache
> committers, where legal issues are discussed.  Please 
> subscribe to that
> list (requires approval) before posting to it.
> 
> First off, thank you to everyone who has transitioned to the 
> new Apache
> License 2.0.  It is a board mandate that *all* software 
> distributed by the
> Apache Software Foundation be under this new license.  This has some
> subtle and not-so-subtle ramifications people should be aware of.
> 
> *) Only software packages created by the Apache Software 
> Foundation may be
> redistributed from Apache's servers and mirrors.  This means 
> no tarballs
> or binaries from other authors or organizations.  We realize 
> that many ASF
> projects depend upon other software, and that these 
> dependencies may make
> it difficult for new users to bootstrap quickly.  There are 
> solutions to
> that problem outside of the ASF: ibiblio, sourceforge, CPAN, etc.  The
> board might grant exceptions to this rule - bring it to us if 
> you'd like
> us to consider it.
> 
> *) Only the Apache license may apply to Apache releases.  
> This means the
> *entire* release.  This means you may not incorporate LGPL, GPL, MPL,
> SCSL, or CPL licensed software within an Apache release, 
> because all of
> those licenses place requirements or restrictions that go 
> above and beyond
> the requirements laid out in the Apache license.  When 
> someone downloads
> an Apache release and reads the Apache license, they should not be
> expected to root through the rest of the release looking for other
> licenses that might apply and might have addition requirements or
> restrictions; at most they should be expected to read the NOTICE text,
> though that is used solely for attributions to survive in derivative
> works.  MIT licensed software *may* be incorporated into an Apache
> project, as may BSD licensed software, software that only requires
> attribution, that kind of thing.  When in doubt when dealing with
> third-party code, bring it to the Incubator, where legal issues can be
> hashed out first.  And be sure and re-read your Contributors License
> Agreement and understand that it applies specifically to you when you
> bring in code from the outside.
> 
> 
> I'd like to also clarify the discussion around "license 
> compatibility".
> Our claim is that the Apache license 2.0 is compatible with 
> the GPL and
> LGPL, and we've also claimed it to be compatible with the 
> MPL, the CPL,
> and many other licenses.  "Compatibility" here means that you 
> may legally
> *combine* Apache code with other code under these approved 
> license, and
> redistribute the work under some license from some non-Apache 
> location.
> However, the license terms of that redistribution must obey 
> the licenses
> of both the Apache license and the license of the other code being
> combined.  "Compatibility" does *not* mean that you can incorporate
> MPL-licensed or GPL-licensed code into your Apache project 
> and release the
> combined work under the Apache license.
> 
> My apologies if this comes across as pedantic; I just wanted 
> to level-set.
> 
> Thanks.
> 
> 	Brian
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

RE: Clarifying some licensing issues for Apache developers

[Brian Behlendorf <br...@collab.net>]

On Tue, 9 Mar 2004, Howard M. Lewis Ship wrote:
> I do have an issue: since we will be using Ant to dynamically download
> libraries, it may *appear* that such libraries are ASL, since we would
> likely not download license files with the JARs.

The GPL requires that the license be included with all redistribution of
GPL'd software.  So, simply downloading the JAR by itself might not be
permissable.  Unless there's a way to include the license inside the JAR
somehow; though that may be fulfilling the requirement in letter but not
in spirit.  Someone might want to ask the authors about that, or the FSF.
The FSF might simply say, so long as it's clearly obvious where to get
both the source code and the license itself... but I don't know.  I know I
install GPL'd software via pkg_install on FreeBSD all the time without
consciously knowing which packages are GPLd or not.

I'd suggest at least a notice somewhere prominent that Ant will download
software from locations other than apache.org, and that people wishing to
redistribute anything that Ant downloads must be aware of the licenses on
that code (perhaps listing those licenses for convenience).

	Brian


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org