Re: NDA issues and acceptable use of sun source (was: Re: JavaSound Was: java.sql.*)
Leo Simons mail at leosimons.com writes: Since the JDK stuff is now all mostly out in the public, and most NDAs are effectively voided once the information they are meant to protect is available through other means not involving an NDA. Missing the cue by just a few days, Sun Microsystems proudly unveiled a new license to go with the 1.6 Mustang beta, and it contains the following, explicit talk about trade secrets, and confidentiality agreements that seems to fit the recently discussed NDA issues perfectly like a fist a glove: 7.0 CONFIDENTIAL INFORMATION 7.1 For purposes of this Agreement, Confidential Information means: (i) business and technical information and any source code or binary code, which Sun discloses to Licensee related to Licensed Software; (ii) Licensee's feedback based on Licensed Software; and (iii) the terms, conditions, and existence of this Agreement. 7.1.(iii) is the Mustang Fight Club rule: The first rule of the Mustang licensee club: you don't talk about the Mustang licensee club. Fortunately, I have not accepted the license, so I can make fun of it. [...] Licensee's obligations regarding Confidential Information will expire no less than five (5) years from the date of receipt of the Confidential Information, except for Sun source code which will be protected in perpetuity. A perpetual NDA on the included Sun source code with each purchase, yum. Licensee agrees that Licensed Software contains Sun trade secrets. Et voila, explicit acknowledgement of trade secrets. Taken from http://java.sun.com/javase/6/jdk-6-beta-license.txt As long as Sun Microsystems believes to have some trade secrets in there, that are worthy of such draconian measures, I don't think it's wise to assume that NDAs with Sun have become invalid without proof to the contrary. The 1.6 beta license has a lot of other nice, comical gems, and is a wonderful piece in the finest tradition of the earlier works from the same software license publishing house. Use with care, avoid excessive exposure, etc. cheers, dalibor topic
NDA issues and acceptable use of sun source (was: Re: JavaSound Was: java.sql.*)
Vorbis is cool :-) Thanks for thinking this stuff through and being careful about protecting everyone and yourself from legal mess. IANAL. Not Legal Advice. On Sat, Feb 11, 2006 at 12:08:20AM +0100, Tor-Einar Jarnbjo wrote: Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. Good questions, I honestly don't know. Working as a Java developer, I now and then need to trace into the original source code or take a look or two at the API implementation to realize why something is not working as I expect. As far as I can remember, I have not done this with Sun's JavaSound implementation. If you put a notice to that effect onto your authorized contributor form that should probably be fine. If you can't remember what bit of the implementation you looked at, chances are you also don't remember what you saw! Sun has repeatedly and publicly stated that this kind of usage should not taint a developer. I don't have the NDA anymore, or am at least not able to find it, having moved around several times the last ten years. Chances are that the NDA is either * expired, or * voided Since the JDK stuff is now all mostly out in the public, and most NDAs are effectively voided once the information they are meant to protect is available through other means not involving an NDA. If you want to be certain, you can probably get in touch with sun legal and figure out if the NDA still applies, and to what. I would hope *they* still have a copy somewhere... For working on a JavaSound implementation, it is probably irrelevant anyway, as JavaSound was not introduced until Java 1.3 and ought not to be covered by any agreement in Sun's NDA. That sounds sensible. Based on the situation you have outlined in your emails, I don't think we should have a problem integrating your stuff and having you work on it here. I for sure will get pissed if this would get us into any kind of trouble and be happy to throw some ASF legal cycles at getting justice! :-) cheers! Leo
Re: NDA issues and acceptable use of sun source (was: Re: JavaSound Was: java.sql.*)
Leo Simons mail at leosimons.com writes: If you put a notice to that effect onto your authorized contributor form that should probably be fine. If you can't remember what bit of the implementation you looked at, chances are you also don't remember what you saw! People have been successfully sued for violating copyrights of works that they didn't mean to plagiarize, but had accessed prior to writing their own. See McCarthy's My Sweet Lord/He's So Fine lawsuit. Sun has repeatedly and publicly stated that this kind of usage should not taint a developer. That does not necessarily mean that the developer is free to implement the same specs, and distribute the results under an open source license. See http://lists.gnu.org/archive/html/classpath/2005-05/msg00014.html for details. N.B. Sun keeps updating the JRL so they may, or may not have fixed some of the bugs I explain in that post. Chances are that the NDA is either * expired, or * voided The simplest way to know is for the contributor to check with Sun's legal department, since it's an agreement between him and Sun, I presume. If we can have that on paper, that's fine. If Sun or the company owning Java after Sun collapses ever hauls us into court, having a paper trail for contributions, in particular potentionally legally challenging ones, is a good thing. Since the JDK stuff is now all mostly out in the public, and most NDAs are effectively voided once the information they are meant to protect is available through other means not involving an NDA. I'd be vary of that. What closed source licenses like JRL, SCSL, etc. do is to partition people into two groups, one on the inside of the shared secret barrier, and one on the outside. If they had no intent to ever enforce the separation, there wouldn't be one. If you parse the language in the SCSL carefully, it talks quite a bit about intellectual property rights, including trade secrets, and other proprietary technology licenses from the same company do the same. Whether partially more liberal proprietary source code licenses from the same source actually remove obligations from more restrictive ones, or keep piling requirements on top of each other, is very hard to say, since they are not designed to be replace another ... the SCSL never mentions the JRL as superceding it, for example. I'd be vary of guessing what the legal status is of someone who's bound by several such agreements and NDAs. There is no way the Harmony project can sort out the legal mess left behind Sun decisively, since any such thing would have to play out in the courts, and we certainly don't want to have to have to go there. In absence of court decisions, there is just the possibility to draw very clear lines what constitutes safe contributions and what doesn't. Such lines are necessarily going to exclude more people that court-tested lines would, but they have the killer feature of not having to go to court with Sun in order to determine them. ;) cheers, dalibor topic
JavaSound Was: java.sql.*
Geir Magnusson Jr wrote: Lets discuss that here. :) I didn't mean to ignore you - but two mail machines were hard to follow. I'm ready to join them into one, and hopefully I'll stop dropping the ball :) Ok, here are a snippet from the mail I sent you: (Win32 partial implementation of JavaSound): http://jarnbjo.de/HJavaSound.zip Installation is quite simple, just copy the following files to jre\lib\ext: dist/sound.jar, dist/vorbis-spi.jar and the following files to some directory in the dll path (e.g. jre\bin\default): dist/sound.dll The ant build file will build the HJavaSound Java source code and the C source using Borland's CBuilderX. I know it's not pretty, using hard coded paths etc., but it was just a quick hack to simplify the build process. The source code for the SPI and player are included in the vorbis-spi and spiplayer directories, for which no build files are included. Hope you don't mind that I already chose to put implementation specific classes in the org.apache.harmony.sound.sampled package. Ogg/Vorbis files should now play with java -jar dist/spiplayer.jar filename. The Vorbis SPI for JavaSound and the SpiPlayer itself are actually parts of my project J-Ogg (ww.j-ogg.de), which is already released under an Apache-style license (http://www.j-ogg.de/core/main?/download-libraries.html). Another issue with this is of course that the current VMs working with Harmony are not able to use Java 5 class files and implementing JavaSound for 1.4 and later extending it for Java 5 would be at least some unnecessary work. Are there any current plans for extending the VMs for Java 5 code? Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. Good questions, I honestly don't know. Working as a Java developer, I now and then need to trace into the original source code or take a look or two at the API implementation to realize why something is not working as I expect. As far as I can remember, I have not done this with Sun's JavaSound implementation. I don't have the NDA anymore, or am at least not able to find it, having moved around several times the last ten years. For working on a JavaSound implementation, it is probably irrelevant anyway, as JavaSound was not introduced until Java 1.3 and ought not to be covered by any agreement in Sun's NDA. Tor
