You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2004/03/11 14:54:19 UTC
[5.0] Problems with the next release
Hi,
There are some problems with the next release, with the decision from
the ASF board to mandate that all ASF releases are to be made of 100%
ASL 2.0 licensed components (as a side note, I'd like to add that this
is obviously a terrible decision). This has many consequences and some
questions marks are left (such as for the JCP provided elements we are
using).
With Tomcat 5.0.x, the most pressing problem is with JMX, since there
are no ASL 2.0 licensed implementations available.
The options seem to be:
A) Ship Tomcat 5.0.20 without JMX, and have it display a message with
instructions on how to install JMX if it's not present (basically,
everywhere but on JDK 1.5.0).
B) Ship the binaries from non ASF servers (we could setup a project for
that on Sourceforge). The sources can be shipped from the ASF servers as
before. It is unclear to me if we can legally call these binaries Apache
Tomcat or not.
Comments ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Problems with the next release
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat wrote:
> Hi,
>
> There are some problems with the next release, with the decision from
> the ASF board to mandate that all ASF releases are to be made of 100%
> ASL 2.0 licensed components (as a side note, I'd like to add that this
> is obviously a terrible decision). This has many consequences and some
> questions marks are left (such as for the JCP provided elements we are
> using).
>
> With Tomcat 5.0.x, the most pressing problem is with JMX, since there
> are no ASL 2.0 licensed implementations available.
>
> The options seem to be:
> A) Ship Tomcat 5.0.20 without JMX, and have it display a message with
> instructions on how to install JMX if it's not present (basically,
> everywhere but on JDK 1.5.0).
> B) Ship the binaries from non ASF servers (we could setup a project for
> that on Sourceforge). The sources can be shipped from the ASF servers as
> before. It is unclear to me if we can legally call these binaries Apache
> Tomcat or not.
>
> Comments ?
I send a note about this limitation to community@apache.org and hope to
see the board relax its position.
Here's what I send to the list :
> 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.
Should I understand that we could no more include third-party jars in
ASF products, for example mx4j jars in Tomcat ?
If it's the case this decision will put many, many users in big trouble
since they couldn't use anymore ready-to-run package (zip or tarball
containing everything needed for run).
As one of the founder of the JPackage Projet, www.jpackage.org, which
try to maintain a repository of java applications and libs, let me say
that the task is not so easy, and for now works only on RPM based boxes,
mostly Linux.
What should do non-RPM users ?
I could understand the board concern about incompatible license, but
when developpers select third-party software to make ASF products,
they take care of it isn't it ?
So I strongly suggest board to reconsider this point or we may see in
a near future ASF products distribution, containing both ASF and
required third party software, outside Apache servers and it will
not help users to find their way.
Am I exact in thinking that the original ASF goal is to provide real
products for real users, and that we should take care of users as much
as we take care of performance, stability ?
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: [5.0] Problems with the next release
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
>
> Here is a reply I got from the community list :
>
> This is not a complete prohibition on all third-party jars or
> libraries, but only on those third-party libraries which are
> licensed under terms more restrictive than the ASL.
>
Ask them is there any list of accepted licenses and libraries.
What about linking to static microsoft libraries?
What can assure them that contributed binaries (and the code itself) are
build with legally obtained software?
Do we need to sign that or ASF will perhaps provide us with the development
tools needed?
Perhaps they should think in that direction.
> However, mx4j is a good example because apparently it
> includes code licensed under the Jetty and Jython licenses
Reading this seems that they've already made a decision, without the will to
help us. What are we suppose to do? Hire a lawyer to clear every library
that has a feature to link with the property software or they will?
I mean, exactly the same situation as with the tomcat-connectors.
Seem that we cannot provide the binaries for that too, cause IIS apparently
doesn't falls nearly to the ASF license.
Are we linking to the any of the prohibited libraries (like api32, kernel32,
ws2_32)? I'm not sure.
Too many questions, and such a small head ;-).
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Problems with the next release
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> This is not a complete prohibition on all third-party jars or libraries,
> but
> only on those third-party libraries which are licensed under terms more
> restrictive than the ASL.
>
> In the case of mx4j, the code is licenced under the mx4j 1.0 License
> [1], which
> is a derivative of the ASL 1.1 license and therefore may potentially be
> included
> in ASF works.
>
> However, mx4j is a good example because apparently it includes code
> licensed
> under the Jetty and Jython licenses [2]. While I am not intimately
> familiar
> with mx4j, this may mean that the total legal effect of using mx4j is not
> contained within the mx4j license alone, but is in fact a combination of
> the
> terms of the three licenses. Since this combination may in fact be more
> restrictive than the terms in the mx4j license alone, the library may
> not be in
> the clear to be used by ASF projects. To confirm this, one would need to
> investigate all three licenses, understand which parts of mx4j fall
> outside of
> its own license, and then come to a decision on how the library can be
> used in
> the ASF.
>
> It is exactly this sort of confusion the ASF would like to avoid. While
> the
> mx4j developers may in fact be perfectly in compliance with using the
> Jetty and
> Jython licenses, users of mx4j will have to take into consideration not
> one, but
> _three_ licenses in order to determine how to legally use the library.
> Therefore, for the sake of our users it is best if an ASF product as a
> whole is
> licensed under terms no more restrictive than those set out in the ASL 2.0.
>
> For further inquries (including a specific resolution to the mx4j issue), I
> would suggest subscribing to the licensing@apache.org list.
This makes zero sense. None of the "more restrictive" licenses pose any
problem for binary redistribution. Anyway, I won't include mx4j, as I'm
not a lawyer, and I have a skewed opinion on licenses anyway.
The biggest question is: what's next ? (it seems painfully obvious: zero
non ASL 2.0 imports)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Problems with the next release
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat wrote:
> Bill Barker wrote:
>
>> I agree with Yoav that we can afford to wait a few days (if only so I
>> don't
>> have to take down the 3.3.2 binary distro :). However, I don't think
>> that,
>> without the ASF changing it's position, we can simply add some lines
>> to the
>> LICENSE file. That may work in C land, but in Java land it's the LGPL
>> argument all over again.
>
>
> I agree we can wait a few days until we reach a consensus.
>
>> IMHO, since we'd have to drop JMX and the Windows installer to ship from
>> ASF, B) is the only reasonable choice.
>
>
> We would have to drop the Windows installer as well :(
>
Here is a reply I got from the community list :
Quoting Henri Gomez <hg...@apache.org>:
>>
>> Should I understand that we could no more include third-party jars in
>> ASF products, for example mx4j jars in Tomcat ?
This is not a complete prohibition on all third-party jars or libraries, but
only on those third-party libraries which are licensed under terms more
restrictive than the ASL.
In the case of mx4j, the code is licenced under the mx4j 1.0 License
[1], which
is a derivative of the ASL 1.1 license and therefore may potentially be
included
in ASF works.
However, mx4j is a good example because apparently it includes code licensed
under the Jetty and Jython licenses [2]. While I am not intimately familiar
with mx4j, this may mean that the total legal effect of using mx4j is not
contained within the mx4j license alone, but is in fact a combination of the
terms of the three licenses. Since this combination may in fact be more
restrictive than the terms in the mx4j license alone, the library may
not be in
the clear to be used by ASF projects. To confirm this, one would need to
investigate all three licenses, understand which parts of mx4j fall
outside of
its own license, and then come to a decision on how the library can be
used in
the ASF.
It is exactly this sort of confusion the ASF would like to avoid. While the
mx4j developers may in fact be perfectly in compliance with using the
Jetty and
Jython licenses, users of mx4j will have to take into consideration not
one, but
_three_ licenses in order to determine how to legally use the library.
Therefore, for the sake of our users it is best if an ASF product as a
whole is
licensed under terms no more restrictive than those set out in the ASL 2.0.
For further inquries (including a specific resolution to the mx4j issue), I
would suggest subscribing to the licensing@apache.org list.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Problems with the next release
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> I agree with Yoav that we can afford to wait a few days (if only so I don't
> have to take down the 3.3.2 binary distro :). However, I don't think that,
> without the ASF changing it's position, we can simply add some lines to the
> LICENSE file. That may work in C land, but in Java land it's the LGPL
> argument all over again.
I agree we can wait a few days until we reach a consensus.
> IMHO, since we'd have to drop JMX and the Windows installer to ship from
> ASF, B) is the only reasonable choice.
We would have to drop the Windows installer as well :(
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Problems with the next release
Posted by Costin Manolache <cm...@yahoo.com>.
Bill Barker wrote:
> I agree with Yoav that we can afford to wait a few days (if only so I don't
> have to take down the 3.3.2 binary distro :). However, I don't think that,
> without the ASF changing it's position, we can simply add some lines to the
> LICENSE file. That may work in C land, but in Java land it's the LGPL
> argument all over again.
>
> IMHO, since we'd have to drop JMX and the Windows installer to ship from
> ASF, B) is the only reasonable choice.
+1 on B. This will give us the option to develop and ship modules that
depend on LGPL with the binary tomcat, without adding "legal risks" to ASF.
However this should only happen if we have consensus ( i.e. no -1 votes,
all committers in agreement ). Distributing only source code from ASF is
IMO an acceptable solution, there is no requirement for projects to
distribute binaries ( I believe the httpd distro is source, with only
contributed binaries ).
Creating a link from tomcat page to the sf project should also be
acceptable ( there are other projects linking to outside sites and
distributions that include their code ).
The name obviously can't be "tomcat" or "apache tomcat" - but there are
lots of commercial distributions including tomcat, so I'm sure we can
find an acceptable solution ( there is an ant-contrib on sf, we may do
a tomcat-contrib or tomcat-dist or something like that ).
Costin
>
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Thursday, March 11, 2004 5:54 AM
> Subject: [5.0] Problems with the next release
>
>
> Hi,
>
> There are some problems with the next release, with the decision from
> the ASF board to mandate that all ASF releases are to be made of 100%
> ASL 2.0 licensed components (as a side note, I'd like to add that this
> is obviously a terrible decision). This has many consequences and some
> questions marks are left (such as for the JCP provided elements we are
> using).
>
> With Tomcat 5.0.x, the most pressing problem is with JMX, since there
> are no ASL 2.0 licensed implementations available.
>
> The options seem to be:
> A) Ship Tomcat 5.0.20 without JMX, and have it display a message with
> instructions on how to install JMX if it's not present (basically,
> everywhere but on JDK 1.5.0).
> B) Ship the binaries from non ASF servers (we could setup a project for
> that on Sourceforge). The sources can be shipped from the ASF servers as
> before. It is unclear to me if we can legally call these binaries Apache
> Tomcat or not.
>
> Comments ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>
> ------------------------------------------------------------------------
>
>
> This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Problems with the next release
Posted by Bill Barker <wb...@wilshire.com>.
I agree with Yoav that we can afford to wait a few days (if only so I don't
have to take down the 3.3.2 binary distro :). However, I don't think that,
without the ASF changing it's position, we can simply add some lines to the
LICENSE file. That may work in C land, but in Java land it's the LGPL
argument all over again.
IMHO, since we'd have to drop JMX and the Windows installer to ship from
ASF, B) is the only reasonable choice.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, March 11, 2004 5:54 AM
Subject: [5.0] Problems with the next release
Hi,
There are some problems with the next release, with the decision from
the ASF board to mandate that all ASF releases are to be made of 100%
ASL 2.0 licensed components (as a side note, I'd like to add that this
is obviously a terrible decision). This has many consequences and some
questions marks are left (such as for the JCP provided elements we are
using).
With Tomcat 5.0.x, the most pressing problem is with JMX, since there
are no ASL 2.0 licensed implementations available.
The options seem to be:
A) Ship Tomcat 5.0.20 without JMX, and have it display a message with
instructions on how to install JMX if it's not present (basically,
everywhere but on JDK 1.5.0).
B) Ship the binaries from non ASF servers (we could setup a project for
that on Sourceforge). The sources can be shipped from the ASF servers as
before. It is unclear to me if we can legally call these binaries Apache
Tomcat or not.
Comments ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Problems with the next release
Posted by Peter Lin <tc...@yahoo.com>.
I have to agree. the decision affects a lot of apache projects. I hope ASF board changes the policy slightly and lengths the time for this to take place.
It's good to have Apache equivalents to many of the libraries being used in apache projects, but it's going to take time. I may have to create a SF project for the monitor plug, write a custom SAX documentHandler to parse the tomcat status, or assist the existing jaxb project on apache.
on jmeter-dev we were discussing the possibility of creating a SF project to distribute versions that don't need manual downloads, but most likely that might not be feasible. I would hate to see jakarta projects fork, just so we can provide complete distributions.
peter lin
Remy Maucherat <re...@apache.org> wrote:Hi,
There are some problems with the next release, with the decision from
the ASF board to mandate that all ASF releases are to be made of 100%
ASL 2.0 licensed components (as a side note, I'd like to add that this
is obviously a terrible decision). This has many consequences and some
questions marks are left (such as for the JCP provided elements we are
using).
With Tomcat 5.0.x, the most pressing problem is with JMX, since there
are no ASL 2.0 licensed implementations available.
The options seem to be:
A) Ship Tomcat 5.0.20 without JMX, and have it display a message with
instructions on how to install JMX if it's not present (basically,
everywhere but on JDK 1.5.0).
B) Ship the binaries from non ASF servers (we could setup a project for
that on Sourceforge). The sources can be shipped from the ASF servers as
before. It is unclear to me if we can legally call these binaries Apache
Tomcat or not.
Comments ?
R�my
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------
Do you Yahoo!?
Yahoo! Search - Find what you�re looking for faster.