Re: [jchevm] porting harmony classlib to JCHEVM
Archie, Below is the README.txt that I intend to include with the (very) rough glue layer. The whole glue layer is currently 350KB. I am not certain if this donation needs to be a bulk contribution. Most of the 350KB derives from existing Apache Harmony code. Also, I don't want to check all these files into source code control until we have a clear understanding where they need to reside and how we want the directories arranged. The README.txt: Feb 11, 2006 Weldon Washburn, Intel The code in this tree is very new. It has not been compiled. This tree, kernel_path, is a generic adapter that will glue the Apache Harmony Class Library to any Java Virtual Machine that runs GNU Classpath. The first JVM that kernel_path will run on is Harmony JCHEVM. It is located at: http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/jchevm/ Directions for obtaining a copy of Harmony Class Library are at: http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html In the Harmony Class Library tree is a document describing how to connect the libraries to a new Java Virtual Machine. These directions are located in the tree at: ../Harmony/doc/kernel/kernel.txt kernel.txt states: The Kernel Java classes are those classes which are tied to the structure of the VM, or whose structure is known by the VM. Most of these classes are defined by the Java 1.4.2 API specification. The IBM VM implementations of these classes are provided in open source. The IBM implementations rely on the presence of (typically) VM specific natives to implement the required Java APIs. Other VM writers can choose to use these implementations, but this forces the writer to use the reference design and the writer must then implement the natives, for which minimal documentation is provided. The kernel_path directory is a copy of the following Harmony Class Library sub-tree: ./Harmony/modules/kernel To reduce clutter, the svn directories and files have been removed from kernel_path. The original directory structure remains unchanged. Current status of these files: kernel_path/VM_native_stubs contains the java declaration of JCHEVM's native method entry points. These are java source files that correspond to _jc_ilib_table [ ] that is defined in: http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/jchevm/libjc/native_lib.c VM_native_stubs files are probably 50% complete. Nothing has been compiled. Most of the mods were done to the kernel_path/src/main/java/java/lang directory. This directory is probably 20% complete. Nothing has been compiled. Probably the hardest file to get right will be j/j/l/Thread.java. None of the following files have been modified yet: kernel_path/src/main/java/java/lang/ref kernel_path/src/main/java/java/lang/reflect kernel_path/src/main/java/com/ibm/oti/vm
Re: [jchevm] porting harmony classlib to JCHEVM
Archie Cobbs wrote: Geir Magnusson Jr wrote: TO me, the ideal is to have a very clear demarcation of what is the Harmony Classlibrary VM interface. So I'd see Harmony VM Interface -- Harmony/Classpath Adapter -- JCHEVM Is this what you mean? Yes.. that's the basic near term idea... (although technically if the adapter is written in Java (as we've discussed) then the Harmony VM interface is not really a VM interface). However I think ideally Classlib's API should be implemented to be equal Classpath's API. That may sound strange so let me try to explain why. The state of things now is that the VM API defined by Classlib is, well, not very well defined :-) That's not actually true. We may be missing documentation or something, but the Harmony Classlib VM API is a well-tested production API used by IBM in their commercial VM offerings. Hard to argue with that. That's why the IBM J9 VM that was offered for evaluation purposes just works. Compare Classlib's Thread.java: trunk/modules/kernel/src/main/java/java/lang/Thread.java with these files from Classpath: http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17root=classpathview=markup http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9root=classpathview=markup Note every method in Classlib's Thread.java is: return null. On the other hand, Classpath's API is much more complete and fully developed, race conditions have been analyzed and handled, SecurityManager implications have been taken into account, etc. To get Classlib to the same level, you'd have to duplicate a whole bunch of (at times very tricky and subtle) work -- not only implementing the API, but figuring out what the right API is -- that's already been figured out over several years in Classpath. Ok, I'm not sure what you are referring to. I know that our VM API is production tested on a certified, complete stack. I'm not sure where Classpath has been used in anger yet. In short there is lots of unimplemented stuff remaining in Classlib's existing API. From a simple argument of expediency, not to mention the benefits for debugging previously mentioned, adopting the already baked Classpath API makes lots of sense. We might be missing information from IBM on this. Tim? geir
Re: [jchevm] porting harmony classlib to JCHEVM
Weldon Washburn wrote: I agree with most everything you said below. The Thread class is indeed tricky. I can't look at GNU Classpath code as I am doing this port. I want kernel_path to be Apache licensed and not a GPL Not looking is certainly a safe approach, but make sure you don't unnecessarily restrict yourself. Re-implemnting an algorithm in your own words is not a copyright violation. And certainly there's less at stake with Classpath code than e.g. looking at Sun's code. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
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: [jchevm] porting harmony classlib to JCHEVM
Geir Magnusson Jr wrote: The state of things now is that the VM API defined by Classlib is, well, not very well defined :-) That's not actually true. We may be missing documentation or something, but the Harmony Classlib VM API is a well-tested production API used by IBM in their commercial VM offerings. Hard to argue with that. That's why the IBM J9 VM that was offered for evaluation purposes just works. My understanding from Weldon's emails is that while it's true that Classlib runs on J9, that's true because J9 provides its own glue for Classlib to make things work. To make Classlib run on any other VM, there would still be a lot of work that needs to be done, which fortunately Weldon is already forging ahead on (if you don't believe me, compare the two java.lang.Thread classes I mentioned (Classpath's and Classlib's) for example). My comment is simply that there would be *lots* of benefits if the bottom of this glue layer we're developing is the same as the VM API that Classpath uses, and moreover this is actually the easiest path to take anyway. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] porting harmony classlib to JCHEVM
Archie Cobbs wrote: Geir Magnusson Jr wrote: The state of things now is that the VM API defined by Classlib is, well, not very well defined :-) That's not actually true. We may be missing documentation or something, but the Harmony Classlib VM API is a well-tested production API used by IBM in their commercial VM offerings. Hard to argue with that. That's why the IBM J9 VM that was offered for evaluation purposes just works. My understanding from Weldon's emails is that while it's true that Classlib runs on J9, that's true because J9 provides its own glue for Classlib to make things work. To make Classlib run on any other VM, there would still be a lot of work that needs to be done, which fortunately Weldon is already forging ahead on (if you don't believe me, compare the two java.lang.Thread classes I mentioned (Classpath's and Classlib's) for example). My comment is simply that there would be *lots* of benefits if the bottom of this glue layer we're developing is the same as the VM API that Classpath uses, and moreover this is actually the easiest path to take anyway. I agree that having something (whatever - glue, tape, twine, spit, bubblegum...) that lets GNU Classpath-using VMs just plug into Apache Harmony's Classlib would be just peachy... I just want to make sure that we know everything surrounding the VM interface to the Classlib... geir __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
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: API coverage results for Harmony?
On Sat, Feb 11, 2006 at 04:01:25PM +, Stuart Ballard wrote: Is there any interest in something like this? Awesome! The ASF has hardware for this kind of stuff, we just need to get it properly set up to do this. /me thinks about what it would take to fire up japitools from within Apache Gump... - LSD
ASF Licensing policy and the EPL (was: javadoc something something...)
Hi all, On Thu, Feb 09, 2006 at 11:56:56PM -0500, Jeremy Huiskamp wrote: I was wondering about this myself. I went and slogged through the epl and had trouble gathering exactly what the license restrictions were. From what I could tell, most of it was just disclaimer. Nah, besides all the disclaimer stuff and the granting of various rights there's also some viralness in there. The EPL is completely viral for source code, and for object form, relicensing is explicitly allowed but requires a notice with the software that source code is available. However, even then, the viralness is restricted completely to the EPL-ed software and/or any derivative works. For example, if you have a javadoc tool licensed under the EPL, a doclet would not be a derivative work, hence you could ship the doclet with the object form version of the EPL and the EPL would not apply to the doclet. I think. IANAL. Not legal advice. Blah. What is the official apache stance on epl code? On 9-Feb-06, at 11:48 PM, Anthony Green wrote: On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote: We were planning to just use the eclipse compiler. No reason to rewrite. Didn't you just write in this thread that you need all the tooling? What makes the compiler special? Nothing. If you can non-Apache FOSS licensed tools, why not just use the excellent gjdoc for your javadoc tool? http://www.gnu.org/software/classpath/cp-tools/ For licensing reasons, and for licensing reasons only. Apache does not yet have an official stance on the EPL license nor on the GPL+Exception license for GNU Classpath, but we're getting quite close to having a detailed, official and clear-worded policy on most of this. Unfortunately, the precise information is all still restricted to private mailing lists but that will also change soon (fingers crossed). IIRC, Apache projects will be allowed to redistribute EPL-licensed software in binary form. The situation with GPL (exception or not) is more involved, and goes further than just the virality and patent clause problems we've extensively discussed before. (I think sublicensing is one of the key bits). Note that redistribute is different from use. (I just answered the question for redistribution since I'm guessing it is part of what you meant here.) Even right now, before there is any kind of new policy, there is nothing stopping us from *using* gjdoc, just as there is nothing stopping us from using GCC. cheers, Leo
Re: NDA issues and acceptable use of sun source
Leo Simons wrote: 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'm not so sure - the fact that there's been that exposure under NDA means there can be no contribution in that area until the NDA problem is resolved. 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. That is a possible out. 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! :-) If what you were exposed to under the NDA has no tie to what you are offering, then the NDA is irrelevant for this. For other things, you still have a problem, but if you've never seen Sun code in and around the sound API, then you are fine. geir
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: NDA issues and acceptable use of sun source
Geir Magnusson Jr wrote: I'm not so sure - the fact that there's been that exposure under NDA means there can be no contribution in that area until the NDA problem is resolved. Which means? Do I have to solve it or are you willing to solve it? It is of course silly of me not to keep legal agreements I have signed, but as Leo pointed out, is Sun not anymore requiring an NDA for other people to get access to the JDK source code. If what you were exposed to under the NDA has no tie to what you are offering, then the NDA is irrelevant for this. For other things, you still have a problem, but if you've never seen Sun code in and around the sound API, then you are fine. I do of course not remember anything of any source code I had in my hands ten years ago. I even quite often forget in the afternoon what I did before lunch. I am not sure however, if Sun's lawyers believe that and I rather don't want to find out. Tor
Re: Using Cairo for Harmony graphic stuff?
On Sat, Feb 11, 2006 at 12:08:55PM -0500, Stefano Mazzocchi wrote: Ryan Bloom wrote: As one of the original authors of APR, I would like to suggest that instead of using OS dependant native code, when we get to the point of writing awt, we should create an apr-window project, and create the library for the abstraction layer. I have had enough conversations with other APR developers to be relatively certain that this idea would be well received. Whoah, that's a load of work you're describing there! :-) Hi Ryan, nice to see you around here. I'm happy that Enrico has changed his mind about APR and I would also be in favor of harmony committing back code to APR. Another think that I wonder, for the windowing stuff, why don't we use Cairo[1]? Firefox 2.0 is going to be based on it, so you would expect lots of polishing/fixing/profiling/OS-portability going on on that front that we would just reuse and it's dual-licensed under LGPL or MPL 1.1, so if we release it under the MPL 1.1 license it's also compatible. What do you think? Thought about it. I would've mention that the Java-GNOME people are working on an AWT peer for Cairo and have a sizeable amount of the java bindings already done (http://cvs.cairographics.org/cairo-java/), but I don't wan't to cause more mudslinging... - LSD
Re: Using Cairo for Harmony graphic stuff? [was Re: Using APR for Harmony's native link to the OS?]
Stefano Mazzocchi wrote: Another think that I wonder, for the windowing stuff, why don't we use Cairo[1]? Isn't Cairo just a rendering library? AFAIK, it does not offer any kind of e.g. portable widget access, which is probably the most tricky thing to implement for AWT. Swing can be implemented in pure Java, based on some simple native support by AWT (open window and supply a Graphics object into which the content can be rendered). I don't see where Cairo can offer much help in that area? 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: Using Cairo for Harmony graphic stuff?
On Mon, Feb 13, 2006 at 02:04:18AM +0100, Tor-Einar Jarnbjo wrote: Stefano Mazzocchi wrote: Another think that I wonder, for the windowing stuff, why don't we use Cairo[1]? Isn't Cairo just a rendering library? Err, yes...it offers drawing primitives for things such as lines and points and glyphs, on top of other platforms such as X11 and win32. AFAIK, it does not offer any kind of e.g. portable widget access, Aye, I think not. which is probably the most tricky thing to implement for AWT. I wouldn't know. I can imagine its less work to build on top of Cairo than to build on top of X11/win32/etc directly, since Cairo is precisely designed to fulfill the gap between something like AWT (or GTK or wxWindows or ...) and the underlying system. But even then a windowing toolkit is always a whole lot of work. Swing can be implemented in pure Java, based on some simple native support by AWT (open window and supply a Graphics object into which the content can be rendered). I don't see where Cairo can offer much help in that area? Well, that Graphics object at some points needs rendering to the screen doesn't it? :-) cheers! LSD
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
[jira] Commented: (HARMONY-42) com.ibm.io.nio.FileChannel is not fully implemented
[ http://issues.apache.org/jira/browse/HARMONY-42?page=comments#action_12366146 ] Richard Liang commented on HARMONY-42: -- Thanks a lot, Tim. We are satisfied with the patch application. You may close this JIRA. com.ibm.io.nio.FileChannel is not fully implemented --- Key: HARMONY-42 URL: http://issues.apache.org/jira/browse/HARMONY-42 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Tim Ellison Attachments: FileChannel_patch.zip, Harmony42-IFileSystem-patch.txt, Harmony42-IMemorySystem-patch.txt, Harmony42-java_io_FileChannelFactory-patch.txt, Harmony42-java_io_FileOutputStream-patch.txt, IFileSystem.java Many functions of FileChannel, such as memory map, transfer, gathering/scattering I/O are not implemented. Further, three classes in java.io, FileInputStream FileOutputStream, and RandomAccessFile, are related to java.nio.FileChannel, so that they can be refactored to base on same JNI interface, just like the network channels and sockets. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Using Cairo for Harmony graphic stuff? [was Re: Using APR for Harmony's native link to the OS?]
Tor-Einar Jarnbjo escreveu: Stefano Mazzocchi wrote: Another think that I wonder, for the windowing stuff, why don't we use Cairo[1]? Isn't Cairo just a rendering library? AFAIK, it does not offer any kind of e.g. portable widget access, which is probably the most tricky thing to implement for AWT. Swing can be implemented in pure Java, based on some simple native support by AWT (open window and supply a Graphics object into which the content can be rendered). I don't see where Cairo can offer much help in that area? http://www.mono-project.com/Windows_Forms#History
Re: verifying signed jars
That's a good idea :-) Richard Liang China Software Development Lab, IBM Tim Ellison wrote: Why not contribute directly to BouncyCastle? Regards, Tim Mikhail Loenko wrote: The sources would be good - we would be able to fix bugs quickly and replace parts of implementation for example where our code is faster. Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Heh. Everything we will do is legal :) The point is - would taking some source from BC be the smart thing to do - would it be complete, and what kind of maintenance burden would this be going forward? Would some kind of re-packaged artifact from the BC project itself be better? Do we need source? Could we have a step where we re-package BC code in a form more suited for our purposes? geir Mikhail Loenko wrote: We can if it is legal Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: So I'll ask the obvious - can we borrow some of this from BC? Stepan Mishura wrote: We should have at least to verify BC provider: 1) Message digest algorithm: SHA-1 2) Signature algorithm: SHA1withDSA Other jars may require additional algorithms, for example, SHA1withRSA. We can verify BC provider first and use it for further jar verifications. Thanks, Stepan Mishura Intel Middleware Products Division On 2/10/06, George Harley [EMAIL PROTECTED] wrote: Hi Tim, In order to verify the signature of those signed provider jars I believe that you would also need trusted implementations of : * SHA-1 and MD5 digest algorithms * DSA and RSA signature algorithms Best regards, George IBM UK Tim Ellison wrote: Stepan Mishura wrote: snip Returning back to the 'missing post'. I agreed with suggestion but currently we don't have Harmony provider so we should define how we locate 'trusted provides' to be secure. We just need a trusted SHA1PRNG, right? then we can open signed providers' jars and get any others. Regards, Tim --
Re: verifying signed jars
How will it solve our problem with verifying signed jars? Thanks, Mikhail On 2/13/06, Richard Liang [EMAIL PROTECTED] wrote: That's a good idea :-) Richard Liang China Software Development Lab, IBM Tim Ellison wrote: Why not contribute directly to BouncyCastle? Regards, Tim Mikhail Loenko wrote: The sources would be good - we would be able to fix bugs quickly and replace parts of implementation for example where our code is faster. Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Heh. Everything we will do is legal :) The point is - would taking some source from BC be the smart thing to do - would it be complete, and what kind of maintenance burden would this be going forward? Would some kind of re-packaged artifact from the BC project itself be better? Do we need source? Could we have a step where we re-package BC code in a form more suited for our purposes? geir Mikhail Loenko wrote: We can if it is legal Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: So I'll ask the obvious - can we borrow some of this from BC? Stepan Mishura wrote: We should have at least to verify BC provider: 1) Message digest algorithm: SHA-1 2) Signature algorithm: SHA1withDSA Other jars may require additional algorithms, for example, SHA1withRSA. We can verify BC provider first and use it for further jar verifications. Thanks, Stepan Mishura Intel Middleware Products Division On 2/10/06, George Harley [EMAIL PROTECTED] wrote: Hi Tim, In order to verify the signature of those signed provider jars I believe that you would also need trusted implementations of : * SHA-1 and MD5 digest algorithms * DSA and RSA signature algorithms Best regards, George IBM UK Tim Ellison wrote: Stepan Mishura wrote: snip Returning back to the 'missing post'. I agreed with suggestion but currently we don't have Harmony provider so we should define how we locate 'trusted provides' to be secure. We just need a trusted SHA1PRNG, right? then we can open signed providers' jars and get any others. Regards, Tim --
Re: verifying signed jars
Hello Mikhail Loenko, :-) I'm just wondering whether it's possible to change/improve BouncyCastle to meet our requirement. Richard Liang China Software Development Lab, IBM Mikhail Loenko wrote: How will it solve our problem with verifying signed jars? Thanks, Mikhail On 2/13/06, Richard Liang [EMAIL PROTECTED] wrote: That's a good idea :-) Richard Liang China Software Development Lab, IBM Tim Ellison wrote: Why not contribute directly to BouncyCastle? Regards, Tim Mikhail Loenko wrote: The sources would be good - we would be able to fix bugs quickly and replace parts of implementation for example where our code is faster. Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Heh. Everything we will do is legal :) The point is - would taking some source from BC be the smart thing to do - would it be complete, and what kind of maintenance burden would this be going forward? Would some kind of re-packaged artifact from the BC project itself be better? Do we need source? Could we have a step where we re-package BC code in a form more suited for our purposes? geir Mikhail Loenko wrote: We can if it is legal Thanks, Mikhail On 2/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: So I'll ask the obvious - can we borrow some of this from BC? Stepan Mishura wrote: We should have at least to verify BC provider: 1) Message digest algorithm: SHA-1 2) Signature algorithm: SHA1withDSA Other jars may require additional algorithms, for example, SHA1withRSA. We can verify BC provider first and use it for further jar verifications. Thanks, Stepan Mishura Intel Middleware Products Division On 2/10/06, George Harley [EMAIL PROTECTED] wrote: Hi Tim, In order to verify the signature of those signed provider jars I believe that you would also need trusted implementations of : * SHA-1 and MD5 digest algorithms * DSA and RSA signature algorithms Best regards, George IBM UK Tim Ellison wrote: Stepan Mishura wrote: snip Returning back to the 'missing post'. I agreed with suggestion but currently we don't have Harmony provider so we should define how we locate 'trusted provides' to be secure. We just need a trusted SHA1PRNG, right? then we can open signed providers' jars and get any others. Regards, Tim --
