You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by Steve Viens <st...@viens.net> on 2004/03/11 11:46:24 UTC

FW: Clarifying some licensing issues for Apache developers

Given the message below, it would appear that we'll need to remove the
following jar files from the jUDDI CVS module:

  jce.jar
  jaxrpc.jar         (from Axis)
  saaj.jar           (from Axis)
  wsdl4j.jar         (from Axis)
  junit.jar          (not bundled in release)
  uddi4j.jar         (not bundled in release)
  servlet.jar        (not bundled in release)
  jdbc2_0-stdext.jar (not bundled in release)

We don't actually distribute udd4j.jar, junit.jar, servlet.jar and
jdbc2_0-stdext.jar with a release. They are in CVS merely to make it
easier for developers to build/test jUDDI.

Any thoughts or comments?

Steve

-----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




Re: FW: Clarifying some licensing issues for Apache developers

Posted by Davanum Srinivas <di...@yahoo.com>.
hang on....don't do anything yet.

thanks,
dims

--- Steve Viens <st...@viens.net> wrote:
> Given the message below, it would appear that we'll need to remove the
> following jar files from the jUDDI CVS module:
> 
>   jce.jar
>   jaxrpc.jar         (from Axis)
>   saaj.jar           (from Axis)
>   wsdl4j.jar         (from Axis)
>   junit.jar          (not bundled in release)
>   uddi4j.jar         (not bundled in release)
>   servlet.jar        (not bundled in release)
>   jdbc2_0-stdext.jar (not bundled in release)
> 
> We don't actually distribute udd4j.jar, junit.jar, servlet.jar and
> jdbc2_0-stdext.jar with a release. They are in CVS merely to make it
> easier for developers to build/test jUDDI.
> 
> Any thoughts or comments?
> 
> Steve
> 
> -----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
> 
> 
> 


=====
Davanum Srinivas - http://webservices.apache.org/~dims/