Javier Fdz-Sanguino Pen~a writes:
> I'm attaching the latest revision I've had time to make to the
> Debian/JAVA faq.. I appreciate new contributions, of course,
It might be worth to add some explicit comments on the SCSL,
and why free software has a problem with Java2. Here's a rough
draft. Paul Fisher, Tim Wilkinson and others might have better
comments to share.
b.
x. Java Licensing
x.x. What is the SCSL?
The SCSL is the "Sun Community Software License" that can
be found <here>. It is not compatible with Open Source for
several reasons, and agreeing to this license (e.g. by
downloading source covered by the SCSL) will make it
impossible for you to contribute to free software
clean-room implementations. According to Sun, this includes
using documentation and API specifications available only
under SCSL.
To quote one open source developer, the SCSL is "about as
free as the former Soviet Union".
x.x. Why is (some) free software not implementing Java2?
Sun has made public statements in connection with their legal
strategy in the Sun-Microsoft lawsuit that indicate that the
company considers the published specifications of Java2 to be
intellectual property that can not legally be used by persons
involved in efforts to create Java2 clean-room implementations.
For this reason, some open source projects have decided to not
implement Java2 any time soon. One example is Kaffe. Some
projects (like the Japhar/Classpath project) have decided to
challenge Sun's legal position and are going ahead with Java2.
Here's alos a pet peeve of mine:
x.x. GPL or LGPL?
Java uses dynamic linking at runtime. Using the reflection
API and class loading, the linking can be completely data
driven, specifying classes and methods by name. This moves
the legal issues of using GPL'ed Java code into the user's
hands, as a violation of the GPL can not be proven from the
executable itself. Unlike plugins, Java classes do not even
have to have a specific structure to be used in such ways.
By using native methods and selecting DLL's at runtime,
this problem might also affect native code.
Example: a GPL'ed Java dependency checker using the
reflection API. Java's runtime linkage, in particular the
reflection API, blurrs the lines between code and data
even more than e.g. native plugins.
If you want to write Java code that can be used without
the user having to worry about licensing issues, consider
using the Lesser GPL (LPGL). If you want to avoid seeing
your classes and packages being used by non-free software,
put them under the GPL.
