harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: Releationship to GNU Classpath?
Date Tue, 06 Jun 2006 16:22:04 GMT
On Tue, Jun 06, 2006 at 04:52:14PM +0200, David Tanzer wrote:
> Hi!
> 
> Cool, one of the easy questions again ;)
> 
> Ok, first of all, Mark Wielaard has written an interesting article on 
> LWN about the status of GNU Classpath which also discusses the 
> relationship to HY from his point of view:
> 
> http://lwn.net/Articles/184967/
> 
> Of course Dalibor's article is great too, but this one is much newer
> and really interesting to read.
> 
> I talked to some Classpath people at FOSDEM 06 (http://fosdem.org) about 
> this because I am too interested in not burning all the bridges. While some
> of them are quite disappointed about how things are now others don't seem 
> to have a problem with us or how we handle this situation. I'm not sure if
> i should write their names here, maybe the people I'm talking about could
> stand up (you know who you are ;) ).

Standing. :)

> 
> More comments inline...
> 
> On Tue, 2006-06-06 at 14:03 +0000, theUser BL wrote:
> [Snip]
> > And here are two blog-entries:
> > http://metastatic.org/text/Concern/2006/05/30/harmony/
> > http://kennke.org/cgi-bin/blosxom/2006/05/30#harmony-jfc
> 
> Well, that's what I think about the comments from Roman and Casey
> (I won't repeat it here):
> 
> http://davidtanzer.net/?q=node/42

Whatever works best for Harmony's contributors is what's best for it.

> 
> [Snip]
> > Then there existing developer, who writes code for Harmony and others who 
> > writes code for GNU Classpath. Thats duplicated work. And if both groups 
> > would working on _one_ class-implementation together, they could be faster 
> > then, if both groups would reinvent the wheel itself.
> 
> Well, competing implementations is not a completely negative thing. 
> Diversity is a chance and not a problem, especially in free software
> projects. Look for example at Gnome and KDE which now exist next to
> each other for years, and both are still alive.

Full ACK. I'd say that Harmony & Classpath are actually conceptually
much closer than Gnome/KDE and could collaborate quote efficiently
eventually, since they need to implement the same specs. Otoh, there is
a lot of political value in having a separate J2SE lever in the JCP for
some J2SE vendors, I assume. :)

> > Is the reason the different licenses?
> 
> There was lots of discussion about these things on harmony-dev during
> the time when I still wrote the mailing list summaries, they are online
> here:
> 
> http://davidtanzer.net/?q=taxonomy/term/5
> 
> But basically: Yes, one of the reasons is the different license.

Structurally, the ASF can not enter a licensing compromise, due to
the way the "contributors license code to ASF under the ASL2.0 only"
system works. Fortunately, the FSF is more flexible, due to to the way
FSF's copyright assignment system works, and will include improvements
in the language of the the GPLv3 that address concerns expressed by
memebers of the ASF, and will explicitely allow for patent-retaliation
language like ASLv2's to be GPLv3 compatible.

What happens after that will be up to the ASF, and is hard to predict.

> [Snip]
> > Or could it be possible, that GNU Classpath developer could also publish its 
> > code under the ASL2 ?
> > Or that Harmony developer could also publish its code under the GNU 
> > Classpath-license?
> 
> Yes and yes, But: There are some issues with dual licensing (Dalibor
> mentioned one in his comment on OSNews). For example, here at the ASF
> the copyright holders of the code are the developers themselves, not
> the ASF. This means I could write some code, contribute it to HY under
> AL2 and also license it under... say... BSD license. But when someone
> else changes the code in HY the changes are only licensed under AL2,
> so all contributors would have to dual-license all the code they write,
> and I don't think that's desired.

That's easily resolved if contributors wish to do it. You use either FSF
or ASF as upstream, and synchronize changes by encouraging people to
collaborate, rather than working in their own walled off gardens.
That has worked really well in GNU Classpath so far, I don't see why it
wouldn't work here.

> [Snip]
> > As I have said before: For me it looks, that two projects doing the same 
> > thing with the same goal, but without interaction to each other.
> 
> Yes, kind of. Maybe this will change again in the future, maybe not.
> But I'm pretty sure that both projects (or all the projects if you also 
> count the VMs that use Gnu Classpath) can exist next to each other.

Sure. They'll be able to exist even with the (eventual) arrival of the
third independant implementation, from Sun. They all target different
audiences, basically.

As much as I appreciate people trying to get yet another discussion going, 
it's all already said in the archives, so there is little need to keep 
bringing up the subject on either GNU Classpath or Harmony lists. :)

The story of opening J2EE shows that one can attract
strategic contributions that would not happen otherwise if one creates 
a single project with a single goal and a single license. 

As long as Harmony keeps shaking out code that'd be left closed away 
otherwise, I think it's doing fine. Having two,three implementations to work
with is much less of a problem than having none.

cheers,
dalibor topic

> Cheers,
> David Tanzer.
> 
> > 
> > 
> > Greatings
> > theuserbl
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > 
> -- 
> David Tanzer, Haghofstrasse 29, 3352 St. Peter / Au, Austria
> http://davidtanzer.net - http://dev.guglhupf.net - http://guglhupf.net



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message