harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Green <gr...@redhat.com>
Subject Re: Problems/Issues/Questions
Date Wed, 11 May 2005 00:05:21 GMT
On Tue, 2005-05-10 at 14:29 -0400, Davanum Srinivas wrote:
> - Any ASF contributor if they want to make changes to CLASSPATH, will 
>   have to adhere to the clean room clauses
>   (http://www.gnu.org/software/classpath/faq/faq.html#faq3_2)

I think this is worth pushing on a little if there is some interest.
AFAIK, this was just a policy to minimize and risk of being called
thieves, and is not central to the FSF's position on Free Software.
Perhaps they may be convinced to tweak this policy a little if it makes

For example, Sun's Java Research License FAQ reads:

"18. Does the JRL prevent you from being able to create an independent
implementation of J2SE?

The JRL is not a tainting license, and includes an express "residual
knowledge" clause. Under the JRL, merely looking at Sun's code does not
prevent you from being able to create your own independent
implementation of J2SE, and in any event, you can terminate the JRL at
any time for any reason. So, yes, you can look at Sun source code and
then later on go and work on an open-source J2SE implementation."

Somebody (mjw?) should run this past FSF legal.

> Issues and possible solutions:
> - Any source code or Jars under GPL cannot be checked into ASF CVS. 
>   One possibility is for FSF folks to publish maven snapshots of 
>   the daily build.

Just out of curiosity, why is this?  Would this apply to code licensed
under the current GNU Classpath license?

> - Need to check if the classpath jars can be part of a install package 
>   from ASF Legal folks. Problem is we don't want users do download two 
>   things from two places to get a working JDK/JRE. One solution is the 
>   shared classpath instance model where many VM's share the same 
>   classpath jar. this may reduce the problem, but not an ideal solution.

Having to go two places means something is busted.  Hopefully this won't
be a problem.  I would be surprised if it was. 

> - Classpath was once LGPL, but ASF/FSF still needs to resolve issues
>   around it, so even that may not be open for the short-term.

What does the LGPL have to do with GNU Classpath, and this effort now?

> - It may or may not be very difficult to add/change the Exception clause
>   to make it easier to develop/ship/use code. Need ASF legal and FSF 
>   legal folks to chime in. Ideally if we change the exception clause to
>   convey the information in say the MIT license 
>   (http://www.opensource.org/licenses/mit-license.php). That would make
>   it REAL easy. But i know it's probably too much to ask for :) Note 
>   that the two problems above will vanish if it happens.

I can't speak for the FSF (or Red Hat) but as I see it, the problem with
the MIT license is that it doesn't preserve the central freedoms of the
code (as defined by the FSF).  Somebody could modify it and not share
changes.   A specific example of something I don't want to see is a
proprietary J2ME fork of our work.  The point of the protective
properties of the GNU Classpath license is to prevent nonsense like
this.  If somebody is going to make a J2ME fork of our hard work then we
should all benefit from this effort (this really speaks to the main
split between the Free Software and Open Source movements.  The Free
Software movement focuses on the social benefits of having a community
around code, whereas the Open Source movement focuses on the practical

> Question from the point of view of a potential user of Harmony:

I think it's important to distinguish between those "users" running
Harmony and those distributing Harmony.  The point of the GNU Free
Software licenses is that you are free to run and modify code any way
you like, with few (if any?) restrictions.  The user in your example
below is really a distributor of Harmony.  This is where the protective
aspects of the GNU licenses steps in.

> - Same question i asked for Geronimo...A specific product in my company
> needs Java's, currently we ship JVM from [SUNW/IBM] by default. This 
> product is NOT positioned as a JVM/JRE engine and NO claims of Java 
> compliance is made. We want use Harmony+Classpath as the default JVM for 
> our product. We will comply with ALL requirements of ASL 2.0 under 
> which Harmony is licensed. We DON'T want to talk to SUN/ASF/FSF or pay 
> them any money (we don't pay SUNW now!!), we DON'T want to run the TCK's 
> before we ship the product. We just want to use Harmony as-is BUT we'd 
> like to issue some patches to our customers if necessary for product 
> support. What are my additional obligations because of Classpath 
> which is the default library in Harmony? (ones that are not applicable 
> to  other ASF projects)

In the end it boils down to the following: source must follow binaries.
If you distribute binaries of GNU Classpath code, then source must also
be made available to that end user. 

One interpretation of this is that if you distribute a "Harmony JRE"
binary release unmodified from one produced and archived by the ASF,
then this really shouldn't be much of an extra burden.

BTW, I'll point out that in the case of the JDK, my understanding is
that library source availability is an _expectation_ from current
commercial JRE users (bundled in something like src.zip, which is often
grokked by IDE tools).

Just a couple of other random comments:

Somebody recently asked me if what we really need is an LGPL specific to
Java.  The danger here, as I see it, is that there will be a temptation
to draft this license in terms of what you can do with bytecode and jar
files.   But there are other ways to build and distribute java code (for
instance, as native executables as produced by the gcj compiler).

Also, the point of the current license was to eliminate various
requirements in the LGPL (like the clause requiring that end users be
able to relink code after replacing the LGPL'd component).

Somebody on IRC recently distinguished between between the MIT and GNU
licenses by saying that GNU licenses force you to "give your changes
back".  This isn't quite true.  It's more accurate to say that the GNU
licenses ask you to give your changes "forward".  Some software licenses
require that you send mods back to the original authors, but the GNU
licenses don't say this.  The GNU licenses say that you are free not to
send your changes back to the original authors.  And if you make changes
to GNU code for your own internal use, then you're free to do that
without sending any changes anywhere, or even telling anybody about


View raw message