Hi David,
As for the car analogy...certainly the "substantially derived" term is
an attempt to separate the
potential "OpenJDK with a twist" things from the
Kaffee/Classpath/Harmony "clean-room"
implementations. Of course people might replace a motor and still call
it a "Chevy".
The question here is not what term real people use, but what term theGM
corporation should put
into a contract to avoid a real potential huge problem with
modifications. They'll
try to separate the "true Chevy's" from the "modified Chevy's", and they
might use a term like
"substantially derived".
I can't imagine that Chevy would let a car dealer put a Chevy engine in
a Honda and call it a "Chevy".
I doubt they'd let a car dealer regularly replace Chevy engines with
Honda engines and still call them
"Chevys".
Getting back to your point...
I think that starting with OpenJDK code and modifying it by removing
parts and adding in other parts could be taken as derivation. That's
certainly our position, that swapping out a part like the VM is a
derivation.
I think it's a matter of ... ah ... percentages? Perhaps? Maybe it
could be described as a metric of 80% of the result is OpenJDK code
then it's substantiallly derived? 80% is a number I pulled out of the
air, but I think it demonstrates what I'm getting at.
To be "derived", I would that that number would have to be higher than
50%, and you can't have both the engine and
the rest of the car being more than 50%. If you allow less than 50%,
then some other implementation could just
grab a chunk of the OpenJDK and be considered "derived". For example,
Classpath could grab the missing pieces that it
needs. I'm not saying that's a bad thing, just saying that that doesn't
make Classpath "derived" from OpenJDK, certainly
not "substantially".
Andy
- David Herron
