Latest version of the Debian/JAVA FAQ

[Bernd Kreimeier <bk@lokigames.com>]

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.