RE: Moving system properties to gnu.classpath.*
Jeroen, Would you like to work with me to try to refactor the way system properties are handled to untangle the initialization dependencies and to allow you to use more Classpath code as-is? I'd like to use more of Classpath as-is but I don't think the particular dependencies we have can be solved other than by doing the changes we did. Basically we can't do any string actions until we initialize the EncodingManager and alias properties, and that requires the System properties to function straight away. Only if all these changes were moved into the new system property class would it work for us. And while I'd like to help with the general problem I frankly don't have the time available to do so - sorry. Whenenever code tries to access a package and a security manager is installed, SecurityManager.checkPackageAccess() is called, so all we need to do is all the gnu.classpath package to the package.access system property. Isn't that test in reflection only? For normal accesses wouldn't you be relying on the class resolution process to identify access control errors - and in this case wouldn't a public class with public methods pass VM access control checks regardless (unless an internal VM access control hook is used)? I'm confused again about what is being proposed: a public API with some kind of runtime check to deny access, or a private API with a runtime check to allow access (doPrivileged?) ? The former still seems to need VM magic, while the latter would require too much security infrastructure to be in place too early in the initialization process. 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
