Hey, +1 from me, but this comes as no surprise, I am sure.
We have a couple of things to think about here.
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
b) hopefully an ICLA from each contributor
c) if copyright is held by your employer (the university) a CCLA
The last element might be the most time consuming. However, our CCLA is
commonly accepted by the likes of IBM and Intel, so I don't believe the
university attorneys will have any issues.
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.
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.
Second, we need to discuss here in Harmony the approach we want to take
with adopting the community of committers. We have many people here
that are not committers that have been working hard earning commit
status, so we need to be careful not to discourage anyone.
On the other hand, to me, when someone brings a large chunk of software
with the intention of continuing to work on it in a community, that
shows a reasonable amount of commitment, one of the things we look for
in committers. What we don't know are technical competency of the
people, and how they "fit" into the community, both in working with
others as well as "alignment of vision".
Possibilities :
1) Donate the code, submit patches, earn commit.
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.
3) Donate the code, some # of people come in w/ full commit.
My personal preference is #2, #1, #3. While I don't like balkanization
of #2, but it has some balance to it - people don't just get full commit
by bringing some code, but still have to earn ot. Yet, they continue to
work on the code they know. I like #3 the least, because we have others
in the community working hard to earn their full commit and it is
something to be earned...
Comments all?
geir
Etienne Gagnon wrote:
Hi Harmony developers,
So, you might have heard of unofficial rumors of potential collaboration
between the Harmony project and the SableVM project. Here's a message I
sent lately on the SableVM mailing list:
http://sablevm.org/lists/sablevm-devel/2006-March/000608.html
To summarize the public and private replies I got to this message: the
prospect of establishing a strong collaboration was met with great
enthusiasm.
I did not want to get into official talks with the Harmony project
before I could make sure that we wouldn't run into license problems.
So, I started been working hard to get the permission of current and
past SableVM developers to get their permission to change the license
and (possibly) execute a software grant. So, I have tracked down all
the 27 developers that have contributed code or patches to SableVM, in
the development trunk or in any other development branch or sandbox. As
of this morning, I had received the consent of 18 developers to change
the license of SableVM. The following email details the distribution of
the developers that have not yet replied to my request email (as of
yesterday evening):
http://sablevm.org/lists/sablevm-devel/2006-March/000614.html
Now that licensing seems not to be an issue anymore, I would like to
propose a close collaboration between our two projects. So, let me
shortly present SableVM.
SableVM is a project that I started during my Ph.D. studies within the
Sable research lab at McGill university. From the beginning, its goal
was to build a free/open-source virtual machine that could achieve two
things:
1- be usable in the "real world" outside of academia,
2- be a research vehicle to within the Java optimization framework of
our lab (which includes, among other things, Soot).
These two objectives are still the guiding our development. Now, if I
am right, "1-" is perfectly in line with the objectives of the Harmony
project. Furthermore, the Harmony project already accepted the JCVM
which shares many design features with SableVM (object layout, etc.)
SableVM has been and is being worked on by many students to develop
non-trivial components. Among interesting components:
- JVMDI & JDWP -> debugging with Eclipse works
- user class loaders
- loading constraints
- robust verifier
- generational, partly incremental GC
- etc.
Many of these features are not yet integrated in our trunk, as we have
strict rules on only integrating robust code into our trunk, so that our
software remains usable by our users.
What I would like to propose, is to contribute our stable, end-user
targeted trunk version to the Harmony project. This would probably
allow for a merge of the JCVM and SableVM development efforts (and who
knows, maybe other contributed VMs eventually?), and help provide a more
complete and robust J2SE environment.
We would also contribute other modules, either with the initial
submission, or later when they stabilize. So, the
development/collaboration model that I propose would is as follow:
1- Day to day development and maintenance of the user targeted VM code
happens within the Harmony repository. SableVM contributors must
abide by Harmony rules to contribute to this so-called "SableVM
trunk".
2- Research and development of trunk-breaking features by SableVM
contributors continues within the SableVM repository, as not to
pollute the Harmony svn with random code. Contribution back to the
SableVM trunk (within the Harmony svn) must happen under Harmony
rules.
Of course, we are very open to other proposals. I am quite excited
about this. How about you?
Cheers,
Etienne
