harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Etienne Gagnon <egag...@sablevm.org>
Subject [Fwd: Re: [jchevm] JCHEVM discussion]
Date Sun, 12 Mar 2006 23:28:55 GMT
[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. :-/

First, let me say that I admire the cleverness of Archie, when it comes
to develop code.  I respect him a lot.  I simply think that he lacked a
little knowledge about Copyright at the time he contributed code to the
Harmony project.  From Geir's answer to my email, I am confident we can
resolve the issue.

See a few comments below.

> 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.

I think that this is where you are in error.  "Expression" has a larger
extent than you think.

I cannot translate a book into another language and claim "full
copyright" on the translation.  I can only claim "co-ownership" on the
translated copy.  Yet, the translated book might actually not share a
single word with the original.  And, if the original author doesn't
agree to it, I won't be able to publish my translation.

Copyright goes even further.  It does cover "characters" in novels,
movies, cartoons.  You can't make another "James Bond" movie without the
consent of its copyright owners, even though you are not copying an
existing movie or book.  Copyright covers the combination of the name,
the psychological traits, the profession [spy], his "Bond, James Bond"
way of presenting himself, etc.  Copyright, unlike trademark, does NOT
actually restrict you from creating another character that shares one or
two traits, yet it does restrict you from copying the "character" as a
whole.  Of course, only a judge gets to decide of border-line cases.

"Expression" is thus a large thing.  This is why companies put a lot of
effort to maintain "clean room" status in their strategic projects.

JCVM is clearly based on SableVM.  You do acknowledge that fact, but you
fail to acknowledge that this makes JCVM/JCHEVM a derivative work.  This
is where we disagree.

Had JCVM simply reused a few "ideas" as explained at a relatively
high-level in my Ph.D. thesis (where I simply describe the important
aspects of some algorithms and data structures), then I would have said
nothing.  But, JCVM borrowed much more.  The exception mechanism,
locking, object layout, etc.  Even the "stop-the-world" (quite tricky)
mechanism is copied almost line to line (with only cosmetic changes).
Only one little similarity => you can claim a "random accident".  Tens
(or even hundreds?) of similarities => you cannot claim "independent work".

Once JCVM is built as a derivative work of SableVM, further JCVM
development does not erase history and make JCVM not a derivative,
unless some very radical change occurs, like a complete re-write.  Even
then, the "derivation" doubt would persist, as your very intimate
knowledge of SableVM's source code makes it impossible to claim "clean
room", or even "arm's length" distance from SableVM's source code.

JCVM really looks similar to SableVM is many ways.  Had you been taking
a distance from SableVM's source code before writing it, you would not
have written so similar code.  This is why I claim that your work is a
derivative work.

> 1. As for "credit", clearly JCVM uses and reimplements many ideas and
> ...
>   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.

I know that you acknowledged credit.  In the peril of misquoting you a
little, I would venture say that you "admit translating".  Yet,
translation is covered under Copyright laws.

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

Actually, most courts do take into account the process used to get to
the final product.  This is helpful to determine if there was "copying"
during development or if some simple "accidental similarity" happened.

Can you claim that you didn't study closely the SableVM source code as
an "inspiration" to re-write this code in JCVM?

> 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.

Studying the development process can help, though.

> 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.

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?

> 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.

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.

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.


Regards,

Etienne

-- 
Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/


-- 
Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Mime
View raw message