harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Etienne Gagnon <egag...@sablevm.org>
Subject Re: Contributing SableVM?
Date Thu, 23 Mar 2006 06:28:38 GMT
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:

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:

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

> 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 M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

View raw message