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 PROTECTED]> > > -- > 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]>
