Re: [5.0] Problems with the next release
- Original Message -
From: "Mladen Turk" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, March 12, 2004 3:24 AM
Subject: RE: [5.0] Problems with the next release
>
>
> > -Original Message-
> > From: jean-frederic clere
> >
> > Mladen Turk wrote:
> > >
> > > What about linking to static microsoft libraries?
> >
> > That is probably not OK.
> >
>
> I know that, but I know too that the law doesn't have a term _probably_ in
> it's dictionary.
>
> >
> > > Do we need to sign that or ASF will perhaps provide us with the
> > > development tools needed?
> >
> > Use Open Source tools and/or help to improve existing ones.
> >
>
> Again, Is it required to use open source tools or not?
> Is it up to me and my moral or is there some ASF board decision on that?
> I had to sign for my current company that will take care that there are no
> illegal software on my boxes (as probably everyone else did).
>
> Take a look at http(apr, apr-util, etc...). The win32 port has vstudio
build
> files (like our connectors). My question is, where those tools comes from?
> ASF or developers that have couple of 1000$ to spend?
> Also I heard that the ASF has an agreement with InstallShield. I would
love
> to receive a license for some of those tools if possible :-).
A quick look at the VS build files for httpd shows that they are using
dynamic linking for the MS stuff ("Multithreaded DLL"). The tools
themselves aren't really relevant: gcc is GPL and glibc is LGPL.
>
> Since all of the board members are from httpd project, seems to me that
all
> the decisions have been made through this point of view. It's not hard to
> implement this decisions for that particular project. They done this so
far,
> although for different reasons (no ssl enabled dist, etc...).
>
> Henri, Remy and Costin proposed to move the binaries to sourceforge, until
> the things clears up.
> I'm in favor of that, and will support such a decision if voted.
>
> MT.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Remy Maucherat wrote: Henri Gomez wrote: Please subscribe to [EMAIL PROTECTED] and follow the thread about 'clarification'. It seems there is a discussion on having non ASF binaries : 2) state that the ASF will allow the use of its infrastructure for the distribution of binary objects that are legally distributable standalone even if they do not originate from the ASF and are not covered by the apache license and create a policy that says that source code must be available alongside as well and no modification to the original packages must be in place [only patches alongside] Ok. So it's confusing ;) I'll revert my changes if the situation evolves. I suggest that we subscribe to [EMAIL PROTECTED] and participate to the thread ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Henri Gomez wrote: Please subscribe to [EMAIL PROTECTED] and follow the thread about 'clarification'. It seems there is a discussion on having non ASF binaries : 2) state that the ASF will allow the use of its infrastructure for the distribution of binary objects that are legally distributable standalone even if they do not originate from the ASF and are not covered by the apache license and create a policy that says that source code must be available alongside as well and no modification to the original packages must be in place [only patches alongside] Ok. So it's confusing ;) I'll revert my changes if the situation evolves. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Please subscribe to [EMAIL PROTECTED] and follow the thread about 'clarification'. It seems there is a discussion on having non ASF binaries : 2) state that the ASF will allow the use of its infrastructure for the distribution of binary objects that are legally distributable standalone even if they do not originate from the ASF and are not covered by the apache license and create a policy that says that source code must be available alongside as well and no modification to the original packages must be in place [only patches alongside] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Problems with the next release
> -Original Message- > From: Henri Gomez > >> Henri, Remy and Costin proposed to move the binaries to > sourceforge, > >> until > >> the things clears up. > >> I'm in favor of that, and will support such a decision if voted. > > Well I didn't agreed on moving TC binaries to sf or others. > Sorry, It's been a lots of mails :-). > > > I am not. Temporary solutions may last long time. Blocking > situations > > normaly evolve faster. > > Yes, what will happen with board if WE decide to stop make Tomcat > release until the problem get fixed ? > I've got a feeling like somebody pulled the plug. They've made a declaration vithout a solution how to fix that (well, except mentioning ibiblio and sf). Further more that mail from board looked like: 'I don't give a shit about you'. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Henri Gomez wrote: Well I didn't agreed on moving TC binaries to sf or others. I mentioned that being also involved in projet like Jpackage, I know that's producing ready to use packages is not so easy, expecially when you have to explain to users that they have to get MANY external jars from outside sites. As Mladen say, the board came mainly from httpd team and in the NATIVE world there is allready distributions which provide the missing/required parts, like openssl, glibc But in Java land, there is no REAL distributions (only jpackage for RPM users), and there is a HUGE difference. Indeed. This move is only thought out in respect to httpd and the related native projects. I am not. Temporary solutions may last long time. Blocking situations normaly evolve faster. Yes, what will happen with board if WE decide to stop make Tomcat release until the problem get fixed ? Bad idea: I think they don't care ;) Right now, I'm in favor of doing solution A, and removing some of the distributions (the .exe and the embedded dist). It doesn't prevent doing B as well. I think we should post a statement on the Tomcat website explaning the reasons for the disappearance of the distributions, as well as voicing our opposition (if we indeed all agree we are opposed to this) to the latest board decision. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
jean-frederic clere wrote: Mladen Turk wrote: -Original Message- From: jean-frederic clere Mladen Turk wrote: What about linking to static microsoft libraries? That is probably not OK. I know that, but I know too that the law doesn't have a term _probably_ in it's dictionary. Do we need to sign that or ASF will perhaps provide us with the development tools needed? Use Open Source tools and/or help to improve existing ones. Again, Is it required to use open source tools or not? No, it is required to avoid non ASF licensed elements in the binaries that are delivered by the ASF. We should ask about "contributed" builds (like the ones in apache/dist/httpd/binaries/) Is it up to me and my moral or is there some ASF board decision on that? I had to sign for my current company that will take care that there are no illegal software on my boxes (as probably everyone else did). Take a look at http(apr, apr-util, etc...). The win32 port has vstudio build files (like our connectors). My question is, where those tools comes from? ASF or developers that have couple of 1000$ to spend? I don't know I am (nearly) not using win32. Also I heard that the ASF has an agreement with InstallShield. I would love to receive a license for some of those tools if possible :-). Since all of the board members are from httpd project, seems to me that all the decisions have been made through this point of view. It's not hard to implement this decisions for that particular project. They done this so far, although for different reasons (no ssl enabled dist, etc...). Every one has an history. (ssl contains crypto some countries have restriction on such things). Henri, Remy and Costin proposed to move the binaries to sourceforge, until the things clears up. I'm in favor of that, and will support such a decision if voted. Well I didn't agreed on moving TC binaries to sf or others. I mentioned that being also involved in projet like Jpackage, I know that's producing ready to use packages is not so easy, expecially when you have to explain to users that they have to get MANY external jars from outside sites. As Mladen say, the board came mainly from httpd team and in the NATIVE world there is allready distributions which provide the missing/required parts, like openssl, glibc But in Java land, there is no REAL distributions (only jpackage for RPM users), and there is a HUGE difference. I am not. Temporary solutions may last long time. Blocking situations normaly evolve faster. Yes, what will happen with board if WE decide to stop make Tomcat release until the problem get fixed ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Mladen Turk wrote: -Original Message- From: jean-frederic clere Mladen Turk wrote: What about linking to static microsoft libraries? That is probably not OK. I know that, but I know too that the law doesn't have a term _probably_ in it's dictionary. Do we need to sign that or ASF will perhaps provide us with the development tools needed? Use Open Source tools and/or help to improve existing ones. Again, Is it required to use open source tools or not? No, it is required to avoid non ASF licensed elements in the binaries that are delivered by the ASF. We should ask about "contributed" builds (like the ones in apache/dist/httpd/binaries/) Is it up to me and my moral or is there some ASF board decision on that? I had to sign for my current company that will take care that there are no illegal software on my boxes (as probably everyone else did). Take a look at http(apr, apr-util, etc...). The win32 port has vstudio build files (like our connectors). My question is, where those tools comes from? ASF or developers that have couple of 1000$ to spend? I don't know I am (nearly) not using win32. Also I heard that the ASF has an agreement with InstallShield. I would love to receive a license for some of those tools if possible :-). Since all of the board members are from httpd project, seems to me that all the decisions have been made through this point of view. It's not hard to implement this decisions for that particular project. They done this so far, although for different reasons (no ssl enabled dist, etc...). Every one has an history. (ssl contains crypto some countries have restriction on such things). Henri, Remy and Costin proposed to move the binaries to sourceforge, until the things clears up. I'm in favor of that, and will support such a decision if voted. I am not. Temporary solutions may last long time. Blocking situations normaly evolve faster. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Problems with the next release
> -Original Message- > From: jean-frederic clere > > Mladen Turk wrote: > > > > What about linking to static microsoft libraries? > > That is probably not OK. > I know that, but I know too that the law doesn't have a term _probably_ in it's dictionary. > > > Do we need to sign that or ASF will perhaps provide us with the > > development tools needed? > > Use Open Source tools and/or help to improve existing ones. > Again, Is it required to use open source tools or not? Is it up to me and my moral or is there some ASF board decision on that? I had to sign for my current company that will take care that there are no illegal software on my boxes (as probably everyone else did). Take a look at http(apr, apr-util, etc...). The win32 port has vstudio build files (like our connectors). My question is, where those tools comes from? ASF or developers that have couple of 1000$ to spend? Also I heard that the ASF has an agreement with InstallShield. I would love to receive a license for some of those tools if possible :-). Since all of the board members are from httpd project, seems to me that all the decisions have been made through this point of view. It's not hard to implement this decisions for that particular project. They done this so far, although for different reasons (no ssl enabled dist, etc...). Henri, Remy and Costin proposed to move the binaries to sourceforge, until the things clears up. I'm in favor of that, and will support such a decision if voted. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
Mladen Turk wrote: -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? That is probably not OK. What can assure them that contributed binaries (and the code itself) are build with legally obtained software? "legally obtained software" if someone is using those he kills its own business! Do we need to sign that or ASF will perhaps provide us with the development tools needed? Use Open Source tools and/or help to improve existing ones. 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. You have to use dynamic linking... Cygwin brings the same API but the license is not ASF like and the API is not 100% compatible. Too many questions, and such a small head ;-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Problems with the next release
> -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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
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 <[EMAIL PROTECTED]>: >> >> 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 [EMAIL PROTECTED] list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
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" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [5.0] Problems with the next release
This account does not exist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
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" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Problems with the next release
Hi, >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 ? Wait for a couple of days (AFAIK there's no pressure to do 5.0.20 immediately) to see the board's reactions to our complaints and requests for clarification. If no changes occur (and I think they will: we'll just have to modify our license file to include a paragraph about MX4J) then we'd vote on the above (I tend to like option A at the moment). Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Problems with the next release
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Search - Find what youre looking for faster.
Re: [5.0] Problems with the next release
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED], 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
