harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [Fwd: Re: [jchevm] JCHEVM discussion]
Date Mon, 13 Mar 2006 00:53:07 GMT
I'm about to run for the airport, but there's one thing I wished to 
point you to just so there's no misunderstanding, and a comment...

Etienne Gagnon wrote:
> [Message bounced->I subscribed->here it is...]
> Hi Archie (and Harmony developers),
> I see that the public discussion has actually started.  I would have
> rather liked to settle all this quietly. :-/

Oh, the public discussion is just because unless it's something 
personal, we like to do things with the most transparency as possible. 
We respect the concerns you raised, and by discussing here, everyone is 
aware and can help work towards the peaceful and amicable resolution.


I'll respond to the snipped out part later - I just want to clarify 
something around the following :
> The problem is identifying "what", if anything, is "untainted" is
> JCHEVM.  This might be a difficult, given your apparent "tainting" at
> the time you developed it.
> You should read Geir's text at:
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200506.mbox/%3c43F59F7E-56A8-4447-96A6-7E57646365A1@apache.org%3e
>  3) Taint
>  ...
>     With those activities in mind, have you done any of the following
>     to an implementation of one or more of the components you listed in
>     item (2) above :
>      - Read some or all the source code for an implementation?
>      - Fixed defects or performed other maintenance activity on an
>        implementation?
>      - Enhanced the source code for an implementation with additional
>        function, performance or other qualities of service?
>   ...
>      If you have answered yes to any question above, you may not be
>      an contributor to the related component of Apache Harmony unless...
> What is your answer to these questions?

Note that you quoted an early version of the contributor questionniare - 
since we do everything (or as much as we can in public) we bring these 
forward to get feedback as we are developing them.

The version that is being used is here :


Note that the last snippet that you quote has been evolved to :

   If you have answered yes to any question above, and that
   implementation is not available under a recognized Open
   Source license, you may not be an contributor to the
   related component of Apache Harmony unless the copyright
   owner of that implementation either:

The key change is "and that implementation is not available under a 
recognized Open Source license" - because except for copying, which we 
don't allow, any ideas found in open-source-licensed source code are not 
trade secrets and therefore able to be re-implemented by others in 
independent, differently-licensed implementations.

Of course, this isn't an attempt to side-step the issue of copying, but 
I did wish to inform you of the document that is currently operational.

>> There's also the possibility that SableVM folks could give their blessing
>> and donate their code, but that might have practical difficulties because
>> all the SableVM contributors would have to agree to the new license
>> (though I'm one of them, so my vote would be easy :-)
> If I understand clearly, unlike the GNU project, the ASF does not ask
> for Copyright assignment; this can simplify things a lot, as Copyright
> assignment would practically be impossible.

That is correct.  We do not wish for copyright assignment.  You the 
author are free to re-license your work under any other license after 
(or before) you have granted the ASF a copyright license to your work 
under the Apache License.

> On the other hand, licensing SableVM under the Apache License can be
> feasible.  I will have to get in touch with other SableVM contributors.
>  The most important contributors (in terms of lines of code) were my
> students; I do not anticipate problems there (hoping so, at least).  If
> I can't get in touch with some minor contributors, I could simply remove
> their code from the re-licensed SableVM.  Anyway, most non-student
> contributors only contributed patches to the class libraries, not to
> SableVM itself, making it a non-issue in such case.
> The question is, should it be licensed under the Apache license, or
> dual-licensed: Apache License + GNU LGPL?  Personally, I would prefer
> dual licensing, to ensure GPL compatibility (at least, until GPL 3 comes
> out, as it seems it will be compatible to the Apache License).  We would
> also have to check all of SableVM's dependencies...  (talking to self):
> I think there are dependencies on GNU Lib C.  Is that a problem?
> So, if the Harmony project has no problem acknowledging the shared
> Copyright of SableVM authors on JCHEVM, I will get in touch with these
> authors to get their consent to a license change.

That's excellent!  I see no problem with that.  We traditionally give 
credit where credit is due for anything we redistribute.

> Actually, we could get in further sharing.  SableVM already has many
> things in it (or awaiting in developer "sandboxes" to be migrated into
> the development trunk):
> 1- Invocation interface support.
> 2- generational/incremental precise garbage collector.
> 3- JVMDI/JDWP implementation.
> 4- High portability: Works on many, many platforms.
> 5- etc.

Yes - we are very interested in modularizing both the classlibrary and VM.

This seems to be going in a healthy direction!  Thanks!


View raw message