You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Etienne Gagnon <eg...@sablevm.org> on 2006/03/22 16:10:52 UTC
Contributing SableVM?
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
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: Contributing SableVM?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Etienne Gagnon wrote:
> Oh! I forgot to add...
>
> I think that the reverse should also apply. I do not think that it
> would be OK for current Harmony commiters to simply go and change the
> SableVM code without discussing it on this list first. Their right to
> commit obvious little patches and improvements within the sablevm code,
> without prior discussion on this list, should be earned too.
That's understood in general in well-mannered Apache communities. I
also noted this, I believe, in my mail.
geir
Re: Contributing SableVM?
Posted by Etienne Gagnon <eg...@sablevm.org>.
Oh! I forgot to add...
I think that the reverse should also apply. I do not think that it
would be OK for current Harmony commiters to simply go and change the
SableVM code without discussing it on this list first. Their right to
commit obvious little patches and improvements within the sablevm code,
without prior discussion on this list, should be earned too.
It's not only a question of fairness; it is a technical one. Even if
some of the SableVM code might look simple, there are often deeper
principles behind the code. It is easy to transgress important
correctness rules without noticing it. The C language offers no
protection against it. [Rules about stopping/resuming java in VMI code,
etc.]
JCHEVM simplified many problems by selecting a non-moving collector.
SableVM has not only a moving collector, but also moving Java frame
stacks, etc. Lots of tricky (yet nice) stuff.
:-)
Etienne
> 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.
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: Contributing SableVM?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 23, 2006, at 1:28 AM, Etienne Gagnon wrote:
> Geir Magnusson Jr wrote:
>
>> 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
>
The issue is that past contributors submitted their code
and licensed it to SableVM under whatever license SableVM
has. To allow the ASF to relicense the s/w, those contributors
must approve that effort, and an iCLA is one legal vehicle
that we use to allow that to happen. When SpamAssassin
moved to the ASF, we went through a similar effort
and obtained iCLAs.
Re: SableVM? -- commit privileges?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
(damn thread hijackers.... :)
Leo Simons wrote:
> Very cool. Besides how cool it is to see this happening, its also amazing
> at which speed its happening.
>
> On Thu, Mar 23, 2006 at 01:28:38AM -0500, Etienne Gagnon wrote:
>> Geir Magnusson Jr wrote:
> <snip type="ip stuff" />
>
>>> 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.
>
> Personally, I agree. We sort-of "know you" by now through e-mail
> interactions and purely based on that (and looking at some of the
> SableVM development history) I trust you enough.
I added this option only for completeness. Notice it was my choice #3.
I never advocate this model.
>
>>> 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
>
> Two people is in many ways different from 18, or 27, in terms of how
> "disruptive" it might/could be to the "dynamics" of development.
>
>>> 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.
>
> Different ASF communities use lots of different rules/models about how the
> trunk can and cannot be changed. For example, some projects (notably
> HTTPD) have a "review-then-commit" policy, where *everyone* *always* needs
> to send *every* patch to the mailing list for review (eg getting a +1)
> before they're allowed to commit it. Mozilla is an example where there is
> even more strictness (they have "super-review" too).
One day, we may actually get there - if we become *the* implementation
of Java SE, then we will go this way. There would be far too much at
stake to not have a process like that. Right now, there is no point.
>
> This is usually somewhat seperate from actual access rights, which can be
> convenient at times. How to go about committing different things to
> different files of different parts of the repository is not so easily
> codified in rules. For example, I highly doubt you would have any kind of
> problem with me committing a mass-reformat of the license headers on files
> in the what-would-be SableVM trunk. I would assume I'm trusted to know what
> I'm doing in such a case.
>
> In my mind, these kinds of things are supposed to be based on trust. Once
> you "trust" that you "have the trust" of the other people working on the
> codebase, you might sometimes agree to switch to a commit-then-review way of
> working from the original review-then-commit mechanism. But "trust" is
> something very hard to codify in some kind of "policy", let alone in access
> control rules.
>
> So I think I would actually prefer option #3 (with the # of people == 2, not
> 27), with the shared understanding that no-one goes around making a mess of
> things or impacting existing workflow.
>
> Some people around the ASF have spent near-insane amounts thinking about
> this kind of thing and I'm one of them. Still not done with the thinking :).
> With every passing year I drift more and more towards a its-not-the-rules-its-
> how-you-apply-them kind of idea.
I understand and sympathize with what you are saying, but I think that
#2 reflects sensitivity for those in the community that are earning
their full commit status "the old fashioned way".
That's why I suggested #2 - people keep working on SableVM w/o any of
the hassle of patches, but full commit is earned over time like everyone
else.
geir
SableVM? -- commit privileges? (was: Contributing SableVM?)
Posted by Leo Simons <ma...@leosimons.com>.
Very cool. Besides how cool it is to see this happening, its also amazing
at which speed its happening.
On Thu, Mar 23, 2006 at 01:28:38AM -0500, Etienne Gagnon wrote:
> Geir Magnusson Jr wrote:
<snip type="ip stuff" />
> > 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.
Personally, I agree. We sort-of "know you" by now through e-mail
interactions and purely based on that (and looking at some of the
SableVM development history) I trust you enough.
> > 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
Two people is in many ways different from 18, or 27, in terms of how
"disruptive" it might/could be to the "dynamics" of development.
> > 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.
Different ASF communities use lots of different rules/models about how the
trunk can and cannot be changed. For example, some projects (notably
HTTPD) have a "review-then-commit" policy, where *everyone* *always* needs
to send *every* patch to the mailing list for review (eg getting a +1)
before they're allowed to commit it. Mozilla is an example where there is
even more strictness (they have "super-review" too).
This is usually somewhat seperate from actual access rights, which can be
convenient at times. How to go about committing different things to
different files of different parts of the repository is not so easily
codified in rules. For example, I highly doubt you would have any kind of
problem with me committing a mass-reformat of the license headers on files
in the what-would-be SableVM trunk. I would assume I'm trusted to know what
I'm doing in such a case.
In my mind, these kinds of things are supposed to be based on trust. Once
you "trust" that you "have the trust" of the other people working on the
codebase, you might sometimes agree to switch to a commit-then-review way of
working from the original review-then-commit mechanism. But "trust" is
something very hard to codify in some kind of "policy", let alone in access
control rules.
So I think I would actually prefer option #3 (with the # of people == 2, not
27), with the shared understanding that no-one goes around making a mess of
things or impacting existing workflow.
Some people around the ASF have spent near-insane amounts thinking about
this kind of thing and I'm one of them. Still not done with the thinking :).
With every passing year I drift more and more towards a its-not-the-rules-its-
how-you-apply-them kind of idea.
> I am sure that we will need a period of adaptation, on both sides.
yup.
> 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.
and the other way around :-)
> 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.
Very much agreed.
> Would this be OK?
I think how all of us think about this kind of stuff is in the end compatible.
Getting all the actual "rules" and "mechanisms" "right" is hard and will take
time and effort.
What do others think?
- Leo
Re: Contributing SableVM?
Posted by Etienne Gagnon <eg...@sablevm.org>.
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/
Re: Contributing SableVM?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Etienne Gagnon wrote:
> Hi Geir,
>
>> b) hopefully an ICLA from each contributor
>
> The ICLA rules are less restrictive than the Apache License rules:
>
> 2. Grant of Copyright License. Subject to the terms and conditions of
> this Agreement, You hereby grant to the Foundation and to
> recipients of software distributed by the Foundation a perpetual,
> worldwide, non-exclusive, no-charge, royalty-free, irrevocable
> copyright license to reproduce, prepare derivative works of,
> publicly display, publicly perform, sublicense, and distribute Your
> Contributions and such derivative works.
>
> Unless I missed something, this not force the ASF to abide by the Apache
> License 2.0 rules. So, for example, the ASF could sublicense
> derivatives of our work under any license it wants, without even
> acknowledging our contribution in a NOTICE file.
Yes. The idea is that we trust the ASF to do the Right Thing. When the
ASF doesn't do the Right Thing, it will be a hollow shell as all of us
would leave.
Also, "we" are the ASF - there is no "them".
>
> Most SableVM authors do not agree to allow derivative works not to
> clearly aknowledge their contribution. This is our only real
> retribution for the work we contribute.
>
> I understand that it is critical, for the ASF, to design new licenses,
> but rule "2." above seems too permissive, at first sight.
>
> Have I missed something?
Nope.
geir
>
> Etienne
>
Re: SableVM? -- ICLA details
Posted by Cliff Schmidt <cl...@gmail.com>.
On 3/23/06, Stefano Mazzocchi <st...@apache.org> wrote:
> With my Board Director hat on:
>
> I believe that it is a bug that the current ICLA gives the ASF enough
> power to relicense something without acknowledging who donated it to us.
>
> I would be in favor of changing the ICLA more than to sign an ad-hoc
> statement like the one you propose.
>
> With my Harmony hat on: I would like this to move as fast as we can and
> I don't know which one of the options is faster.
>
> Cliff, are you watching this? any comment?
sure -- below
On 3/24/06, Dalibor Topic <ro...@kaffe.org> wrote:
> Leo Simons wrote:
>
> >> , that that can
> >> lead to no end of confusion over the actual license of a VM using
> >> modules from Harmony, if the SableVM developer believes to have a say in
> >> it.
> >
> > No I would say that it cannot, since that sablevm developer would at a minimum
> > have licensed the software under the apache license to apache, and then apache
> > would have licensed that software to the end user under the apache license, and
> > what that means is rather clear.
> >
>
> It's not clear at all to me from reading the ASL2, so let's spell it
> out: Would such a hypothetical developer have a say in the license of a
> VM using Harmony's modules or not? Cliff?
I'll try to address the issues that Stefano and Dalibor have brought
up with a summary of how works flow through Apache:
The works distributed by the ASF come from three sources:
1. works owned by committers or their employers and licensed to the
ASF under a (c)CLA or Software Grant.
2. third-party works that are licensed in ways that allow us to
redistribute them within Apache products -- see
http://people.apache.org/~cliffs/3party.html for a draft of a policy
applying to these works.
3. the collective work of the product distribution itself, as
selected, coordinated, and arranged by the PMC. Unlike individual
commits and third-party works, the copyright in this collective work
is owned by the ASF.
Setting aside #3, here's how we deal with licensing of #1 and #2:
#1: The CLAs and Software Grant give the ASF a very broad copyright
license with basically no restrictions -- not even the notice
requirements of the Apache License. This allows the ASF the option to
sublicense the contributions under some future version of the Apache
License, including a version with the NOTICE section removed. The
CLAs/SG also includes a patent license and revocation clause that is
identical to what is passed on in the Apache License (the ASF doesn't
have much flexibility with this piece).
#2: Third-party works are always redistributed and sublicensed by the
ASF under the exact same terms that we received them under. We
certainly do not have the rights to remove any licensing restrictions
from third-party works nor subicense any rights not specified in the
license.
In neither case, should we be replacing a copyright notice with our
own. However, for committer contributions, we may choose to place
everyone's copyright notice in a single file, rather than scattered
throughout each piece of code that a committer authored (I will bring
this up on legal-discuss shortly). For third-party works, we never
touch the copyright header -- we leave such notices as we found them.
So, while I believe that there is nothing legally preventing the ASF
from distributing CLA works under a future license that removes the
NOTICE requirement, the copyright notices will always be maintained
somewhere in each release. It's also probably worth noting that there
are several NOTICE files today that have a line in there stating that
the initial contribution was developed by some company, like IBM or
BEA. No company has ever asked for a contract with the ASF to ensure
we never remove the NOTICE from any future release, but (AFAIK) there
also has not been any interest from anyone in removing it.
Does that help?
Cliff
Re: SableVM? -- ICLA details
Posted by Stefano Mazzocchi <st...@apache.org>.
Etienne Gagnon wrote:
> 5- The ASF provides me with an official, legally binding document,
> signed by officers that have sufficient rights to do so, stating that
> it will only sub-license (distribute, etc.) code contributed by SableVM
> authors (can be identified specifically) and derivatives of this code,
> under licenses that require explicit acknowledgment of the copyright
> of these authors and that require redistribution of the related text
> found in the NOTICE file. [I have no trouble letting the ASF lawyers
> come up with some text proposal. I would highly suggest reusing words
> off the Apache License 2.0 to do so. I can even propose some text, if
> you wish me to do so.]
>
> 6- Each ICLA and Software Grant has an explicit hand written reference
> to the ASF document in "5-" beside the signature(s). A copy of the
> ASF document in "5-" is added as an appendix to the ICLA/SG in your
> records and our records.
With my Board Director hat on:
I believe that it is a bug that the current ICLA gives the ASF enough
power to relicense something without acknowledging who donated it to us.
I would be in favor of changing the ICLA more than to sign an ad-hoc
statement like the one you propose.
With my Harmony hat on: I would like this to move as fast as we can and
I don't know which one of the options is faster.
Cliff, are you watching this? any comment?
--
Stefano.
Re: SableVM? -- ICLA details
Posted by Stefano Mazzocchi <st...@apache.org>.
Dalibor Topic wrote:
>> 5- The ASF provides me with an official, legally binding document,
>> signed by officers that have sufficient rights to do so, stating that
>> it will only sub-license (distribute, etc.) code contributed by SableVM
>> authors (can be identified specifically) and derivatives of this code,
>> under licenses that require explicit acknowledgment of the copyright
>> of these authors and that require redistribution of the related text
>> found in the NOTICE file. [I have no trouble letting the ASF lawyers
>> come up with some text proposal. I would highly suggest reusing words
>> off the Apache License 2.0 to do so. I can even propose some text, if
>> you wish me to do so.]
>
> Is the intent that you want to be able to claim copyright on VMs linking
> to Harmony's VM modules?
From what I understood, Etienne is concerned that the ASF would take
his code and decide to relicense it under the Apache License 2.0 without
mentioning him and wants to be protected against that even if there is
no record nor will of anybody here of doing so.
A little paranoid maybe, but sounds reasonable to me.
--
Stefano.
Re: SableVM? -- ICLA details
Posted by Stefano Mazzocchi <st...@apache.org>.
Dalibor Topic wrote:
> Having
> submarine copyright holders on VMs using Harmony's VM modules or class
> libraries would be a pretty bad thing.
Dalibor,
FYI, *NO* ASF is immune for what you call "submarine copyright holders".
The ASF does not have records of all the copyright holders of the
software it distributes. I would also venture to say that the ASF does
*NOT* own any code at all, since it never paid anybody to write any code
nor asked for copyright transfer.
This was a very very very cautious decision and quite a clever one, if
you ask me: the copyright remains of the respective owners.
Just like for Kaffe, the IP trail of any ASF project is not trivial to
reconstruct, but this doesn't matter because:
a) all code is licensed under the same license
b) the ASF was given the right to relicense via the CLAs
Copyright law was not designed for "sharing" but for copy protection.
But when you give a "license" you are reducing some of that protection.
The fact that you still "own" a piece of intellectual property is
completely ineffective if you have given enough rights to the users to
modify, change, redistribute and, in case of the ASF, relicense.
Etienne identified an issue with this scheme: the ICLA gives the ASF
enough power to relicense his code without having to put his name on it,
even if he still maintains the copyright of (part of) it.
The ASF states "Copyright ASF and its licensors, where applicable."
Which means everything and nothing at the same time. We could also
remove that statement and nothing would change from a legal point of view.
Etienne doesn't like the fact that his name might simply disappear. He
doesn't like that and he's asking the ASF to guarantee him that his name
won't be removed from the NOTICE file.
Call it ego polishing, call it altar building, call it academic career
booster, call it whatever you want, but I still think he has the right
to be assured that his name won't be removed from the credits.
I see nothing harmful in this request, it's just going to take some time
to make it happen.
--
Stefano.
Re: SableVM? -- ICLA details
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> On Fri, Mar 24, 2006 at 12:05:11PM -0800, Stefano Mazzocchi wrote:
>> 3) not having ownership does not effect the ability for the ASF to
>> create successful and perpetual open development efforts around such
>> code. The owner cannot stop the ASF from continuing the effort unless it
>> violates the contract that was signed with the CLA. Given the broad
>> spectrum of rights that the CLA gives to the ASF.
>>
>> 4) copyright statements and giving credits are two different things
>> and I think it's wise to keep them separate.
>>
>> 5) the ASF considers it a moral obligation to give credit when due,
>> not a contractual one. In 10 years, Etienne is the only one who had a
>> problem with this.
>
> Or, potentially, the only one who has ever brought it up :-)
Fair enough.
>> It is reasonable for him to ask for such an
>> obligation to be contractual and not just moral, yet it is also
>> reasonable (and predictable) for some ASF members to feel insulted by
>> such a request.
>
> Hadn't actually thought of it in those terms just yet (and guessing at
> other people's opinions is always hard), but yeah, I can very much
> imagine things like that. Hmm.
>
> How confident are you this is the first time the question has been asked?
I don't know of any other that asked (or noticed) such a thing. I was
quite intrigued by it myself as I never thought of such implications.
With my ASF hat on, I would say because it's so natural that we'll give
credit when due, that we didn't even think to specify it in such a
contract. But I did not write it nor I was part of its writing, so I
can't speak for them.
> It, and its social and moral implications (and the same for the possible
> answers) is in some ways quite intriguing...
Somebody once said that the main difference between the FSF and the ASF
philosophy is that the FSF considers a contractual obligation to give
back the code and a moral one to respect the brand while the ASF has a
contractual obligation to respect the brand and a moral one to give back
the code.
Both deeply believe in giving credits when due and before the Apache
License 2.0, it was a moral obligation.
The Apache License 2.0 somewhat makes it more contractual, with the
NOTICE file, but it's actually a byproduct, I don't think it was
intentional.
For example, we do not, ON PURPOSE, regulate at the ASF level the
@author tags: the granularity of credits giving is left unspecified and
it's something that each and every community might decide on their own,
just like day 2 day project operations.
I personally wouldn't have a problem if we modified the CLAs to say that
no matter what we'll keep credit when due, somewhere, somehow, around
the project, unless the author explicitly asks for it to be removed (I
did such a thing in JMeter and Ant, for example, because I was sick of
receiving requests for code that I wrote years ago and that I had
nothing to do with at this moment... the code was totally different but
my name was still in the @author tag).
That said, without a reason for this to change (as SableVM seems to be
easier to integrate as an external piece), it's unlikely that we'll do
it "just because", even if it makes sense.
--
Stefano.
Re: SableVM? -- ICLA details
Posted by Stefano Mazzocchi <st...@apache.org>.
Etienne Gagnon wrote:
> Leo Simons wrote:
>> Or, potentially, the only one who has ever brought it up :-)
>
> As I said, in an earlier message, I take back my request. I do not wish
> to offend anybody. :-)
I know that your intentions were not to offend and, personally, I
wasn't, but I was perceiving a little friction building up on this camp
so I wanted to raise a warning flag.
I believe that your decision of relicensing in a compatible way it's the
best step forward because it's the most reversible situation and has
lower impact on both sides.
I also trust that once you get to know how the ASF works a little more,
you might feel less in need for contractual obligations about the
protection of your credits. But even if that is not the case and SableVM
wants to continue to have an independent and separate community, I
personally don't see any problem with that.
--
Stefano.
Re: SableVM? -- ICLA details
Posted by Etienne Gagnon <eg...@sablevm.org>.
Leo Simons wrote:
> Or, potentially, the only one who has ever brought it up :-)
As I said, in an earlier message, I take back my request. I do not wish
to offend anybody. :-)
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: SableVM? -- ICLA details
Posted by Leo Simons <ma...@leosimons.com>.
On Fri, Mar 24, 2006 at 12:05:11PM -0800, Stefano Mazzocchi wrote:
> 3) not having ownership does not effect the ability for the ASF to
> create successful and perpetual open development efforts around such
> code. The owner cannot stop the ASF from continuing the effort unless it
> violates the contract that was signed with the CLA. Given the broad
> spectrum of rights that the CLA gives to the ASF.
>
> 4) copyright statements and giving credits are two different things
> and I think it's wise to keep them separate.
>
> 5) the ASF considers it a moral obligation to give credit when due,
> not a contractual one. In 10 years, Etienne is the only one who had a
> problem with this.
Or, potentially, the only one who has ever brought it up :-)
> It is reasonable for him to ask for such an
> obligation to be contractual and not just moral, yet it is also
> reasonable (and predictable) for some ASF members to feel insulted by
> such a request.
Hadn't actually thought of it in those terms just yet (and guessing at
other people's opinions is always hard), but yeah, I can very much
imagine things like that. Hmm.
How confident are you this is the first time the question has been asked?
It, and its social and moral implications (and the same for the possible
answers) is in some ways quite intriguing...
- LSD
Re: SableVM? -- ICLA details
Posted by Dalibor Topic <ro...@kaffe.org>.
On Fri, Mar 24, 2006 at 12:05:11PM -0800, Stefano Mazzocchi wrote:
> Geir Magnusson Jr wrote:
> >
> >
> >Geir Magnusson Jr wrote:
> >>
> >>
> >>Dalibor Topic wrote:
> >>>Leo Simons wrote:
> >>>
> >>>>>, that that can
> >>>>>lead to no end of confusion over the actual license of a VM using
> >>>>>modules from Harmony, if the SableVM developer believes to have a
> >>>>>say in
> >>>>>it.
> >>>>
> >>>>No I would say that it cannot, since that sablevm developer would at
> >>>>a minimum
> >>>>have licensed the software under the apache license to apache, and
> >>>>then apache
> >>>>would have licensed that software to the end user under the apache
> >>>>license, and
> >>>>what that means is rather clear.
> >>>>
> >>>
> >>>It's not clear at all to me from reading the ASL2, so let's spell it
> >>>out: Would such a hypothetical developer have a say in the license of
> >>>a VM using Harmony's modules or not? Cliff?
> >>
> >>No.
> >
> >I thought about this for a second more - the apache license is a license
> > from each contributor of their contribution to the licensee, so I would
> >guess that yes, any contributor could hypothetically have a say on what
> >a licensee does w/in the boundaries of their contribution.
>
> no, hold it, this is not true. Once you give a perpetual license, you
> can't revoke it. If you own some code, you can relicense it under
> different conditions, but since the license that you had before was a
> OSI license it gives other the ability to fork.
>
> >I dunno. I am not a lawyer, and I'm really tired :)
>
> The ability to fork is what saves users from copyright holders going
> wacko and changing the license in 'less then open source'.
>
> Which means that you might own some code, but you don't own its usage
> dynamics once you enter an OSI/free-software licensing scheme.
We're all in violent agreement here.
My past discussions on the subject with Etienne Gagnon and to some
extent Gregorz Prokopski lead me to believe that they did up to a few
weeks ago believe to own the usage dynamics of their code, i.e. held
running (for example) ASF's software on GPL'd VMs to be copyright
infringement if such VMs linked to more liberally (i.e. LGPL,
GPL+linking exception, ASLv2, BSD, ...) licensed code they held
copyrights to.
That was the reason we avoided mixing our code in the past.
If Etienne and Grzegorz now indeed interpret the ASL2's provisions
regarding the boundaries of what consititutes a derivative work in the
same way as we do, i.e. linking to a module does not cause the code to
be a derivative work, i.e. no shared copyright outside the part
contributed to the ASF, then that's excellent news.
I would love to be able to link to Etienne's and Grzegorz's code in
Apache Harmony without exposing my users to ligitation risks, or claims
that they are doing something illegal by running ant or Eclipse on
their VM.
>
> If not, hell, it would be a perpetual lock-in situation.
>
> So, in short:
>
> 1) the ASF is not asking for copyright transfer, so "submarine
> copyright holders" are all over the place (I'm one too, I own code in so
> many java projects I can't even count them, and I wasn't working for
> anybody so that is definitely my code).
>
> 2) not having ownership simplifies donations and guarantees the
> ability for the author to do whatever he/she pleases with the code even
> after it was donated.
>
> 3) not having ownership does not effect the ability for the ASF to
> create successful and perpetual open development efforts around such
> code. The owner cannot stop the ASF from continuing the effort unless it
> violates the contract that was signed with the CLA. Given the broad
> spectrum of rights that the CLA gives to the ASF.
>
> 4) copyright statements and giving credits are two different things
> and I think it's wise to keep them separate.
>
> 5) the ASF considers it a moral obligation to give credit when due,
> not a contractual one. In 10 years, Etienne is the only one who had a
> problem with this. It is reasonable for him to ask for such an
> obligation to be contractual and not just moral, yet it is also
> reasonable (and predictable) for some ASF members to feel insulted by
> such a request.
>
I think it is a very reasonable request, as long as the intent is to
ensure that credit is given where credit is due. Etienne has done
excellent work on SableVM, and I can understand that he wants to that
work to be recognized.
If Etienne can confirm that it's all that there is to it, and claims no
copyright on VMs linking to modules containing SableVM code in the
Harmony repository, then we are done in this thread, I think.
cheers,
dalibor topic
> --
> Stefano.
>
Re: SableVM? -- ICLA details
Posted by Geir Magnusson Jr <ge...@pobox.com>.
To be really clear, because I can see room for misunderstanding - my
mental context for this is the larger scope regarding how contributors
retain rights.
Therefore I do think that a copyright holder has a say in a VM using
Harmony's modules insofar that the copyright holders contribution is
involved, and further, the license of VM doesn't respect the terms under
which the copyright holder licensed the contribution to the creator of
said VM.
I hope that's clearer.
geir
Geir Magnusson Jr wrote:
>
>
> Stefano Mazzocchi wrote:
>> Geir Magnusson Jr wrote:
>>>
>>>
>>> Geir Magnusson Jr wrote:
>>>>
>>>>
>>>> Dalibor Topic wrote:
>>>>> Leo Simons wrote:
>>>>>
>>>>>>> , that that can
>>>>>>> lead to no end of confusion over the actual license of a VM using
>>>>>>> modules from Harmony, if the SableVM developer believes to have a
>>>>>>> say in
>>>>>>> it.
>>>>>>
>>>>>> No I would say that it cannot, since that sablevm developer would
>>>>>> at a minimum
>>>>>> have licensed the software under the apache license to apache, and
>>>>>> then apache
>>>>>> would have licensed that software to the end user under the apache
>>>>>> license, and
>>>>>> what that means is rather clear.
>>>>>>
>>>>>
>>>>> It's not clear at all to me from reading the ASL2, so let's spell
>>>>> it out: Would such a hypothetical developer have a say in the
>>>>> license of a VM using Harmony's modules or not? Cliff?
>>>>
>>>> No.
>>>
>>> I thought about this for a second more - the apache license is a
>>> license from each contributor of their contribution to the licensee,
>>> so I would guess that yes, any contributor could hypothetically have
>>> a say on what a licensee does w/in the boundaries of their contribution.
>>
>> no, hold it, this is not true. Once you give a perpetual license, you
>> can't revoke it. If you own some code, you can relicense it under
>> different conditions, but since the license that you had before was a
>> OSI license it gives other the ability to fork.
>
> I wasn't suggesting that you could revoke it.
>
> My thoughts were along the lines of what the apache license says - that
> each contributor gives each recipient some rights for their contribution
> according to the terms of the license.
>
> If a recipient does not follow the terms of the license, what prevents
> any of the contributors from taking action, since the license is between
> each contributor and the recipient. The ASF is *a* contributor too, and
> therefore can take action because we have standing, but why can't each
> each contributor act independently if the terms of the license are
> violated for their particular contribution?
>
>>
>>> I dunno. I am not a lawyer, and I'm really tired :)
>>
>> The ability to fork is what saves users from copyright holders going
>> wacko and changing the license in 'less then open source'.
>>
>> Which means that you might own some code, but you don't own its usage
>> dynamics once you enter an OSI/free-software licensing scheme.
>>
>
> Except if the terms of the license under which you provided the code
> aren't followed, right?
>
> geir
>
>
Re: SableVM? -- ICLA details
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Stefano Mazzocchi wrote:
> Geir Magnusson Jr wrote:
>>
>>
>> Geir Magnusson Jr wrote:
>>>
>>>
>>> Dalibor Topic wrote:
>>>> Leo Simons wrote:
>>>>
>>>>>> , that that can
>>>>>> lead to no end of confusion over the actual license of a VM using
>>>>>> modules from Harmony, if the SableVM developer believes to have a
>>>>>> say in
>>>>>> it.
>>>>>
>>>>> No I would say that it cannot, since that sablevm developer would
>>>>> at a minimum
>>>>> have licensed the software under the apache license to apache, and
>>>>> then apache
>>>>> would have licensed that software to the end user under the apache
>>>>> license, and
>>>>> what that means is rather clear.
>>>>>
>>>>
>>>> It's not clear at all to me from reading the ASL2, so let's spell it
>>>> out: Would such a hypothetical developer have a say in the license
>>>> of a VM using Harmony's modules or not? Cliff?
>>>
>>> No.
>>
>> I thought about this for a second more - the apache license is a
>> license from each contributor of their contribution to the licensee,
>> so I would guess that yes, any contributor could hypothetically have a
>> say on what a licensee does w/in the boundaries of their contribution.
>
> no, hold it, this is not true. Once you give a perpetual license, you
> can't revoke it. If you own some code, you can relicense it under
> different conditions, but since the license that you had before was a
> OSI license it gives other the ability to fork.
I wasn't suggesting that you could revoke it.
My thoughts were along the lines of what the apache license says - that
each contributor gives each recipient some rights for their contribution
according to the terms of the license.
If a recipient does not follow the terms of the license, what prevents
any of the contributors from taking action, since the license is between
each contributor and the recipient. The ASF is *a* contributor too, and
therefore can take action because we have standing, but why can't each
each contributor act independently if the terms of the license are
violated for their particular contribution?
>
>> I dunno. I am not a lawyer, and I'm really tired :)
>
> The ability to fork is what saves users from copyright holders going
> wacko and changing the license in 'less then open source'.
>
> Which means that you might own some code, but you don't own its usage
> dynamics once you enter an OSI/free-software licensing scheme.
>
Except if the terms of the license under which you provided the code
aren't followed, right?
geir
Re: SableVM? -- ICLA details
Posted by Stefano Mazzocchi <st...@apache.org>.
Geir Magnusson Jr wrote:
>
>
> Geir Magnusson Jr wrote:
>>
>>
>> Dalibor Topic wrote:
>>> Leo Simons wrote:
>>>
>>>>> , that that can
>>>>> lead to no end of confusion over the actual license of a VM using
>>>>> modules from Harmony, if the SableVM developer believes to have a
>>>>> say in
>>>>> it.
>>>>
>>>> No I would say that it cannot, since that sablevm developer would at
>>>> a minimum
>>>> have licensed the software under the apache license to apache, and
>>>> then apache
>>>> would have licensed that software to the end user under the apache
>>>> license, and
>>>> what that means is rather clear.
>>>>
>>>
>>> It's not clear at all to me from reading the ASL2, so let's spell it
>>> out: Would such a hypothetical developer have a say in the license of
>>> a VM using Harmony's modules or not? Cliff?
>>
>> No.
>
> I thought about this for a second more - the apache license is a license
> from each contributor of their contribution to the licensee, so I would
> guess that yes, any contributor could hypothetically have a say on what
> a licensee does w/in the boundaries of their contribution.
no, hold it, this is not true. Once you give a perpetual license, you
can't revoke it. If you own some code, you can relicense it under
different conditions, but since the license that you had before was a
OSI license it gives other the ability to fork.
> I dunno. I am not a lawyer, and I'm really tired :)
The ability to fork is what saves users from copyright holders going
wacko and changing the license in 'less then open source'.
Which means that you might own some code, but you don't own its usage
dynamics once you enter an OSI/free-software licensing scheme.
If not, hell, it would be a perpetual lock-in situation.
So, in short:
1) the ASF is not asking for copyright transfer, so "submarine
copyright holders" are all over the place (I'm one too, I own code in so
many java projects I can't even count them, and I wasn't working for
anybody so that is definitely my code).
2) not having ownership simplifies donations and guarantees the
ability for the author to do whatever he/she pleases with the code even
after it was donated.
3) not having ownership does not effect the ability for the ASF to
create successful and perpetual open development efforts around such
code. The owner cannot stop the ASF from continuing the effort unless it
violates the contract that was signed with the CLA. Given the broad
spectrum of rights that the CLA gives to the ASF.
4) copyright statements and giving credits are two different things
and I think it's wise to keep them separate.
5) the ASF considers it a moral obligation to give credit when due,
not a contractual one. In 10 years, Etienne is the only one who had a
problem with this. It is reasonable for him to ask for such an
obligation to be contractual and not just moral, yet it is also
reasonable (and predictable) for some ASF members to feel insulted by
such a request.
--
Stefano.
Re: SableVM? -- ICLA details
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Geir Magnusson Jr wrote:
>
>
> Dalibor Topic wrote:
>> Leo Simons wrote:
>>
>>>> , that that can
>>>> lead to no end of confusion over the actual license of a VM using
>>>> modules from Harmony, if the SableVM developer believes to have a
>>>> say in
>>>> it.
>>>
>>> No I would say that it cannot, since that sablevm developer would at
>>> a minimum
>>> have licensed the software under the apache license to apache, and
>>> then apache
>>> would have licensed that software to the end user under the apache
>>> license, and
>>> what that means is rather clear.
>>>
>>
>> It's not clear at all to me from reading the ASL2, so let's spell it
>> out: Would such a hypothetical developer have a say in the license of
>> a VM using Harmony's modules or not? Cliff?
>
> No.
I thought about this for a second more - the apache license is a license
from each contributor of their contribution to the licensee, so I
would guess that yes, any contributor could hypothetically have a say on
what a licensee does w/in the boundaries of their contribution.
I dunno. I am not a lawyer, and I'm really tired :)
geir
Re: SableVM? -- ICLA details
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Dalibor Topic wrote:
> Leo Simons wrote:
>
>>> , that that can
>>> lead to no end of confusion over the actual license of a VM using
>>> modules from Harmony, if the SableVM developer believes to have a say in
>>> it.
>>
>> No I would say that it cannot, since that sablevm developer would at a
>> minimum
>> have licensed the software under the apache license to apache, and
>> then apache
>> would have licensed that software to the end user under the apache
>> license, and
>> what that means is rather clear.
>>
>
> It's not clear at all to me from reading the ASL2, so let's spell it
> out: Would such a hypothetical developer have a say in the license of a
> VM using Harmony's modules or not? Cliff?
No.
>
>>> I'm asking since going to court over disagreement of Kaffe's
>>> license's effects has been explained to me by some SableVM developers
>>> as a possible consequence of using SableVM's code in the past
>>
>> I have no idea what "Kaffe's license's effects" means.
>
> Some SableVM developers have asserted in the past that running some
> applications on top of a GPLd VM constitutes a crime, which could be
> avoided by using SableVM, rather than other VMs.
I think the crime was putting a VM under the GPL ;)
>
> That was due to an unfortunate misinterpretation of the actual effect of
> the GPL, which had the even more unfortunate side effect that some
> people have blown it way out of proportion, and waged a campaign against
> distributors of GPLd VMs, their users and packagers for over two years.
> It was not very pleasant while it lasted.
>
> I would very much like to avoid that Harmony's downstream users have to
> go through the same time wasting ordeal over and over again, that
> various people outside of SbaleVM went through a few times. Having
> submarine copyright holders on VMs using Harmony's VM modules or class
> libraries would be a pretty bad thing.
>
Huh? People don't *assign* copyright to the ASF, they grant a license to
their work.
So *all* software that you get from the ASF certainly has "submarine
copyright holders" in the sense that it is possible that one or more
people do own the copyright for any given piece of code.
But you don't care, because it's licensed to you under the terms of the
Apache License.
> The requested changes sound to me like asking for shared copyright in
> all VMs using Harmony's modules, and I just want to know if that is the
> case, or not. Preferrably from the people asking for those changes. :)
We don't care. There is shared copyright on all of this. Right?
gier
Re: SableVM? -- ICLA details
Posted by Dalibor Topic <ro...@kaffe.org>.
Leo Simons wrote:
>> , that that can
>> lead to no end of confusion over the actual license of a VM using
>> modules from Harmony, if the SableVM developer believes to have a say in
>> it.
>
> No I would say that it cannot, since that sablevm developer would at a minimum
> have licensed the software under the apache license to apache, and then apache
> would have licensed that software to the end user under the apache license, and
> what that means is rather clear.
>
It's not clear at all to me from reading the ASL2, so let's spell it
out: Would such a hypothetical developer have a say in the license of a
VM using Harmony's modules or not? Cliff?
>> I'm asking since going to court over disagreement of Kaffe's license's effects
>> has been explained to me by some SableVM developers as a possible consequence
>> of using SableVM's code in the past
>
> I have no idea what "Kaffe's license's effects" means.
Some SableVM developers have asserted in the past that running some
applications on top of a GPLd VM constitutes a crime, which could be
avoided by using SableVM, rather than other VMs.
That was due to an unfortunate misinterpretation of the actual effect of
the GPL, which had the even more unfortunate side effect that some
people have blown it way out of proportion, and waged a campaign against
distributors of GPLd VMs, their users and packagers for over two years.
It was not very pleasant while it lasted.
I would very much like to avoid that Harmony's downstream users have to
go through the same time wasting ordeal over and over again, that
various people outside of SbaleVM went through a few times. Having
submarine copyright holders on VMs using Harmony's VM modules or class
libraries would be a pretty bad thing.
The requested changes sound to me like asking for shared copyright in
all VMs using Harmony's modules, and I just want to know if that is the
case, or not. Preferrably from the people asking for those changes. :)
> Honestly, the IP trail for
> kaffe is at best incomprehensible to most mortals, so I can somehow imagine lots
> of room for disagreement :-).
Given that it's the oldest active free software VM, with an active,
collaborative, transparent development community going back to 1996,
I don't think there are any questions regarding Kaffe's development
history.
It's all been done out there in the open, afaict.
> The apache license is a rather nice license. If you trust it to be valid, and that
> all the people applying it apply it properly, and you yourself apply it properly,
> then there is not so much room for different interpretation or confusion as there
> is for (for example) GPLv2, and hence not so much chance of getting sued.
Most license stewards try leave very little room for confusion in their
licenses, be it FSF, ASF, or anyone else. There is as little room for
confusion in the GPL as is in the ASL2. Both work pretty much the same
way, they only differ in the scope of how much of an author's rights
they chose to pass on, under which specific conditions, and some small
details, like using a lawyer-friendly vs. rest-of-us-friendly terminology.
Other than that, it's all the same thing: the let you use works, modify,
lern from, pass them on freely, and have fun, based on copyright law.
At least from where I stand. :)
cheers,
dalibor topic
Re: SableVM? -- ICLA details
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, Mar 23, 2006 at 01:57:51PM -0800, Dalibor Topic wrote:
> On Thu, Mar 23, 2006 at 01:12:33PM -0800, Leo Simons wrote:
> > Dalibor,
> >
> > On Thu, Mar 23, 2006 at 09:46:16AM -0800, Dalibor Topic wrote:
> > > On Thu, Mar 23, 2006 at 10:32:19AM -0500, Etienne Gagnon wrote:
> > > > 5- The ASF provides me with an official, legally binding document,
> > > > signed by officers that have sufficient rights to do so, stating that
> > > > it will only sub-license (distribute, etc.) code contributed by SableVM
> > > > authors (can be identified specifically) and derivatives of this code,
> > > > under licenses that require explicit acknowledgment of the copyright
> > > > of these authors and that require redistribution of the related text
> > > > found in the NOTICE file. [I have no trouble letting the ASF lawyers
> > > > come up with some text proposal. I would highly suggest reusing words
> > > > off the Apache License 2.0 to do so. I can even propose some text, if
> > > > you wish me to do so.]
> > >
> > > Is the intent that you want to be able to claim copyright on VMs linking
> > > to Harmony's VM modules?
> >
> > Huh?
> >
> > Regardless of intent (something I can't answer for obviously), how would that
> > possibly be a valid claim? Attribution of A with regard to X is not in any
> > way related to copyright of A with regard to Y, right?
>
> Sure, but that's something a downstream user wouldn't want to have to court
> over, if they can avoid it.
Of course.
> If a downstream user ends up using a module from
> Harmony in their VM, and if some SableVM developer regards such use as creating
> a derivative work, that he has a shared copyright in
This is not a completely unlikely situation.
> , that that can
> lead to no end of confusion over the actual license of a VM using
> modules from Harmony, if the SableVM developer believes to have a say in
> it.
No I would say that it cannot, since that sablevm developer would at a minimum
have licensed the software under the apache license to apache, and then apache
would have licensed that software to the end user under the apache license, and
what that means is rather clear.
The only thing this hypothetical sablevm developer could do is complain that the
license under which he licensed the code is not followed, but in that case it would
probably be much much more productive to go and talk to the ASF directly. If the
sablevm developer was right, obviously that would be very annoying to the end user
as well as for the ASF, but still not all that confusing.
> I'm asking since going to court over disagreement of Kaffe's license's effects
> has been explained to me by some SableVM developers as a possible consequence
> of using SableVM's code in the past
I have no idea what "Kaffe's license's effects" means. Honestly, the IP trail for
kaffe is at best incomprehensible to most mortals, so I can somehow imagine lots
of room for disagreement :-). In any case, the IP trail for harmony should be
somewhat simpler.
>, so we have avoided using their code
> to protect our end users and distributors from potential lawsuits. I'd
> like to be able to use code in Harmony without fear of being dragged to court
> for copyright infringement, if I interpret the license on my own code
> differently from some SableVM developer, no matter which license it is.
Me too. While in some ways there is always fear of being dragged to court (since
for example patents exist), our explicit goal has always been that you won't be
infringing on copyrights with regard to harmony distributions if you comply with
the terms of the apache license (and perhaps some other applicable ones, but I
think so far the applicable ones will be subsets of the apache license), and you
need not fear that you will.
The apache license is a rather nice license. If you trust it to be valid, and that
all the people applying it apply it properly, and you yourself apply it properly,
then there is not so much room for different interpretation or confusion as there
is for (for example) GPLv2, and hence not so much chance of getting sued.
cheers,
Leo
Re: SableVM? -- ICLA details
Posted by Dalibor Topic <ro...@kaffe.org>.
On Thu, Mar 23, 2006 at 01:12:33PM -0800, Leo Simons wrote:
> Dalibor,
>
> On Thu, Mar 23, 2006 at 09:46:16AM -0800, Dalibor Topic wrote:
> > On Thu, Mar 23, 2006 at 10:32:19AM -0500, Etienne Gagnon wrote:
> > > 5- The ASF provides me with an official, legally binding document,
> > > signed by officers that have sufficient rights to do so, stating that
> > > it will only sub-license (distribute, etc.) code contributed by SableVM
> > > authors (can be identified specifically) and derivatives of this code,
> > > under licenses that require explicit acknowledgment of the copyright
> > > of these authors and that require redistribution of the related text
> > > found in the NOTICE file. [I have no trouble letting the ASF lawyers
> > > come up with some text proposal. I would highly suggest reusing words
> > > off the Apache License 2.0 to do so. I can even propose some text, if
> > > you wish me to do so.]
> >
> > Is the intent that you want to be able to claim copyright on VMs linking
> > to Harmony's VM modules?
>
> Huh?
>
> Regardless of intent (something I can't answer for obviously), how would that
> possibly be a valid claim? Attribution of A with regard to X is not in any
> way related to copyright of A with regard to Y, right?
Sure, but that's something a downstream user wouldn't want to have to court
over, if they can avoid it. If a downstream user ends up using a module from
Harmony in their VM, and if some SableVM developer regards such use as creating
a derivative work, that he has a shared copyright in, that that can
lead to no end of confusion over the actual license of a VM using
modules from Harmony, if the SableVM developer believes to have a say in
it.
I'm asking since going to court over disagreement of Kaffe's license's effects
has been explained to me by some SableVM developers as a possible consequence
of using SableVM's code in the past, so we have avoided using their code
to protect our end users and distributors from potential lawsuits. I'd
like to be able to use code in Harmony without fear of being dragged to court
for copyright infringement, if I interpret the license on my own code
differently from some SableVM developer, no matter which license it is.
cheers,
dalibor topic
> Leo *scratches head a lot these days* Simons
Re: SableVM? -- ICLA details
Posted by Leo Simons <ma...@leosimons.com>.
Dalibor,
On Thu, Mar 23, 2006 at 09:46:16AM -0800, Dalibor Topic wrote:
> On Thu, Mar 23, 2006 at 10:32:19AM -0500, Etienne Gagnon wrote:
> > 5- The ASF provides me with an official, legally binding document,
> > signed by officers that have sufficient rights to do so, stating that
> > it will only sub-license (distribute, etc.) code contributed by SableVM
> > authors (can be identified specifically) and derivatives of this code,
> > under licenses that require explicit acknowledgment of the copyright
> > of these authors and that require redistribution of the related text
> > found in the NOTICE file. [I have no trouble letting the ASF lawyers
> > come up with some text proposal. I would highly suggest reusing words
> > off the Apache License 2.0 to do so. I can even propose some text, if
> > you wish me to do so.]
>
> Is the intent that you want to be able to claim copyright on VMs linking
> to Harmony's VM modules?
Huh?
Regardless of intent (something I can't answer for obviously), how would that
possibly be a valid claim? Attribution of A with regard to X is not in any
way related to copyright of A with regard to Y, right?
Leo *scratches head a lot these days* Simons
Re: SableVM? -- ICLA details
Posted by Dalibor Topic <ro...@kaffe.org>.
On Thu, Mar 23, 2006 at 10:32:19AM -0500, Etienne Gagnon wrote:
> Hi Leo,
>
> I started replying to your email, suggesting modifications to the ICLA
> that would address my concerns. As this would probably lead to a very
> long license thread, I erased it, and I am proposing a simpler solution.
>
> I am proposing that we strictly abide by the advertised Apache Harmony
> Contribution Policy at:
> http://incubator.apache.org/harmony/contribution_policy.html
> but, we add one additional condition that must be met by the ASF, and we
> add an explicit mention of it on signed ICLAs:
>
> 1- Current and future SableVM contributors sign the ICLA for
> contributing patches and possibly gaining commit rights.
> http://www.apache.org/licenses/icla.txt
>
> 2- Also, contributors must complete the Authorized Contributor
> Questionnaire and submit to the Harmony PMC.
> http://incubator.apache.org/harmony/auth_cont_quest.html
>
> 3- I sign a Software Grant license (with the authorization of the
> appropriate SableVM authors to do so) for each bulk contribution.
> http://www.apache.org/licenses/software-grant.txt
>
> 4- I fill a Bulk Contribution Checklist for each bulk contribution.
> http://incubator.apache.org/harmony/bulk_contribution_checklist.html
>
> 5- The ASF provides me with an official, legally binding document,
> signed by officers that have sufficient rights to do so, stating that
> it will only sub-license (distribute, etc.) code contributed by SableVM
> authors (can be identified specifically) and derivatives of this code,
> under licenses that require explicit acknowledgment of the copyright
> of these authors and that require redistribution of the related text
> found in the NOTICE file. [I have no trouble letting the ASF lawyers
> come up with some text proposal. I would highly suggest reusing words
> off the Apache License 2.0 to do so. I can even propose some text, if
> you wish me to do so.]
Is the intent that you want to be able to claim copyright on VMs linking
to Harmony's VM modules?
cheers,
dalibor topic
>
> 6- Each ICLA and Software Grant has an explicit hand written reference
> to the ASF document in "5-" beside the signature(s). A copy of the
> ASF document in "5-" is added as an appendix to the ICLA/SG in your
> records and our records.
>
>
> I sincerely think that the above should be acceptable to all parties
> involved. SableVM authors would end up strictly abiding by the existing
> contribution policy, yet the ASF would be providing us with the security
> we require to acknowledge our contributions.
>
> See below for a short comment.
>
> Leo Simons wrote:
> >>So, for example, the ASF could sublicense
> >>derivatives of our work under any license it wants, without even
> >>acknowledging our contribution in a NOTICE file.
> >
> > "When hell freezes over..."
>
> As far as I know, the ASF has no power to control US federal and state
> governments. So, the ASF cannot assure me that US laws will never
> change in the next millennium (you never know how long the US government
> will extend copyright, given Disney's lobbying) as to allow Microsoft or
> any such party to gain control on the ASF, possibly after a bankrupt or
> something similar. It is very difficult to predict the future of any
> corporation, be it a private, public, profit or non-profit organization.
> So, I feel very, very uncomfortable to give a blank check to anybody.
>
> [Of course, the US government can also adopt laws that invalidate
> written contracts...]
>
>
> Hoping that my proposal above is acceptable to all.
>
> Etienne
> PS: It seems we're getting down to the "real" stuff... heh.
>
> --
> Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
> SableVM: http://www.sablevm.org/
> SableCC: http://www.sablecc.org/
Re: SableVM? -- ICLA details
Posted by Etienne Gagnon <eg...@sablevm.org>.
Hi Geir,
>> If SableVM hosted an Apache License 2.0 on http://sablevm.org , then
>> Harmony could regularly import that code (and modifications) into its
>> repository.[...]
...
>> SableVM could also import back Harmony modifications in its svn, [...]
...
> Yes, that's true.... but it would run afoul of our concerns for IP
> provenance. I'd be against this.
Oh, yes! I should have thought about this. It would effectively make
things much harder, trying to recover history across two repositories.
My recent experience tracing back all contributions within a single
repository with 4800+ revisions was painful enough (this doesn't even
begin to describe the real feeling).
>> Advantages:
>>...
>> - It is much easier to get Sun's TCK blessing a complete J2SE
>> implementation, than having to build the J2SE from distinct, separate
>> pieces (i.e. Harmony libs, SableVM vm, other downloadable separately
>> pieces.)
>
> That's not true. There is no requirement in the TCK license for any
> such thing.
Interesting. I had not realized this. I thought that Harmony was
looking to certify an "all Harmony/Apache" system.
If it is OK to work towards certifying a combined system, then it would
be much better, in order to keep a clear IP trail of SableVM, if all of
its development happened in a single repository: user-targeted VM
development in trunk and research development in sandboxes. My previous
vision of "user-targeted VM in Harmony svn" and "research in SableVM
svn" would actually be an IP trail nightmare.
> You are mixing apples and oranges, I think. The ASF could switch to the
> BSD and still require the ICLA and SG. The serve different purposes.
I think Stefano and explained my thought clearly [ much better than I
did :-) ]: The ICLA is very (or ultimately?) permissive to the ASF.
The BSD/MIT/... licenses are more restrictive to the ASF.
While talking of it... I take back my request for a document signed by
ASF officers; I certainly don't want anybody to feel insulted. It has
never been my intention to offend anybody, and certainly not the ASF!
> I'm not giving up, but if in the end we can't make ends meet, SableVM
> can stay put, and with the license change, be included in certified
> distributions of Apache Harmony.
Actually, your latest proposal seems very attractive. Combined with the
earlier IP trail concerns, it seems to me like the easiest and fastest
road to fruitful collaboration. :-)
Cheers,
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: SableVM? -- ICLA details
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Etienne Gagnon wrote:
> Leo Simons wrote:
>> simple = good :-)
>
> :-)
>
>> In any case, if an ASF officer needs to sign legal paperwork that is
>> unlike anything the ASF has ever signed before, you'll immediately notice
>> a slowdown of all processes since all of a sudden things drop out of
>> "internet time". This makes me instinctively dislike any process that
>> requires official action by an ASF officer.
>
> OK. Then we have to find a different solution than going through ICLA/SG.
>
> If SableVM hosted an Apache License 2.0 on http://sablevm.org , then
> Harmony could regularly import that code (and modifications) into its
> repository. This would be identical to reusing someone else's BSD or
> MIT licensed code, which Harmony already does.
Yes, that's true.... but it would run afoul of our concerns for IP
provenance. I'd be against this.
>
> SableVM could also import back Harmony modifications in its svn, so that
> both projects keep a synchronized code base, avoiding an unnecessary fork.
We'll, it would be a fork. A weird, "binar" fork, but a fork nonetheless.
And one that I think would fail over time, because we wouldn't be
working together as one community. We'd never make the hard decisions -
we'd probably each decide to punt and "just do it in our repository".
>
> Advantages:
>
> - Harmony can still ship as a single, complete piece of software
> including sablevm or parts of it, providing a complete J2SE 5.0
> implementation under AL2 license.
>
> - It is much easier to get Sun's TCK blessing a complete J2SE
> implementation, than having to build the J2SE from distinct, separate
> pieces (i.e. Harmony libs, SableVM vm, other downloadable separately
> pieces.)
That's not true. There is no requirement in the TCK license for any
such thing.
>
> - Increase cross-project collaboration, without the need for double
> registration of contributors to both project.
>
> - Still allows for mix and matching JCHEVM and SableVM code, as all is
> license compatible.
>
>>> It is very difficult to predict the future of any
>>> corporation, be it a private, public, profit or non-profit organization.
>> I am happy to predict though that neither Disney nor Microsoft gain control
>> over the ASF in the next millenium. It seems a safer bet than the weather :)
>
> I predict the same; yet I know very few people that can truely claim
> 100% accurate predictions 1000 years in advance...
>
>>> So, I feel very, very uncomfortable to give a blank check to anybody.
>>
>> Ok. Never licensed anything under the BSD license, have you? :-)
>
> BSD still forces you to include the copyright and license notice. This
> is much stricter than the ICLA/SG. :-)
?
You are mixing apples and oranges, I think. The ASF could switch to the
BSD and still require the ICLA and SG. The serve different purposes.
And notice how people have moved away from the notice requirements of
classic BSD, mainly because it's a royal pain.
>
> So, how about this new, more modest, yet hopefully simple proposal?
I'm not giving up, but if in the end we can't make ends meet, SableVM
can stay put, and with the license change, be included in certified
distributions of Apache Harmony.
geir
>
> Etienne
>
Re: SableVM? -- ICLA details
Posted by Etienne Gagnon <eg...@sablevm.org>.
Leo Simons wrote:
> simple = good :-)
:-)
> In any case, if an ASF officer needs to sign legal paperwork that is
> unlike anything the ASF has ever signed before, you'll immediately notice
> a slowdown of all processes since all of a sudden things drop out of
> "internet time". This makes me instinctively dislike any process that
> requires official action by an ASF officer.
OK. Then we have to find a different solution than going through ICLA/SG.
If SableVM hosted an Apache License 2.0 on http://sablevm.org , then
Harmony could regularly import that code (and modifications) into its
repository. This would be identical to reusing someone else's BSD or
MIT licensed code, which Harmony already does.
SableVM could also import back Harmony modifications in its svn, so that
both projects keep a synchronized code base, avoiding an unnecessary fork.
Advantages:
- Harmony can still ship as a single, complete piece of software
including sablevm or parts of it, providing a complete J2SE 5.0
implementation under AL2 license.
- It is much easier to get Sun's TCK blessing a complete J2SE
implementation, than having to build the J2SE from distinct, separate
pieces (i.e. Harmony libs, SableVM vm, other downloadable separately
pieces.)
- Increase cross-project collaboration, without the need for double
registration of contributors to both project.
- Still allows for mix and matching JCHEVM and SableVM code, as all is
license compatible.
>>It is very difficult to predict the future of any
>>corporation, be it a private, public, profit or non-profit organization.
>
> I am happy to predict though that neither Disney nor Microsoft gain control
> over the ASF in the next millenium. It seems a safer bet than the weather :)
I predict the same; yet I know very few people that can truely claim
100% accurate predictions 1000 years in advance...
>> So, I feel very, very uncomfortable to give a blank check to anybody.
>
>
> Ok. Never licensed anything under the BSD license, have you? :-)
BSD still forces you to include the copyright and license notice. This
is much stricter than the ICLA/SG. :-)
So, how about this new, more modest, yet hopefully simple proposal?
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: SableVM? -- ICLA details
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, Mar 23, 2006 at 10:32:19AM -0500, Etienne Gagnon wrote:
> I started replying to your email, suggesting modifications to the ICLA
> that would address my concerns. As this would probably lead to a very
> long license thread, I erased it, and I am proposing a simpler solution.
simple = good :-)
> I am proposing that we strictly abide by the advertised Apache Harmony
> Contribution Policy at:
> http://incubator.apache.org/harmony/contribution_policy.html
> but, we add one additional condition that must be met by the ASF, and we
> add an explicit mention of it on signed ICLAs:
>
> 1- Current and future SableVM contributors sign the ICLA for
> contributing patches and possibly gaining commit rights.
> http://www.apache.org/licenses/icla.txt
>
> 2- Also, contributors must complete the Authorized Contributor
> Questionnaire and submit to the Harmony PMC.
> http://incubator.apache.org/harmony/auth_cont_quest.html
>
> 3- I sign a Software Grant license (with the authorization of the
> appropriate SableVM authors to do so) for each bulk contribution.
> http://www.apache.org/licenses/software-grant.txt
>
> 4- I fill a Bulk Contribution Checklist for each bulk contribution.
> http://incubator.apache.org/harmony/bulk_contribution_checklist.html
>
> 5- The ASF provides me with an official, legally binding document,
> signed by officers that have sufficient rights to do so, stating that
> it will only sub-license (distribute, etc.) code contributed by SableVM
> authors (can be identified specifically) and derivatives of this code,
> under licenses that require explicit acknowledgment of the copyright
> of these authors and that require redistribution of the related text
> found in the NOTICE file. [I have no trouble letting the ASF lawyers
> come up with some text proposal. I would highly suggest reusing words
> off the Apache License 2.0 to do so. I can even propose some text, if
> you wish me to do so.]
Interesting. I'm rather sure the ASF has never done something like that
before. As soon as it comes to "official" or "legally binding" I tend to
try and gracefully bow out of any discussion.
> 6- Each ICLA and Software Grant has an explicit hand written reference
> to the ASF document in "5-" beside the signature(s). A copy of the
> ASF document in "5-" is added as an appendix to the ICLA/SG in your
> records and our records.
>
> I sincerely think that the above should be acceptable to all parties
> involved.
I can imagine so but realistically I have no clue.
> SableVM authors would end up strictly abiding by the existing
> contribution policy, yet the ASF would be providing us with the security
> we require to acknowledge our contributions.
In any case, if an ASF officer needs to sign legal paperwork that is
unlike anything the ASF has ever signed before, you'll immediately notice
a slowdown of all processes since all of a sudden things drop out of
"internet time". This makes me instinctively dislike any process that
requires official action by an ASF officer.
> See below for a short comment.
>
> Leo Simons wrote:
> >>So, for example, the ASF could sublicense
> >>derivatives of our work under any license it wants, without even
> >>acknowledging our contribution in a NOTICE file.
> >
> > "When hell freezes over..."
>
> As far as I know, the ASF has no power to control US federal and state
> governments. So, the ASF cannot assure me that US laws will never
> change in the next millennium (you never know how long the US government
> will extend copyright, given Disney's lobbying) as to allow Microsoft or
> any such party to gain control on the ASF, possibly after a bankrupt or
> something similar.
No, indeed it cannot.
> It is very difficult to predict the future of any
> corporation, be it a private, public, profit or non-profit organization.
I am happy to predict though that neither Disney nor Microsoft gain control
over the ASF in the next millenium. It seems a safer bet than the weather :)
> So, I feel very, very uncomfortable to give a blank check to anybody.
Ok. Never licensed anything under the BSD license, have you? :-)
> [Of course, the US government can also adopt laws that invalidate
> written contracts...]
Don't get me started on the things the US government feels it can do...
> Hoping that my proposal above is acceptable to all.
>
> Etienne
> PS: It seems we're getting down to the "real" stuff... heh.
Yeah looks like it!
- Leo
Re: SableVM? -- ICLA details
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Sorry about the delay. Traveling.
Etienne Gagnon wrote:
> I am proposing that we strictly abide by the advertised Apache Harmony
> Contribution Policy at:
> http://incubator.apache.org/harmony/contribution_policy.html
> but, we add one additional condition that must be met by the ASF, and we
> add an explicit mention of it on signed ICLAs:
>
> 1- Current and future SableVM contributors sign the ICLA for
> contributing patches and possibly gaining commit rights.
> http://www.apache.org/licenses/icla.txt
>
> 2- Also, contributors must complete the Authorized Contributor
> Questionnaire and submit to the Harmony PMC.
> http://incubator.apache.org/harmony/auth_cont_quest.html
>
> 3- I sign a Software Grant license (with the authorization of the
> appropriate SableVM authors to do so) for each bulk contribution.
> http://www.apache.org/licenses/software-grant.txt
>
> 4- I fill a Bulk Contribution Checklist for each bulk contribution.
> http://incubator.apache.org/harmony/bulk_contribution_checklist.html
>
> 5- The ASF provides me with an official, legally binding document,
> signed by officers that have sufficient rights to do so, stating that
> it will only sub-license (distribute, etc.) code contributed by SableVM
> authors (can be identified specifically) and derivatives of this code,
> under licenses that require explicit acknowledgment of the copyright
> of these authors and that require redistribution of the related text
> found in the NOTICE file. [I have no trouble letting the ASF lawyers
> come up with some text proposal. I would highly suggest reusing words
> off the Apache License 2.0 to do so. I can even propose some text, if
> you wish me to do so.]
>
> 6- Each ICLA and Software Grant has an explicit hand written reference
> to the ASF document in "5-" beside the signature(s). A copy of the
> ASF document in "5-" is added as an appendix to the ICLA/SG in your
> records and our records.
>
To be frank, I am not in favor of this 5 and 6.
I wouldn't support giving any subset of our contributors a special
treatment like this. How could we say no to any other contributor that
asked for the same consideration?
>
> I sincerely think that the above should be acceptable to all parties
> involved. SableVM authors would end up strictly abiding by the existing
> contribution policy, yet the ASF would be providing us with the security
> we require to acknowledge our contributions.
*We* would have that acknowledgment here at Apache Harmony, but I tend
to be uninterested in forcing downstream recipients to do things.
Please don't take this as dismissive of your concerns - I too am proud
of the work that I do, and like anyone else, don't mind recognition.
>
> See below for a short comment.
>
> Leo Simons wrote:
>>> So, for example, the ASF could sublicense
>>> derivatives of our work under any license it wants, without even
>>> acknowledging our contribution in a NOTICE file.
>> "When hell freezes over..."
>
> As far as I know, the ASF has no power to control US federal and state
> governments. So, the ASF cannot assure me that US laws will never
> change in the next millennium (you never know how long the US government
> will extend copyright, given Disney's lobbying) as to allow Microsoft or
> any such party to gain control on the ASF, possibly after a bankrupt or
> something similar. It is very difficult to predict the future of any
> corporation, be it a private, public, profit or non-profit organization.
> So, I feel very, very uncomfortable to give a blank check to anybody.
>
> [Of course, the US government can also adopt laws that invalidate
> written contracts...]
>
So here's my concern. The ASF as foundation acts in the best interests
of it's charter, which IMO has implicit considerations for the community
surrounding our codebases.
I trust the ASF to do the right thing.
Here's a totally hypothetical example - suppose the law changed, either
explicitly or via caselaw, that put any entity (individuals or company)
listed in documentation with a software product in some kind of legal
risk or jeopardy. I can just imagine the "Responisiblity in Software
Act" or some other such foolishness.
The ASF would act, changing policy and license to protect the developers.
A suggestion like yours would tie their hands or seriously complicate it.
I guess I need to re-read through this so I can be sure I understand
where you are coming from.
geir
>
> Hoping that my proposal above is acceptable to all.
>
> Etienne
> PS: It seems we're getting down to the "real" stuff... heh.
>
Re: SableVM? -- ICLA details
Posted by Etienne Gagnon <eg...@sablevm.org>.
Hi Leo,
I started replying to your email, suggesting modifications to the ICLA
that would address my concerns. As this would probably lead to a very
long license thread, I erased it, and I am proposing a simpler solution.
I am proposing that we strictly abide by the advertised Apache Harmony
Contribution Policy at:
http://incubator.apache.org/harmony/contribution_policy.html
but, we add one additional condition that must be met by the ASF, and we
add an explicit mention of it on signed ICLAs:
1- Current and future SableVM contributors sign the ICLA for
contributing patches and possibly gaining commit rights.
http://www.apache.org/licenses/icla.txt
2- Also, contributors must complete the Authorized Contributor
Questionnaire and submit to the Harmony PMC.
http://incubator.apache.org/harmony/auth_cont_quest.html
3- I sign a Software Grant license (with the authorization of the
appropriate SableVM authors to do so) for each bulk contribution.
http://www.apache.org/licenses/software-grant.txt
4- I fill a Bulk Contribution Checklist for each bulk contribution.
http://incubator.apache.org/harmony/bulk_contribution_checklist.html
5- The ASF provides me with an official, legally binding document,
signed by officers that have sufficient rights to do so, stating that
it will only sub-license (distribute, etc.) code contributed by SableVM
authors (can be identified specifically) and derivatives of this code,
under licenses that require explicit acknowledgment of the copyright
of these authors and that require redistribution of the related text
found in the NOTICE file. [I have no trouble letting the ASF lawyers
come up with some text proposal. I would highly suggest reusing words
off the Apache License 2.0 to do so. I can even propose some text, if
you wish me to do so.]
6- Each ICLA and Software Grant has an explicit hand written reference
to the ASF document in "5-" beside the signature(s). A copy of the
ASF document in "5-" is added as an appendix to the ICLA/SG in your
records and our records.
I sincerely think that the above should be acceptable to all parties
involved. SableVM authors would end up strictly abiding by the existing
contribution policy, yet the ASF would be providing us with the security
we require to acknowledge our contributions.
See below for a short comment.
Leo Simons wrote:
>>So, for example, the ASF could sublicense
>>derivatives of our work under any license it wants, without even
>>acknowledging our contribution in a NOTICE file.
>
> "When hell freezes over..."
As far as I know, the ASF has no power to control US federal and state
governments. So, the ASF cannot assure me that US laws will never
change in the next millennium (you never know how long the US government
will extend copyright, given Disney's lobbying) as to allow Microsoft or
any such party to gain control on the ASF, possibly after a bankrupt or
something similar. It is very difficult to predict the future of any
corporation, be it a private, public, profit or non-profit organization.
So, I feel very, very uncomfortable to give a blank check to anybody.
[Of course, the US government can also adopt laws that invalidate
written contracts...]
Hoping that my proposal above is acceptable to all.
Etienne
PS: It seems we're getting down to the "real" stuff... heh.
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
SableVM? -- ICLA details (was: Contributing SableVM?)
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, Mar 23, 2006 at 02:23:20AM -0500, Etienne Gagnon wrote:
> > b) hopefully an ICLA from each contributor
>
> The ICLA rules are less restrictive than the Apache License rules:
>
> 2. Grant of Copyright License. Subject to the terms and conditions of
> this Agreement, You hereby grant to the Foundation and to
> recipients of software distributed by the Foundation a perpetual,
> worldwide, non-exclusive, no-charge, royalty-free, irrevocable
> copyright license to reproduce, prepare derivative works of,
> publicly display, publicly perform, sublicense, and distribute Your
> Contributions and such derivative works.
>
> Unless I missed something, this not force the ASF to abide by the Apache
> License 2.0 rules.
I think this is true and intentional.
> So, for example, the ASF could sublicense
> derivatives of our work under any license it wants, without even
> acknowledging our contribution in a NOTICE file.
"When hell freezes over..."
You know, I'm actually not so sure to what extent the ASF can sublicense/
relicense stuff contributed under the terms of an ICLA. I guess it
indeed goes pretty far (been a while since I read the ICLA).
However...
1) the ASF generally does not have ICLAs for every contribution -- so a
lot of things are licensed to the ASF under only the Apache License
(in some cases still the 1.1 license I believe);
2) the ASF is a non-profit foundation with a Board and a Membership who
on average would rather quit their day job and move to Japan (or say
they live there now, Europe), and eat old shoes for the rest of their
life rather than changing something fundamental like acknowledging
contributions;
3) the ASF has a 10-year spot-clean track record of doing this kind of
stuff properly.
...and for me personally this has meant enough trust in the ASF to not
have any problem with signing an ICLA.
I believe (but am not sure) that contributing things under the terms of
an ICLA rather than under the terms of the Apache License makes it
somewhat easier for the ASF to legally protect its contributors, and it
makes keeping an IP track record easier (since it is paperwork that you
sign rather than a mutual license agreement you implicitly accept or
something like that). But I'm not a lawyer and I'm always a little confused
by how that kind of thing works.
I believe that having relevant ICLAs is desireable but not always a
neccessary condition for the ASF to accept a contribution. However...
Having signed and sent in an ICLA is a requirement prior to receiving a
user account on any ASF hardware and hence is a requirement for commit
privileges to any part of the ASF subversion repository, and I really
doubt that this is something that will change. I suspect clause #7 of the
ICLA has something to do with that.
So my current understanding is that while having an ICLA for all the SableVM
contributors would be nice, having an ICLA for all the SableVM developers
who are to become harmony committers is a hard requirement.
> Most SableVM authors do not agree to allow derivative works not to
> clearly aknowledge their contribution. This is our only real
> retribution for the work we contribute.
I understand this and this makes sense.
> I understand that it is critical, for the ASF, to design new licenses,
> but rule "2." above seems too permissive, at first sight.
>
> Have I missed something?
I don't think so but I'm not completely sure ("Why do we still need
these CLAs now that we have the 2.0 license?" was a FAQ a while back
around here and the answer is not well-documented). Geir?
cheers,
Leo
Re: Contributing SableVM?
Posted by Etienne Gagnon <eg...@sablevm.org>.
Hi Geir,
> b) hopefully an ICLA from each contributor
The ICLA rules are less restrictive than the Apache License rules:
2. Grant of Copyright License. Subject to the terms and conditions of
this Agreement, You hereby grant to the Foundation and to
recipients of software distributed by the Foundation a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare derivative works of,
publicly display, publicly perform, sublicense, and distribute Your
Contributions and such derivative works.
Unless I missed something, this not force the ASF to abide by the Apache
License 2.0 rules. So, for example, the ASF could sublicense
derivatives of our work under any license it wants, without even
acknowledging our contribution in a NOTICE file.
Most SableVM authors do not agree to allow derivative works not to
clearly aknowledge their contribution. This is our only real
retribution for the work we contribute.
I understand that it is critical, for the ASF, to design new licenses,
but rule "2." above seems too permissive, at first sight.
Have I missed something?
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: Contributing SableVM?
Posted by Enrico Migliore <en...@fatti.com>.
Geir Magnusson Jr wrote:
>
> 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
>
Hi,
I think option #2 is more than reasonable. Yet, having a large number of
programmers (Harmony + SableVM) involved in the development of JC is a
promising step.
As far as I am concerned, it will take time to study the SableVM code
and its build system before being productive, but that's not a problem.
Enrico
Re: Contributing SableVM?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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
>
Re: Contributing SableVM?
Posted by George Harley <ge...@googlemail.com>.
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?
>
Quite excited would be an understatement for me !
+1000
Thanks,
George
> Cheers,
>
> Etienne
>
>
Re: SableVM? -- naming things
Posted by Etienne Gagnon <eg...@sablevm.org>.
Leo Simons wrote:
>>This was in a private email discussion between Geir, Archie and me...
>
> Really? How do I know about it then? ...
Oh! Then, it's me that apologizes. Maybe I mentioned or implied this
wish in some other email without noticing it. Sorry for the
misunderstanding!
Cheers,
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: SableVM? -- naming things
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, Mar 23, 2006 at 11:40:10AM -0500, Etienne Gagnon wrote:
> > I seem to recall that you mentioned previously that if any part of
> > SableVM would move to be a part of harmony you'd prefer that the name
> > SableVM be kept...
>
> This was in a private email discussion between Geir, Archie and me...
Really? How do I know about it then? ...
> [Leo, please be careful not to report private discussions without first
> asking permission from relevant people to do so. Such things can lead
> to diplomatic disasters. Luckily, it's not the case here. :-)]
In any case, apologies.
> So, let me rephrase my expressed wish (yet, I really don't know if now
> is an appropriate time to discuss such a thing):
I don't know either. I just dabble. You get better at it :-)
The reason I ask the questions is now is because I'm looking for possible
unsurmountable problems. If we find any, then it does not make sense to
waste "official" or "lawyer" time. I tend to try and make sure that there
is something all people involved really really really want, and that all
the hows and whys and if-and-only-if-thens and WHEREASes are fully
spelled out, before sending questions "upwards" into the official
channels.
<snip/>
> Hoping that this clarifies this non-issue. :-)
Crystal clear, thanks!
> Have fun!
You too!
regards,
Leo
Re: SableVM? -- naming things
Posted by Etienne Gagnon <eg...@sablevm.org>.
Hi Leo,
> I seem to recall that you mentioned previously that if any part of
> SableVM would move to be a part of harmony you'd prefer that the name
> SableVM be kept...
This was in a private email discussion between Geir, Archie and me...
[Leo, please be careful not to report private discussions without first
asking permission from relevant people to do so. Such things can lead
to diplomatic disasters. Luckily, it's not the case here. :-)]
So, let me rephrase my expressed wish (yet, I really don't know if now
is an appropriate time to discuss such a thing):
I imagine that SableVM's contributed code would be stored in a sablevm/
subdirectory of Harmony, in the svn repository. Now, this code is
likely to evolve with time, thanks to the contribution of Harmony
contributors (including some UQAM and McGill students). I also see
other VMs part being merged into the sablevm/ code.
I would wish that the directory name "sablevm/" survives for the VM
itself, at least as long as the code contributed by SableVM authors
(even under ICLA) constitutes the majority of the VM code.
This is not a "requirement"; it is merely a "wish". SableVM's authors
would be very grateful, though, if you granted us this little wish.
As for the "public" name of the VM, I expect Harmony to call it "the
Harmony Reference Virtual Machine" or something similar, specially if
this VM keeps SableVM's culture of targeting portability,
maintainability and "robustness" first. I would rather like to see a
TCK-compatible VM sooner, than a "faster" TCK-incompatible one.
I expect end users to call it "Harmony VM", or even "Harmony"...
Come to think of it, they'll actually call it "Eclipse" or "Ant", as
they'll not even think that there is a runtime system behind the Java
application they run. :-)
So, to repeat myself: we would consider it as a nice "Thank You!" of the
Harmony team if it kept the code in a sablevm/ directory. We do not ask
for the public name of the VM to be SableVM, yet we would be flattered
if Harmony developers used the name "sablevm" on this mailing list as a
short name for "Harmony Reference Virtual Machine". :-)
See some comments below.
> I wonder whether it would be confusing to users/contributors/developers
> that there would be a "SableVM trunk" at the ASF (which might very well
> have branches and tags of its own) and then a "SableVM research effort"
> "somewhere else".
My use of "SableVM trunk" in an earlier message was not an attempt to
impose such name usage. It was simply an attempt to write clearly
understandable context-sensitive text. :-P
> ...how does or would the Sable research lab and/or McGill university
> feel about that?...
Actually, the Sable group has become a multi-university one. See:
http://www.sable.mcgill.ca/people/
I'm actually one of the Faculty leaders of the group, now. [I got a
promotion at some point of history. :-)]
As I said, we're just "wishing" for more/less directory name
preservation (and maybe preservation of the _svm* prefix in the code,
and little inconsequential things like that) as a nicety. It's not a
formal requirement. [The only formal requirement is the preservation of
the acknowledgment in the NOTICE file.]
Hoping that this clarifies this non-issue. :-)
Have fun!
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
SableVM? -- naming things (was: Contributing SableVM?)
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Mar 22, 2006 at 10:10:52AM -0500, Etienne Gagnon wrote:
> SableVM is a project that I started during my Ph.D. studies within the
> Sable research lab at McGill university.
<snip/>
I seem to recall that you mentioned previously that if any part of
SableVM would move to be a part of harmony you'd prefer that the name
SableVM be kept...
...how does or would the Sable research lab and/or McGill university
feel about that? I can imagine the overall "sable" project might have
some claim (morally or legally or even both) to the "sable" name? (The
ASF has a bit of a tendency to get associated (by users) with the
"brand names" of its successful projects, and we wouldn't want to make
a mess of things by (for example) killing the "google ratings" for the
sable research lab website...)
Continuing on this thread...
> 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.
I wonder whether it would be confusing to users/contributors/developers
that there would be a "SableVM trunk" at the ASF (which might very well
have branches and tags of its own) and then a "SableVM research effort"
"somewhere else".
It might be easier to invent a brand new name that somehow maintains an
association (I like an island around here called Texel. So as an example,
something like "Apache Harmony TexelVM") for the #1 effort, and the
SableVM name is kept for the #2 effort.
You get into explanations like
"Apache Harmony TexelVM is derived from the same codebase as the SableVM
effort at the <sable project>(link to website). SableVM these days uses
TexelVM as the stable basis for further research effort, and several
SableVM developers actively contribute to the TexelVM effort within
Harmony and are committers on the harmony project."
which to me seem easier if there is some distinct name. E.g. somewhat like
the distinction between JCVM and JCHEVM (with "HE" being Harmony Edition),
though SableHEVM doesn't really sound all that nice...
What do you think?
cheers,
Leo
Re: Contributing SableVM?
Posted by Etienne Gagnon <eg...@sablevm.org>.
Hi all,
Thanks for the positive feedback.
In my earlier message I forgot to ask: If the Harmony project is
interested in the SableVM contribution (how is that officially
decided?), what process should I follow to actually make a contribution?
I've fond a "Contribution Policy" web page, but I didn't find a
"How-To"... :-)
Thanks,
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: Contributing SableVM?
Posted by Alex Karasulu <ao...@bellsouth.net>.
Weldon Washburn wrote:
> On 3/22/06, Etienne Gagnon <eg...@sablevm.org> wrote:
>
>> 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
>>
>
> +1 on the above. I suspect it will be fairly easy to get Harmony
> Class Library "hello world" working on the merged JCHEVM and SableVM.
>
>
+1 SableVM is a nice piece of work ... I got Felix on it and almost got
ApacheDS running on it.
Alex
Re: Contributing SableVM?
Posted by Weldon Washburn <we...@gmail.com>.
On 3/22/06, Etienne Gagnon <eg...@sablevm.org> wrote:
>
> 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
+1 on the above. I suspect it will be fairly easy to get Harmony
Class Library "hello world" working on the merged JCHEVM and SableVM.
--
Weldon Washburn
Intel Middleware Products Division