Re: JFORK: Or a reasonable response to the Sun SCSL
Okay, well we have taken a look at the legal side of this argument
(unsuprisingly) and here's what we know:
1. JDK 1.0 - very liberal license, pretty much allowed you to do what you
wanted.
2. JDK 1.1 - clean-room license, allows you to use the spec for a
clean-room implementation so long as you implement the entire spec. It's
worth nothing that without this taking Sun's specifications into your
'clean-room' violates your clean-room. At Transvirtual we tend to call
what we do an "independent implementation".
3. JDK 1.2 - SCSL - about as open as the former Soviet Union. You cannot
use their specs to write your own implementation and call it your own -
doesn't even matter if it's commercial or not.
Because of (3) Transvirtual hasn't been pushing JDK 1.2 compliance in
Kaffe since it's unclear we could actually use the results if Sun asked us
not to. We have infact started this work but we know we may have to pull
it if Sun were to threaten us.
There is a little hope here however and that is with the various standards
bodies. Sun have submitted to ECMA and eventually to ISO and if you've
been following this things have not gone to plan. It looks increasingly
likely that Java 2 will become some kind of ISO standard from which
everyone can implement without being owned by Sun. Be nice that, but it's
not happened yet. There's also Sun's submission to the ATSC DASE
committee (US digital TV overlords) to make Java a standard on that
platform and we can hope that the platform will also be open (I've been
involved with some fighting here too but Sun are in bed with Philips on
this one and I'm not hopeful).
If you suppose the worse case then JFORK would have to use JDK 1.1 as
a basis and take off in a different direction and actively *not* include
JDK 1.2 technology ... and that'd be difficult to do cleanly since
everytime I pick up a Java magazine there's some article about Collections
or Weak References, or something else. Because the specs. are published
you cannot avoid contamination - so forget your cleanroom. Oh, and this
is supposing Sun don't enforce the JDK 1.1 "no subsetting or supersetting"
restriction on you which, if they did, would force you back to JDK 1.0 as
a starting point.
On the plus side for the SCSL it is possible that the "academic use"
aspect of it may infact have caused Sun to release their intellectual
property claim to some extent and so despite the remaining clauses
in the license, using their documentation but not their code might be
okay. This is an issue of copyright v. contract (not completely unlike
what M$ are arguing in court right now) and the only way we'll find out if
this is actually true is for it to goes to court. Right now only M$ is
likely to try this. You can also argue that Sun is abusing it's copyright
by publishing specifications you can buy in a bookstore and then denying
your rights to reimplement. But this stuff is big lawyers and lots of
money territory.
You'd think that if you can buy a spec in a bookstore and you write an
implementation of it then you're okay? Wrong. A contract in a book might
mean diddly squat but the copyright is another thing entirely - and
copyright have the potential to be more damaging that contracts or even
ludicrous software patents. In Sun v. M$ Sun's claim is that M$ abused
copyright (since they screwed up the contract so badly they probably won't
win the case based on contract law) while M$ argues this is a contact
dispute. If the judge sides with M$ then the software industry as a whole
is screwed, never mind Java, any spec published by any company that you
choose to re-implement is open for later "abuse of copyright" charges if
the company feels like it. It'd be like IBM telling Oracle that they're
not implementing SQL quite right so they'd better stop doing it, oh and
pay them for the priviledge.
Anyway, enough of my ranting. JFORK might work in bringing the attention
of the Java community to focus on the real problems of the SCSL but it
will probably get used as a weapon by Sun to protect their "standard" from
"abuse". The real issue here is not Java so much as the perception of
the SCSL and right now I don't know how you effectively change that - I
boycott it but how do you presuade the 250,000 people who downloaded Star
Office to do the same.
Regards
Tim Wilkinson,
Transvirtual Techologies, Inc.
Reply to: