Re: [Legal] Requirements for Committers
On Jun 30, 2005, at 2:11 PM, Ricardo Morin wrote: Hi, I have some comments on Section I, Division of the Repository. In the current proposal, it appears as if the partitioning of the repository is three big chunks: JVM, Class library and Website/Documentation. Due to the very large size of this project, I would like to propose to break down the Class library part into the following more discrete modules: - GUI – Essentially swing - Client – Awt, java2D, etc - Core – lang, util, networking, io - Enterprise – jdbc, corba, jmx, etc - Security – security and crypto - XML – Xerces/Xalan - Tools – javac, jar, jdb, etc If we ever have to do a class library, this is fine by me. This will move the project more in the modular direction, which was stated as one of main goals for Harmony. I believe that communities of interest are most likely to form around these projects. Yes, indeed. But for now, until we have a compelling reason to consider our own class library, we're working out how to work with GNU Classpath. So Section I would look like: I. Division of Repository - 1) JVM 2) GUI class libraries 3) Client class libraries 4) Core class libraries 5) Enterprise class libraries 6) Security class libraries 7) XML class libraries 8) Tools 9) Website and Documentation I'd rather see, if we did classlib : 1) JVM a) core b) mm c) JIT i) interpreter ii) compiler 2) ClassLibrary a) GUI b) Client c) core d) . z) tools 3) Website and documentation This is a minor restructuring, but one that seems to make more hierarchical sense to me. I would also like to propose to update Section II to clarify the granularity of the access control list to the division of the repository above. That or finer, because we may need to partition some of the large grain down, such as having a person who has to be kept out of jvm.jit.compiler but can work in interpreter. Right? geir Thoughts? Comments? Thanks, Ricardo --- Geir Magnusson Jr. [EMAIL PROTECTED] wrote: NOTE : THE FOLLOWING IS FOR DISCUSSION PURPOSES. THIS PROPOSAL GOES BEYOND STANDARD APACHE PRACTICE, AND WILL HAVE TO BE REVIEWED - IF WE CHOOSE TO FOLLOW THIS ROUTE - BY THE ASF. There are many legal and political concerns about the Apache Harmony project, and it behooves us to do the best job we can at all times in ensuring that the software contributed or created by the community is as clean (in the IP sense) as possible. We do this to protect the ASF, the committers, and the users of the software. There are are few issues that come to mind when thinking about committers : 1) What IP has the committer been exposed to, and what is the position of the owner of that IP with respect to the committer's participation? For example, has the committer been exposed to copyrighted or patented material, in which an accidental re-creation would put the project or users at risk of legal action from the IP owner? 2) If people have been exposed to code that would be problematic for us, what can we do to allow the maximum participation with the minimal risk? 3) How do we ensure that we carefully track our committers and what they've been exposed to? To solve, consider the following : I. Division of Repository - For starters, we can divide our SVN repository into parts : 1) JVM - VM - JIT - GC - etc 2) Class library - VM/lib interface :-b 3) Website and Documentation and we limit access to the SVN to which your contributions have no taint as we understand it at the moment. Because attitudes will change over time, I think that taint can go away as an individual's issue that causes the 'taint' gets resolved. We can start with access for website and docs immediately w/o much consideration for 'taint'. II. Specific Access Control Lists -- Through fine-grained (as necessary) access control lists for the SVN repo, we'll allow committers into repos for project components for which they have no taint. If they've worked on Sun's class libraries in the past but no exposure to VM, we keep them from any class library work we do (if any) and allow them into VM-related code. I think for simplicity in accounting, we should be conservative and explicit about access. You are granted access only to repos that you ask to be granted access to (although with the exception of the taint issue, we should grant to anything asked for...) and encourage people to keep their personal list small, and ask for access to be removed if they no longer need it. III. Strict Limits on Committer Contribution - Committers can only commit contributions to the repositories that they personally created specifically for contribution to Apache Harmony. This is the standard
Re: [Legal] Requirements for Committers
On Jun 23, 2005, at 3:36 AM, usman bashir wrote: Hi! gier! i m from Pakistan and here and in even our some neigbouring counteries like INDIA etc , the employer has the right over only those things that we write for them. but not for those whom we write for us , so even it is possible to do parrallel work for others. but as u suggested a letter from our contractor, i can provide but it ll certainly raise some eyebrowse here even though it is not going to help harmory me or my company:) as for as other restrcition are concern i am free from them as i have never feel concern what the Sun writes for us. so even though having more then onse src.zip (as due to several JDKs on my machine) , i never dig into their codes. so i request u either reiterate over ur statment about company statement and if u r still looking over it then i have to mess up with my PM. We'll have a new version of this out here on the list soon that addresses this. I think that you won't have to go hassle your manager or employer if there is clearly no right over the work you would be doing for Harmony. geir On 6/14/05, Ben Laurie [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: On Jun 9, 2005, at 3:48 AM, Robin Garner wrote: 8) Employment Limitations Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. To me, this is _way_ too restructive. It is very restrictive, and is a starting point for the discussion. This is a real problem, I think. I believe that people don't understand the restrictions they are working under, and the ramifications of what can happen. While this kind of statement wouldn't be a problem for me currently, from time to time I've been employeed by either a large company or the Australian Government, neither of which have any legal rights to anything I do out of hours, but who would have conniptions if asked to sign an agreement like this. Simply because the pointy haired bosses wouldn't understand what it was about, and would go into knee-jerk abnegation-of-responsibility mode. LOL. KJAORM Well, what do we do? I'm not sure we can punt here, but clearly we want to make it so the broadest community can participate. Clearly your requirements only apply if the contributor's employer has rights to their contribution. If the employer has no rights, then all the contributor need do is to state that. Cheers, Ben. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff -- Usman Bashir Certified IBM XML Solution Developer Certified UML Developer Brainbench Certified Internet Perfessional[advance](BCIP) Brainbench Certified Java Perfessional (BCJP) Brainbench Certified .NET Perfessional Brainbench Ceritified C++ Perfessional (BCCP) Software engineer IT24 Faculty Member Operation Badar Lahore -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for Committers)
Dalibor Topic wrote: Steve Blackburn wrote: Dalibor Topic wrote: Many people don't see the need to look at non-free software in general, and chances are pretty slim that anyone I know will ever get that bored and out of reading material to accept the 'Read only' license, for an example of a very funny non-free software license. I have never looked at non-free implementations, but I am interested to know what this means for those of us who have extensive exposure to implementations such as Kaffe (GPL) or Jikes RVM (CPL). My reading of it is that I can't work on any part of Harmony for which I am tainted by my Jikes RVM exposure without permission from the copyright holder of Jikes RVM. Is that right? Nope. :) You can look at free software and work on other software as much as you want to, as free software licenses do not claim further rights beyound the rights granted to the author through copyright laws. I.e. if you copy or modify free software works, you are bound by their license terms, as the copyright laws grant the authors a say in derivative works. If you don't do that, then the author has no say in your own, original work. You are allowed to study free software (freedom 1 [1]). You can do what you want with that knowledge, modulo patents and creating derived works.[0] Its not quite as simple as that (I happen to have been taking legal advice recently on this question) - if I look at your implementation, then I write my own, and my own is substantially similar to yours, then I may be infringing your copyright, even if I wrote mine from scratch. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for Committers)
I've had different answers on legal-discuss to some of these questions. I would encourage folks to avoid these kinds of detailed legal discussions here in favor of discussions with generally more qualified people on that list. I would merely like to state that the issue of derivative work is NOT straightforward and the issue of the JRL is not even as straighforward as it seems unfortunately and encourage further discussion take place on legal-discuss. Moreover, it is my personal opinion that the JBoss-Geronimo issue was a very specific set of circumstances that have no real lessons to learn for this project (though I speak only for myself). -Andy Geir Magnusson Jr. wrote: On Jun 9, 2005, at 8:10 AM, Bruno F. Souza wrote: Dalibor Topic wrote: You can look at free software and work on other software as much as you want to, as free software licenses do not claim further rights beyound the rights granted to the author through copyright laws. I.e. if you copy or modify free software works, you are bound by their license terms, as the copyright laws grant the authors a say in derivative works. If you don't do that, then the author has no say in your own, original work. You are allowed to study free software (freedom 1 [1]). You can do what you want with that knowledge, modulo patents and creating derived works.[0] Well, the tainting (if that can be said that way) on open source licenses only have any effect if the original license has some reciprocity rules (like the GPL/LGPL for example) that prevents you to use the code anyway you want. Under copyright, you cannot simply copy the code, and as such, Harmony's code should not bear any resemblance to other free J2SE implementations to which the license is not Apache compatible. As seen in the JBoss vs Geronimo legal discussion, we should probably be careful here as well. To be clear, there never was any JBoss code copied for Geronimo. One issue from that discussion was similarity of design approach, but I think that's ok. If we see that Kaffe has a great trick of caching the $foo objects to solve the problem of constantly reloading from disk, then I don't see a problem with us using the same strategy as long as we don't use the source code from Kaffe. This is how fields of knowledge grow - people learn from each other. And another can or worms is Sun's research license (JRL), that specifically says: B. Residual Rights. You may use any information in intangible form that you remember after accessing the Technology, except when such use violates Sun's copyrights or patent rights. That pretty much spells out the same as what Dalibor said: You can do what you want with that knowledge, modulo patents [rights] and creating derived works [copyright rights]. So, if we're allowing (with the mentioned care to not infringe copyright rights) anyone to work on Harmony that have worked on the open source implementations, should we allow those that have read or worked on Sun's code under the JRL the same treatment? This non-lawyer says yes, but there may be some clarification needed. Or for the sake of extra care, we should avoid both or one of the situations? Maybe that would be going too far? Geronimo did not avoid contributions from people that worked at JBoss, and I understand that besides some trouble along the way, it all turned out OK in the end. Yes. One of the key lessons from Geronimo (which had nothing to do with JBoss, actually) was that we should track the bulk contributions, even from committers. These can be a small as a developers favorite little string library or something, and if that person has been doing OSS for a while, has probably licensed that under other licenses to other projects. That dev is free to relicense if they choose, of course. The problem is when someone does a source code comparison and gets a match, questions are asked, and it's much easier to answer the question when you have a database of contributions you can refer to rather than um, lets go look... geir More food for though... -- Bruno. __ Bruno Peres Ferreira de Souza Brazil's JavaMan http://www.javaman.com.br bruno at javaman.com.br if I fail, if I succeed, at least I live as I believe -- Andrew C. Oliver SuperLink Software, Inc. Java to Excel using POI http://www.superlinksoftware.com/services/poi Commercial support including features added/implemented, bugs fixed.
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for Committers)
On Jun 9, 2005, at 8:10 AM, Bruno F. Souza wrote: Dalibor Topic wrote: You can look at free software and work on other software as much as you want to, as free software licenses do not claim further rights beyound the rights granted to the author through copyright laws. I.e. if you copy or modify free software works, you are bound by their license terms, as the copyright laws grant the authors a say in derivative works. If you don't do that, then the author has no say in your own, original work. You are allowed to study free software (freedom 1 [1]). You can do what you want with that knowledge, modulo patents and creating derived works.[0] Well, the tainting (if that can be said that way) on open source licenses only have any effect if the original license has some reciprocity rules (like the GPL/LGPL for example) that prevents you to use the code anyway you want. Under copyright, you cannot simply copy the code, and as such, Harmony's code should not bear any resemblance to other free J2SE implementations to which the license is not Apache compatible. As seen in the JBoss vs Geronimo legal discussion, we should probably be careful here as well. To be clear, there never was any JBoss code copied for Geronimo. One issue from that discussion was similarity of design approach, but I think that's ok. If we see that Kaffe has a great trick of caching the $foo objects to solve the problem of constantly reloading from disk, then I don't see a problem with us using the same strategy as long as we don't use the source code from Kaffe. This is how fields of knowledge grow - people learn from each other. And another can or worms is Sun's research license (JRL), that specifically says: B. Residual Rights. You may use any information in intangible form that you remember after accessing the Technology, except when such use violates Sun's copyrights or patent rights. That pretty much spells out the same as what Dalibor said: You can do what you want with that knowledge, modulo patents [rights] and creating derived works [copyright rights]. So, if we're allowing (with the mentioned care to not infringe copyright rights) anyone to work on Harmony that have worked on the open source implementations, should we allow those that have read or worked on Sun's code under the JRL the same treatment? This non-lawyer says yes, but there may be some clarification needed. Or for the sake of extra care, we should avoid both or one of the situations? Maybe that would be going too far? Geronimo did not avoid contributions from people that worked at JBoss, and I understand that besides some trouble along the way, it all turned out OK in the end. Yes. One of the key lessons from Geronimo (which had nothing to do with JBoss, actually) was that we should track the bulk contributions, even from committers. These can be a small as a developers favorite little string library or something, and if that person has been doing OSS for a while, has probably licensed that under other licenses to other projects. That dev is free to relicense if they choose, of course. The problem is when someone does a source code comparison and gets a match, questions are asked, and it's much easier to answer the question when you have a database of contributions you can refer to rather than um, lets go look... geir More food for though... -- Bruno. __ Bruno Peres Ferreira de Souza Brazil's JavaMan http://www.javaman.com.br bruno at javaman.com.br if I fail, if I succeed, at least I live as I believe -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Legal] Requirements for Committers
On Jun 9, 2005, at 7:51 AM, Ahmed Saad wrote: On 6/8/05, Steve Blackburn [EMAIL PROTECTED] wrote: I have never looked at non-free implementations, but I am interested to know what this means for those of us who have extensive exposure to implementations such as Kaffe (GPL) or Jikes RVM (CPL). My reading of it is that I can't work on any part of Harmony for which I am tainted by my Jikes RVM exposure without permission from the copyright holder of Jikes RVM. Is that right? Same goes here!! here is the story.. i got two books (Programming the Java Virtual Machine and Inside the Java Virtual Machine).. i started reading about VM internals... and i thought i'd download kaffe or jikes RVM source code to look at their implementation and to play a little after reading some chapters from one of these books... will i be able to contribute to harmony vm if i do such? That is our intention, yes. We just need to work out how we do this. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Legal] Requirements for Committers
What I meant was there is little one can do against someone signing a license in bad faith. You can do, and should do, certain due diligence beforehand but there is a point where you just have to assume someone will live up to the promise he or she is making by agreeing to a license. On Jun 9, 2005, at 3:51 PM, Onno Kluyt wrote: That is what courts are for . (at least the bad faith part) On Jun 9, 2005, at 6:23 AM, Geir Magnusson Jr. wrote: Worse is someone signing in bad faith or in ignorance.
Re: [Legal] Requirements for Committers
8) Employment Limitations Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. To me, this is _way_ too restructive. While this kind of statement wouldn't be a problem for me currently, from time to time I've been employeed by either a large company or the Australian Government, neither of which have any legal rights to anything I do out of hours, but who would have conniptions if asked to sign an agreement like this. Simply because the pointy haired bosses wouldn't understand what it was about, and would go into knee-jerk abnegation-of-responsibility mode. What is wrong with a personal statement confirming that no third party has a claim on the IP of the contribution. Seems to work for the CPL, but then IANAL ... robin
RE: [Legal] Requirements for Committers
Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. To me, this is _way_ too restructive. ... Same in France. Besides, by default, the employer cannot take property on what is done out of the scope of work [A]; and even in the case when an employee writes some code out of the scope of his job and at work, some French justice cases [1] say the work is the employee's. (although it seems this is up to the judge to decide it...) All the same, the author's 'droit moral' (moral right [?]) and its most restrictive interpretation, 'droit de paternite' (paternity right [?]) is 'perpetuel, inalienable et imprescriptible' (perpetual, not cessible, unprescriptible; art L212-1, French Intellectual Property Code). I think we really need to rephrase correctly the legal aspect of the committer's conditions because such very blatantly impossible to defend kind of stances are amongst the best ways to have a judge angry... Also, contrats de cession (sort of copyright agreements) must be very precisely phrased but limited in scope [2] lest French courts decide to break them [3]. All the same with subsequent lease or copyleft, of course [4]. Sorry these are more problems than solutions. (please note I am not a lawyer, so you should trust it and die - if you are interested I can try to find good references in France. As I live in Japan I leave to our Japanese colleagues the honor to expose the situation in Japan, which I would be very interested to hear about) Regards, RB [A] When writing code as an employee, French law says the author is not you but your employer, only and only if it is done under the employer's directions (this last point being of course spicy to prove or falsify :-) ). Technically the property (droit moral, droit de paternite) is unprescriptible. [1] arret Pachot, 7 fev. 1986 [2] L131-3 La validite d'une trasmission est subordonnee a la distinction des droits transferes et a la delimitation de leur domaine d'exploitation dans l'acte [3] TGI Paris, 26 novembre 2002, M. Demont c/ SARL Forever Living Products 2004-12-09 Dossier : Salarié La personne physique qui cède en pleine propriété deux logiciels conçus avant son embauche obtient la requalification de la cession en droit d'usage à durée déterminée. Le TGI rappelle le caractère nécessairement explicite de la cession de droits... [4] TGI Paris 4 oct 1983 une sous-license de droit d'auteur sur le logiciel consentie en l'absence d'autorisation du titulaire du droit constitue une contrefacon. Other sources: [Droit de la propriete intellectuelle, 2eme ed. Jonanna Schmidt-Szalewski, Jean-Luc Pierre Ed. Litec] [Propriete Litteraire et artistique Pierre-Yves Gautier 4eme ed. PUF Droit] -Original Message- From: Robin Garner [mailto:[EMAIL PROTECTED] Sent: Thursday, June 09, 2005 4:49 PM To: harmony-dev@incubator.apache.org Cc: harmony-dev@incubator.apache.org Subject: Re: [Legal] Requirements for Committers 8) Employment Limitations Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. To me, this is _way_ too restructive. While this kind of statement wouldn't be a problem for me currently, from time to time I've been employeed by either a large company or the Australian Government, neither of which have any legal rights to anything I do out of hours, but who would have conniptions if asked to sign an agreement like this. Simply because the pointy haired bosses wouldn't understand what it was about, and would go into knee-jerk abnegation-of-responsibility mode. What is wrong with a personal statement confirming that no third party has a claim on the IP of the contribution. Seems to work for the CPL, but then IANAL ... robin
Re: [Legal] Requirements for Committers
On Jun 9, 2005, at 3:48 AM, Robin Garner wrote: 8) Employment Limitations Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. To me, this is _way_ too restructive. It is very restrictive, and is a starting point for the discussion. This is a real problem, I think. I believe that people don't understand the restrictions they are working under, and the ramifications of what can happen. While this kind of statement wouldn't be a problem for me currently, from time to time I've been employeed by either a large company or the Australian Government, neither of which have any legal rights to anything I do out of hours, but who would have conniptions if asked to sign an agreement like this. Simply because the pointy haired bosses wouldn't understand what it was about, and would go into knee-jerk abnegation-of-responsibility mode. LOL. KJAORM Well, what do we do? I'm not sure we can punt here, but clearly we want to make it so the broadest community can participate. What is wrong with a personal statement confirming that no third party has a claim on the IP of the contribution. Seems to work for the CPL, but then IANAL ... The CPL is just a license, not an organization that would be creating and distributing software under that license. The scenario that I fear is someone confirming that no third party has a claim, in perfectly good faith. Then, after some time goes by, they get involved with a big company as an employee, contractor or such, and as part of the paperwork, sign a document that changes that situation. They may not remember their claim, and thus any work after that puts the project at some level of risk we didn't have before. Worse is someone signing in bad faith or in ignorance. We're open to any and all suggestions. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
On Tainting/Residual Rights (Was: Re: [Legal] Requirements for Committers)
Steve Blackburn wrote: Dalibor Topic wrote: Many people don't see the need to look at non-free software in general, and chances are pretty slim that anyone I know will ever get that bored and out of reading material to accept the 'Read only' license, for an example of a very funny non-free software license. I have never looked at non-free implementations, but I am interested to know what this means for those of us who have extensive exposure to implementations such as Kaffe (GPL) or Jikes RVM (CPL). My reading of it is that I can't work on any part of Harmony for which I am tainted by my Jikes RVM exposure without permission from the copyright holder of Jikes RVM. Is that right? Nope. :) You can look at free software and work on other software as much as you want to, as free software licenses do not claim further rights beyound the rights granted to the author through copyright laws. I.e. if you copy or modify free software works, you are bound by their license terms, as the copyright laws grant the authors a say in derivative works. If you don't do that, then the author has no say in your own, original work. You are allowed to study free software (freedom 1 [1]). You can do what you want with that knowledge, modulo patents and creating derived works.[0] Non-free software licenses, though, like the SCSL-derivatives covering large portions of core Java technology, make claims that go wildly beyound the rights given to the copyright holders through copyright law. For example, the SCSL claims all sorts of rights on 'Modifications', defining Modifications for the purpose of the license way beyound the scope of the copyright law. GLOSSARY, 13. Modification(s) means (i) any change to Covered Code; (ii) any new file or other representation of computer program statements that contains any portion of Covered Code; and/or (iii) any new Source Code implementing any portion of the Specifications. 13(i) is your normal copyright law. 13(ii) is your normal copyright law with an extra spin: it tries to prohibit fair use by claiming that containing *any portion* of SCSL covered code turns your code into a modification of SCSL covered code. Given that you're writing your code in java, chances are that any class you write shares a certain amount of text with some SCSLd covered code, simply because they are written in the same programming language. So 13(ii) covers pretty much all java code ever written by anyone who licensed code under SCSL. To put more graphically, GLOSSARY,13(ii) == All your Java are belong to us Let's get to 13(iii), which is a little more convulted. It says any *new* Source Code implementing *any portion* of the *Specifications*. New code is quite obvious, so it coveres all new code you write. Then we have a clarification, it's any new code you write that implements any portion of some specs. implementing any portion of specs doesn't say 'extending Object is OK', it says there are some specs, you implement any single bit out of them, your code is covered. Both the JDK API spec and the JLS cover java.lang.Object's method signatures. If your code extends java.lang.Object, it implements a portion of the JLS and JDK API, since you can call the methods covered by the Object API on it. If that's too far fetched for you, take classes implementing the Serializable interface, or your classes extending SCSL covered classes, and overriding methods in them. But the really convulted part of 13(iii) is in the reference to Specifications. If we look up Specifications in the glossary, we'll find GLOSSARY, 21. Specifications means the specifications for the Technology and other documentation, as designated on the Technology Download Site, as may be revised by Original Contributor from time to time. This clause gives the copyright owner (or whoever hacks the site) a backdoor to revise the specifications, and claim violation afterwards, even if you were compliant originally. The license does not specify the Technology download site precisely (with some URL) anywhere. It does specify the community source download site, but that one has no JDK specs. Beautyful. From my blog on just a few of the hidden gems of tragicomical legalese buried in the SCSL available on http://advogato.org/person/robilad/diary.html?start=46. Free Software licenses don't start from the maximal 'we now fully own you, period' position. They start from the minimal 'we own our work, copyright law is cute, this license and copyright law together grant you broad rights, use them wisely and have fun' position and simply rely on copyright law, permissions for dervied works and common sense to sort out the authorship rights rather than claiming everything and all you come up with by default as covered by them. You still own your own brain after studying Free software. Free Software licenses need not to explicitely tell you that, as they make no claims to your
Re: [Legal] Requirements for Committers
That is what courts are for . (at least the bad faith part) On Jun 9, 2005, at 6:23 AM, Geir Magnusson Jr. wrote: Worse is someone signing in bad faith or in ignorance.
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for Committers)
Dalibor Topic wrote: [hot stuff] Holy cow, with a bit of hindsight, that was one little emotional firebrand speech without harmonic undertones. I am afraid I pressed the send button way too soon, so sorry about that, and I hope to avoid turning the list into a legal speculative fest. After some experience on debian-legal, I should know better than to send firebrand speeches to mailing lists. ;( Instead of sheepishly feeding the speculations further myself, I'll take it up with some friendly folks at the parents of the JRL, and try to figure out what the JRL is really meant to mean, and see if all of my fears regarding the JRL covering other things really are as unfounded as everyone would/should hope. If they are unfounded, well, awesome, everyone wins. If they are not unfounded, well, the JRL could be fixed to make them unfounded, and everyone wins. Let's be winners. love, peace and understanding, dalibor topic
RE: [Legal] Requirements for Committers
On Wed, 2005-06-08 at 10:34 +0900, Renaud BECHADE wrote: It is quite similar in French law (soft copyright law being a derivative of usual author copyright law: author's right belongs to the author, period; usage right can be granted/sold/etc. but NOT the author's property). Hi, be aware that in France, when your are working for companies, they are the Author of what you are working on during your working hours. So, either do it during your spare time, or have a signed agreement with your company which specifically name you as the Author... Cheers, Emmanuel Lcharny
RE: [Legal] Requirements for Committers
Right, I forgot to mention what happens in the case of a working contract... Sorry. (But we are not linked with a working contract and the derogative article of the intellectual property right you cite contains the very word employees / art. L113-9) After checking a few sources it seems though that there are many pitfalls when doing the rights transfer after the soft is written... I'll try to check more sources. Regards, RB Ex: (in French below, sorry) Basically a guy sold a soft to a company before he was employed. This was restated by the judge as a use right lease for a given, limited duration. http://www.pifrance.com/rechercher.php - TGI Paris, 26 novembre 2002, M. Demont c/ SARL Forever Living Products 2004-12-09 Thème : TIC Dossier : Salarié La personne physique qui cède en pleine propriété deux logiciels conçus avant son embauche obtient la requalification de la cession en droit d'usage à durée déterminée. Le TGI rappelle le caractère nécessairement explicite de la cession de droits... Mots clés : logiciel ; progiciel ; droits d'auteur ; contrat de travail ; transaction ; droit d'usage ; exploitation ; cession des droits (non) ; atteinte au droit moral (non) ; articles L.113-9 et L.131-3 du CPI ; requalification ; cession ; gestion d'entreprise. -Original Message- From: Emmanuel Lecharny [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 3:41 PM To: harmony-dev@incubator.apache.org Subject: RE: [Legal] Requirements for Committers On Wed, 2005-06-08 at 10:34 +0900, Renaud BECHADE wrote: It is quite similar in French law (soft copyright law being a derivative of usual author copyright law: author's right belongs to the author, period; usage right can be granted/sold/etc. but NOT the author's property). Hi, be aware that in France, when your are working for companies, they are the Author of what you are working on during your working hours. So, either do it during your spare time, or have a signed agreement with your company which specifically name you as the Author... Cheers, Emmanuel Lécharny
Re: [Legal] Requirements for Committers
On 08-06-2005 00:08, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I. Division of Repository +1 II. Specific Access Control Lists +1 We could consider setting up a totally separate SVN repo for this, because the svn-authorization file would be the authoritive source of tainting info and we may want to publish that file. III. Strict Limits on Committer Contribution +1 IV. Be Proactive in Committer Education +1 We could have [a legal form] as part of a standard svn commit message template, for example. Other ideas welcome. Perhaps employ a post-commit hook that rejects commits that don't have a filled-out template. we might consider a form asking information like the following. There's a lot in there. I don't feel qualified to comment. Comments? Expanding on what I said in my other e-mail, committer is something that has many non-legal connotations here at the ASF. It might make sense to define all or most of this in terms of contributors. WDYT? - Leo
Re: [Legal] Requirements for Committers
On Jun 8, 2005, at 5:16 AM, Leo Simons wrote: On 08-06-2005 00:08, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I. Division of Repository +1 II. Specific Access Control Lists +1 We could consider setting up a totally separate SVN repo for this, because the svn-authorization file would be the authoritive source of tainting info and we may want to publish that file. Yes, good idea III. Strict Limits on Committer Contribution +1 IV. Be Proactive in Committer Education +1 We could have [a legal form] as part of a standard svn commit message template, for example. Other ideas welcome. Perhaps employ a post-commit hook that rejects commits that don't have a filled-out template. Well, I was thinking more of an informational message, but a short, simple set of Y/N questions might help. OTOH, people might just get in the habit of just doing the right answers, and not reading... we might consider a form asking information like the following. There's a lot in there. I don't feel qualified to comment. Comments? Expanding on what I said in my other e-mail, committer is something that has many non-legal connotations here at the ASF. It might make sense to define all or most of this in terms of contributors. WDYT? Yes - Authorized Contributor as a defined term as one who has executed the form. geir - Leo -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Legal] Requirements for Committers
On Jun 8, 2005, at 8:54 AM, Nacho G. Mac Dowell wrote: Hi all, Geir Magnusson Jr. wrote: a) Having a copy of src.jar on a computer as long as you never viewed or edited the contents of the file. How many people on this list have NEVER looked (not edited) at, say, java.lang.String? I've seen it via the debugger, but no - I've never opened src.jar and edited String.java Thats said, this is an important issue. We do need to figure out what the ramifications of exposure to src.jar code are. (The statement you are commenting on was just the first of what I suspect will be an iteration or two...) We want to start with the most conservative definition of taint and work our way out of it. I believe that we can work with Sun (or any other copyright holder) to clarify the position on this matter. If you want people with extensive java knowledge to contribute to Harmony this requirement seems like a dead-end to me. Not for the VM internals, but for the class libraries. I suppose that, at least, any curious java developer using eclipse (I don't know about other IDE's) has. Something else would be pretending no one ever looked at src.jar... Don't flame me, please. I'm just trying to address one of my major concerns about Harmony. If this is a MUST requirement, then Sun did a great job when releasing src.jar... No one will flame you - this is a valid point. I'm pretty sure that wasn't Sun's intention, and I also believe that Sun has no desire to assert that casual exposure to the contents of src.jar by developers creating, debugging or running Java applications taints those developers. However, we do need to find a clear way for them to express this, if they are interested or we must remain conservative on this issue. (I don't speak for Sun, of course...) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Legal] Requirements for Committers
On Wed, 2005-06-08 at 14:54 +0200, Nacho G. Mac Dowell wrote: How many people on this list have NEVER looked (not edited) at, say, java.lang.String? Me. And all other GNU Classpath contributors on this list. At least 3 of the 9 listed in the proposal as possible commiters. If you want people with extensive java knowledge to contribute to Harmony this requirement seems like a dead-end to me. I view myself as having extensive java knowledge. Not for the VM internals, but for the class libraries. I already addressed this. It's a fallacy to believe you need to look at Sun's code to do a good implementation of the class libraries. In fact, I belive it will lead to a better implementation. /Sven
Re: [Legal] Requirements for Committers
Nacho G. Mac Dowell wrote: Hi all, Geir Magnusson Jr. wrote: a) Having a copy of src.jar on a computer as long as you never viewed or edited the contents of the file. How many people on this list have NEVER looked (not edited) at, say, java.lang.String? Many, I'd think. To avoid the temptation, you should simply delete src.jar from your computer. If you want people with extensive java knowledge to contribute to Harmony this requirement seems like a dead-end to me. Not for the VM internals, but for the class libraries. I suppose that, at least, any curious java developer using eclipse (I don't know about other IDE's) has. Something else would be pretending no one ever looked at src.jar... There actually are people that have not looked at Sun's code out there. Everyone coming new to the language, for example. Many people don't see the need to look at non-free software in general, and chances are pretty slim that anyone I know will ever get that bored and out of reading material to accept the 'Read only' license, for an example of a very funny non-free software license. Don't flame me, please. I'm just trying to address one of my major concerns about Harmony. If this is a MUST requirement, then Sun did a great job when releasing src.jar... The current licensing terms of a popular non-free implementation(SCSL, JRL, JIUL, JDL), despite all the various FAQs, and enthousiastic statements by some marketing staff at the respective company, do not address the issues at hand in a clear enough fashion. See http://lists.gnu.org/archive/html/classpath/2005-05/msg00014.html for one of many, many problems with the JRL, for example. Yes, a certain company's legal team is pretty good at not helping what they perceive as potential threats to their status. If that is an itch you need to scratch, get in touch with *them* and get it fixed, as they are the only ones who can. cheers, dalibor topic
Re: [Legal] Requirements for Committers
Dalibor Topic wrote: Many people don't see the need to look at non-free software in general, and chances are pretty slim that anyone I know will ever get that bored and out of reading material to accept the 'Read only' license, for an example of a very funny non-free software license. I have never looked at non-free implementations, but I am interested to know what this means for those of us who have extensive exposure to implementations such as Kaffe (GPL) or Jikes RVM (CPL). My reading of it is that I can't work on any part of Harmony for which I am tainted by my Jikes RVM exposure without permission from the copyright holder of Jikes RVM. Is that right? --Steve
Re: [Legal] Requirements for Committers
On Wed, 8 Jun 2005, Dalibor Topic wrote: Geir Magnusson Jr. wrote: a) Having a copy of src.jar on a computer as long as you never viewed or edited the contents of the file. At least in the Linux versions 1.5.0_03 and 1.4.2_05 of the J2SE SDK there is no file src.jar. However there seems to be a file src.zip. Maybe it is a good sign, that most folks here don't actually know, how the file is named. Uli
Re: [Legal] Requirements for Committers
Geir Magnusson Jr. wrote: 8) Employment Limitations Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. IANAL, but this is a really tricky part, as different laws apply depending on where the contributor lives. Most countries have a different approach on this subject than the anglo-american copyright, namely the author's right. For my part, living in Germany, there is no way for my employer (even though I'm employed as a software developer) to claim any rights on work I'm doing in my spare time and there is no legal way for me to disclaim or overdraw my author's right on any work I've done. Even the author's right on the work I'm doing for my employer stays with me, all they can claim is an exclusive right to _use_ the code. I have been working on a few smaller projects lately, which may be of interest to the Harmony project, and I would find it a pity, if your legal requirements makes it difficult for me to contribute. Tor
Re: [Legal] Requirements for Committers
Geir Magnusson Jr. wrote:
What are you working on?
It's a framework to ease JNI programming, or more precisely to make it
possible to call native, e.g. OS functions without writing wrapper code
in C to do type conversions etc.
For example, invoking the Windows MessageBox function in user32.dll can
be done like this:
EasyJni jni = EasyJni.getInstance();
NativeLibrary user32 = jni.loadNativeLibrary(user32);
long ctext = jni.createCString(Message box text, UTF-16LE);
long ctitle = jni.createCString(Message box title, UTF-16LE);
int res = (int)user32.invokeLong(
MessageBoxW, 0, ctext, ctitle, MessageBoxConstants.MB_OKCANCEL);
jni..free(ctext);
jni.free(ctitle);
C structs can be mapped to Java classes using annotations, as here with
the WAVEFORMAT struct used by the Windows audio API:
@NativeStruct(endian=Endian.little, size=16)
public class WaveFormat implements Modifiable {
@NativeField(type=FieldType.int16, offset=0)
private int formatTag;
@NativeField(type=FieldType.int16, offset=2)
private int channels;
@NativeField(type=FieldType.int32, offset=4)
private int samplesPerSecond;
@NativeField(type=FieldType.int32, offset=8)
private int avgBytesPerSecond;
@NativeField(type=FieldType.int32, offset=12)
private int blockAlign;
// getter and setter methods ...
}
I needed this for some audio functionality, which is not available
through JavaSound. The JNI library could probably be used in several
fields, and seeing that Classpath does not implement any parts of
JavaSound, my Windows media API wrappers are probably a good starting
point for a new JavaSound implementation (at least targetted for Windows).
Tor
Re: [Legal] Requirements for Committers
On 6/8/05, Tor-Einar Jarnbjo [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: What are you working on? It's a framework to ease JNI programming, or more precisely to make it possible to call native, e.g. OS functions without writing wrapper code in C to do type conversions etc. Tor, is it legal to for you to contribute the API of this JNI programming framework? IMHO the API is as valuable as the implementation. -- Best Regards Steven Gong
RE: [Legal] Requirements for Committers
It is quite similar in French law (soft copyright law being a derivative of usual author copyright law: author's right belongs to the author, period; usage right can be granted/sold/etc. but NOT the author's property). Not sure about Japanese law (I am living in Japan and France :-)). I guess we should not try to have legal stances that are just too obscure or absolute (and hence just not compatible with some countries laws). Sorry this is more like a problem than a solution, but it would be a pity to be deep in the because we ignore laws diversity. -Original Message- From: Tor-Einar Jarnbjo [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 8:01 AM To: harmony-dev@incubator.apache.org Subject: Re: [Legal] Requirements for Committers Geir Magnusson Jr. wrote: 8) Employment Limitations Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. IANAL, but this is a really tricky part, as different laws apply depending on where the contributor lives. Most countries have a different approach on this subject than the anglo-american copyright, namely the author's right. For my part, living in Germany, there is no way for my employer (even though I'm employed as a software developer) to claim any rights on work I'm doing in my spare time and there is no legal way for me to disclaim or overdraw my author's right on any work I've done. Even the author's right on the work I'm doing for my employer stays with me, all they can claim is an exclusive right to _use_ the code. I have been working on a few smaller projects lately, which may be of interest to the Harmony project, and I would find it a pity, if your legal requirements makes it difficult for me to contribute. Tor
Re: [Legal] Requirements for Committers
Good Best Regards, William Wu Software Engineer Sybase Shanghai RD Center Room 1202-1206, Building One, Zhangjiang Semiconductor Industry Park 3000 Longdong Avenue Pudong, Shanghai 201203 Tel: 8621-68799918 ext 3081 Fax: 8621-68790199 Email: [EMAIL PROTECTED]
Re: [Legal] Requirements for Committers
On Jun 7, 2005, at 9:34 PM, Renaud BECHADE wrote: It is quite similar in French law (soft copyright law being a derivative of usual author copyright law: author's right belongs to the author, period; usage right can be granted/sold/etc. but NOT the author's property). Not sure about Japanese law (I am living in Japan and France :-)). I guess we should not try to have legal stances that are just too obscure or absolute (and hence just not compatible with some countries laws). Sorry this is more like a problem than a solution, but it would be a pity to be deep in the because we ignore laws diversity. Which aspect? We're not ignoring diversity here. We're trying to get started figuring out what to do. We'll have to consult the ASF legal team, but the issues of the CCLA is universal at the ASF anyway. The issues won't go away if we just try and ignore them. geir -Original Message- From: Tor-Einar Jarnbjo [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 8:01 AM To: harmony-dev@incubator.apache.org Subject: Re: [Legal] Requirements for Committers Geir Magnusson Jr. wrote: 8) Employment Limitations Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. IANAL, but this is a really tricky part, as different laws apply depending on where the contributor lives. Most countries have a different approach on this subject than the anglo-american copyright, namely the author's right. For my part, living in Germany, there is no way for my employer (even though I'm employed as a software developer) to claim any rights on work I'm doing in my spare time and there is no legal way for me to disclaim or overdraw my author's right on any work I've done. Even the author's right on the work I'm doing for my employer stays with me, all they can claim is an exclusive right to _use_ the code. I have been working on a few smaller projects lately, which may be of interest to the Harmony project, and I would find it a pity, if your legal requirements makes it difficult for me to contribute. Tor -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
