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. http://fedoraproject.org/wiki/Licensing#head-a32840ab846df2697fa2972a598eb804eefd017e http://fedoraproject.org/wiki/Packaging/Guidelines?highlight=%28Guidelines%29#head-c23c2cd3782be842dc7ab40c35199c07cfbfe347 http://fedoraproject.org/wiki/Packaging/LicensingGuidelines?highlight=%28Guidelines%29#head-5dcaa7704b32aabaddc2e709f328f48eea6c91de
Examples?
http://iced-tea.org/wiki/FrequentlyAskedQuestions 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: https://bugzilla.redhat.com/show_bug.cgi?id=433070 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: http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/java-1.6.0-openjdk/devel/generate-fedora-zip.sh?content-type=text%2Fplain 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) > http://iced-tea.org/wiki/FrequentlyAskedQuestions > > 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 distribution-specific patches. The "with exceptions" is referring to the GNU Classpath linking exception, not non-free software.
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 openjdk/ASSEMBLY_EXCEPTION ...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 http://openjdk.java.net/legal/exception-modules-2007-05-08.html ("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. (later) ... 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: ./openjdk/jdk/src/solaris/native/sun/security/smartcardio/MUSCLE/COPYING Copyright (c) 1999-2003 David Corcoran <corcoran> All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: ... 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: icedtea6-1.0-78e1287fc42757d4c23bb8e7b711e2c91513db58.tar.gz This provides the IcedTea source code. This tarball provides autotools support, non-x86 ports, a plugin, and distribution-specific patches openjdk-6-src-b06-28_feb_2008-fedora.tar.gz This is the rest of the source code that comprises java-1.6.0-openjdk*. This tarball is generated from the upstream source tarball: openjdk-6-src-b06-28_feb_2008.tar.gz 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": http://download.java.net/openjdk/jdk6/ 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 Fedora package.
(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 propagation impossible.
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 policies :-) 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. Thanks,
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 :-(
Hi Alexandre, 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 http://java.sun.com/developer/techDocs/hi/repository/ 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 openjdk/hotspot/agent/src/share/lib/jlfgr-1_0.jar:openjdk/hotspot/agent/src/share/lib/maf-1_0.jar 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 http://mail.openjdk.java.net/pipermail/discuss/2008-March/001106.html > 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: ./openjdk/jdk/test/sun/management/jmxremote/bootstrap/*/launcher ./openjdk/jdk/test/sun/management/windows/revokeall.exe 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.