Geir Magnusson Jr wrote: > First, I'm going to assume that you will have no problem in getting > > a) permission from all contributors to re-license under the Apache License
I'm almost done with this. Only one significant permission has yet to be received. (Yet, I got a unofficial verbal permission from this contributor, already). > b) hopefully an ICLA from each contributor Do you need this for "past contributors"? This would be very onerous. SableVM, throughout history, has maintained a "clean room" development process, with utmost respect for intellectual property of others. Our current contribution policy is strictly enforced; every contributor has formally agreed to the following terms: http://sablevm.org/svn/repository/sablevm/trunk/doc/contribution_policy.txt Signing an ICLA is OK for current and future contributors. > c) if copyright is held by your employer (the university) a CCLA This won't be needed for me and my UQAM students. UQAM does not claim copyright on the work of its professors and students. The IP Policy is described in UQAM's 36th Policy. It's written in French, of course, and it is available online: http://www.instances.uqam.ca/politiques/Politique_36.htm Unfortunately, I am not fluent enough in English law vocabulary to translate this document. But, in summary, it says that UQAM won't claim copyright unless UQAM has specifically mandated the professor or student to produce the work, or if the work is the result of a specific contract with a third party where IP rights were specified. You might want to ask non-UQAM contributors about their relation with their employer or university, and see if the CCLA is needed for them. FYI: McGill University also has an IP Policy, with specific clauses on Software. You might want to ask McGill students for a copy of it. It has a clause that says somehow that McGill gives back its share of copyright to the author, when developing free software. > We also have other process items which you may or may not be aware of > over and above the standard Apache process - the so-called Authorized > Contributor Questionnaire (ACQ) and the Bulk Contribution Checklist > (BCC). The former is a kind of "inventory" we take of each contributor > to assess where they may have been exposed to code for which such > exposure might lead to problems for our codebase if they contributed. I guess that, by "contributors", you mean "present" and "future" ones. This would be OK. > The latter is something that you would fill out to account for ACQs of > contributors and such for the software you are donating. Please review > and ask any questions here. OK. I'll read it and ask if there's any trouble. > 1) Donate the code, submit patches, earn commit. Hmmm... Do I really have to earn commit rights to SableVM? Sincerely, I do not think that this would be reasonable for some key SableVM developers. > 2) Donate the code, and some number of people come in with it with > commit granted to the "sableVM" part of the repository, and interaction > with the other parts of the codebase are done via patch until earned. > All existing committers have full access, but simple manners would > dictate we wouldn't go barging into code we don't understand. In the SableVM repository, only a few contributors have commit rights to the trunk. I see no trouble on having other SableVM authors earn their commit right; this is already how we proceed. Currently, there are only two commiters to the SableVM trunk: - Grzegorz Prokopski - Me There was also David Belanger, the SableJIT author, but he has earned his M.Sc. and now works for a company. He probably needs to get a CCLA, now. If you decide to integrate SableJIT into Harmony, some day, then I would argue that David should get commit rights. In our development process, all other developers commit their code into sandboxes (instead of sending floating patches in emails), and trunk commiters get to review the code and commit it (using svn merge & svn ci). > 3) Donate the code, some # of people come in w/ full commit. Greg and me are unlikely to modify much code in the class libraries. We're VM developers, not class lib developers. Yet, my worry is that not having access to the class library side of the VM interface might be quite limiting, to say the least. I would say that access to LUNI is probably a must, under some restrictions (see below). Both Greg and me have a long experience with class library maintenance and Subversion. We've been taking care of the maintenance of the SableVM/Classpath VM interface, and of fixing some sablevm-classpath bugs from while to while. I don't see myself starting to commit anything in the class library code (including the VMI) without first discussing it on this list. Actually, I would first have a working copy of it available my sandbox, in the SableVM svn repository, for Harmony developers to look at and test. So, how about the following: We go with some hybrid of your options #2 and #3. The number of "automatic commiters" is limited to two developers: Greg and me. To commit anything outside the SableVM code, Greg and me must first discuss it on this list, and get the consent of Harmony developers. The right to commit obvious little patches and improvements outside the sablevm code, without prior discussion on this list, must be earned. I am sure that we will need a period of adaptation, on both sides. I anticipate discussions on how to setup the SableVM code in the Harmony repository so as to make sure that the coding style match the Harmony coding style, and on which tool dependencies are OK or not, etc. So, I don't see Greg and me randomly changing code in the SableVM code without first discussing any significant change on this list. Yet, I see no reason for us to "earn" the right to fix a little interpretation engine bug, for example. Would this be OK? Etienne -- 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
