[Message bounced->I subscribed->here it is...]
Hi Archie (and Harmony developers), I see that the public discussion has actually started. I would have rather liked to settle all this quietly. :-/ First, let me say that I admire the cleverness of Archie, when it comes to develop code. I respect him a lot. I simply think that he lacked a little knowledge about Copyright at the time he contributed code to the Harmony project. From Geir's answer to my email, I am confident we can resolve the issue. See a few comments below. > A little background: copyright covers the "expression" of an idea. > To cover the idea itself, a patent is required. This issue is about > copyright; nobody is claiming that SableVM has exclusive rights to > any algorithms AFAIK. I think that this is where you are in error. "Expression" has a larger extent than you think. I cannot translate a book into another language and claim "full copyright" on the translation. I can only claim "co-ownership" on the translated copy. Yet, the translated book might actually not share a single word with the original. And, if the original author doesn't agree to it, I won't be able to publish my translation. Copyright goes even further. It does cover "characters" in novels, movies, cartoons. You can't make another "James Bond" movie without the consent of its copyright owners, even though you are not copying an existing movie or book. Copyright covers the combination of the name, the psychological traits, the profession [spy], his "Bond, James Bond" way of presenting himself, etc. Copyright, unlike trademark, does NOT actually restrict you from creating another character that shares one or two traits, yet it does restrict you from copying the "character" as a whole. Of course, only a judge gets to decide of border-line cases. "Expression" is thus a large thing. This is why companies put a lot of effort to maintain "clean room" status in their strategic projects. JCVM is clearly based on SableVM. You do acknowledge that fact, but you fail to acknowledge that this makes JCVM/JCHEVM a derivative work. This is where we disagree. Had JCVM simply reused a few "ideas" as explained at a relatively high-level in my Ph.D. thesis (where I simply describe the important aspects of some algorithms and data structures), then I would have said nothing. But, JCVM borrowed much more. The exception mechanism, locking, object layout, etc. Even the "stop-the-world" (quite tricky) mechanism is copied almost line to line (with only cosmetic changes). Only one little similarity => you can claim a "random accident". Tens (or even hundreds?) of similarities => you cannot claim "independent work". Once JCVM is built as a derivative work of SableVM, further JCVM development does not erase history and make JCVM not a derivative, unless some very radical change occurs, like a complete re-write. Even then, the "derivation" doubt would persist, as your very intimate knowledge of SableVM's source code makes it impossible to claim "clean room", or even "arm's length" distance from SableVM's source code. JCVM really looks similar to SableVM is many ways. Had you been taking a distance from SableVM's source code before writing it, you would not have written so similar code. This is why I claim that your work is a derivative work. > 1. As for "credit", clearly JCVM uses and reimplements many ideas and > ... > per-class loader memory allocation, and thread management. In fact, > without SableVM as an example to work from this project would probably > have never been attempted. Of course, any errors in translation are mine. > > Whether credit is due is not in question. I know that you acknowledged credit. In the peril of misquoting you a little, I would venture say that you "admit translating". Yet, translation is covered under Copyright laws. > The truth is apparently no one really knows for sure. How "different" > does some software have to be before the copyright no long applies? > (Rhetorical question) Actually, most courts do take into account the process used to get to the final product. This is helpful to determine if there was "copying" during development or if some simple "accidental similarity" happened. Can you claim that you didn't study closely the SableVM source code as an "inspiration" to re-write this code in JCVM? > There is a spectrum between cut and paste (clear violation) and > completely different implementation of the same idea or algorithm > (clearly allowed as long as there is no patent). In between people > can have different opinions of where the line is drawn of course. Studying the development process can help, though. > 3. So what do we do? My wish is to give SableVM the benefit of the doubt. > If there's something in there they claim is "theirs", we can take it out > and replace it. I'd rather do that than argue about it. We should > remember that JCVM owes SableVM a debt of gratitude and respect their > wishes. The problem is identifying "what", if anything, is "untainted" is JCHEVM. This might be a difficult, given your apparent "tainting" at the time you developed it. You should read Geir's text at: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200506.mbox/[EMAIL PROTECTED] 3) Taint ... With those activities in mind, have you done any of the following to an implementation of one or more of the components you listed in item (2) above : - Read some or all the source code for an implementation? - Fixed defects or performed other maintenance activity on an implementation? - Enhanced the source code for an implementation with additional function, performance or other qualities of service? ... If you have answered yes to any question above, you may not be an contributor to the related component of Apache Harmony unless... What is your answer to these questions? > There's also the possibility that SableVM folks could give their blessing > and donate their code, but that might have practical difficulties because > all the SableVM contributors would have to agree to the new license > (though I'm one of them, so my vote would be easy :-) If I understand clearly, unlike the GNU project, the ASF does not ask for Copyright assignment; this can simplify things a lot, as Copyright assignment would practically be impossible. On the other hand, licensing SableVM under the Apache License can be feasible. I will have to get in touch with other SableVM contributors. The most important contributors (in terms of lines of code) were my students; I do not anticipate problems there (hoping so, at least). If I can't get in touch with some minor contributors, I could simply remove their code from the re-licensed SableVM. Anyway, most non-student contributors only contributed patches to the class libraries, not to SableVM itself, making it a non-issue in such case. The question is, should it be licensed under the Apache license, or dual-licensed: Apache License + GNU LGPL? Personally, I would prefer dual licensing, to ensure GPL compatibility (at least, until GPL 3 comes out, as it seems it will be compatible to the Apache License). We would also have to check all of SableVM's dependencies... (talking to self): I think there are dependencies on GNU Lib C. Is that a problem? So, if the Harmony project has no problem acknowledging the shared Copyright of SableVM authors on JCHEVM, I will get in touch with these authors to get their consent to a license change. Actually, we could get in further sharing. SableVM already has many things in it (or awaiting in developer "sandboxes" to be migrated into the development trunk): 1- Invocation interface support. 2- generational/incremental precise garbage collector. 3- JVMDI/JDWP implementation. 4- High portability: Works on many, many platforms. 5- etc. Regards, Etienne -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
