[jchevm] JCHEVM discussion

[Geir Magnusson Jr <ge...@pobox.com>]

Ok....

We have a tradition here at the ASF of working as transparently as 
possible.  Right now, it's my opinion that there's nothing with this 
issue that would require carrying on the code examination off-list.

This is something that we were aware of when Archie made the 
contribution - he prominently and openly credited SableVM for ideas and 
algorithms.  You can review the discussion around this here :

   http://issues.apache.org/jira/browse/HARMONY-3

A contributor to the SableVM project has contacted Archie and the ASF 
and believes that some of JCHEVM constitutes a derivative work of some 
code in SableVM.  The contributor has been invited to participate in 
this discussion with us if he chooses - we are all working towards the 
same amicable outcome.

While this is an important issue, it's a simple one that we will deal 
with in a straightforward, rapid and open manner, and put it behind us 
one way or the other.  It will have no long term effect on the project - 
if anything, it will give us experience in handling cases like this in 
the future, which I am sure will pop up despite our best efforts.  Stuff 
happens.

I applaud Archie for his candor and openness wrt these issues so far, 
and suggest that Archie is in the best position to lead off the 
discussion :) [hint]

Also, I have asked the SableVM contributor to state exactly which files 
in SableVM are infringed by which files in JCHEVM to give us a better 
basis to work from.

geir

Re: [jchevm] JCHEVM discussion

[Archie Cobbs <ar...@dellroad.org>]

Archie Cobbs wrote:
> In JCHEVM, the thread handling and thin lock algorithms are very much the
> same algorithms, and my implementation contains similiar function names
> to SableVMs, etc. The code is written differently but basically does the

For the convenience of anyone who wants to take a look at this code...

SableVM (combined into one file):

http://sablevm.org/svn/repository/sablevm/trunk/src/libsablevm/thread.c

JCHEVM:

https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm/libjc/thread.c
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm/libjc/lock.c

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

Re: [jchevm] JCHEVM discussion

[Geir Magnusson Jr <ge...@pobox.com>]

Archie Cobbs wrote:

[SNIP]

> 
> 3. So what do we do? My wish is to give SableVM the benefit of the doubt.
> If there's something in there they claim is "theirs", we can take it out
> and replace it. I'd rather do that than argue about it. We should
> remember that JCVM owes SableVM a debt of gratitude and respect their
> wishes.
> 
> In particular there are lots of thread handling and locking algorithms,
> and these AFAICT are the only two areas of the code that might be
> considered "not different enough" (though I haven't heard back from
> them yet exactly what they are claiming), and these are easily replaced.
> 
> 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 :-)

Thanks Archie.  I've asked Etienne for a list of what he finds 
objectionable so we have a fixed point to work from.

I'll update when I hear back.

geir

Re: [jchevm] JCHEVM discussion

[Archie Cobbs <ar...@dellroad.org>]

Geir Magnusson Jr wrote:
> I applaud Archie for his candor and openness wrt these issues so far, 
> and suggest that Archie is in the best position to lead off the 
> discussion :) [hint]

Umm, ok here goes :-)

There are a couple of different issues. I'll try to separate them out
to the best ability of my own understanding.

A little background: copyright covers the "expression" of an idea.
To cover the idea itself, a patent is required. This issue is about
copyright; nobody is claiming that SableVM has exclusive rights to
any algorithms AFAIK.

1. As for "credit", clearly JCVM uses and reimplements many ideas and
algorithms from SableVM. This should be obvious. I have a lot of respect
for Etienne's work. The SableVM project as a whole deserves all of our
respect. Quoting the JCVM manual:
http://jcvm.sourceforge.net/share/jc/doc/jc.html

   An acknowledgment is due here. JC borrows heavily from Etienne Gagnon's
   innovative SableVM Java virtual machine implementation. Several ideas
   have been blatantly stolen from SableVM, including bidirectional object
   layout, the object lockword design and spin-free thin lock algorithm,
   per-class loader memory allocation, and thread management. In fact,
   without SableVM as an example to work from this project would probably
   have never been attempted. Of course, any errors in translation are mine.

Whether credit is due is not in question.

2. The copyright issue is the main one in question. JCVM was LGPL, so
there was never an issue. When I donated JCVM as JCHEVM, copyright became
an issue because of the new license. My thoughts at the time are here:
http://issues.apache.org/jira/browse/HARMONY-3

In JCHEVM, the thread handling and thin lock algorithms are very much the
same algorithms, and my implementation contains similiar function names
to SableVMs, etc. The code is written differently but basically does the
same thing. After all, an algorithm is a bunch of exact steps that must
be executed in a certain order. So does JCVM constitute a "different
expression" under the copyright law? That's the question -- and not one
for me, for IANAL and TINLA.

The truth is apparently no one really knows for sure. How "different"
does some software have to be before the copyright no long applies?
(Rhetorical question)

There is a spectrum between cut and paste (clear violation) and
completely different implementation of the same idea or algorithm
(clearly allowed as long as there is no patent). In between people
can have different opinions of where the line is drawn of course.

3. So what do we do? My wish is to give SableVM the benefit of the doubt.
If there's something in there they claim is "theirs", we can take it out
and replace it. I'd rather do that than argue about it. We should
remember that JCVM owes SableVM a debt of gratitude and respect their
wishes.

In particular there are lots of thread handling and locking algorithms,
and these AFAICT are the only two areas of the code that might be
considered "not different enough" (though I haven't heard back from
them yet exactly what they are claiming), and these are easily replaced.

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 :-)

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com