[lsb-discuss] LSB conf call notes for 2008-07-30
mark at klomp.org
Tue Aug 12 11:48:24 PDT 2008
On Tue, 2008-08-12 at 08:19 +0100, Alan Cox wrote:
> > No. command line utility names don't seem to be trademarkable.
> > Distributions have been distributing /usr/bin/java implementations under
> > the GPL (gcj, kaffe, classpath) without any need for trademarks.
> Caselaw citation please ? I refer you to the SSH v openssh saga. I don't
> believe that one ever hit a court of law but it shows the problem can
> come up. As I keep saying Sun can trivially fix this by making a simple
> official statement on the question. Estoppel does the rest.
I don't have any caselaw to site. Just common sense that at least for
all free distributions, long, long before openjdk, we have always worked
under the assumption that functional names of compatible free
replacement for java, javac, jar, appletviewer, keytool, etc. were fair
game. But your point is certainly valid that Sun could choose to
explicitly address this issue and make the whole (perceived?) problem go
> > And passing the ("OpenJDK") JCK doesn't give any trademarks rights.
> > So, while the binaries of IcedTea as shipped by Fedora (on x86 and x86_64)
> > pass the TCK the result still cannot be called Java (TM). As far as I know
> > Sun hasn't published any document or agreement to make this possible
> > whether or not the implementation passes the TCK.
> Then we have an even bigger problem and LSB blocker.
Well, you just have to split your concerns.
Java/Specification, Java/Testsuite, Java/Trademark/Certification.
First there is the issue of what "Java" means technically and whether or
not there is an actual specification for it. Sun hasn't made answering
that question very easy (now even their stock ticker symbol is called
Although there are pretty good specifications for the VM runtime and
compiler for the java programming language. There doesn't seem to be a
definite and complete specification for the core class libraries.
Neither does there seem to be a specific list of which tools (java,
javac, jar, apt, appletviewer, extcheck, idlj, javap, javah, jarsigner,
javadoc, keytool, pack200, rmic, rmid, serialver, javaws, policytool,
etc.) are part of "Java" and which are specific to some specific
implementation. In practice this matters since ISVs often certify their
applications against a specific Java implementation and platform.
For the LSB it might make sense to sidestep this whole issue though and
take the openjdk implementation as reference implementation and mandate
that one (or icedtea, which at least adds applet, java webstart and
non-x86 platform support). In my personal experience a lot of "java
applications" depend on specific implementation details because the spec
is either too weak or non-existent for certain parts of the core
Then there is the question of a possible testsuite. Whether or not the
TCK and the legal issues around it make sense for mandating for LSB
compliance (imho they are not really usable for any community
distribution). And whether the TCK actually tests enough of the above
specification to guarantee ISVs that an implementation that passes the
testsuite will be enough to rely on it. Since you see a lot of ISVs
certify separately for different Java/Platform combinations it might be
that the TCK is a only a minimal compatibility hurdle and not the final
word when it comes to Java implementations. This of course depends on
what Java really means in this context.
Lastly there is the actual Java trademark/certification program. If you
look at the TCK license that comes with OpenJDK you will notice that it
does not grand any rights to the mark. As far as I know there isn't any
program in place for that, even if someone claims to pass the TCK. It
looks like every vendor makes its own private deal with Sun for this.
This might or might not be a problem for the LSB. It might be a good
idea to separate the java name/trademark and the name used for a
"LSB/Java" compliant thing.
> > It isn't days, but certainly many hours. But it can certainly take up
> > to a whole day because of all the interactive tests that need human
> > interaction.
> And another..
There are other testsuites for java that take less time. Like the Mauve
testsuite, which is distributed under the GPL.
http://sourceware.org/mauve/ Which might get around the restrictions of
the TCK. But unfortunately still has less coverage. That can of course
be changed if people would like to contribute to it if the LSB chooses
to base their certification on it.
More information about the lsb-discuss