The problem first came
in February: the Red Hat Directory Server developers would like to
include the Java Security Services module in the Fedora distribution. The
code, it seems, is free, but there is still a problem: the Java virtual
machine requires that all Java Cryptography Extension providers (of which
JSS is one) to be signed with a Sun-approved key. If an application tries
to use a JCE module which lacks the requisite signature, the whole thing
comes crashing down - an experience which probably differs from what the
user had in mind. In practice, this limitation means that users either use
the signed version obtained from Sun, or do not use JSS at all.
Warren Togami recently posted a couple of
possibilities for how Fedora might be able to ship JSS. They were:
- The Fedora team builds the JSS module, then compares it to the
Sun-signed version. Assuming they match, Fedora has proved that it
can rebuild the software. So the project can declare Mission
Accomplished, dump the module it just built, and ship Sun's version.
A variation on this approach suggested later on involved having Red
Hat obtain an approved key and sign the modules that Fedora would
distribute; in this way, Fedora could add its own modifications.
- Fedora ships an unsigned version of JSS. Applications would then have
to be recoded to load the module in a way which shorts out the
signature check. Any applications not fixed up in this way would
The first option, at first blush, would appear to work. Fedora would be
able to build its own module and ship the source. It falls down, however,
as soon as a Fedora user tries to make a change; that user will not be able
to rebuild the patched module in a way that will actually work. Derivative
distributions would run into the same problem. As a result, it would
appear that Fedora stopped considering this option fairly quickly.
Not signing the module at all has obvious problems as well. It seems
likely that many potential JSS users have their own applications in mind.
If those applications do not work, they will rightly see Fedora as not
having support for the features they are looking for.
Other alternatives have been considered; one is to emphasize the use of the
GCJ compiler and try to steer users away from Sun's virtual machine. That
approach would certainly offer a higher degree of freedom, at the cost of
not really providing what many Java users appear to want. Additionally,
not everybody is convinced that GCJ has achieved the level of maturity that
many users would expect.
In an interesting way, this is really just the Tivo problem under a
different guise. Locked-down hardware refuses to run software which lacks
the expected signatures. In this case, we have virtual hardware, in the
form of the Java virtual machine, which is doing the same thing. The
result is the same as well: the software is available and nominally free,
but the users of that software cannot create their own versions and expect
to be able to run them.
If Sun follows through on its desire to move to GPLv3, and if that license
retains its requirement that any needed signing keys be distributed with
the source, Sun may find itself in an interesting position. It is hard to
see how the current policy would be compliant with the new GPL's
The upcoming GPL Java release would appear to be the best hope for
distributors trying to deal with this situation. Once the code is free,
distributors can patch it to make the whole of Java distributable as free
software. So the real solution to shipping JSS with a distribution which
insists on freedom would appear to be to wait for a free Java.
to post comments)