Re: RFP: jrockit -- A virtual machine for Java
-----Original Message-----
From: Dalibor Topic <robilad@kaffe.org>
To: Johan Walles <walles@mailblocks.com>
Cc: debian-java@lists.debian.org
Sent: Wed, 06 Oct 2004 17:43:14 +0200
Subject: Re: RFP: jrockit -- A virtual machine for Java
Johan Walles wrote:
>> ' If the version of JRockit you are licensing under this Agreement
is > > a “
pre-final,” “beta,” “technology preview,” or similar pre-production >
release
(collectively, “Pre-final Versions”), as a condition to this >
license you agree to
discontinue your use of the Pre-final Version and > replace each copy
of such
Pre-Final Version with the successor general > availability release
as soon as it
becomes available from BEA.' which is > impossible to satify as BEA
does not
provide debian packages.
> > I don't follow you. Why would this clause require BEA ship Debian
packages?
If I get a 'beta' package for jrockit, then I must 'replace it with
the successor'
version of JRockit as soon as it becomes available 'from BEA' and
discontinue
my use of old JRockit version.
Do you mean "I" as in "the re-distributor / debian maintainer, bound by
the re-distribution agreement"? In that case, when BEA gives you a tar
file with a stable release, you have to package that stable release and
release it as an update to the beta release you previously shipped. No
.deb required from BEA.
Or do you mean "I" as in "the end-user, bound by the JRockit EULA"? In
that case that clause doesn't apply to you as it isn't part of the EULA.
> I'd doubt that Debian would make any "representations or warranties
[...] in
the distribution". So unless Debian promises the world to > users of
the JRockit
.deb, this point is a no-op for Debian.
Not necessarily. An indemnification clause is financially quite risky
for a volunteer project, and it's never clear how those things would
end up being interpreted in court. Let me try to draw up a completely
hypothetical example:
Let's say Debian includes JRockit as 'A virtual machine for Java'.
Java is a trademarked term, and there are a lot of funny restrictions
on its use to label software. BEA is a SCSL licensee, afaik. So, let's
say another commercial SCSL licensee that happens to be a JVM vendor
downloads Debian-sid with JRockit on it, runs the JDK TCK, and notices
deviations in spec compliance on Debian-sid. Then he convinces Sun to
sue BEA for abusing the Java trademark by letting Debian ship a
non-compliant SCSL-derived JVM. [1] After the legal battles are
settled, BEA can come to claim the cash spent on lawyers back from
Debian, because it was Debian that said that 'jrockit is a virtual
machine for Java', but BEA doesn't make claims that jrockit is
certified on Debian.
I see your point.
//Johan
----------------------------------------------
Mailblocks - A Better Way to Do Email
http://about.mailblocks.com/info
Reply to: