Red Hat Bugzilla – Bug 438421
OpenJDK source bundle contains binary artifacts
Last modified: 2013-01-09 23:37:11 EST
This package violates Fedora's packaging guidelines and licensing policies. It
contains binary blobs that don't qualify for the exceptions to the Exceptions in
the Packaging Guidelines, and stating "GPLv2 with exceptions" as the license tag
is misleading at best: the exceptions are not additional permissions or even
restrictions to code under the GPL, there's additional code in there that is not
licensed under the GPL at all (it's non-Free Software licenses), that's only
provided in binary form, and that require additional permissions for the GPL
code to be distributed combined with it.
These binary blogs are IcedTea's reason d'etre. I don't have all the details.
This is something that the package proponent should have looked into and disclosed.
Alexandre, the -openjdk package in Fedora is actually derived from the IcedTea
source tree, as I understand things. See the review bug for more information:
If the IcedTea code actually has binary blobs then there is a larger problem.
When I spoke to our OpenJDK packagers, they told me that the binary blobs had
been removed from our package. If they have not, please point them out specifically.
Non free bits are removed from the fedora package, see:
If you have a specific example of something that is not removed that has a non
free license, please indicate it specifically.
(In reply to comment #2)
> These binary blogs are IcedTea's reason d'etre. I don't have all the details.
Without specific examples I'll have to assume there's a misunderstanding here,
perhaps caused by the out-of-date Wiki page. Shortly after the release of
OpenJDK 6 Sun released free replacements for the encumbrances for which IcedTea
was providing replacements.
IcedTea continues to provide autotools support, non-x86 ports, a plugin, and
The "with exceptions" is referring to the GNU Classpath linking exception, not
Thanks, Colin, this does indeed sound better. This means that only the package
name is misleading.
How about adding 'icedtea' to the NVR somewhere, to make it clear that it's the
100% Free version that we're shipping?
Thomas, Kevin, there seems to be a disconnect between what you write and what
Colin wrote. AFAIK IcedTea is Free Software, so I don't see that there would be
anything to remove from it to get to a Free Software package. However, you
appear to say that the tree is based not on the IcedTea repository, but rather
on some other tree, and that *some* components were removed. I can't tell
whether these removals are the same as those used to create IcedTea out of OpenJDK.
But, again, this is not something that I have to show. It is up to the package
proponent to show that the licensing terms are acceptable for Fedora, and for
legal to verify that this is indeed the case.
Also, one has to be careful with OpenJDK 6. Even though it provides sources for
a lot of stuff, it could only be built with a pre-existing OpenJDK 6, and the
reason was because it extracted binary stuff from the pre-existing package. So
looking at the source tree isn't quite enough: one has to check that it isn't
propagating non-Free dependencies behind the scenes.
The new trademark guidelines from Sun permit us to call it OpenJDK, even with
the binary chunks removal, which is why we are using that name. There is nothing
in the Fedora OpenJDK package that is non-free, so I'm closing this bug out.
If you (or anyone) finds anything in the package that is non-free (or
questionable), feel free to reopen.
I see this in
...GNU General Public License <http://www.gnu.org/copyleft/gpl.html> version 2
only ("GPL2"), with the following clarification and special exception.
As a special exception, Sun gives you permission to link this
OpenJDK Code with certain code licensed by Sun as indicated at
("Designated Exception Modules") to produce an executable,
regardless of the license terms of the Designated Exception Modules,
and to copy and distribute the resulting executable under GPL2,
provided that the Designated Exception Modules continue to be
governed by the licenses under which they were offered by Sun.
... new GPL2 code may still be combined with Designated Exception Modules if
the new code is made subject to this exception by its copyright holder.
---------- quoted material ends ---
... which appears to be a 'you must pass along this restriction' license
exceptions term requirement.
Also this BSDish license is seen:
Copyright (c) 1999-2003 David Corcoran <email@example.com>
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
I suggest that the bug be reopened to clean these two issues (comment 11 and 12)
up, but am not its creator.
There are two relevant source tarballs here:
This provides the IcedTea source code. This tarball provides autotools support,
non-x86 ports, a plugin, and distribution-specific patches
This is the rest of the source code that comprises java-1.6.0-openjdk*. This
tarball is generated from the upstream source tarball:
This is the upstream OpenJDK tarball. This tarball does not contain the
encumbrances. No OpenJDK tarball has ever included the encumbrances. The
OpenJDK tarball is intended to be 100% Free Software and is distributed
separately from the encumbrances which are distributed as jar files containing
the "binary plugs":
The reason we generate openjdk-6-src-b06-28_feb_2008-fedora.tar.gz from
openjdk-6-src-b06-28_feb_2008.tar.gz is that there remain a few questionable
license headers on some source code files. We report these to Sun and remove
them since they're non-essential to the build. So far they have represented
minor licensing oversights. We also include the trademark license in the
-fedora variant of the tarball. See generate-fedora-zip.sh for details.
We performed the audit that resulted in generate-fedora-zip.sh before we
introduced java-1.7.0-icedtea into Fedora 8. We discussed the issues in private
email exchanges with Sun. There is no archive of the audit in Bugzilla. That
said, you remind me that we should probably re-audit now since there have been a
few releases of upstream OpenJDK since IcedTea's introduction in Fedora 8. But
rest assured that we wouldn't knowingly include non-free encumbrances in a
(In reply to comment #13)
> We report these to Sun and remove them since they're non-essential to the build.
By "them" I'm referring to the source files, not the license headers. We remove
source files with questionable license headers from the tarball before uploading
it to the Fedora source repository, so that Fedora never distributes the
affected source files in any form.
(In reply to comment #11)
I don't understand your objection. I've CC'd Mark Wielaard since he knows more
about this exception than I do.
(In reply to comment #12)
> Also this BSDish license is seen:
That's fine. This license is included in THRID_PARTY_README.
(In reply to comment #9)
> Also, one has to be careful with OpenJDK 6. Even though it provides sources for
> a lot of stuff, it could only be built with a pre-existing OpenJDK 6, and the
> reason was because it extracted binary stuff from the pre-existing package. So
> looking at the source tree isn't quite enough: one has to check that it isn't
> propagating non-Free dependencies behind the scenes.
We recognized this propagation risk and took measures to avoid it throughout
IcedTea's development. We have never built IcedTea (or OpenJDK) using a
proprietary JDK. The first IcedTea binaries were built with ecj against libgcj.
We continue to maintain this bootstrapping ability in upstream IcedTea (we
perform automated full bootstraps nightly) and in the java-1.6.0-openjdk spec
file (see the gcjbootstrap macro).
After the initial bootstrapping into Rawhide (against ecj/libgcj), subsequent
java-1.7.0-icedtea package builds were performed against previous
java-1.7.0-icedtea package builds. Then the first java-1.6.0-openjdk package
builds were performed against Fedora 8's java-1.7.0-icedtea packages. So the
build pedigree of the current java-1.6.0-openjdk packages has made non-free code
In general I agree that the package name is misleading since the package is
really just the IcedTea packaged and s/IcedTea/OpenJDK/g (but then again,
IcedTea itself is mainly removing encumbrances and adding missing pieces like
applet and webstart support, providing a clean free software bootstrapping
system and s/OpenJDK/IcedTea/g - plus adding the zero port and the cacao jits
and some patches to better integrate java into a GNU/Linux distro). But this
seems legal fine according to the TRADEMARK license file since the vast majority
of IcedTea is similar to OpenJDK. The hope of course is that upstream OpenJDK
will be completely Free Software itself soon and that some of the IcedTea
improvements will be accepted.
In reply to comment #11. The Assembly Exception is provided as an exception for
the "Designated Exception Modules", which are precisely those binary blobs
replaced by IcedTea. The last sentence of the Assembly Exception says that the
exception only carries through IF new code is also placed under the same
exception language. This implies that the exception could be removed from
derived works if someone doesn't wish to grant this exception. All this is
pretty irrelevant given that none of the Designated Exception Modules are
actually shipped with IcedTea (aka the openjdk6 rpm).
Thank you all for the information, it seems like it was just a matter of a
misleading name, after all. OpenJDK 6 is known non-Free, so it disturbs me that
Fedora will ship something that is Free under that name. This might mislead
others to ship OpenJDK 6 proper, "because Fedora does", and so they will end up
shipping non-Free Software.
I'd much rather the OpenJDK build in Fedora was somehow marked as distinct from
the original non-Free OpenJDK 6 (I don't care if it's IcedTea somewhere in the
name, or the words 'free' or 'fedora' are added to the NVR somewhere), but I can
now see how this got through policies and legal: it does indeed comply with
Sorry about the noise. Please take this as a hint of how misleading the chosen
name is, and how other Free Software activists might react and jump to incorrect
conclusions based on as little evidence as the name and the announcement that
stated that Sun had removed *most* of the encumbrances.
I suggest improving the messaging in the Release Notes as well, to give people
confidence in Fedora's mission to be built on 100% Free Software.
Err... So I went ahead and prepared the java-1.6.0-openjdk to build, and found
a bunch of odd-looking files in there.
./openjdk/jdk/make/tools/crypto contains a number of binary-only Java class
files inside .zip files.
./openjdk/jdk/test/sun/security/pkcs11/nss/lib/*/ contain various dynamic
libraries AFAICT without sources or licensing terms.
./openjdk/jdk/test/sun/management/jmxremote/bootstrap/*/launcher have sources in
../launcher.c AFAICT, but I can't figure out why we'd need a binary for these;
even more so a binary for just a few platforms.
./openjdk/jdk/test/sun/management/windows/revokeall.exe, even if based on
revokeall.c in the same directory, may contain system libraries under unknown
licenses that we're probably not interested in abiding by.
openjdk/hotspot/agent/src/share/lib/jlfgr-1_0.jar contains images and a LICENSE
that doesn't permit modification and doesn't qualify as a Free Software license.
I don't know how essential these images are for the software to tell whether
they render they handle the software that depends on them non-Free.
openjdk/hotspot/agent/src/share/lib/maf-1_0.jar contains .class files whose
sources I couldn't find.
There are many other .jar files, mainly used for testing. I haven't looked at
them at all.
That's all for now. It doesn't look good :-(
Thanks for the review. I added Mark Reinhold and Joe Darcy to the CC. They have
resolved all the previous legal issues we had with the upstream openjdk source
code. And they/sun have been very helpful resolving any issues. They have all
been oversights or simple mistakes. So I am pretty confident we will resolve
these issues also. The packaging renaming also shows that people do believe that
over time openjdk as provided by sun upstream will be as free as icedtea.
Mark/Joe, Alexandre pointed out some remaining binary blobs that we seem to have
overlooked. Some of these might be packaging errors in openjdk6 (previous
versions of the package were based on icedtea/openjdk7). Also his analysis is
against the version of icedtea6/openjdk6 as packaged for fedora, so this doesn't
yet include the new upstream source openjdk6 b07-20_mar_2008, but is based on
the b06-28_feb_2008 one (icedtea 1.6).
I haven't analyzed the things Alexandre found yet, but some general remarks below:
(In reply to comment #19)
> Err... So I went ahead and prepared the java-1.6.0-openjdk to build, and found
> a bunch of odd-looking files in there.
> ./openjdk/jdk/make/tools/crypto contains a number of binary-only Java class
> files inside .zip files.
The original analysis of openjdk when we setup icedtea didn't include any
crypto. We might have overlooked some classes here. In the worst case we can
fall back on GNU Crypto from GNU Classpath as we did for previous IcedTea releases.
> ./openjdk/jdk/test/sun/security/pkcs11/nss/lib/*/ contain various dynamic
> libraries AFAICT without sources or licensing terms.
> ./openjdk/jdk/test/sun/management/jmxremote/bootstrap/*/launcher have sources in
> ../launcher.c AFAICT, but I can't figure out why we'd need a binary for these;
> even more so a binary for just a few platforms.
> ./openjdk/jdk/test/sun/management/windows/revokeall.exe, even if based on
> revokeall.c in the same directory, may contain system libraries under unknown
> licenses that we're probably not interested in abiding by.
All the above are under the jdk/test dir, see below.
> openjdk/hotspot/agent/src/share/lib/jlfgr-1_0.jar contains images and a LICENSE
> that doesn't permit modification and doesn't qualify as a Free Software license.
> I don't know how essential these images are for the software to tell whether
> they render they handle the software that depends on them non-Free.
Yes, this looks non-free. It seems to come from
It seems necessary for...
> openjdk/hotspot/agent/src/share/lib/maf-1_0.jar contains .class files whose
> sources I couldn't find.
Which seems an example program "Mark's Application Framework Demo", which
doesn't seem to do much. (You can run it with gij -cp
demo.FrameworkDemo) It can most likely simply be removed.
> There are many other .jar files, mainly used for testing. I haven't looked at
> them at all.
In previous checks we have mainly ignored the test files. Unfortunately the test
framework (jtreg) those tests are based on isn't available as free software. So
all these tests aren't even run. We can and probably should remove them all for
now. The good news is that jtreg is scheduled to be released as free software
soon. Then we can revise the test issues again. See
> That's all for now. It doesn't look good :-(
Thanks. Sorry for the bad impression. Rest assured we will do our best to clean
these things up asap. They are simple mistakes, there is no intention to put
anything non-free in.
Thanks for bringing this to our attention. We'll look into it ASAP.
I've filed Sun bug 6678489 to track this on the upstream side.
(In reply to comment #21)
> Thanks for bringing this to our attention. We'll look into it ASAP.
> I've filed Sun bug 6678489 to track this on the upstream side.
The sources for build b08 of OpenJDK 6 have been published
(http://download.java.net/openjdk/jdk6/) and all the suspect files under the src
and make trees have been addressed as well as some of the test files. We are
reviewing all the binary files under the test directory to ensure their
licensing is made more transparent. In more detail, the binary files under
make/src/crypto were inadvertently added during a workspace restructuring merge,
are not needed, and have been removed. The hotspot/agent files are used for a
debugging facility, the sericability agent. To expedite matters, since these
files aren't critical functionality, they have been moved to closed for now;
likewise many of the pkcs11 test files have been moved to closed and may migrate
back as their licensing is made more explicit.
(Historically we haven't required a C compiler to run the regression tests, and
some platforms of interest don't come with one by default, so in a few cases
the test directory contains some executables checked in.)
(In reply to comment #22)
> The sources for build b08 of OpenJDK 6 have been published
> (http://download.java.net/openjdk/jdk6/) and all the suspect files under the src
> and make trees have been addressed as well as some of the test files. We are
> reviewing all the binary files under the test directory to ensure their
> licensing is made more transparent. In more detail, the binary files under
> make/src/crypto were inadvertently added during a workspace restructuring merge,
> are not needed, and have been removed. The hotspot/agent files are used for a
> debugging facility, the sericability agent. To expedite matters, since these
> files aren't critical functionality, they have been moved to closed for now;
> likewise many of the pkcs11 test files have been moved to closed and may migrate
> back as their licensing is made more explicit.
> (Historically we haven't required a C compiler to run the regression tests, and
> some platforms of interest don't come with one by default, so in a few cases
> the test directory contains some executables checked in.)
I noticed these binaries still exist:
All the rest have been resolved. Thanks for acting quickly.
I have added those binaries to the generate-fedora-script.sh so they are removed
from the openjdk tarball. I will build the updated package into rawhide now.