Re: clickthrough license
David Holmes wrote: GNU is not Unix, and GNU Classpath is not (the core) Java (library). We just don't have a cute acronym to express that. I don't believe that not saying the Java word when describing what GNU Classpath is lets you off the hook here. If nothing else the classes and API's in the java* namespaces would fall under Sun's copyright. Now I don't personally believe it would be in Sun's interests to come down on GNU Classpath and prosecute this, rather it would be in Sun's (and the Java Community's) best interests to have GNU Classpath be conformant with the spec license and pass the TCK. But I'm concerned that the FSF's politics on all this might deny the possibility of this ever happening. But that's not my direct concern. I get a few mails that ask me how legal Kaffe is a few times a year, so I hope this can serve as a 'no idea, hypothetical question' template for GNU Classpath, too :) The ambiguousness in Sun's licenses surrounding Java technology is probably intentional, as it allows Sun's legal team to pick the battles they want to fight. The FSF can't do anything about other people's licenses that are designed to be open to interpretation, afaict, and it can't really tell you how the other people will interpret their licenses if you end up in court. Sun's licenses are ulrimately their own to figure out. :) I guess that most people would agree that conforming to the specs is a great thing, and passing the TCK would be quite neat, too, as then VMs using GNU Classpath could claim to interpret the spec in similar ways as Sun does[1]. But it's not up to GNU Classpath to set the rules here, because GNU Classpath does not have a stake in Java(TM). If and when Sun wants, say, SableVM or Kaffe or gcj or IKVM or any other VM on GNU Classpath to be conformant to their specifications wrt to passing the TCK, they'll make their TCK available under an acceptable[2] license, and then something can (and probably will) be done about it. FSF's politics have no influence on how Sun licenses their code, afaict. All the FSF can do is to say: 'that's OK', or 'that's not good enough for these reasons'. I'd be very surprised if giving up freedom in exchange for access to a marketing initiative, or for a promise of compatibility/scare of incompatibility ever became part of FSF politics. If Sun makes offers that demand such things, I'd guess that those offers are likely to be politely declined. But that's OK. It's up to Sun to figure out how to license their code in ways that coincide with their intentions, hopes and fears. I'm sure that they'll find a good way to strike an acceptable balance *eventually*. That might take a few more years.[3] But there is no need to push Sun to hurry up, in my opinion. They'll get there on their own terms, when they are ready. They have enough clever people working for them to figure out what needs to be done, and how to go about it without being constantly whacked from the sidelines to 'open up Java already'. For a bit of a silver lining, the 1.5 JSR indicates that the TCK may be released under a license that doesn't contaminate everything it touches with the SCSL, but it remains to be seen if that is actually going to be the case. Till then, it's all 'what-if' speculation. Sun has tolerated[4] clean-room efforts like Kaffe since 1996, without threatening legal action, afaict, so I don't see why they should change their minds now. Sun's OpenOffice.org developers have recently created a Java vendor interface to make it easier for free runtime developers to plug their VMs into OOo, in order to get OOo to run on free runtimes, and further it's reach. I'm working on it from the Kaffe side. I doubt that would be happening if Sun regarded free runtimes as illegal thieves of their specification. I'd say that Kaffe or SableVM or gcj or IKVM are not threatening Sun's products, they are rather playing in a completely different league, by being free software, and by explicitely *not being* Java(TM). To recapitulate: Kaffe in not Java(TM). Kaffe is not Pepsi(TM). Kaffe is also not Coca Cola(TM) and definitely not a BigMac(TM). :) Kaffe is Kaffe. If it works for you, that's cool, if it doesn't let's fix it. But noone should claim that Kaffe is Java(TM), because that's simply not true[5]. cheers, dalibor topic [1] Which only matters if you are dealing in marketing anyway, as then you can slap cute Sun logos on your VM and make certain claims about your VM without fear that Sun's legal team will slap you for abusing their trade marks. But a cute logo doesn't mean that a VM is any good in practice, it just means that the VM vendor decided to 'tap into the power of the brand' and do whatever is required to get the right to slap that logo on their product. :) [2] Which means no ambiguous 'NOTICE FROM SUN MICROSYSTEMS' stunts like the one someone pulled on Geronimo JOnAS. :) [3] My conservative guess is 2012, as according to X-Files,
Re: clickthrough license
Per Bothner wrote: I do? The API's are not as far as I am aware trademarked. It seems to me that defining a set of API's that match Sun's Java API's would be copying them - hence infringing on copyright. Implementing a specification is *not* copying the specification. This is correct. Under the US legal system the filtration-abstraction -comparison test would not qualify the API itself as 'expressive' but rather 'functional' code. The very case which set this precedent, Computer Associates International, Inc. v. Altai, Inc was itself largely about APIs. (The software in question was an API compatibility layer) However, I assume (as a non-lawyer) that copyright law does allow Sun to place restrictions on downloading/reading (i.e. copying) the specification, and hence there is a specification license. Interpreting the license is I understand more an issue of contract law than of copyright law. This does not matter because the API itself is not expressive content and therefore, copying it does not require license. It's simply not a protectable expression. Now, IANAL but having taken some courses on IP law, I think you'd either have to be insane (or SCO) to try to sue someone over reproducing a publicy documented API. (And obviously, patent and trademark issues are a different matter.) /Sven ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: clickthrough license
Dalibor, Till then, it's all 'what-if' speculation. Sun has tolerated[4] clean-room efforts like Kaffe since 1996, without threatening legal action, afaict, so I don't see why they should change their minds now. I hear everything you said. But the issue that started this discussion was whether a classpath developer could accept Sun's clickthrough license to read the latest Java specifications. My argument has been that even without a click-through licencse, all of the Java specifications and API's are protected by Sun's specification license, no matter whether you downloaded them or simply read them online. So the answer to this has to be yes, it is ok for a Classpath developer to accept Sun's specification license, otherwise none of us can refer to the API docs or spec to clarify any aspect of the APIs. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: clickthrough license
Mark Wielaard writes: I just looked at these two jsr's and both are not even available through a click-through. (Strangely enough both just point to the sun 1.5.0 implementation documentation, which as far as I know doesn't include the specs at all.) Yes I was a little surprised to see this too. All of the JSR's covered by the Tiger umbrella JSR's just point to the JDK as being the specification. In otherwords the API Javadoc plus supporting package.html and other linked pages *ARE* the specification. And while you don't need to accept any license directly to read the online documentation of the JDK you do need to accept the click-through to download either the JDK or the DOCS, and the online doc page does have a link to Copyright and License Terms for Documentation. (I'm not a lawyer so I don't know if reading the online docs implies any acceptance of the licence - personally I'd expect that the license would be much more prominent eg. The documentation accessed from this page is protected by a license any viewing of these pages constitutes acceptance of that licence.) The JCP also doesn't require the (final) specifications to be provided under a click-wrap. Being involved in this at present with another JSR I can assure you that the JCP does require a click-through license for downloading specs. For these Tiger related JSR's it seems the actual J2SE specification license is assumed to apply. Aren't all standards whether deemed open or not, protected by some similar license? I am not sure I am following you here. The given goal of GNU Classpath is to provide a free implementation of the core class libraries so that people can use these libraries to create (free) software for the GNU system. For this we try to be as compatible as we can be while making sure that the freedoms of the GNU project are preserved. Hopefully we make this happen while also being 100% compatible with other implementations. GNU is not Unix, and GNU Classpath is not (the core) Java (library). We just don't have a cute acronym to express that. I don't believe that not saying the Java word when describing what GNU Classpath is lets you off the hook here. If nothing else the classes and API's in the java* namespaces would fall under Sun's copyright. Now I don't personally believe it would be in Sun's interests to come down on GNU Classpath and prosecute this, rather it would be in Sun's (and the Java Community's) best interests to have GNU Classpath be conformant with the spec license and pass the TCK. But I'm concerned that the FSF's politics on all this might deny the possibility of this ever happening. But that's not my direct concern. David ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: clickthrough license
David Holmes wrote: The JCP also doesn't require the (final) specifications to be provided under a click-wrap. Being involved in this at present with another JSR I can assure you that the JCP does require a click-through license for downloading specs. I'm not saying you're wrong, but I think it would be useful if you could point to a specific document that states such a requriement. Notice also that the JCP and related agreement/processes ahve changed over the years. I don't believe that not saying the Java word when describing what GNU Classpath is lets you off the hook here. If nothing else the classes and API's in the java* namespaces would fall under Sun's copyright. You mean Sun's trademark, not copyright, of course. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: clickthrough license
Being involved in this at present with another JSR I can assure you that the JCP does require a click-through license for downloading specs. I'm not saying you're wrong, but I think it would be useful if you could point to a specific document that states such a requriement. I should said PMO rather than JCP. The JCP document itself doesn't cover this, however the PMO seems to require it. If you look at the Spec lead Guide on jcp.org you'll see that for Proposed Final Draft The PMO will provide the spec license ... and then for Final Approval Ballot The PMO hosts the Final Approval Ballot for you, and uses Sun's general FCS license unless you provide your own FCS license.. On other words, the specification licenses are provided by the PMO not the JCP itself. (Note that the specification license is distinct from the RI and TCK licenses.) You'd need to contact the PMO directly to clarify this and to see what possible licenses exist. I don't believe that not saying the Java word when describing what GNU Classpath is lets you off the hook here. If nothing else the classes and API's in the java* namespaces would fall under Sun's copyright. You mean Sun's trademark, not copyright, of course. I do? The API's are not as far as I am aware trademarked. It seems to me that defining a set of API's that match Sun's Java API's would be copying them - hence infringing on copyright. But I'm no IP lawyer. Oh and I now see that every JavaDoc page states Use is subject to license terms at the bottom with a link to the spec license. So whether you read the javadocs online, download them yourself via the clikc-through, download an actual specification or read an official book, then these API's are always covered by Sun's specification license. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: clickthrough license
David Holmes wrote: I should said PMO rather than JCP. The JCP document itself doesn't cover this, however the PMO seems to require it. If you look at the Spec lead Guide on jcp.org you'll see that for Proposed Final Draft The PMO will provide the spec license ... and then for Final Approval Ballot The PMO hosts the Final Approval Ballot for you, and uses Sun's general FCS license unless you provide your own FCS license.. On other words, the specification licenses are provided by the PMO not the JCP itself. (Note that the specification license is distinct from the RI and TCK licenses.) You'd need to contact the PMO directly to clarify this and to see what possible licenses exist. You're quoting from a section on the Proposed Final Draft. It is not unreasonable that the draft would have a more restrictive license than the actual final spec. However, the final release does say the spec must be set up with a click-through license. However, I'm sure Spec Leads can pick their license terms, at least within certain limits. And some JSRs are open-source, at least the implementation. But JCP is all very complicated, with a huge amount of process, and I can't pretend to what extent Classpath might have problems. I don't believe that not saying the Java word when describing what GNU Classpath is lets you off the hook here. If nothing else the classes and API's in the java* namespaces would fall under Sun's copyright. You mean Sun's trademark, not copyright, of course. I do? The API's are not as far as I am aware trademarked. It seems to me that defining a set of API's that match Sun's Java API's would be copying them - hence infringing on copyright. Implementing a specification is *not* copying the specification. However, I assume (as a non-lawyer) that copyright law does allow Sun to place restrictions on downloading/reading (i.e. copying) the specification, and hence there is a specification license. Interpreting the license is I understand more an issue of contract law than of copyright law. If you don't read the official specification and haven't agreed to the license, then you can implement whatever you want without concern about Sun's copyright, assuming you use public documents, such as books and magazine articles. However, avoiding the official Sun-licensed specification doesn't protect you from patent or trademark issues. And Sun has trademarked Java, so if you implement a class called java.lang.String then you could conceivably be infringing on Sun's trademark. That's why I believe Sun's trademarks and patents are a more fundamental concern that the copyright. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: clickthrough license
However, I'm sure Spec Leads can pick their license terms, at least within certain limits. And some JSRs are open-source, at least the implementation. I think the spec leads can, within-limits, define the terms for the RI and TCK - because in a sense they own that. But they don't own the spec itself and I believe the PMO controls the actual license for that. But the easiest way to know for sure is to ask the PMO. :) Implementing a specification is *not* copying the specification. No it is not. But if you implement these specifications, and claim to be doing so, then the Specification License applies. To implement something that defines the same API's that happen to be in a specification, without claiming to implement that specifications (which is what Classpath seems to be trying to do) would seem to me to be copying those API's. However, I assume (as a non-lawyer) that copyright law does allow Sun to place restrictions on downloading/reading (i.e. copying) the specification, and hence there is a specification license. Interpreting the license is I understand more an issue of contract law than of copyright law. I agree. My point was that I believe that if you tried to say this isn't an implementation of the specification XXX, it just happens to support the same API's then at best you would be breaching copyright. If you don't read the official specification and haven't agreed to the license, then you can implement whatever you want without concern about Sun's copyright, assuming you use public documents, such as books and magazine articles. Hmmm - I'm not sure how far you can take this argument. Reasonable use allows books and articles to describe parts of the API's. I don't think you can get around the reasonable use restrictions by recombining from multiple sources that individually would be considered reasonable use. However, avoiding the official Sun-licensed specification doesn't protect you from patent or trademark issues. And Sun has trademarked Java, so if you implement a class called java.lang.String then you could conceivably be infringing on Sun's trademark. Yes that could well be true. That's why I believe Sun's trademarks and patents are a more fundamental concern that the copyright. Well whatever we want to call it, I don't think Classpath can pretend that it is free from these concerns, just by not claiming to implement an actual Java specification. And to get back to the original issue I don't think any of the Classpath implementors should have to be concerned about accepting the Sun Specification License terms if they want to implement those new or enhanced API's. Hence this issue should be clarified through FSF legal. Otherwise, none of us will be able to quote from Sun's API docs when clarifying the required behaviour of anything! Cheers, David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: clickthrough license
On Fri, 2004-10-08 at 06:39, Mark Wielaard wrote: The JCP also doesn't require the (final) specifications to be provided under a click-wrap. As these JSR's show it it perfectly fine to publish the specification, reference implementation and test compatability kit in the public domain. (Unfortunately, as you point out most JSRs don't do this at the moment. Please tell specification leads about the option to do everything in the open.) Getting specs open doesn't appear to be too hard but I've had trouble in the past getting TCKs open because there is some feeling that in order to assure compatibility that one prevent inspection of TCK source. The theory is this makes it more difficult to fake the TCK results which prove or disprove compatibility. The practice I've seen is to let people self-certify. All of these experiences were from my involvement in OSS/J. I don't buy these arguments. People could fake the results with a binary TCK as well. People doing implementations have no motive to not pass the TCK as customers (or users) would then find their code which worked with the RI suddenly doesn't work on xyz despite claims of compatibility. Despite this, business types just don't get it sometimes and in some cases the geeks aren't running the show behind the JSR. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: clickthrough license
Hi, On Tue, 2004-10-05 at 00:54, David Holmes wrote: It got worse the last years. Specs, or at least draft specs would be published publicly without having any click-through license to which people have to consent. There are also some nice counter examples though of expert groups doing everything publicly (JSR133 about the memory model, JSR166 about concurrency util classes). Even those open JSR's ultimately have a click-through license on the final spec. I just looked at these two jsr's and both are not even available through a click-through. (Strangely enough both just point to the sun 1.5.0 implementation documentation, which as far as I know doesn't include the specs at all.) JSR133 is available at http://www.cs.umd.edu/~pugh/java/memoryModel/ JSR166 is available at http://gee.cs.oswego.edu/dl/concurrency-interest/ The JCP also doesn't require the (final) specifications to be provided under a click-wrap. As these JSR's show it it perfectly fine to publish the specification, reference implementation and test compatability kit in the public domain. (Unfortunately, as you point out most JSRs don't do this at the moment. Please tell specification leads about the option to do everything in the open.) But it does concern me that such unofficial sources would be preferred over the actual specification. Of course actual specifications are preferred over unofficial sources. But then the actual specifications have to be available in such a way that we can be sure that we are free to use them. Also the use of unofficial sources is often explicitly encouraged since what you might call the actual specification (like the api documentation sun publishes online) is often not strict enough to describe what is actually expected. More often than not I have found books published about various packages are much more in depth than the official specification. Further, given Classpath's goals, I don't see how it could ever claim to be what it is, without requiring compliance with Sun's licenses regarding independent implementations. I am not sure I am following you here. The given goal of GNU Classpath is to provide a free implementation of the core class libraries so that people can use these libraries to create (free) software for the GNU system. For this we try to be as compatible as we can be while making sure that the freedoms of the GNU project are preserved. Hopefully we make this happen while also being 100% compatible with other implementations. GNU is not Unix, and GNU Classpath is not (the core) Java (library). We just don't have a cute acronym to express that. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: clickthrough license
Hi David, On Mon, 2004-10-04 at 01:01, David Holmes wrote: I think you will find that all the Java specifications are protected by a similar license (which basically preserves the namespace usage and requires complete conformance from an implementation). It got worse the last years. Specs, or at least draft specs would be published publicly without having any click-through license to which people have to consent. There are also some nice counter examples though of expert groups doing everything publicly (JSR133 about the memory model, JSR166 about concurrency util classes). Besides, the terms/claims in these click-through documents seems to change over time, so if we really need to accept them to be used as primary source of information when working on GNU Classpath then we need to (re)check each time. Even specs that get printed will have a license included in the book. Only third party books that describe an API will not have such a license, but nor are they definitive sources of information on an API specification. There is a lot of case law about using publicly published information from printed books. So books (with a normal ISBN number) are always prefered to use as authorative source. If that means not having the definitive source then so be it. Programmers will use published books or publicly published articles to write their programs, so we better make sure we are at least compatible with what they use/expect. Best get this cleared through FSF legal ASAP. It is pretty clear. Use public documentation, which doesn't need you to consent to any additional click-through terms, as primary source when working on GNU Classpath, preferably books. For anything else we (FSF Legal) needs to look at the specific terms. Since as noticed above the terms are not always the same. FSF Legal will always advise not to take any unnessecary risks that might endanger the (perceived) free software status of a GNU project. (If we might need to go to court to proof that what we did was OK, then don't!) Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: clickthrough license
Mark Wielaard wrote: Programmers will use published books or publicly published articles to write their programs, so we better make sure we are at least compatible with what they use/expect. Programmers will use Sun's JavaDoc-generated API documents. If anyone reports a bug, that is what they will refer to. It is pretty clear. Use public documentation, which doesn't need you to consent to any additional click-through terms, as primary source when working on GNU Classpath, preferably books. There is often no such documentation. Most book are tutorial, not reference works that are anywhere close to comprehensive, or are out of date. There is one Swing book I know (O'Reilly's) that attempts to cover the APIs systematicaly, for example, but even it is surely insufficient for a useful independent implementation. Sun's documentation license for 1.5 is quite unclear in what it covers. For example a literal reading seems to prohibit writing books or articles about the JDK. (It is neither developing application or an independent implementation.) In that case, is it safe to depend on books and articles that may be the result of unpermitted actions? It seems to me the license restricts how you use and distribute the specification itself. However, it cannot as a matter of copyright law restrict the ideas or concepts of the specification, or prevent us from learning from it. It could make such restrictions under trade secret law, but it would be nonsense to claim as a trade secret something freely available on the web. So the real concerns are any patents Sun may have, plus the trademarks Sun may have. But none of those are affected by whether or not we read Sun's specifications. Of course I would like a lawyer (and specifically Eben Moglen) to evaluate this analysis. Perhaps I'm wrong in dismising the specification as a trade secret, for example. FSF Legal will always advise not to take any unnessecary risks that might endanger the (perceived) free software status of a GNU project. Right, but even if reading the specification is a risk, I suspect it falls into the necessary category. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
RE: clickthrough license
Mark, For GNU Classpath we only use publicly available information. Please do not refer to proprietary information while working on GNU Classpath. If this document is the only way to make a fully compatible implementation for the XMLEncode and XMLDecoder then please let me know and I run this agreement past FSF legal. Best is to find a book in which this specification, or an explanation of it, is published. If there is such a book I'll make sure you will get it. I think you will find that all the Java specifications are protected by a similar license (which basically preserves the namespace usage and requires complete conformance from an implementation). Even specs that get printed will have a license included in the book. Only third party books that describe an API will not have such a license, but nor are they definitive sources of information on an API specification. Best get this cleared through FSF legal ASAP. Cheers, David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: clickthrough license
Hi, On Sat, 2004-10-02 at 14:34, Robert Schuster wrote: I found the official specification papers for the java.bean.XMLDecoder which is part of JSR-57 andwant to download them but they are wrapped in a license agreement. It does not look dangerous to me but I am cautious and wait until someone from this list says it is OK to accept it. For GNU Classpath we only use publicly available information. Please do not refer to proprietary information while working on GNU Classpath. If this document is the only way to make a fully compatible implementation for the XMLEncode and XMLDecoder then please let me know and I run this agreement past FSF legal. Best is to find a book in which this specification, or an explanation of it, is published. If there is such a book I'll make sure you will get it. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
