Re: License issue (the come back)
Ainsi parlait Jon Scott Stevens :
on 3/12/02 7:05 AM, Guillaume Rousse [EMAIL PROTECTED] wrote:
So we did, and here is the result
You didn't find licenses for a lot of software that has licenses...instead
of saying 'no license' which implies that it does not have a license, you
should have stated ('could not find a license')...
I went through the java.sun.com website and in about 30 seconds found the
licenses for the first 3 'no license' items below...you can do the rest of
the work...
As stated in my original mail :
no license means in current package only
Real problem is not to have exhaustive list, but to discuss the correct
behaviour to adopt regarding a given license combination.
--
Guillaume Rousse [EMAIL PROTECTED]
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
... - I looked at the license and the words Ex: You have chosen to download Java(TM) Message Service (JMS) API -- Javadoc 1.0.2b Sun Microsystems, Inc. Binary Code License Agreement Two things - the mailing list [EMAIL PROTECTED] is more geared towards this and filled with people who actually enjoy these things. Secondly - the license you see in the above case is *NOT* the license the ASF needs to be able ot distribute. What you see is the license under which you, the end user, gets the code. This is not nessesarily the same as the license needed by an entity such as the ASF to re-distrubute code. In the open source world, e.g. with an ASF license, it happens to be that those two are identical - but in the general case, and sepcifically in the case of SUN, that is not so. For this reason we actually have several contracts negotiated out of band with SUN to this effect. Dw -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
Ainsi parlait [EMAIL PROTECTED] : The BCL states that you cannot make a distribution of the .jar file outside of your product. In other words, if you want to distribute the single .jar file, you can't do that. (i) distribute the Software complete and unmodified and only bundled as part of your Programs Well, the very reason that we package this proprietary stuff is precisely that they are needed by other packages (otherwise we wouldn't provide them). So even if included in separate files, they are actually distributed as dependencies of other softwares. If our program is our complete set of packages, we could consider them as bundled inside. [..] BTW, the clause 'complete and unmodified' is very interesting - does it refers to the jar or the whole binary package ( most people refer to the whole downloaded package as 'software', and the jar is a piece of it ). If so, tomcat and most other packages that include it are breaking the licences, since they repackage and include only the jar. 'Software' is previously defined as 'accompanying software and documentation and any error corrections provided by Sun (collectively Software) Right, and providing them in full packages with documentation, license and other original files, as we do, is more respectful in this regard. -- Guillaume Rousse [EMAIL PROTECTED] GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
Ainsi parlait GOMEZ Henri : We have setup [EMAIL PROTECTED] for that reason (this is also commonly discussed on [EMAIL PROTECTED] and [EMAIL PROTECTED]) and both list are not available to basic commiters ? But the first one is: try [EMAIL PROTECTED] -- Guillaume Rousse [EMAIL PROTECTED] GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
On Wed, 13 Mar 2002 11:41, [EMAIL PROTECTED] wrote: BTW, the clause 'complete and unmodified' is very interesting - does it refers to the jar or the whole binary package ( most people refer to the whole downloaded package as 'software', and the jar is a piece of it ). If so, tomcat and most other packages that include it are breaking the licences, since they repackage and include only the jar. 'Software' is previously defined as 'accompanying software and documentation and any error corrections provided by Sun (collectively Software) yep ;) Even more fun is the restriction on creating 'java., javax., or sun.' packages. Does it mean that you're not allowed to include open source ( and clean room ) implementations of javax. pacakges if you include one of those licences ? yep. The only possible conclusion is that software shouldn't be redistributed without a lawyer checking and aproving every included license, and we need a list of licenses that are acceptable for inclusion on packages we distribute ( from jakarta, xml, etc ), verified by a lawyer. Correct - but even packages that presumably have IBM (and sun?) people working on them have questionable legalities. Take xerces (or crimson), at one stage they included the jaxp source code and even if it doesn't anymore it surely links against it. However I can't see how this is even vaguely legal - due to the licensing issues brought up recently wrt the JCP process. It uses the products of the JCP and I am not aware of any different licensing policy for the jaxp stuff. Nor am I aware of any publically avaiable TCK for the JAXP library which means that apaches xml parser is in violation of the license for JAXP spec. I could be wrong but thats how I understand it and as such even major projects at Apache are not legal. Fun eh? I presume there is some form of implied consent/licensing or somethin gthat may hold up if it ever went to court but even then I really dislike the fact that we have to rely on the good will of a company not to sue apache or even worse to sue Apaches users ;( Then again IANAL and could be completely wrong? Anyone want to explain why I am wrong? :) -- Cheers, Pete You know what a dumbshit the 'average man' on the street is? Well, by definition, half of them are even dumber than that! J.R. Bob Dobbs -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
-Original Message- From: Peter Donald [mailto:[EMAIL PROTECTED]] [...] I presume there is some form of implied consent/licensing or somethin gthat may hold up if it ever went to court but even then I really dislike the fact that we have to rely on the good will of a company not to sue apache or even worse to sue Apaches users ;( Then again IANAL and could be completely wrong? Anyone want to explain why I am wrong? :) I believe this is somewhat the same mess about GPL and dynamic linking. http://lwn.net/2001/0628/a/esr-modules.php3 No one is able to figure what it means and from what I understand from Eric Raymond post this is somewhat 'oh wait, I'm saying this but this is subject to change anytime and anyway this can be overruled by a legal decision some day depending on how they interpret it. For now I say this but eh, good luck.' Awesome. All this 'smoke' is I believe absolutely intentional to reserve room for future legal actions in case an entity becomes a little bit 'annoying'. Stephane -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
On Wed, 13 Mar 2002, Peter Donald wrote: Correct - but even packages that presumably have IBM (and sun?) people working on them have questionable legalities. Take xerces (or crimson), at one stage they included the jaxp source code and even if it doesn't anymore it surely links against it. They still include the jaxp source code, in xml-commons. But it's a clean-room implementation, made directly from the spec. AFAIK the people who wrote the code were not in the expert group when they wrote it. It's a bit strange, since trax was incorporated in jaxp1.1, but the code existed on apache even before was part of the spec. Nor am I aware of any publically avaiable TCK for the JAXP library which means that apaches xml parser is in violation of the license for JAXP spec. I could be wrong but thats how I understand it and as such even major projects at Apache are not legal. Fun eh? Probably it only mean it can't have a logo with 'jaxp' on it. We also use a clean room implementation of JMX in tomcat, same thing probably applies there. AFAIK ( and again don't take my word for it, call your lawyer :-), clean room implementations based on a published spec are perfectly legal. Probably the name/logo is protected, but saying that your code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 'compatible' ) should be ok. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
Hi Costin, Does not the DMCA expressly prohibit reverse-engineering? Or is it just legaleze, not applicable in the real world? Un saludo, Alex. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 13 de marzo de 2002 17:04 Para: Jakarta General List Asunto: Re: License issue (the come back) [snip] AFAIK ( and again don't take my word for it, call your lawyer :-), clean room implementations based on a published spec are perfectly legal. Probably the name/logo is protected, but saying that your code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 'compatible' ) should be ok. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
On Wed, 13 Mar 2002, Fernandez Martinez, Alejandro wrote: Does not the DMCA expressly prohibit reverse-engineering? Or is it just legaleze, not applicable in the real world? Implementing a published API/specification have nothing to do with reverse-engineering and I don't think it is prohibited. What seems to be prohibited by the words in the licence is distributing a BCL jar togheter with a clean-room implementation of another spec ( which require implementing javax./java. classes ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
on 3/13/02 9:31 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Implementing a published API/specification have nothing to do with reverse-engineering and I don't think it is prohibited. Nope. It isn't. I re-implemented a BEA specification (dbKona) based on their publicly available javadoc's. http://share.whichever.com/index.php?SCREEN=village -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
That's good news. Thanks a lot, Alex. -Mensaje original- De: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 13 de marzo de 2002 18:52 Para: [EMAIL PROTECTED] Asunto: Re: License issue (the come back) on 3/13/02 9:31 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Implementing a published API/specification have nothing to do with reverse-engineering and I don't think it is prohibited. Nope. It isn't. I re-implemented a BEA specification (dbKona) based on their publicly available javadoc's. http://share.whichever.com/index.php?SCREEN=village -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
From http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf, the latest J2EE specification. Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Sun's intellectual property rights that are essential to practice the Specification, to internally practice the Specification solely for the purpose of creating a clean room implementation of the Specification that: (i) includes a complete implementation of the current version of the Specification, without subsetting or supersetting; (ii) implements all of the interfaces and functionality of the Specification, as defined by Sun, without subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by Sun in the Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all of the interfaces and functionality of such optional components, without subsetting or supersetting; (v) does not add any additional packages, classes or interfaces to the java.* or javax.* packages or subpackages (or other packages defined by Sun); (vi) satisfies all testing requirements available from Sun relating to the most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; (vii) does not derive from any Sun source code or binary code materials; and (viii) does not include any Sun source code or binary code materials with-out an appropriate and separate license from Sun.The Specification contains the proprietary information of Sun and may only be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from Sun if you fail to comply with any provision of this license. Upon termina-tion or expiration, you must cease use of or destroy the Specification. OTOH, this, from the JMX spec: This document and the technology it describes are protected by copyright and distributed under licenses restricting their use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. So it looks like clean room uncertified products that implement JMX are OK. They are not for J2EE. According to these licenses, in any case. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 11:04 AM To: Jakarta General List Subject: Re: License issue (the come back) On Wed, 13 Mar 2002, Peter Donald wrote: Correct - but even packages that presumably have IBM (and sun?) people working on them have questionable legalities. Take xerces (or crimson), at one stage they included the jaxp source code and even if it doesn't anymore it surely links against it. They still include the jaxp source code, in xml-commons. But it's a clean-room implementation, made directly from the spec. AFAIK the people who wrote the code were not in the expert group when they wrote it. It's a bit strange, since trax was incorporated in jaxp1.1, but the code existed on apache even before was part of the spec. Nor am I aware of any publically avaiable TCK for the JAXP library which means that apaches xml parser is in violation of the license for JAXP spec. I could be wrong but thats how I understand it and as such even major projects at Apache are not legal. Fun eh? Probably it only mean it can't have a logo with 'jaxp' on it. We also use a clean room implementation of JMX in tomcat, same thing probably applies there. AFAIK ( and again don't take my word for it, call your lawyer :-), clean room implementations based on a published spec are perfectly legal. Probably the name/logo is protected, but saying that your code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 'compatible' ) should be ok. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
So when someone is publishing a book he can attach a licence and restrict the way the information in the book is used ? We're not talking about copyrights here - this is not about redistributing the spec - but about what you can do with what you learn by reading a book ( or how you can listen a song, talk about it etc ). I remember reading somewhere about some fair use of published information and books, but didn't know that this can be restricted. I should start reading the prefaces of the books, maybe they'll start including a licence and 'if you disagree with the terms, you must burn the book imediately'. Costin On Wed, 13 Mar 2002, Steve Downey wrote: From http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf, the latest J2EE specification. Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Sun's intellectual property rights that are essential to practice the Specification, to internally practice the Specification solely for the purpose of creating a clean room implementation of the Specification that: (i) includes a complete implementation of the current version of the Specification, without subsetting or supersetting; (ii) implements all of the interfaces and functionality of the Specification, as defined by Sun, without subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by Sun in the Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all of the interfaces and functionality of such optional components, without subsetting or supersetting; (v) does not add any additional packages, classes or interfaces to the java.* or javax.* packages or subpackages (or other packages defined by Sun); (vi) satisfies all testing requirements available from Sun relating to the most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; (vii) does not derive from any Sun source code or binary code materials; and (viii) does not include any Sun source code or binary code materials with-out an appropriate and separate license from Sun.The Specification contains the proprietary information of Sun and may only be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from Sun if you fail to comply with any provision of this license. Upon termina-tion or expiration, you must cease use of or destroy the Specification. OTOH, this, from the JMX spec: This document and the technology it describes are protected by copyright and distributed under licenses restricting their use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. So it looks like clean room uncertified products that implement JMX are OK. They are not for J2EE. According to these licenses, in any case. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 11:04 AM To: Jakarta General List Subject: Re: License issue (the come back) On Wed, 13 Mar 2002, Peter Donald wrote: Correct - but even packages that presumably have IBM (and sun?) people working on them have questionable legalities. Take xerces (or crimson), at one stage they included the jaxp source code and even if it doesn't anymore it surely links against it. They still include the jaxp source code, in xml-commons. But it's a clean-room implementation, made directly from the spec. AFAIK the people who wrote the code were not in the expert group when they wrote it. It's a bit strange, since trax was incorporated in jaxp1.1, but the code existed on apache even before was part of the spec. Nor am I aware of any publically avaiable TCK for the JAXP library which means that apaches xml parser is in violation of the license for JAXP spec. I could be wrong but thats how I understand it and as such even major projects at Apache are not legal. Fun eh? Probably it only mean it can't have a logo with 'jaxp' on it. We also use a clean room implementation of JMX in tomcat, same thing probably applies there. AFAIK ( and again don't take my word for it, call your lawyer :-), clean room implementations based on a published spec are perfectly legal. Probably the name/logo is protected, but saying that your code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 'compatible' ) should be ok. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL
RE: License issue (the come back)
Does not the DMCA expressly prohibit reverse-engineering? Or is it just legaleze, not applicable in the real world? The DMCA is about circumventing copy right protecting devices or constructs. Implementing a library based on a public description of an API; where this description is obtained under a license which allows for such implementations is a different story. Though in this specific case - you propably may be allowed to implement it from the API - mixing own implementation with other essential components you have not written - i.e. packaging for distribution may be harder - as you may not be able to add any javax classes or any third party jar with it. Also note that there is still some complexity with regard to the above license you get with the description - as a description -without- a license may mean you can implement but not re-distribute those parts you learned from the description and (c) right issues on the actual description as carried into your implementation. Dw. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
.. I remember reading somewhere about some fair use of published information and books, but didn't know that this can be restricted. I should start reading the prefaces of the books, maybe they'll start including a licence and 'if you disagree with the terms, you must burn the book imediately'. .. you should return this information inmediately and will be reimbursed. Commercial in confidence. Dw. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
On Thu, 14 Mar 2002 03:04, [EMAIL PROTECTED] wrote: On Wed, 13 Mar 2002, Peter Donald wrote: Correct - but even packages that presumably have IBM (and sun?) people working on them have questionable legalities. Take xerces (or crimson), at one stage they included the jaxp source code and even if it doesn't anymore it surely links against it. They still include the jaxp source code, in xml-commons. But it's a clean-room implementation, made directly from the spec. The directly from the spec is where the problem lies. It uses suns IP and thus must the TCK. We don't and thus we are in violation of the license and thus Apache and every user is open to being sued if sun chooses to do so. Nor am I aware of any publically avaiable TCK for the JAXP library which means that apaches xml parser is in violation of the license for JAXP spec. I could be wrong but thats how I understand it and as such even major projects at Apache are not legal. Fun eh? Probably it only mean it can't have a logo with 'jaxp' on it. nope - if you use the IP then it needs to pass TCK - to do otherwise is not legal. Unless we have another license agreement concerning jaxp with Sun that is unpublished (as alluded to before) then we are not legal. It may be thrown out in court but it is still expensive to fight it. We also use a clean room implementation of JMX in tomcat, same thing probably applies there. JMX has always been under a different license and I didn't think you had a clean room impl you just had some MBeans. AFAIK ( and again don't take my word for it, call your lawyer :-), clean room implementations based on a published spec are perfectly legal. Probably the name/logo is protected, but saying that your code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 'compatible' ) should be ok. Wrong - at least as I understand the licensing issue. To implement the spec(s) in many cases you must pass the TCK. It can cost a fair chunk of $ to run against the TCK which pretty much excludes all opensource projects from ever legally implementing different specs (ie the XML ones we do at apache). -- Cheers, Pete The only way to discover the limits of the possible is to go beyond them into the impossible. -Arthur C. Clarke -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
On Thu, 14 Mar 2002, Peter Donald wrote: They still include the jaxp source code, in xml-commons. But it's a clean-room implementation, made directly from the spec. The directly from the spec is where the problem lies. It uses suns IP and thus must the TCK. We don't and thus we are in violation of the license and thus Apache and every user is open to being sued if sun chooses to do so. This is getting intersting... To be honest, I allways believed that Jaxp, and all are 'open standards'. ( i.e. they allow clean room implementation ) Again, we need a lawyer here - but if this is the case I think we should do something. There are plenty of open standards ( too many even :-), and if a spec is not open, it shouldn't be used - but an alternative ( or a new open standard ). I hear many java APIs are cloned to .net, and that a lot of .net is 'open standard' - I'm pretty sure it has a lot of APIs that could do the same thing as the non-open ones, and we can clone them in java. An open API/standard should be used whenever possible. nope - if you use the IP then it needs to pass TCK - to do otherwise is not legal. Unless we have another license agreement concerning jaxp with Sun that is unpublished (as alluded to before) then we are not legal. It may be thrown out in court but it is still expensive to fight it. That's why we need the list of software/licenses that we can use and redistribute, and what's not on the list shouldn't be used. Especially software that implements non-open standards. We also use a clean room implementation of JMX in tomcat, same thing probably applies there. JMX has always been under a different license and I didn't think you had a clean room impl you just had some MBeans. We use openjmx ( now called mx4j ), that's a clean-room impl of the spec ( AFAIK ) AFAIK ( and again don't take my word for it, call your lawyer :-), clean room implementations based on a published spec are perfectly legal. Probably the name/logo is protected, but saying that your code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 'compatible' ) should be ok. Wrong - at least as I understand the licensing issue. To implement the spec(s) in many cases you must pass the TCK. It can cost a fair chunk of $ to run against the TCK which pretty much excludes all opensource projects from ever legally implementing different specs (ie the XML ones we do at apache). Ok, I didn't know that - and I bet many other people are in the same situation. If anyone can confirm this with a professional, then I think it should be displayed pretty clearly on a visible page, and we should find alternative open standards to use. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
the story continues... JSPA community draft ballot results
Sad, but true: http://jcp.org/jsr/results/99-7-1.jsp /Steven -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: the story continues... JSPA community draft ballot results
Steven Noels [EMAIL PROTECTED] wrote: Sad, but true: http://jcp.org/jsr/results/99-7-1.jsp /Steven I don't know how much sadness there is in that vote. Of course it's not a victory, but reading from the comments of the different voters (at the bottom), the issues we raised were listened to, and given some thought. Especially if you read Caldera's and Apple's comments (two corporations really close to the open-source world - Caldera=Linux and Apple=Darwin - and who both voted yes), I feel that it might be ok now, but many will be watching in the future. But I believe that it really depends with what eyes you look at it (although I bet that at Sun they're celebrating! :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: the story continues... JSPA community draft ballot results
Pier Fumagalli wrote: I don't know how much sadness there is in that vote. Of course it's not a victory, but reading from the comments of the different voters (at the bottom), the issues we raised were listened to, and given some thought. Well, this is a vote prior to going public draft, so hopefully we are still able to raise even more attention and really get what we want. The comments of IBM and the like clearly indicate to me that the revised JSPA will be 'nirvana'. /Steven -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: the story continues... JSPA community draft ballot results
I wrote: The comments of IBM and the like clearly indicate to me that the revised JSPA will be 'nirvana'. ^^^ Uh-oh... 'not be nirvana', of course. Must go to bed ;-) /Steven -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: the story continues... JSPA community draft ballot results
Still I think it is time for a Jon style headline on the front page. Perhaps something with shock appeal like JSPA Vote Screws open source and makes Microsoft look open -- Just my opinion. Send a press release to CNET this time, they were quite interested. -Andy On Wed, 2002-03-13 at 17:42, [EMAIL PROTECTED] wrote: On Wed, 13 Mar 2002, Steven Noels wrote: Sad, but true: http://jcp.org/jsr/results/99-7-1.jsp Do not despair - you got something good - some biggies being quite vocal and supportive of a standpoint univocally attributed to apache -and- generally considered as reasonable and lofty. And rightly so ! The above page, and comments, are public. And this will be seen and will be picked up by the industry. Really - the pressure is all on SUN to fix things. And some big companies have said in public that they expect tangible fixes. Good work guys ! Dw -- Dirk-Willem van Gulik Comments From http://jcp.org/jsr/results/99-7-1.jsp: From On 11-Mar-2002, Apple voted YES with the following comment: Apple fully supports the issues that have been raised by Apache and others, but the new JSPA represents a good step forward relative to the current one. W On 11-Mar-2002, Apple voted YES with the following comment: Apple fully supports the issues that have been raised by Apache and others, but the new JSPA represents a good step forward relative to the current one. We believe taking this to community review may provide the input that is needed to refine the JSPA before it goes to public review. During the community review, we would like to work with the PMO to refine the JSPA to better reflect the needs of those participating in open source efforts. -- On 11-Mar-2002, HP voted YES with no comment. -- On 11-Mar-2002, Borland voted YES with no comment. -- On 11-Mar-2002, Fujitsu voted YES with no comment. -- On 11-Mar-2002, Oracle voted YES with no comment. -- *** On 11-Mar-2002, Macromedia voted NO with the following comment: The free and creative spirit of the JCP should be directly and clearly manifested and protected legally. The major objections from the open source community argue that this is not the case, and we feel that the current language does not directly quell these concerns. We would like to see the issues that Apache raises on behalf of the open source community resolved in the JSPA itself before moving forward. -- *** On 11-Mar-2002, BEA voted NO with the following comment: After considerable soul searching, BEA has decided to vote NO on this revision of the JSPA. While considerable effort has been exerted by all concerned and significant progress has been made, we still are not convinced that this JSPA would provide the level playing field we have long advocated for Java technologies. The concerns voice by Apache and the open source community is one avenue of concern as is the autocratic power that continues to be vested in spec leads enabling them to attempt mischief to obtain competitive advantage by controlling both the pace of innovation and the availability of that innovation to the marketplace. Unless and until these issues can be satisfactorily addressed, we prefer to stick with our current agreements. -- On 11-Mar-2002, Caldera voted YES with the following comment: Caldera agree with a lot of the concerns expressed by Apache. We would like to see more to be done to protect the interests of open source providers. -- *** On 11-Mar-2002, Compaq voted NO with the following comment: Compaq shares Apache's concerns and IBM's concerns that the JSPA proposed revision provides insufficient protection for interests of open source providers and competitors (as enumerated at http://jakarta.apache.org/site/jspa-position.html). Compaq must therefor vote no on this proposed revision -- On 11-Mar-2002, IONA voted YES with no comment. -- On 09-Mar-2002, Doug Lea ABSTAINED FROM VOTING with the following comment: I share most of Apache's concerns. However, I also think that it would be useful to open this up to the scrutiny of all JCP members, not just the EC. These two factors cancel themsleves out, hence I
Re: the story continues... JSPA community draft ballot results
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steven Noels [EMAIL PROTECTED] writes: Sad, but true: http://jcp.org/jsr/results/99-7-1.jsp I demand a recount! :) OK... this is strange: On 11-Mar-2002, Caldera voted YES with the following comment: Caldera agree with a lot of the concerns expressed by Apache. We would like to see more to be done to protect the interests of open source providers. Did Caldera understand what they voted for? If they agree with Apache why did they vote yes? Kevin - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/ Learn from other people's mistakes, you don't have time to make your own. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8j+Q3AwM6xb2dfE0RAsR4AJ4l845WxXM8X8Vn83rCvnGrlGWTRgCfbMGu hOiZLoxfiqM/8bx2Kpkt2Ho= =kYgJ -END PGP SIGNATURE- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
PMC Chair elelection
The first order of business for the new PMC is the election of a Chair. Would all PMC members indicate if they would be willing to act as Chair for the next 12 months. Once each PMC member has indicated their availability, we can proceed to an election. If there are more than three candidates, I propose a preferential voting system where each PMC member gives numbered preferences. If no candiate has a clear majority, the votes from the candidate with the least number of votes are distributed according to the indicated preferences. This process continues until one candidate has a majority (4 votes). If you are not happy with this process, that's OK - just -1 this email and propose an alternative. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: the story continues... JSPA community draft ballot results
On Wed, 13 Mar 2002, Sam Ruby wrote: Caldera agree with a lot of the concerns expressed by Apache. We would like to see more to be done to protect the interests of open source providers. Did Caldera understand what they voted for? If they agree with Apache why did they vote yes? Apparently, Apple, Caldera, and Doug Lea each felt that these issues are resolvable in the public review. Which makes sense - given what happened with W3C's public review of the rand issue. The issue is very similar, almost identical - and I hope the solution will be the same ( i.e. enough public comments to make it impossible for this to pass in the current form ). Now the problem is getting enough people to send feedback during the public review - and posting a clear pointer with the address to send comments to and the background informations on the main page ( or on all apache pages ) would be a good start. Slashdot will be another. I believe the 'public comments' are sent to all those who're supposed to vote, and is supposed to have a certain influence, isn't it ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Borland, Fujitsu, HP, IONA, Nokia, and Oracle voted with Sun tolock Open Source out of Java.
I like the title. :-) http://jakarta.apache.org/site/news.html#0313.1 -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
