RE: LICENSE in .jar files
I guess I'm wondering what the legal definition of reverse-engineer means. To me that means disassemble. If I just write something that happens to have the same interface, inputs and outputs, to me that doesn't qualify as reverse-engineer but maybe thats just me. When my 5 year old stepson imitates my movements and voice intonations I don't feel like he reverse engineered me :-) -Andy On Wed, 2002-03-20 at 21:36, [EMAIL PROTECTED] wrote: On Thu, 21 Mar 2002, Conor MacNeill wrote: I don't know. IANAL. We really do need a lawyer. Anyway, in my view, you would not be able to legally run such a reverse engineered clone on a Sun You have a lawyer - or rather - the PMC has access to those beast. This is being worked on (even today - during the ASF board meeting) - and will be resolved. Feel free to keep bringing good examples of potential problems to [EMAIL PROTECTED] Dw -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] BTW. Define: release ;-) That sounds like former persident Bill Clinton with his define sexual relations. Such a question insinuates guilt, and that you are trying to find a letter of the law loop hole to be clever about. Lawers are like wolves, they'll eat you for lunch. You may think you have a loop hole, but just shed the right light, and it is exposed. You're always better following the spirit of the law, because the devil is in the details (and in the pin striped suite) On Wed, 2002-03-20 at 19:55, Conor MacNeill wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Thu, 21 Mar 2002, Peter Donald wrote: I think what Peter said was that you can read the spec only if you agree with the licence, and that prevents you from implementing it unless you follow all the rules. You can read the spec. You just can't use the spec to create a cleanroom implementation of the specification. You can still read it to understand how to use somebody else's implementation. Presumably, however, having read the spec, you are tainted. That includes the requirement to pass the official test suite, and probably other restrictions I don't understand. The problematic clause is this one, I presume: (vi) satisfies all testing requirements available from the Specification Lead 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; Presumably we cannot distribute the xml-apis unless we can meet this requirement of the spec. This page http://jcp.org/aboutJava/communityprocess/final/jsr063/ asserts that there is a JAXP TCK, although you can't seem to purchase it online. Other restrictions - who knows? When the spec says (vii) does not derive from any of the Specification Lead's source code or binary code materials;, it is not clear to me what that covers, especially in the case of JAXP where I think the RI comes from Apache, based on code originally contributed by the Specification Lead (Sun). Also there may be a specific Out-of-Band Sun-Apache licence in place as alluded to by Dirk earlier. It's obvious some of the people who worked on this did read the spec - so it seems this is not a legal implementation. If there is no specific agreement between Sun and Apache covering this, then I agree. The licencing and jcp lists are closed to the public, and this seems to be the job of the PMC and ASF ( to verify that all the software is legally used ). I can only hope a lawyer will be used to validate it. If this is not resolved - we have to start removing all dependencies to JAXP and all other APIs that are not legal, and eventually work on replacements. There is no other way. I presume you can still depend on JAXP without having your own clean room implementation, nor including it in a distribution. You would have to require the user to acquire their own copy of the jaxp classes/interfaces. I haven't seen any restrictions in the spec on linking. Conor -- To unsubscribe, e-mail: mailto:general- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555 .html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- 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 in .jar files
acoliver wrote: I do. I was just curious. Have you a licence for that? :-) It's a mad world. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
Sorry for my tangent - it's clear that on legal matters, I should just
get the heck outta Dodge and let someone with more patience work on it.
8-{
I've forwarded a link (with threading) to your (Conor's) message to the
xml PMC so they should be aware of this licensing issue with JAXP and xml-commons.
=
- Shane
eof aka=mailto:[EMAIL PROTECTED];
.sig=Du sublime au ridicule il n'y a qu'un pas. /
__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
So could a non-tainted person through black box testing produce their own JAXP clone? -Andy On Wed, 2002-03-20 at 19:55, Conor MacNeill wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Thu, 21 Mar 2002, Peter Donald wrote: I think what Peter said was that you can read the spec only if you agree with the licence, and that prevents you from implementing it unless you follow all the rules. You can read the spec. You just can't use the spec to create a cleanroom implementation of the specification. You can still read it to understand how to use somebody else's implementation. Presumably, however, having read the spec, you are tainted. That includes the requirement to pass the official test suite, and probably other restrictions I don't understand. The problematic clause is this one, I presume: (vi) satisfies all testing requirements available from the Specification Lead 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; Presumably we cannot distribute the xml-apis unless we can meet this requirement of the spec. This page http://jcp.org/aboutJava/communityprocess/final/jsr063/ asserts that there is a JAXP TCK, although you can't seem to purchase it online. Other restrictions - who knows? When the spec says (vii) does not derive from any of the Specification Lead's source code or binary code materials;, it is not clear to me what that covers, especially in the case of JAXP where I think the RI comes from Apache, based on code originally contributed by the Specification Lead (Sun). Also there may be a specific Out-of-Band Sun-Apache licence in place as alluded to by Dirk earlier. It's obvious some of the people who worked on this did read the spec - so it seems this is not a legal implementation. If there is no specific agreement between Sun and Apache covering this, then I agree. The licencing and jcp lists are closed to the public, and this seems to be the job of the PMC and ASF ( to verify that all the software is legally used ). I can only hope a lawyer will be used to validate it. If this is not resolved - we have to start removing all dependencies to JAXP and all other APIs that are not legal, and eventually work on replacements. There is no other way. I presume you can still depend on JAXP without having your own clean room implementation, nor including it in a distribution. You would have to require the user to acquire their own copy of the jaxp classes/interfaces. I haven't seen any restrictions in the spec on linking. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
BTW. Define: release ;-) On Wed, 2002-03-20 at 19:55, Conor MacNeill wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Thu, 21 Mar 2002, Peter Donald wrote: I think what Peter said was that you can read the spec only if you agree with the licence, and that prevents you from implementing it unless you follow all the rules. You can read the spec. You just can't use the spec to create a cleanroom implementation of the specification. You can still read it to understand how to use somebody else's implementation. Presumably, however, having read the spec, you are tainted. That includes the requirement to pass the official test suite, and probably other restrictions I don't understand. The problematic clause is this one, I presume: (vi) satisfies all testing requirements available from the Specification Lead 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; Presumably we cannot distribute the xml-apis unless we can meet this requirement of the spec. This page http://jcp.org/aboutJava/communityprocess/final/jsr063/ asserts that there is a JAXP TCK, although you can't seem to purchase it online. Other restrictions - who knows? When the spec says (vii) does not derive from any of the Specification Lead's source code or binary code materials;, it is not clear to me what that covers, especially in the case of JAXP where I think the RI comes from Apache, based on code originally contributed by the Specification Lead (Sun). Also there may be a specific Out-of-Band Sun-Apache licence in place as alluded to by Dirk earlier. It's obvious some of the people who worked on this did read the spec - so it seems this is not a legal implementation. If there is no specific agreement between Sun and Apache covering this, then I agree. The licencing and jcp lists are closed to the public, and this seems to be the job of the PMC and ASF ( to verify that all the software is legally used ). I can only hope a lawyer will be used to validate it. If this is not resolved - we have to start removing all dependencies to JAXP and all other APIs that are not legal, and eventually work on replacements. There is no other way. I presume you can still depend on JAXP without having your own clean room implementation, nor including it in a distribution. You would have to require the user to acquire their own copy of the jaxp classes/interfaces. I haven't seen any restrictions in the spec on linking. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LICENSE in .jar files
On Thu, 21 Mar 2002 13:03, Andrew C. Oliver wrote: So could a non-tainted person through black box testing produce their own JAXP clone? I don't see how as they need access to Suns IP someway and there is no way to get a license to do that. Ie can't use spec without being tainted and can't use any *legal* implementation of spec because all legal implementations are not able to grant the right of reimplementation. I doubt that would hold up in court but it has held up various opensource projects that are actually concerned about legalities (see the GNU Classpath archives). Fun fun fun. -- Cheers, Pete ** | Trying is the first step to failure. | | So never try, Lisa - Homer Jay Simpson | ** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
-Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Thursday, 21 March 2002 1:03 PM To: Jakarta General List Subject: RE: LICENSE in .jar files So could a non-tainted person through black box testing produce their own JAXP clone? -Andy I don't know. IANAL. We really do need a lawyer. Anyway, in my view, you would not be able to legally run such a reverse engineered clone on a Sun JDK From the JDK 1.4 licence. Java Technology Restrictions. You may not modify the Java Platform Interface (JPI, identified as classes contained within the java package or any subpackages of the java package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create, additional classes, interfaces, or subpackages that are in any way identified as java, javax, sun or similar convention as specified by Sun in any naming convention designation. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
-Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Thursday, 21 March 2002 1:10 PM To: Jakarta General List Subject: RE: LICENSE in .jar files BTW. Define: release ;-) I guess it would be up to a court to define release :-) I don't know what it means :-) There are similar definition problems with terms such as distribution. Does providing a jar in CVS consistute distribution. Probably does. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
On Thu, 21 Mar 2002, Conor MacNeill wrote: I don't know. IANAL. We really do need a lawyer. Anyway, in my view, you would not be able to legally run such a reverse engineered clone on a Sun You have a lawyer - or rather - the PMC has access to those beast. This is being worked on (even today - during the ASF board meeting) - and will be resolved. Feel free to keep bringing good examples of potential problems to [EMAIL PROTECTED] Dw -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LICENSE in .jar files
Well, This may work if: 1 the license applies to the redistributed version 2 or this license is provided only as a proof of purchase (that is a receipt that allows ASF to distribute this) but something more has to be indicated, that is, how to get it for yourself so as to be able to redistribute it The problem is the following: I'm still expecting some advice from our lawyers but I understand currently that ALL Sun licenses are non-transferable. As such, anyone in the name of ASF may include this in one of the ASF packages but it does give no rights to redistribute to anyone that receives this (e.g. me downloading Ant) (*1). So that: folks receiving such a package should be indicated that they can redistribute Apache software but not Sun software and, if they want to use Sun software, that they should pick their version at Sun's site. (this also involves that Sun maintains such links alive, it is not the case of Jaxp 1.1... until we're sure they do this, it may make sense to URGE downloaders to get their copy right now) After good thoughts, I feel this a bit like a trap as for many things, there is no way to get rid of Sun interface class files. A complete readme, giving pointers to download your own lawful version of jaxp.jar, would also include how to live without jaxp.jar, if this is possible. Getting rid of servlet.jar, for example, seems way harder... So that... license in .jar files ?? Maybe, but with a readme indicating that one is bound by the conditions of this license even though one has never read it... Paul (*1) Actually, I am sure a dreaded crazy guy may even say that the action of cvs-update is already a redistribution so that another person, maybe not lawfully member of ASF would be prohibited to build a distribution PS: JDOM beta 8 (see http://www.jdom.org) just did it almost as you say, they now have licenses and pointers to original projects, they did not say anything about redistribution though... On Vendredi, mars 15, 2002, at 03:09 , Kevin A. Burton wrote: Jus thinking out loud. Would it be a good protocol to put a LICENSE file in .jar files under META-INF ? Specifically with the JCP stuff and some JAR files that come from SUN and can't be redistributed. Thanks. Comments appreciated. Kevin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LICENSE in .jar files
on 3/14/02 6:09 PM, Kevin A. Burton [EMAIL PROTECTED] wrote: Would it be a good protocol to put a LICENSE file in .jar files under META-INF ? Sure. *poof* it is now done in all of the Jakarta projects. Don't you like magic like that? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LICENSE in .jar files
On 3/14/02 9:17 PM, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 3/14/02 6:09 PM, Kevin A. Burton [EMAIL PROTECTED] wrote: Would it be a good protocol to put a LICENSE file in .jar files under META-INF ? Sure. *poof* it is now done in all of the Jakarta projects. Don't you like magic like that? Wouldn't it be great if there was a BMW 530 in my garage when I wake up tomorrow? (your cue, Jon... Blond/toledo, sport, cold, split seats, xenon) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LICENSE in .jar files
On Thu, 2002-03-14 at 22:16, Geir Magnusson Jr. wrote: On 3/14/02 9:17 PM, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 3/14/02 6:09 PM, Kevin A. Burton [EMAIL PROTECTED] wrote: Would it be a good protocol to put a LICENSE file in .jar files under META-INF ? Sure. *poof* it is now done in all of the Jakarta projects. Don't you like magic like that? Wouldn't it be great if there was a BMW 530 in my garage when I wake up tomorrow? oooh mee too mee tooo!!! Thanks Papa Jon! (your cue, Jon... Blond/toledo, sport, cold, split seats, xenon) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
