[lsb-discuss] LSB conf call notes for 2008-07-30

Alan Cox alan at lxorguk.ukuu.org.uk
Sat Aug 9 02:26:39 PDT 2008

> They've earned their trust through steady work with and within the Java 
> libre community, and keeping their word on opening up the reference 
> implementation of the Java platform. I understand that may not be good 
> enough for everyone, though, and that's fine, that's what discussions 
> like this one are for.

When I started in the Unix world Sun were very open, did a lot of cool
stuff and then went bad. Today Sun are doing a lot of cool open stuff but
they can still go bad - you can't pitch a standard based on future good
behaviour of any single company.

There are various reasons the LSB shouldn't mandate Java which are plain
business risk issues

- Sun employees might wake up one morning as a Microsoft subsiduary (or
any one else big) - Yahoo's nearly did.
- Sun might go out of business in which case the test suite could end up
in anyone's hands
- Sun might go bad again

And a huge political one

- Tie the LSB to the Java test suite in any meaningful way as a
requirement and the LSB ceases (in the eyes of some government
definitions) to be an "open standard", so it ceases to be acceptable on
government tender documents and the like.

With the rest of the LSB it is specified on functionality without a
series dependency on non-free stuff. If the FSF go nutty Linux can carry
on fine without them as can the LSB. There is no 'test suite' owned by
the FSF that could be used to push an agendum.

The LSB has to find a way both to recognize that many folks want java,
recognize that these folks want "java" to mean something and keep it
otherwise independent of the LSB. Hence why the LSB should merely be
defining a term or phrase which indicates that java is part of a given
LSB distro, and a minimal spec so that if java is part of a given LSB
distro it shall be installed/behave in a consistent way that every ISV
can be happy with.

If the LSB directly references the java test suite it represents a
significant shift (for the bad) by tying the LSB into proprietary
software dependencies, and worse yet from a risk perspective ones
controlled by a single company.

The political consequences are enormous too I would add - the LSB would
cease in many government environments to be classfied as "open standard"
as it would have proprietary dependencies. That would prevent governments
from specifying LSB compliance in some jurisdictions.


More information about the lsb-discuss mailing list