You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by se...@apache.org on 2004/03/09 23:23:19 UTC
Re: Clarifying some licensing issues for Apache developers]
Indeed, I was going to post about this, as we currently use the following non-Apache software:
- htmlparser (this may be OK)
- jdom
- js (rhino)
- junit (not needed at runtime)
- Tidy
- HiRes timer
It's easy enough to remove these from the JMeter jars and zips, and ditto from CVS.
Now I don't think it would be unreasonable to ask developers to download these separately, but for users it's another matter.
I suspect we can get rid of some of these jars without causing any problems for users - e.g. Junit - but what do we do about the
rest?
The message will no doubt spawn a few discussions - if the way forward does not shortly become clear, we'll need to ask for
clarification.
S.
----- Original Message -----
From: "Jordi Salvat i Alabart" <js...@atg.com>
To: "JMeter Developers List" <jm...@jakarta.apache.org>
Sent: Tuesday, March 09, 2004 10:03 PM
Subject: [Fwd: Clarifying some licensing issues for Apache developers]
I'd say we're into several counts of policy breach?
How are other 'application' (as opposed to 'library') projects coping
with these requirements?
-------- Original Message --------
Subject: Clarifying some licensing issues for Apache developers
Date: Tue, 9 Mar 2004 10:59:49 -0800 (PST)
From: Brian Behlendorf <br...@collab.net>
Reply-To: licensing@apache.org
To: committers@apache.org
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: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Clarifying some licensing issues for Apache developers]
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 9 Mar 2004, peter lin <jm...@yahoo.com> wrote:
> bsf is from IBM right?
You could simply migrate to Apache BSF <http://jakarta.apache.org/bsf/>.
The whole migration can be done by replacing package names on imports.
I don't think BSF has been in Sebb's list, though.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Clarifying some licensing issues for Apache developers]
Posted by peter lin <jm...@yahoo.com>.
htmlparser is ok, since we explicitly got a permission and the source files all have apache 2.0 license.
bsf is from IBM right? so that one may have to be downloaded manually.
looks like we will need to update the first page of jmeter documentation to tell users where to d/l all these jar files. we could write new apache replacements for these libs, but that feels like taking a huge step backwards.
peter lin
sebb@apache.org wrote:
Indeed, I was going to post about this, as we currently use the following non-Apache software:
- htmlparser (this may be OK)
- jdom
- js (rhino)
- junit (not needed at runtime)
- Tidy
- HiRes timer
It's easy enough to remove these from the JMeter jars and zips, and ditto from CVS.
Now I don't think it would be unreasonable to ask developers to download these separately, but for users it's another matter.
I suspect we can get rid of some of these jars without causing any problems for users - e.g. Junit - but what do we do about the
rest?
The message will no doubt spawn a few discussions - if the way forward does not shortly become clear, we'll need to ask for
clarification.
S.
----- Original Message -----
From: "Jordi Salvat i Alabart"
To: "JMeter Developers List"
Sent: Tuesday, March 09, 2004 10:03 PM
Subject: [Fwd: Clarifying some licensing issues for Apache developers]
I'd say we're into several counts of policy breach?
How are other 'application' (as opposed to 'library') projects coping
with these requirements?
-------- Original Message --------
Subject: Clarifying some licensing issues for Apache developers
Date: Tue, 9 Mar 2004 10:59:49 -0800 (PST)
From: Brian Behlendorf
Reply-To: licensing@apache.org
To: committers@apache.org
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: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------
Do you Yahoo!?
Yahoo! Search - Find what you�re looking for faster.