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.
[SNIP]
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/[EMAIL
PROTECTED]
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 :
http://incubator.apache.org/harmony/auth_cont_quest.html
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!
geir
