harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Wielaard <m...@klomp.org>
Subject Re: Harmony: project purpose
Date Sun, 08 May 2005 12:07:21 GMT
Hi,

On Sun, 2005-05-08 at 00:44 -0700, Jason Brittain wrote:
> * 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

Thanks.

> * 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?

The intention of the current GNU Classpath license is to be acceptable
to the Apache community. If it is not, then we are willing to discuss
and eventually change it in a way so that it is.

> * 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 am optimistic. There are currently talks on the highest levels of the
FSF and ASF to get things finally cleared up. It looks like we will have
a breakthrough soon. But it happens when it happens. Till then we will
at least for the projects participating on Harmony make the best of it.

> * 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.

Yes, the FSF and GNU projects like to use pure unadulterate GPL whenever
they can. But that doesn't mean they don't want to compromise when that
is of strategic interest. For GNU Classpath we have adapted the license
two times already to appeal to a wider audience. We are willing to do
that again if necessary.

Dalibor and I had a little discussion session about the GNU community,
the GPL, making compromises and working with other communities a while
ago: http://www.klomp.org/mark/classpath/CommunityGPLCompromise/
As you can see one of the participants was Geir. That is one of the
reasons we are now talking about Harmony.

>    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.

We all make different compromises. And we all want to do the best for
our respective GNU or Apache communities. That is something we have to
respect. So I am sure we won't cooperate on everything. But I do hope we
will cooperate on most things and make the results usable to both the
Apache and the GNU worlds.

> * 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.

We do feel the same pain "on the other side". Often the first reaction
of someone pointing out a Apache licensed code base is to say "O, no!
That would be nice to use, but I am sure if we asked to distribute under
a acceptable license they get mad. Lets not have a flameware. Lets not
ask. Lets start our own thing." That is sad, but it happens. And
sometimes it happens for good technical reasons. But often it happens
because of some legal technicality. It would indeed be great if that
could be solved not just in project Harmony, but also on a bigger
FSF/ASF scale.

> * 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?

Yes it was with the Apache License 1.1. This part has been solved by
rewording it a bit so that it is technically GPL compatible in the 2.0
version. The only remaining difficulty with the 2.0 version is the
precise wording of the patent retaliation clause. There were some other
misunderstandings which have been worked out already.

> 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.

Note that this is the reason there is no GNU Classpath 1.0 release yet.
We don't feel that it is a complete free replacement for the proprietary
core class libraries just yet. The coverage is somewhere between 1.1 and
1.5, with some packages better then their proprietary counterparts,
where others have just been started. Kaffe actually keeps a list of the
progress they are making with the integrated effort:
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-kaffe.html
The problem here has always been whether or not we should just halt
development and just forbid people to work on the parts they would
really want to improve (maybe just because their application uses those
parts, but not others). But that is just not how cooperative distributed
development works. We are all volunteers and rejecting work that is
technically good and useful is just not what we do. We could create
different branches for work on 1.1, 1.2, 1.3, 1.4 and 1.5 work
simultaniously. But this is a lot of extra work and maintanance for
which we don't have the voluteers atm. We do have a separate branch for
the new generics work in GNU Classpath though. We do have a volunteer
that manages that branch. So we could certainly use someone that just
made a GNU Classpath 1.1, 1.2, 1.3 and 1.4 'cuts'. Containing just those
parts that could be considered part of the proprietary counterpart of
the JDK. That is real work though. So we would need really dedicated
volunteers that really can do that work of cutting up the unified
release. We also don't want to see lots and lots of shattered releases
that are all not really done. But there is a lot of important other work
to do that might be more urgent to get done. Just focussing on getting
full 1.4 and 1.5 coverage will certainly be multiple person-months of
work.

Cheers,

Mark

-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/

Mime
View raw message