This message is for the discussion of the Distributor License for Java (DLJ)
Hi Roger and Ray,
I found a real issue with the DLJ license: see clause (2b):
"2b. the Software is distributed with your *Operating System*, and such
distribution is solely for the purposes of running Programs under the
control of your Operating System and designing, developing and testing
Programs to be run under the control of your Operating System"
This wording would allow Debian, Ubunty, Gentoo, Fedora, Red Hat and other Linux distributions to
redistribute customized packaging for Sun Java, but won't allow JPackage to do so as JPackage
doesn't provide an operating system.
But JPackage is the upstream provider for packages used by Red Hat, SuSE, Mandriva and most
RPM-based Linux distributions. The Debian guys also use JPackage specs, they do liitle more than
converting JPackages RPMs do Debian DPKGs (deb). So we need a different wording, or maybe an
explicit exception, to allow JPackage to provide binary RPMs for Sun Java.
Maybe we could add something like "the Software is distributed with your Operating System, *or as
extension packages for an Operating System*, and such distribution is solely..."
After all, if Linux distribution foobar doesn't packages Sun Java, wouldn't you want a third-party
to distribute the packages so that foobar distribution users have easy access to Sun Java to run
s, Fernando Lozano
>> > > This README is inside the DLJ download bundles for the JDK and JRE at
>> > > https://jdk-distros.dev.java.net/developer.html
> > This file doesn't seem to
> > say anything about modification. It is similar to the README files
> > inside other JRE and JDK versions. Are you saying that the README linked
> > on that page is different from the one inside the bundle? I don't
> > necessarily want to download the bundle either, as they should give the
> > license terms upfront.
The README file linked is the same one from the regular JDK downloads, which are not covered by the
DLJ license. I guess they should fix the page and remove those links as they will confuse lots of
So you do have to download the bundle to see the README file the DLJ license refers to. But there's
no click-though license attached to this bundle, that is, downloading it does not implies you agreed
to the DLJ. Just redistributing / repackaging the bundle ties you to the DLJ terms.
> > Note that JPackage is not a Linux distro, so it is not clear how this
> > license applies to JPackage. Perhaps Sun and the ``Debian and Ubtuntu
> > people'' were not concerned with this.
I agree with you, but I guess this was an unintentional mistake. I talked to Sun people involved
with designing the DLJ about the importance of JPackage for the Linux distributions and I'm sure
they will find a way to make the license apply to JPackage.
It was a huge improvement from last year, where we could not approach Sun people to discuss the
Linux distribution problems.
> > But with regard to distributing
> > free implementations like kaffe, I do not think this is allowed under
> > clause 2c of the current license, since kaffe is distributed with the
> > Sun JDK and may be used to replace certain components in it without
> > replacing everything (via alternatives, etc.).
> > He also said (according to you) that compiling with ecj is allowed, but
> > does he understand that `javac' may point to ecj, even if the Sun JDK is
> > installed? Does he understand that Apache xml-commons may be used to
> > replace classes inside the JDK?
As far as you don't change the original javac executable provided by the jdk bundkle you're safe.
About xml-commons, they don't replace classes inside the JDK as you don't change rt.jar to use them.
Classes like XML parsers, cryptography provides and other service-provider kinds of interfaces are
meant to be replaced by other implementations. You cannot delete Sun XML classes from the jdk
bundle, but you can add another implementation and even configure the JDK (though the .properties
files) to use the other implementation as the default one.
The intent is that DLJ applies when you do not recompile any Sun code, so it could not be used to
port Sun JDK to another processor architecture (say ARM Linux) or to another operating system (say
OpenBSD). But the intent is that you could change any resource file.
To keep Sun legal happy they devised that README trick, and so all files that may be removed or
changed have to be listed there (but this can be done without changes to the license itself). They
expect the initial README to provide an incomplete list, and wish to receive the community feedback
about which other files need to be added.
PS: If you have not heard Sun CEO keynote from JavaOne, you should. It shows a big difference in Sun
statements about open sourcing Java. It was told the question is not whether Java should be open
sourced, but how. Opensourcing a proprietary software is not an easy proccess. (Remember when
Netscape opened up the code from navigator, how many months were taken until there were a mozilla
source tarbal that could actually be compiled?) And Sun has to real with many customers that do not
share our vision about F/OSS software.
> > Roughly, the way that I read the new license, you must distribute the
> > Sun JDK ``alone'' (as per section (2c)). Moreover, you must not develop
> > any applications with this JDK---you may only use it to build packages
> > that will be shipped with your Operating System (as per section (2b)).
From the DLJ FAQ:
4. What does the DLJ allow me to do?
* Use the JDK on your OS to design, develop, test, and run Java programs
8. Does this license prevent me shipping any alternative technologies in my OS
The DLJ does not restrict you from shipping any other technologies you
choose to include in your distribution."
emails from the JPackage mailing list that were send to the JDK Community Leaders from the Linux Community Leader
> > The very first comment in the FAQ is (I don't know how to put this
> > nicely) a lie. Sun has not been listening to or working with Linux
> > distributions, particularly JPackage.
Although I have to believe you Sun has not talked to anyone from JPackage (and they have never
claimed to do so), isn't it a bit too strong to claim they have not been working with anyone from
I think this is not the moment to rant against Sun. It would be better for now to get involved with
the jdk-distros project and see how much Sun is actually willing to use our feedback and make a
JPackage for sun jdk a reality.
After all, if we want them to work with us, we have to show a little goodwill.
> > Anyway similarities to JPackage
> > were likely chosen since Ubuntu has been receptive to our policies (they
> > ship both jpackage-utils and java-gcj-compat, IIRC).
And isn't this good? JPackage conventions are published on the web site and the spec files availabe,
so Sun is as free as anyone (like Debian) to use the knowledge gained from the work. Would you
prefer them to ignore JPackage completely?
> > The ``JPackage bug''
> > has been
> > open for over four years. Furthermore, one of their proposed fixes (in
> > their current RPM) actually seems to mangle any links/binaries in /usr/bin.
Their current RPM has nothing to do with the new license and the binaries released under them. But
is my undestanding now we can provide a RPM that solves that bug. And hopefully, Sun will
incorporate this work once it's ready.
> > (1) Distribution: Linux distributions distribute other software
> > alongside the Sun JDK which may be used to replace the Sun JDK. This can
> > be done in at least three ways: (a) other proprietary JDK's such as
> > Blackdown, IBM, and BEA, (b) certain libraries from GNU and Apache and
> > others (xml-commons is a good example) (c) free environments such as
> > CACAO, Classpath, Eclipse, GCJ, JamVM.
Roger Brinkley from Sun explicity told me this is allowed by the new license.
> > (2) Combination: The alternatives system allows combination of various
> > JRE's and JDK's as well as libraries. It is possible to use, say, the
> > Sun JDK with the Eclipse compiler (ecj), and the Apache libraries.
Roger Brinkley told me the license won't allow you to use sun JVM with GNU Classpath, but it would
not prevent you from using bounceclastle alongside Sun JRE. It won't also prevent you from using ecj
or jikes to compile Java code agains Sun libraries and them running it against Sun JRE.
More mail feed back from the Linux community Leader
> > I failed to mention other ways one might want to modify the JDK
> > configuration itself: (a) the default font list (b) the security
> > provider lists (e.g., to add bouncycastle) (c) desktop and mailcap files
> > (e.g., for javaws), files that are sometimes incorrect upstream, as we
> > have seen.
> > Sun does not care about, and in fact seems to want to prohibit, any kind
> > of integration with the Linux desktop.
I'm in JavaOne and have talked with Sun people about the new license. They seem very open and
interested in discussing remaining issues with the license, to enable packagers to provive Sun JRE
and JDK packages that meet each distribution quality criterias.
I asked about font list and other JRE properties files, and I was told the README for the packages
lists files that can be modified, and the list should include everything you asked for. If not, they
ask us to tell them which specific files need to be changed and why, so they can be added to the
README and the tarball updated.
More mail from the Linux Community Leader
>> > > I asked about font list and other JRE properties files, and I was told the README for the
>> > > packages lists files that can be modified, and the list should include everything you asked for.
>> > > If not, they ask us to tell them which specific files need to be changed and why, so they can be
>> > > added to the README and the tarball updated.
> > To which file are you referring and where exactly can I find it? I am
> > aware of the README in the JRE and JDK that states what files you do not
> > need to distribute, but that is all.
This README is inside the DLJ download bundles for the JDK and JRE at
At least I was told so. I downloading the files to check this, but internet access here is slow and
I'm on battery.
> > By the way, the original Sun license has a similar clause:
> > e. you do not distribute additional software intended to replace any
> > component(s) of the Software,
> > Ironically (or perhaps not), the new license actually appears to be
> > *more* restrictive in this regard, so I would not call it a step forward.
> > It is one thing for Sun to portray certain intentions in public, but it
> > is another when you actually see their licenses (and this is the only
> > thing that counts, unfortunately).
Sun wants to preserve the integrity of their Java implementation. They do not want anyone to pick up
certain pieces and not getting others. They do not want someone to replace part of the Sun JRE and
JDK and create potential problems, so they do not allow to change or removing anything that is
considered part of the JavaSE implementation. But they want to allow replacing and changing
But Roger Brinkley was very clear the intention of the license was to allow a Linux distro to
include Sun Java and other Java implementations and libraries alongside F/OSS implementations like
Kaffe. The changes on that clause were created by Sun lawers (and acordingly to Roger reviwed and
approved by Debian and Ubuntu people) as meeting this goal
More feedback from Linux Community Leader
I was scared with item 2c when I saw it the first time but the subtle changes look to me as enough
to solve the packaging and distribution problem. Though I am not a lawer and so I may be wrong. You
Sun has interests to preserve, they are not incompatible with free redistribution and repackaging of
the JRE. And I don't believe they are acting on bad faith. They actually told me they are willing to
change the text of the license if someone points a problem and finds a solution.
I'd like to hear from someone that can really talk about law and contracts (licenses). Maybe we can
find the people from Debian and Ubuntu who reviewed the license. Or maybe someone from Red Hat or
SuSe can comment about it.
>> > > Could you point which point so I can talk about it to Sun people while I'm here at JavaOne?
> > It is mostly point 2c which I have already detailed in a previous email.
> > This is just after quick look. Perhaps there are even more problem areas.
> > But to be clear, even if someone from Sun says otherwise, everyone is
> > still required to do as the license says (and I am sure your contact at
> > Sun would agree with that), so it is not enough for someone at Sun to
> > say (or even believe) that the license says a certain thing, the license
> > itself (if a real problem actually exists) would actually need to be
> > changed before anything could happen.
We now have a feedback channel. Let's use it.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.