Re: License issue (the come back)
Ainsi parlait Santiago Gala : [..] FYI: Some time ago, I was forbidden to download a java package because my ISP did not have reverse DNS address mapping properly setup, even though I'm in Spain, not a free world enemy, AFAIK. The message I got was something like we could not assess your origin country satisfactorily, consult technical support. So, Sun is/was using technical mappings between IP block ownership and country to enforce such provisions. I don't know the current status. I had to ssh to a machine that was granted the permission, download from there, and then put it in my machine from there. I was not breaking any law, since I'm allowed to download it. In a sense, they do the following: if the machine used to download the code is in an allowed country, it is not considered export, so they allow it, and transfer the export responsibility further down the chain. (sorry for this late answer) I know they use such kind of filtering based on your domain name. It also means just using a private indirection, as you did, or public redirect service as anonymiser.com bypass it easily. So we can say that Sun attempts to fulfill this clause, but not that they actually comply to. We could also have a banner saying if you're a evil guy (as defined by US state department), please do not click here with the same efficiency. -- 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)
-Original Message- From: Guillaume Rousse [mailto:[EMAIL PROTECTED]] [...] I know they use such kind of filtering based on your domain name. It also means just using a private indirection, as you did, or public redirect service as anonymiser.com bypass it easily. So we can say that Sun attempts to fulfill this clause, but not that they actually comply to. We could also have a banner saying if you're a evil guy (as defined by US state department), please do not click here with the same efficiency. That did not prevent a French tribunal to stupidely force Yahoo to do such filtering on french ips so that people could not see Nazi related items in auctions even though this is absolutely impossible to comply with this (what about aol users ? and others from company with a host located out of france ?, etc...) Yahoo was supposed to be fine $91,000 per day of violation. Not sure what is the status of this crap though but even if this is on, it would be piece of cake to bypass it. There was even an audition of Vinton Cerf which states the following in the report: It has been proposed that users identify where they are at the request of the web server, such as the one(s) serving yahoo.fr - or yahoo.com. There are several potential problems with this approach. For one thing, users can choose to lie about their locations. For another, every user of the web site would have to be asked to identify his or her location since the web server would have no way to determine a priori whether the user is French or is using the Internet from a French location. Some users consider such questions to be an invasion of privacy. While I am not completely acquainted with privacy provisions in the Europe Union, it might be considered a violation of the rights of privacy of European users, including French users to request this in formation. Of course if this information is required solely because of the French Court Order, one might wonder on what grounds all other users all over the world are required to comply. Another complaint about the idea of asking user for their location in that this might have to be done repeatedly by each web site that the user accesses - yahoo cannot force every web site to make this request. When a user first contacts the server(s) at yahoo.fr - or yahoo.com, one might imagine that the question of geographic location might be asked and then a piece of data called a cookie might be stored one the user's computer disk. Repeated visits to Yahoo sites might then refer to this cookie for user location information. The problem with this idea is that cookies are considered by many to be an invasion of privacy also, as a result many users either configure browsers to reject storage of cookies on their disk drives or they clear them away after each session on the Internet - thus forcing the query about geographical location each time the user encounters a Yahoo-controlled web site. Again, Yahoo would have no way to force a web site net under its control to either ask the location question or to request a copy of the cookie containing the location. Indeed, it would open up a vulnerability for each user if arbitrary web sites were told how to retrieve the cookie placed there by the Yahoo sites. It has been suggested that the filtering need only apply to users accessing the Internet from French Territories or by users who are French citizens. It is not clear whether the jurisdiction of the French Court extends to actions taken by French citizens who are not in French territory at the time of their access to Internet. For these and many other reasons, it does not appear to be very feasible to rely on discovering the geographic location of users for purposes of imposing filtering of the kind described in the Court Order. [...] report here: http://www.lapres.net/html/ya2011.html Stephane -- 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] : On Thu, 14 Mar 2002, GOMEZ Henri wrote: 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. jpackage need this kind of information to determine what could be freely present in its rpm distribution and what should be dropped. Yes, and it's important to find out which packages are indeed based on open standards and remove the others imediately. Not only because it's required by the licence, but because packaging them might get people to use them, and that's bad. That what we initially attempted to do , provide only free software, but we had to quickly adopt a less strict policy in order to have something to package... If a package is based on an open standard and a clean room implementation exists and is comparable with the reference and has better license - I think the choice should be clear too. Sure, but that choice depends of developpers, not of packagers... And the current question is: what to do when no alternative exists ? From current discussion, it seems everyone agrees main problem comes from BCL itself, and not additional software-specific clauses. There are actually two problems: 1) the bundled as part of your software clause 2) the US export laws compliance clause My personal understanding of the BCL allows me to consider distributing javamail in its own package ad part of a whole distribution project comply with 1). And the technical issue of 2) make me thinks it is pointless anyway. Now if someone can demonstrate me i'm wrong in either of those points, i'd be happy to revert to our old practice of distributing spec files only, and let final users build their own packages themselves. -- 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: Re: License issue (the come back)
On Fri, 15 Mar 2002 16:05:41 0100 Guillaume Rousse [EMAIL PROTECTED] wrote. Correct me if I'm wrong but if you break US law while in France without breaking any French laws and no US laws covered by extradition treaties, I don't think you care unless you enter the US physically (and have ticked off someone enough to notice). I also don't think a license can bind you to follow US law. Moot point for me, but maybe not for others. -- 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 07:51, [EMAIL PROTECTED] wrote: 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... Thats one way of describing it ;) To be honest, I allways believed that Jaxp, and all are 'open standards'. ( i.e. they allow clean room implementation ) Nope ;( 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. Its sad when you start thinking microsofts platform is more open :/ I think this may be an avenue depending on how the revision of the JCP goes. If it doesn't go well and someone with enough political correctness was willing to go for it I think it would be a very good way to progress. It would first be a matter of establishing relationships with other big players in Java world that have clout and are sympathetic to our situation. ie If we could set up a decent process and work with other standards organizations (ECMA, IEEE, W3C), have a relatively formal participation contract (and thus *safe* from eyes of corporate/IP lawyers) and finally make allies of organisations like IBM, Apple and whoever else then it would be viable for many things. We could even join up with existing opensource organizations to cross-pollinate ideas. Apache + GNU + Eclipse + Netbeans + JBoss would make an impressive opensource shard. IBM + Apple + others would make a fairly convincing commercial shard. Join em together and we have a new Java standards body. It still would be difficult to do anything with respect to the real core as Sun controls the source to a large degree. However for many of the other components/add-ons then it would be quite viable to do this. Especially if tools like JDiff+XDoclet could auotmate most API testing and functional testing could be done with JUnit or some other custom framework. It is not so much a technical problem but a marketing one. Given the right environment I think it could happen - best to wait and see how JCP reorg turns out though. -- Cheers, Pete -- An intellectual is someone who has been educated beyond their intelligence. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
Peter Donald wrote: ie If we could set up a decent process and work with other standards organizations (ECMA, IEEE, W3C), have a relatively formal participation contract (and thus *safe* from eyes of corporate/IP lawyers) and finally make allies of organisations like IBM, Apple and whoever else then it would be viable for many things. This would be good. Open source software has a strong position in the web marketplace. It should be possible to use that position to gain influence in standards processes. The IETF is an open body that sets network standards; why can't there be a similar body that standardises APIs? I do feel, however, that the appropriate model is the IETF, not the W3C. The W3C charges a fee for participation, which discriminates against open source efforts. It is better than JCP, but if we are designing our own standards body why settle for second best? The IETF has worked through the intellectual property problems. So for example when you attend a working group meeting you receive a piece of paper saying that you can't do a Rambus... The IETF will allow patented algorithms under certain circumstances. Of course we are free to decide not to. The IETF is a good model, IMHO, but we don't have to create an exact copy. It still would be difficult to do anything with respect to the real core as Sun controls the source to a large degree. Well, gcj is one free implementation of much of the core. At the same time, it would probably be unhelpful to come up with a revision of the core J2SE standard. It makes sense to concentrate on areas where standards are in more of a state of flux. -- Pete -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 14, 2002 12:07 PM To: Jakarta General List Subject: Re: License issue (the come back) snip / Please, not another standard body !!! Could someone check the definition of 'standard' ? Something, such as a practice or a product, that is widely recognized or employed, especially because of its excellence It is not something with the word 'standard' in the title, nor does it require a 'standard body' to give it this status. Apache httpd is a standard. Log4j is a standard. At lest 1/2 of the stuff that comes out of JCP is not standard ( by this definition ), even if it has the word standard in title and a standard body to put a stamp on it. We are talking about APIs - and my opinion is a good API requires a lot of feedback and iterations - that's not what the 'public review' can even be close to providing. No expert or expert group can substitute that, regardless of how good he is. Costin You chose a definition that suits your argument. In the industry, the definition is usually more like: That which is established by authority as a rule for the measure of quantity, extent, value, or quality; esp., the original specimen weight or measure sanctioned by government, as the standard pound, gallon, or yard. Source: Webster's Revised Unabridged Dictionary, C 1996, 1998 MICRA, Inc. Apache httpd isn't a standard in that sense. It implements a standard, the HTTP standard, RFC2616, and others. Log4J isn't a standard, it's a product. It's in wide use, but it isn't even universally used within Jakarta. Commons-logging is closer to a standard than Log4J. [Note, I use log4j in my applications. It *is* the standard that has been set within my company. That provides for interop between components that we develop.] Tomcat, on the other hand, is a standard. As a Reference Implementation of the Servlet and JSP specifications, it is authoritative when the specification is silent or ambiguous. If a web app functions correctly on Tomcat, and does not on, for example, WebSphere, then, unless Tomcat is demonstrably not implementing the spec, WebSphere is broken. RI doesn't mean sample code, or proof of concept, both of which are valuable, it means this is part of the definition. -- 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, Steve Downey wrote: You chose a definition that suits your argument. In the industry, the definition is usually more like: I just used google. That which is established by authority as a rule for the measure of quantity, extent, value, or quality; esp., the original specimen weight or measure sanctioned by government, as the standard pound, gallon, or yard. Source: Webster's Revised Unabridged Dictionary, C 1996, 1998 MICRA, Inc. But you need to look up 'authoritiy' first. Your definition is wrong from start: it's Kg, Meter, Celsius degree ! That's the _standard_, sanctioned by international organizations and most governments :-) Apache httpd isn't a standard in that sense. It implements a standard, the HTTP standard, RFC2616, and others. Log4J isn't a standard, it's a product. Again, that depends on the definition of the standard and the definition of authority. What's the standard for networks - OSI or TCP/IP ? By your definition, OSI ( since ISO is a government sanctioned organization - at least at that time IETF wasn't a big authority in comparation ). There are few doznes organizations that self-claim the 'authority' to create standards, and except for ISO and probably ECMA(?) I don't think too many are governement backed. The authority of W3C or IETF comes from the wide acceptance of ( some of ) their specifications. In this sense, JCP has the same authority with for example Microsoft standards. It's in wide use, but it isn't even universally used within Jakarta. Commons-logging is closer to a standard than Log4J. [Note, I use log4j in my applications. It *is* the standard that has been set within my company. That provides for interop between components that we develop.] Exaclty my point. Each company and project can decide what authority they recognize and the quality of the various (alternative) specifications. And it's perfectly reasonable to expect many organizations to not recognize non-open specifications as standards, regardless of the authority that propose it ( be it MSFT or JCP ). ( by non-open I mean specs with licences that prevent clean room implementation, of course that would also require a dictionary search ) Tomcat, on the other hand, is a standard. As a Reference Implementation of the Servlet and JSP specifications, it is authoritative when the I don't think tomcat is a standard, but parts of it may become, if other servers adopt it ( like webapps/ directory ). I think Ant is a standard - at least by my definition - even if it doesn't claim that. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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]
License issue (the come back)
Hello. They have been already *several* discussions about Sun proprietary APIs licenses, and more precisely about exact redistribution conditions. Current consensus in ASF, AFAIK, is that redistribution of crypto API (as jsse) is strictly forbidden, and redistribution of non-crypto APIS is not permitted with source code. We (jpackage project, http://jpackage.sourceforge.net) contacted sun legal department to have an official response on this topic. We exposed our own practices, that is to provide a non-free section for all normal APIs with standard packages, and a non-distributable section for all crypto APIs and JDKs, with empty packages. The only response we had was: read the license carefully :-) (kind of RTFM, actually) So we did, and here is the result non-free jaasBCL + LDS jaf BCL javahelpBCL + LDR javamailBCL + LDS jaxpBCL + LDS jdbc-stdext no license jimiBCL + LDS jms no license jndino license jta no license jtopen no package jts BCL + LD netbeans-java-extbinno license resolverno license non-distributable javacc ? jsseBCL + LD sun-jsdk1.3 BCL + LDS + LDR sun-jsdk1.4 BCL + LDS + LDR blackdown-jsdk1.3 BCL + LDS + LDR ibm-jsdk1.3 ? BCL means standard Binary Code License, which is the basic Sun Binary Code License for all software. Most java software add extra clauses, especially concerning redistribution, which are refered here as LDS (License to distribute software), LRD (License to distribute redistributables) and LD (License to distribute). Full citations of those clauses are included at the end of the message. no license means in current package only, and ? means uncertainity. My own interpretation follows: 1) There is nothing in any of those license making click-through procedure mandatory 2) There is no point having jsse and jts in different section are they are subject to exactly the same conditions 3) The US export laws enforcement clause is part of BCL, which apply to *all* packages, not only to crypto packages. 4) LDR refers to a a distributable section in README file, that was not found either in javahelp nor in JDKs The last point is the only real problem IMHO. Basically, it forbids to export software in free world ennemy countries TM. I don't know if making somone from such a country able to download software from a website could be considered software exportation, but considering the technical impossibility to prevent it, i doubt Sun itself could claims to fulfill it. Apart this problem, i still don't see what prevent distribution of all packages having at least one of those additional distribution clause (LD or LDS), as long as original license is preserved. LDR with a non-existent distributable section is not acceptable here. However, IANAL, and as I know ASF people have already stepped onto this problem, i would like your opinion here. Thanks for your help. LDS 2. License to Distribute Software. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java (TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Java applets or applications (Programs), (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. LD 1. License to Distribute. Sun grants you a non-exclusive, non-transferable, royalty-free, limited license to (a) use the binary form of the Software for the sole purpose of designing, developing and testing your JavaTM applets and applications intended to run on a compatible Java environment (the Programs), provided that the Programs add significant and primary functionality to the Software, and (b) reproduce and distribute the binary form of the Software through multiple tiers of distribution provided that you: (i) distribute the Software complete and unmodified; (ii) do not distribute additional software intended to
RE: License issue (the come back)
The last point is the only real problem IMHO. Basically, it forbids to export software in free world ennemy countries TM. I don't know if making somone from such a country able to download software from a website could be considered software exportation, but considering the technical impossibility to prevent it, i doubt Sun itself could claims to fulfill it. On the other hand it would be hard to prove that you exported it yourself to a banned country, and didn't provide it to a user in the continental US who then sent it abroad. It certainly seems unworkable in principle, and as a foreigner I wonder what the US lawmakers would consider to be adequate protection against downloading by evil foreigners. You can pretty much bet the farm that terrorists won't let licence conditions stop their plans. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
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...
non-free
jaasBCL + LDS
jafBCL
javahelpBCL + LDR
javamail BCL + LDS
jaxpBCL + LDS
jdbc-stdext no license
BCL
jimiBCL + LDS
jmsno license
BCL
jndino license
BCL
jtano license
jtopenno package
jtsBCL + LD
netbeans-java-extbinno license
resolverno license
non-distributable
javacc?
jsseBCL + LD
sun-jsdk1.3 BCL + LDS + LDR
sun-jsdk1.4BCL + LDS + LDR
blackdown-jsdk1.3 BCL + LDS + LDR
ibm-jsdk1.3?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
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... Could you help us in such works since : - you were damn't fast on such hard task - you have many friends at Sun which could help you Don't forget that Guillaume and I are french and we may have sometimes problems in understanding all the subtilities of all the Sun licenses in english only. We'll be more than happy to have a french version of them. Nota that many others companies like IBM provide license in several languages to help their users / customers... BTW, Guillaume and I want to know if we could or couldn't make the Sun jars available via jpackage project next to others free jars, with the final goal to have a ready to use Java distribution which will be a great benefits for all the Java community, both developpers and users. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
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 What about a dummy program - say Linux java installer - with minimal code ? If this is not acceptable, you can probably just redistribute ant or tomcat4, which make use of almost all those packages. Ant is the best vehicle, and very usefull to have it installed anyway. 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) 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 ? 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. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
on 3/12/02 4:41 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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. Costin Correct. We have setup [EMAIL PROTECTED] for that reason (this is also commonly discussed on [EMAIL PROTECTED] and [EMAIL PROTECTED]) and have setup pages like this one to help us track things... http://jakarta.apache.org/site/jars.html -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
On Tue, 12 Mar 2002, Jon Scott Stevens wrote: http://jakarta.apache.org/site/jars.html The problem is that the list should be reversed - i.e. what licences are _allowed_ and verified by a lawyer. And we have 2 issues - what jars are allowed in CVS, and what jars are allowed in the binary software we distribute. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
on 3/12/02 5:02 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The problem is that the list should be reversed - i.e. what licences are _allowed_ and verified by a lawyer. And we have 2 issues - what jars are allowed in CVS, and what jars are allowed in the binary software we distribute. Costin We welcome your contributions. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
It has nothing to do with language barriers or who I know. - I went to each product on Sun's website. Ex: http://java.sun.com/products/jms/ ok - I clicked the 'Download' link on the left side navigation. Ex: http://java.sun.com/products/jms/docs.html ok - I clicked the 'continue' button on the page. Ex: Download the version 1.0.2b Source, API Documentation and Jar (the jar file has been added) ok - 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 And then you have to understand what is exactly BCL. I'm not a lawyer, english is not my primary language sorry, so 2 reasons to be more than carefull BTW, Guillaume and I want to know if we could or couldn't make the Sun jars available via jpackage project next to others free jars, with the final goal to have a ready to use Java distribution which will be a great benefits for all the Java community, both developpers and users. 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. Ok, so you confirm us that the Sun jars couldn't be used outside a real program and as such couldn't be part of a RPM distribution ? But what happen if that distribution use these jars (ie javamail) for REAL program (like Tomcat 4.x) ? (i) distribute the Software complete and unmodified and only bundled as part of your Programs 'Part of my program', could we see a distribution as a set of programs depending on BCL jars for both build, install and runtime ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
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 ? have setup pages like this one to help us track things... http://jakarta.apache.org/site/jars.html Yes, but how could I find this page from homepage ? BTW, you could add to jaf exclusion : jaas, javahelp, javamail, jdbc-stdext, jimi, jms, jta, jts -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
