harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Brittain <ja...@brittainweb.org>
Subject Re: Harmony: project purpose
Date Sun, 08 May 2005 07:44:50 GMT
Stefano Mazzocchi wrote:
> Sam Ruby wrote:
>> Doug Lea wrote:
>>
>>> Re: licensing etc.
>>>
>>> I think the brilliance of Geir's move here is that all of
>>> FSF, Sun, IBM, BEA, etc now have equal motivation to change
>>> their licensing so that they can participate. I hope they all
>>> do.
>>
>> Add the ASF to that list.
>>
>> I firmly believe that we can form an inclusive community in which
>> everybody who is willing to meet each other half was has an opportunity
>> to participate.
> 
> Amen.

This is one of the most important points I've read yet.  Each of these
licenses have one or more clauses that are unacceptable for whatever reason,
and the Apache license is no exception.

My perspective, as neither an ASF member nor an FSF member:

* I'm excited to hear about this project!  I do plan to contribute where I
   can, even if I can only be a small contributor.

* The more open source Java there is, the better, even if we have competing
   projects, and especially if we have projects that use different licenses that
   each are good for their own intended purpose.  Competition is good for us.
   And, why shouldn't we be able to choose the best license for the task at hand,
   and still have good code to use?

* I have been watching the Kaffe and Classpath projects since their inception,
   and wow, that's quite a bit of work they bit off for the sake of free Java.
   Although the licenses don't work for me, I'm proud of them for sticking with
   it.  And, I must congratulate them on being complete enough to run Tomcat.
   This is the first OSS JVM I've ever been able to get Tomcat running on.
   Keep up the exceptional work!
   http://article.gmane.org/gmane.comp.jakarta.tomcat.devel/51624/match=kaffe++tomcat

* Aside from dual-licensing, reimplementation seems to be the only way to have
   the same kind of software available under more than one OSS license.  And,
   I believe the Apache licenses have a different and mutually exclusive purpose
   in life versus the (L)GPL licenses.  Probably few codebases will be
   dual-licensed AL and (L)GPL like the "tri-licensed" Mozilla browser, which the
   FSF describes as the "disjunction of the GPL and the MPL".
   http://www.mozilla.org/MPL/
   Maybe I'm wrong here, but if Kaffe and Classpath were dual-licensed this way,
   wouldn't that be acceptable to all, except for the ASF politics of adopting
   donated code?

* I believe that the AL and GPL have different goals that are mutually exclusive.
   It would sure solve some problems if they could one day be reconciled enough
   to consolidate major OSS projects like this.  It's certainly worth trying.
   But, people have been trying to get these two licenses to be compatible enough
   to collaborate for a long time and it still hasn't happened, so I have serious
   doubts that it happen.

* I have chosen not to contribute to Kaffe nor to Classpath, solely due to
   their licenses.  Yes, I'm aware that Classpath's license is GPL with
   exceptions to make it not GPL anymore.  But, to me, it's either GPL or it's
   not GPL.  If it's not the GPL, I don't understand why the FSF would want to
   help.  The FSF worded the GPL carefully and deliberately to achieve certain
   goals.  Removing the viralness of the GPL undermines restrictions that the FSF
   seems to want in there.  This changes the license significantly.  It's not
   actually the GPL.  It's close, but it's probably more like the LGPL, which
   is also not the license that the Classpath project members chose.  It hurts
   my brain to try to figure out what the terms of the unmodified GPL really
   mean for a Java program, let alone what they mean after special (major)
   exceptions.  And, as for Kaffe's license, I find the GPL's terms unacceptable
   for the Java language and Java runtime because the terms used are more like
   C language constructs that have undefined or multiply defined meanings for
   the Java language or the Java runtime.  I also do not find the GPL as free as
   the AL or BSD-style licenses due mainly to the viralness, which is there for
   reasons that I understand, but in the end it's just unacceptable for the
   Java code that I write and the ways I need/want to use it.

* It sure seems like the about only time the committers of a GPL or LGPL Java
   project spend time seriously considering the terms of their chosen license is
   when they hear about an Apache licensed project with the same goals that is
   getting some resources and attention.  In the absence of the Apache licensed
   project, I've asked about BSD-style relicensing or dual-licensing and it's
   just out of the question (to be clear, I never asked for a BSD licensed Kaffe
   nor Classpath, but other (L)GPL'd projects that will remain unnamed).  I've
   often been told "there's nothing wrong with the (L)GPL, it's plenty free
   enough and we're not changing it".  I've all but given up asking.  But, then
   when enough people give up waiting and asking, and have to have it licensed
   as BSD-style, and form a new project to just reimplement all of it because
   there is no other option, then lots of GPL developers seem more interested in
   discussing collaboration again.  I wish this wasn't a recurring pattern.

* I like the Apache license all except for the attribution terms.  Really, guys,
   do you think everyone would just forget that the ASF existed if the
   attribution terms weren't in the license?  To me it seems like a vanity
   restriction placed on all licensees.  If there's a good reason for it, I
   wish I knew what it was.  It's not a very big deal, but I wish OSS code
   could be free of advertizing.  But, also, hasn't this been one of the
   barriers to GPL compatibility/collaboration since this is a license
   restriction that the GPL doesn't have?

Now, a suggestion for the Harmony project:

- Any Java runtime can only safely implement one version of Java at a time.
   For example, it's either Java 1.3 or it's Java 1.4.  It can't be both.
   Programs that run on the JVM often try to detect which version of Java
   they're running on, and call appropriate methods based on the detected
   version.  If you target Java 1.5 now, by the time you get, say, one fourth
   of the way to having it fully implemented, the latest stable version of
   Java may be Java 2.3 (or something higher like that), and 1.5 won't seem
   important anymore.  If then you try to implement newer versions of some core
   classes to stay at least partially compatible with the latest stable Java,
   then parts of the core will implement v1.5, and parts will implement v2.3,
   and programs will end up being very confused about which version of Java
   they're running on, and will break in random ways.  I noticed this problem
   with Kaffe, and I wanted to mention it here.  Please, in any one binary
   release of Harmony, make sure it attempts to implement exactly one version of
   Java.

Cheers.

-- 
Jason Brittain

This message presents personal opinions which are not necessarily those
of my employer(s).

Mime
View raw message