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
Re: CLA issues Was: java.sql.*
Leo Simons wrote: I'll also request everyone tries to ensure that you do not try and represent anything as legal fact unless its been thoroughly verified that it is indeed rather certain that what is being said is undisputable. Also, always try and provide as much references as possible. The problem root lies back in the times when the first laws where written to protect intellectual property. In UK, copyright laws were written, which originally only regulated reproduction and publishing rights, while in France the laws were centered around the droite d'auteur or author's right. Later, copyright laws were only adopted in the countries most strongly influenced by the UK, e.g. USA and probably Canada, while most other countries adopted the French idea of generally protecting the author as a static owner of his intellecutal property. In Germany, the author's rights are so strong, that they even to some extend apply for works produced by an employee or as part of a paid assignment. The issues I'm pointing out are regulated like this in the German Gesetz über Urheberrecht und verwandte Schutzrechte (Law on author's rights and related protective rights): §29(1): Das Urheberrecht ist nicht übertragbar, es sei denn, es wird in Erfüllung einer Verfügung von Todes wegen oder an Miterben im Wege der Erbauseinandersetzung übertragen. The author's right is not transferable, unless it is transfered to an inheritor in connection with the author's death. §§ 41 and 42 are regulating the author's Rückrufsrecht or revokation right. §41 is regulating the case, in which an exclusive usage right is not being practised, while §42 is regulating the author's right to revoke a usage right, in case of gewandelter Überzeugung, however that is to be translated properly to English. Modified/changed belief or conviction is a brave attempt. §42(2) regulates that the author's right to exercise his revokation right can not be excepted. §34 regulates the transfer of usage rights and sublicensing (Übertragung von Nutzungsrechten). Any such transfer must be agreed upon by the author, although it is restricted in which cases he may deny such transfer to take place. At least the way I interpret these regulations, it is not possible for the author to agree to a blanket sublicensing grant, as his rights depends on the exact conditions around the license transfer. Regulations on derivative works are spread across several paragraphs (§§14, 23, 39, etc). As in the issue with §42, derivative works may not be produced or published if they are against the author's belief (which may change with time). Tor
Re: CLA issues Was: java.sql.*
IANAL. This is not legal advice. On Mon, Feb 13, 2006 at 11:59:48AM +0100, Tor-Einar Jarnbjo wrote: Leo Simons wrote: I'll also request everyone tries to ensure that you do not try and represent anything as legal fact unless its been thoroughly verified that it is indeed rather certain that what is being said is undisputable. Also, always try and provide as much references as possible. The problem root lies back in the times when the first laws where written to protect intellectual property. In UK, copyright laws were written, which originally only regulated reproduction and publishing rights, while in France the laws were centered around the droite d'auteur or author's right. Later, copyright laws were only adopted in the countries most strongly influenced by the UK, e.g. USA and probably Canada, while most other countries adopted the French idea of generally protecting the author as a static owner of his intellecutal property. In Germany, the author's rights are so strong, that they even to some extend apply for works produced by an employee or as part of a paid assignment. The issues I'm pointing out are regulated like this in the German Gesetz ?ber Urheberrecht und verwandte Schutzrechte (Law on author's rights and related protective rights): ?29(1): Das Urheberrecht ist nicht ?bertragbar, es sei denn, es wird in Erf?llung einer Verf?gung von Todes wegen oder an Miterben im Wege der Erbauseinandersetzung ?bertragen. The author's right is not transferable, unless it is transfered to an inheritor in connection with the author's death. ?? 41 and 42 are regulating the author's R?ckrufsrecht or revokation right. ?41 is regulating the case, in which an exclusive usage right is not being practised, while ?42 is regulating the author's right to revoke a usage right, in case of gewandelter ?berzeugung, however that is to be translated properly to English. Modified/changed belief or conviction is a brave attempt. ?42(2) regulates that the author's right to exercise his revokation right can not be excepted. ?34 regulates the transfer of usage rights and sublicensing (?bertragung von Nutzungsrechten). Any such transfer must be agreed upon by the author, although it is restricted in which cases he may deny such transfer to take place. At least the way I interpret these regulations, it is not possible for the author to agree to a blanket sublicensing grant, as his rights depends on the exact conditions around the license transfer. Regulations on derivative works are spread across several paragraphs (??14, 23, 39, etc). As in the issue with ?42, derivative works may not be produced or published if they are against the author's belief (which may change with time). Yup, all that sounds pretty familiar, and thanks for writing it up. I disagree with some of how you map these laws onto what is stated in the Apache CLA, and I also don't think it necessarily results in the kinds of problems that you are worrying about. However, this is getting firmly off-topic for a development mailing list. I'm sure we're boring everyone to death; lets take this discussion elsewhere :-) cheers, Leo
Re: CLA issues Was: java.sql.*
I think the best thing to do here is consult a German lawyer, or some legal resource that has a clue about open source licensing. We aren't going to be able to answer any of this here in a definitive way. I will again note that for contributions made here, at the ASF, we do not ask for copyright transfer, but simply a license to the work. (That you have agreed to.) I would further argue that if the author must retain right to revoke the license or have control over derivative works, then open source is impossible in Germany. Given that there is plenty of open-source activity in Germany - and serious efforts - I think that we're misunderstanding something fundamental about German copyright law. geir Tor-Einar Jarnbjo wrote: Leo Simons wrote: I'll also request everyone tries to ensure that you do not try and represent anything as legal fact unless its been thoroughly verified that it is indeed rather certain that what is being said is undisputable. Also, always try and provide as much references as possible. The problem root lies back in the times when the first laws where written to protect intellectual property. In UK, copyright laws were written, which originally only regulated reproduction and publishing rights, while in France the laws were centered around the droite d'auteur or author's right. Later, copyright laws were only adopted in the countries most strongly influenced by the UK, e.g. USA and probably Canada, while most other countries adopted the French idea of generally protecting the author as a static owner of his intellecutal property. In Germany, the author's rights are so strong, that they even to some extend apply for works produced by an employee or as part of a paid assignment. The issues I'm pointing out are regulated like this in the German Gesetz über Urheberrecht und verwandte Schutzrechte (Law on author's rights and related protective rights): §29(1): Das Urheberrecht ist nicht übertragbar, es sei denn, es wird in Erfüllung einer Verfügung von Todes wegen oder an Miterben im Wege der Erbauseinandersetzung übertragen. The author's right is not transferable, unless it is transfered to an inheritor in connection with the author's death. §§ 41 and 42 are regulating the author's Rückrufsrecht or revokation right. §41 is regulating the case, in which an exclusive usage right is not being practised, while §42 is regulating the author's right to revoke a usage right, in case of gewandelter Überzeugung, however that is to be translated properly to English. Modified/changed belief or conviction is a brave attempt. §42(2) regulates that the author's right to exercise his revokation right can not be excepted. §34 regulates the transfer of usage rights and sublicensing (Übertragung von Nutzungsrechten). Any such transfer must be agreed upon by the author, although it is restricted in which cases he may deny such transfer to take place. At least the way I interpret these regulations, it is not possible for the author to agree to a blanket sublicensing grant, as his rights depends on the exact conditions around the license transfer. Regulations on derivative works are spread across several paragraphs (§§14, 23, 39, etc). As in the issue with §42, derivative works may not be produced or published if they are against the author's belief (which may change with time). Tor
Re: CLA issues Was: java.sql.*
Geir Magnusson Jr schrieb: I would further argue that if the author must retain right to revoke the license or have control over derivative works, then open source is impossible in Germany. Obiously it is not, as long as the software users accept the potenial risk of having to replace the software with something else. The revokation right is not my interpretation, but very clearly stated in the law. Given that there is plenty of open-source activity in Germany - and serious efforts - I think that we're misunderstanding something fundamental about German copyright law. It is unfortunately not very uncommon that German companies have a policy not to use OS software at all, partly because of the unclear legal status and potential problems, which may arise with a legal dispute, partly because of other issues, e.g. not having anyone to sue if something goes wrong. As I was working for Siemens 5-6 years ago, this limitiation was so strict, that we were not even allowed to use open source text editors (e.g. vi or Emacs) to write code, but were forced to use a very poor and annoying product, as there were not really many options when you have to find a commercial text editor for HP-UX. Tor
Re: CLA issues Was: java.sql.*
Tor-Einar Jarnbjo wrote: Geir Magnusson Jr schrieb: I would further argue that if the author must retain right to revoke the license or have control over derivative works, then open source is impossible in Germany. Obiously it is not, as long as the software users accept the potenial risk of having to replace the software with something else. The revokation right is not my interpretation, but very clearly stated in the law. It's not OSS if the author can do that arbitrarily. Think about it - you could wait until something is really popular, and then go shake down every user using it... Given that there is plenty of open-source activity in Germany - and serious efforts - I think that we're misunderstanding something fundamental about German copyright law. It is unfortunately not very uncommon that German companies have a policy not to use OS software at all, partly because of the unclear legal status and potential problems, which may arise with a legal dispute, partly because of other issues, e.g. not having anyone to sue if something goes wrong. Heh. As I was working for Siemens 5-6 years ago, this limitiation was so strict, that we were not even allowed to use open source text editors (e.g. vi or Emacs) to write code, but were forced to use a very poor and annoying product, as there were not really many options when you have to find a commercial text editor for HP-UX. Double heh. geir
Re: CLA issues Was: java.sql.*
Geir Magnusson Jr wrote: It's not OSS if the author can do that arbitrarily. Think about it - you could wait until something is really popular, and then go shake down every user using it... Not necessarily the users directly, but at least the enity, which is managing the reproduction and distribution rights. The point is to guarantee the author an adequate commision if e.g. more copies of his work are published than the author was able to expect when he granted the original publishing license. The idea does not match very well with free as in free beer, but this is indeed the legal situation in most countries. Heh. Double heh. Yes, heh. Tor
Re: CLA issues Was: java.sql.*
Tor-Einar Jarnbjo wrote: Geir Magnusson Jr wrote: Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. What questions do you have for both? I thought I better split this, to prevent the discussion from getting too confusing. One thing I already pointed out with the Apache CLA is that it is very biased towards US copyright law. Well, the ASF is a US Corporation (non-profit) so those are the laws under which we operate. I am not a lawyer and I really have no clue if US copyright law, German Urheberrecht or both applies if I, living in Germany, am signing a contract with a US entity. The most serious legal crash is probably section 2: Grant of Copyright License. First problem is, that I can't grant you anything I currently don't have, a copyright on my work. The German counterpart, my Urheberrecht is not transferable and any license I give to use, redistribute, modify etc. the work may under some conditions be revoked. Any contract diverging from these principles is in Germany legally void. We aren't asking for a copyright transfer. You still retain any and all copyright on the work. What you are doing is granting a license to the work under the Apache License. Another specific issue related to my proposed Vorbis SPI for JavaSound donation, is if you regard third party source code to be classified as format documentation . To be more exact, the Vorbis format specification from the Xiph Foundation proved to contain several errors and their attitude when me pointing it out was, that the reference decoder is the only thing to be considered as a formal specification. This means of course, that at least when it comes to some estimated 20-40 lines of code, my Vorbis decoder implementation is at least based on the reference decoder from Xiph, which is AFAIK released under a BSD license. Yes, it's a BSD license. We think that's good :) We'd have no problems, because the software that is derivative of a BSD work is yours to license as you see fit. It's your IP. Patent issues are also unclear to me. At this point the CLA is really vague (§5), only demaning me to represent that my contribution is free of any patents that I am personally aware of. I have absolutely no ability to judge on that, which of course fulfils, that I am not personally aware of any claims, but depending on the contributors knowledge on patent and license law, this paragraph lies somewhere between meaningsless and very dependent on which country's patents and licenses are to be considered. Interesting. I find section 5 straightforward : - you attest that your contributions are your original work (IOW, you aren't contributing the work of someone else...) - you will provide complete details of any kind of restrictions *that you are aware of*. So this could be limits on the work because while it is your original work, it was a work for hire - paid for and owned by someone else. Or you implemented a patent. If you don't know of any patents on the work, don't go looking for them. We're not asking you to guarantee that there is no patent encumbrance, just that if you know of any, you tell us. geir
Re: CLA issues Was: java.sql.*
Hi Tor-Einer, I live in The Netherlands, which has all but identical copyright laws to Germany. My parents live in Germany and have looked at this kind of stuff before. I've talked to german ASF committers about legal stuff before who have had their companies look at things. I'm not a lawyer and this is not legal advice. Blah Blah. On Sat, Feb 11, 2006 at 12:47:20AM +0100, Tor-Einar Jarnbjo wrote: Geir Magnusson Jr wrote: Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. What questions do you have for both? I thought I better split this, to prevent the discussion from getting too confusing. One thing I already pointed out with the Apache CLA is that it is very biased towards US copyright law. I am not a lawyer and I really have no clue if US copyright law, German Urheberrecht or both applies if I, living in Germany, am signing a contract with a US entity. Me neither, but I do know that at least the subset of international copyright law that is common to both jurisdictions applies, which should be sufficient. The most serious legal crash is probably section 2: Grant of Copyright License. First problem is, that I can't grant you anything I currently don't have, a copyright on my work. The German counterpart, my Urheberrecht is not transferable and any license I give to use, redistribute, modify etc. the work may under some conditions be revoked. Any contract diverging from these principles is in Germany legally void. Like Geir already mentioned, the CLA asks for a copyright license and not a copyright transfer. This is not a problem under any law in any western country. I don't think the ASF CLA has ever been tested in a German court and I somewhat doubt it ever will be. Legal departments from several German software vendors have reviewed the CLA and then approved its signing by their employees, which is probably as close as we can get to being sure that it is valid enough. Another specific issue related to my proposed Vorbis SPI for JavaSound donation, is if you regard third party source code to be classified as format documentation . To be more exact, the Vorbis format specification from the Xiph Foundation proved to contain several errors and their attitude when me pointing it out was, that the reference decoder is the only thing to be considered as a formal specification. This means of course, that at least when it comes to some estimated 20-40 lines of code, my Vorbis decoder implementation is at least based on the reference decoder from Xiph, which is AFAIK released under a BSD license. This is fine. Even if you copy-pasted something like 20 lines, it is debatable whether that's copyrightable work. Since we don't like debates, we can just add the appropriate (copyright) notices and the like to the relevant source code and NOTICE file(s) to comply with the BSD license. Patent issues are also unclear to me. Yup, they're unclear to everyone, including most European software vendors and the European Union. Big mess. At this point the CLA is really vague (?5), only demaning me to represent that my contribution is free of any patents that I am personally aware of. I have absolutely no ability to judge on that, which of course fulfils, that I am not personally aware of any claims, but depending on the contributors knowledge on patent and license law, this paragraph lies somewhere between meaningsless and very dependent on which country's patents and licenses are to be considered. Exactly. It makes big U.S. companies do a lot of work while it doesn't cause a lot of headache for average joe hacker who hates thinking about patents. Its by design; the main goal of clauses like this is to protect ASF contributors and ASF users from worrying about patents. hope this helps, cheers, Leo
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: CLA issues Was: java.sql.*
Geir Magnusson Jr wrote: I thought I better split this, to prevent the discussion from getting too confusing. One thing I already pointed out with the Apache CLA is that it is very biased towards US copyright law. Well, the ASF is a US Corporation (non-profit) so those are the laws under which we operate. Yes, but US laws are not the laws under which probably most of the contributors are operating and not the laws applicable in most locations where Apache software is being used. Copyright is a legal area where US and British law deviate quite a lot from most other countries and assuming or expecting that US law is relevant if it comes to a legal dispute between e.g. a non-US contributor and a non-US software user or a non-US owner of related intelletual rights, is IMHO rather naive. License. First problem is, that I can't grant you anything I currently don't have, a copyright on my work. The German counterpart, my Urheberrecht is not transferable and any license I give to use, redistribute, modify etc. the work may under some conditions be revoked. Any contract diverging from these principles is in Germany legally void. We aren't asking for a copyright transfer. You still retain any and all copyright on the work. What you are doing is granting a license to the work under the Apache License. Well, you skip the most important part, that some statements in the paragraph are legally void in Germany, and probably most countries, not having an Anglo-Saxon style copyright law. Most problematic are probably the claims for an perpetual, irrevocable license and the claim for sublicensing rights and rights to produce derivative works. I really don't like to bother with legal regulations, but wether you or I like it, this agreement won't hold if proven in a German court and a German court will be responsible, if a German contributor for some reason should decide to take legal actions against some other German entity, which e.g. is producing, distributing or using a derivate work of the contributor's original work. The word German in the last sentence may be replaced with many other nationalities, without invalidating the content :-/ Tor
Re: CLA issues Was: java.sql.*
Tor, IANAL. On Mon, Feb 13, 2006 at 01:34:15AM +0100, Tor-Einar Jarnbjo wrote: assuming or expecting that US law is relevant if it comes to a legal dispute between e.g. a non-US contributor and a non-US software user or a non-US owner of related intelletual rights, is IMHO rather naive. Just about every web hosting company out there and just about every large software vendor out there ships or uses software licensed from the Apache Software Foundation under the Apache License, version 2.0, which is hence sublicensed under the Apache CLA and/or the Apache License from the ASF its contributors. The german government is also well-known for using a lot of ASF software! Just about every huge software vendor out there that has employees in a variety of countries has employees in a variety of countries which contribute under this same CLA, often while being paid by that same company to do so. Many of those vendors have also sent in CCLAs and or software grants. Some of the most skilled and knowledgeable intellectual property lawers, both European and American, have reviewed and/or constantly review the ASF its legal processes, documents, etc. So, IMHO, while you certainly shouldn't trust me or my word or my opinion to be correct when it comes to legal matters, if a document is up on http://www.apache.org/licenses/ as official paperwork and is further considered current best practice, you should not have to worry about it being naive (even if you should always worry about it being right). This is one of the major benefits of doing things under the wings of the ASF - you get to worry just a little less about this stuff. The ASF paperwork is about as close as you can get to a standard, with the possible exception of the FSF paperwork (in particular, you might be interested in http://www.fsfeurope.org/projects/fla/fla.en.html ). License. First problem is, that I can't grant you anything I currently don't have, a copyright on my work. The German counterpart, my Urheberrecht is not transferable and any license I give to use, redistribute, modify etc. the work may under some conditions be revoked. Any contract diverging from these principles is in Germany legally void. We aren't asking for a copyright transfer. You still retain any and all copyright on the work. What you are doing is granting a license to the work under the Apache License. Well, you skip the most important part, that some statements in the paragraph are legally void in Germany, and probably most countries, not having an Anglo-Saxon style copyright law. Most problematic are probably the claims for an perpetual, irrevocable license and the claim for sublicensing rights and rights to produce derivative works. I really don't like to bother with legal regulations, but wether you or I like it, this agreement won't hold if proven in a German court and a German court will be responsible, if a German contributor for some reason should decide to take legal actions against some other German entity, which e.g. is producing, distributing or using a derivate work of the contributor's original work. The word German in the last sentence may be replaced with many other nationalities, without invalidating the content :-/ I don't know enough about law or legal systems to be able to dispute the above, and I'm not going to try, but I do know that it does not match up with what I've previously been told by a variety of people. I believe current ASF counsel is all US-based. I would suggest seeking legal advice from a lawyer specializing in how open source licensing applies within German copyright law. I know there's a lawyer or two here in The Netherlands that specialize in this kind of licensing stuff, Germany must have some, too. I'll also request everyone tries to ensure that you do not try and represent anything as legal fact unless its been thoroughly verified that it is indeed rather certain that what is being said is undisputable. Also, always try and provide as much references as possible. There is enough confusion with regard to all this legal stuff already, and we should make sure we don't try to add to it. 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
java.sql.* (was: Re: Which applications run using Harmony classes?)
Would I be correct in assuming that the majority of java.sql would be trivial to implement by reading the javadocs (everything except DriverManager)? I can take a whack at the low hanging fruit this weekend. Jeremy On 10-Feb-06, at 12:05 PM, zoe slattery wrote: Upayavira wrote: zoe slattery wrote: OK - well - here is a plan. I have these scripts in a hacked together state and they currently rely on reading the output from -verbose:class generated by an IBM JRE. Ideally I'd like them to be able to read a couple of different formats. If anyone is interested in knowing if their app would (in theory) run using Harmony classes open a JIRA called Would $my_favourite_app run on Harmony? and attach the output from java -verbose:class $my_favourite_app. If this works I can pick up the output and use it to test the tool. Please would you also attach the output from java -version? I will append (or ask someone to append) a list of missing files to the JIRA. When I'm happy that my scripts work and I've tidied up the code I'll attach the source as a JIRA and write some instructions on how to use it. FWIW in looking at Derby, it looks as though we still need SQL (could have predicted that I suppose) and JNDI, but those seem to be all that are missing. I can send the list of missing classes to anyone that wants to verify this - it's just slightly too long to paste into mail Paste it on the wiki (wiki.apache.org/harmony/). I'd be curious to see it. Done - at the end of Tim's Apache Derby page: http:// wiki.apache.org/harmony/Apache_Derby Upayavira
Re: java.sql.*
Jeremy Huiskamp schrieb: Would I be correct in assuming that the majority of java.sql would be trivial to implement by reading the javadocs (everything except DriverManager)? I can take a whack at the low hanging fruit this weekend. The java.sql package mostly contains interfaces, so it shouldn't be too much work, but what's so difficult about the DriverManager. It only has to manage a list of registered Driver implementations and the getConnection methods should only iterate through the available drivers, check if the URL is supported and if yes, delegate the call to Driver#connect. Tor
Re: java.sql.*
On 10-Feb-06, at 1:14 PM, Tor-Einar Jarnbjo wrote: Jeremy Huiskamp schrieb: Would I be correct in assuming that the majority of java.sql would be trivial to implement by reading the javadocs (everything except DriverManager)? I can take a whack at the low hanging fruit this weekend. The java.sql package mostly contains interfaces, so it shouldn't be too much work, but what's so difficult about the DriverManager. It only has to manage a list of registered Driver implementations and the getConnection methods should only iterate through the available drivers, check if the URL is supported and if yes, delegate the call to Driver#connect. Didn't say it was difficult, just that it's not trivial ;-) As in, the javadocs don't tell me everything I could possibly need to know to implement it. I'd love to take a crack at it, but I figured I'd start with the really easy stuff. If you beat me to it then so much the better :) Jeremy Tor
Re: java.sql.*
Actually, we've been looking at contributing some stuff that we have already got in this area - I'll let you know by Tuesday (latest). If we can it would at least give you a head start on this and it would be really great if you could help us improve what we have. Jeremy Huiskamp wrote: On 10-Feb-06, at 1:14 PM, Tor-Einar Jarnbjo wrote: Jeremy Huiskamp schrieb: Would I be correct in assuming that the majority of java.sql would be trivial to implement by reading the javadocs (everything except DriverManager)? I can take a whack at the low hanging fruit this weekend. The java.sql package mostly contains interfaces, so it shouldn't be too much work, but what's so difficult about the DriverManager. It only has to manage a list of registered Driver implementations and the getConnection methods should only iterate through the available drivers, check if the URL is supported and if yes, delegate the call to Driver#connect. Didn't say it was difficult, just that it's not trivial ;-) As in, the javadocs don't tell me everything I could possibly need to know to implement it. I'd love to take a crack at it, but I figured I'd start with the really easy stuff. If you beat me to it then so much the better :) Jeremy Tor
Re: java.sql.*
Jeremy Huiskamp wrote: Didn't say it was difficult, just that it's not trivial ;-) As in, the javadocs don't tell me everything I could possibly need to know to implement it. I'd love to take a crack at it, but I figured I'd start with the really easy stuff. If you beat me to it then so much the better :) I already thought about contributing some other stuff, but I am unsure if I fulfil the requirements for contributing (especially regarding exposure to Sun's source code). I sent a mail to Geir Magnusson about JavaSound implementation a few weeks ago, but didn't get any reaction. Perhaps it's better to discuss this here on the mailing list. Tor
Re: java.sql.*
Tor-Einar Jarnbjo wrote: Jeremy Huiskamp wrote: Didn't say it was difficult, just that it's not trivial ;-) As in, the javadocs don't tell me everything I could possibly need to know to implement it. I'd love to take a crack at it, but I figured I'd start with the really easy stuff. If you beat me to it then so much the better :) I already thought about contributing some other stuff, but I am unsure if I fulfil the requirements for contributing (especially regarding exposure to Sun's source code). I sent a mail to Geir Magnusson about JavaSound implementation a few weeks ago, but didn't get any reaction. Perhaps it's better to discuss this here on the mailing list. Yes, this would be the place. Sorry about that - I am in the middle of a machine change, and email switch, so I've been an email blackhole at times... geir Tor
Re: java.sql.*
Geir Magnusson Jr wrote: Yes, this would be the place. Sorry about that - I am in the middle of a machine change, and email switch, so I've been an email blackhole at times... So, I sent you a partial implementation of JavaSound and a Vorbis SPI, any interest? One problem is of course, that I more than once have taken a look at Sun's source code for different reasons and even signed an NDA some ten years ago to get access to the source code for JDK 1.1. Your requirements in the contributor license agreement and questionnaire are IMHO rather vague. Tor
Re: java.sql.*
Tor-Einar Jarnbjo wrote: Geir Magnusson Jr wrote: Yes, this would be the place. Sorry about that - I am in the middle of a machine change, and email switch, so I've been an email blackhole at times... So, I sent you a partial implementation of JavaSound and a Vorbis SPI, any interest? 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 :) One problem is of course, that I more than once have taken a look at Sun's source code for different reasons and even signed an NDA some ten years ago to get access to the source code for JDK 1.1. Your requirements in the contributor license agreement and questionnaire are IMHO rather vague. Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. What questions do you have for both? geir
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
CLA issues Was: java.sql.*
Geir Magnusson Jr wrote: Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. What questions do you have for both? I thought I better split this, to prevent the discussion from getting too confusing. One thing I already pointed out with the Apache CLA is that it is very biased towards US copyright law. I am not a lawyer and I really have no clue if US copyright law, German Urheberrecht or both applies if I, living in Germany, am signing a contract with a US entity. The most serious legal crash is probably section 2: Grant of Copyright License. First problem is, that I can't grant you anything I currently don't have, a copyright on my work. The German counterpart, my Urheberrecht is not transferable and any license I give to use, redistribute, modify etc. the work may under some conditions be revoked. Any contract diverging from these principles is in Germany legally void. Another specific issue related to my proposed Vorbis SPI for JavaSound donation, is if you regard third party source code to be classified as format documentation . To be more exact, the Vorbis format specification from the Xiph Foundation proved to contain several errors and their attitude when me pointing it out was, that the reference decoder is the only thing to be considered as a formal specification. This means of course, that at least when it comes to some estimated 20-40 lines of code, my Vorbis decoder implementation is at least based on the reference decoder from Xiph, which is AFAIK released under a BSD license. Patent issues are also unclear to me. At this point the CLA is really vague (§5), only demaning me to represent that my contribution is free of any patents that I am personally aware of. I have absolutely no ability to judge on that, which of course fulfils, that I am not personally aware of any claims, but depending on the contributors knowledge on patent and license law, this paragraph lies somewhere between meaningsless and very dependent on which country's patents and licenses are to be considered. Tor
