harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: Some questions on the proposal
Date Mon, 09 May 2005 18:51:21 GMT
Sven de Marothy wrote:
> On Mon, 2005-05-09 at 06:47 -0400, Geir Magnusson Jr. wrote:
>>I think the biggest barriers are various licensing issues, the fact  
>>that there isn't a "full stack project", and completeness.
> Well, the general issues of FSF vs ASF licensing if of course a concern
> to everybody. But with that said, I don't think the current Classpath
> license is an issue. As I said, there are VMs of all kinds using GNU
> Classpath. Even proprietary ones.
> The lack of a 'full stack project' isn't really a concern of mine. It's
> a software-bundling issue, not a programming one. But it's worth
> pointing out that GCJ *does* intend to have a full Java stack. 
> Compiler (native and bytecode), VM, jar utility, javadoc, etc.

For what it's worth, Kaffe does have the full-stack thing too, and has 
been having it as far as I can remember.[1] Otoh, Gcj's integration of 
everything in jpackage and fedora core is awesome, really.

The latest Kaffe release, for example, comes beside the VM, with jar, 
javap, a javac wrapper, javadoc, javah, rmic, rmiregistry, native2ascii 
and serialver utilities, most of which come from the very nice GNU 
Classpath tools project.

Thanks to increasing cooperation between Kaffe and Gcj developers, Kaffe 
already includes some components from gcj (with more to come). We have 
in a pretty straightforward way begun a harmonization effort in the GNU 
Classpath runtime world a while ago, which will hopefully lead to nice 
component interfaces that allow us to more easily reuse parts of runtimes.

Such a thing could also open up opportunities for runtime developers 
that were so far shy of collaborating with us to integrate components 
from GNU Classpath runtimes in their offerings, or vice versa, given a 
workable middle ground on the licensing and design of such interfaces 
and/or components.

Harmony sounds like a very nice place to do that, to provide the 
concrete case for ASF and FSF to collaborate more closely, and to bring 
people with a broader set of backgrounds and interests together on 
aligned goals, be they architecture, design or actual implementations of 
VMs, components and libraries.

Having the ASF participate in all that, either through creating an own 
runtime, or by adopting or joining forces with the existing projects 
like gcj, IKVM, SableVM, JikesRVM, JamVM, Cacao, or even Kaffe would be 
a great thing for everyone, I believe. From my experience with 
co-maintaining Kaffe, I'd heavily argue for collaborating with everyone 
on as much as possible, and reusing existing code, rather than repeating 
the mistakes that were made by Kaffe and gcj in the early days, when 
dinosaurs walked the earth.

As an ASF project, Harmony can provide an environment for collaboration 
that is more comfortable to people that so far have either not heard of 
efforts like Kaffe or gcj, or ignored them for various reasons.

> Well, none of the other free JVMs out there intend to be incompatible.
> As Mark pointed out, Dalibor/Kaffe is in the process of trying to work
> something out regarding the TCK. I guess it depends on what you mean by
> complete and tested.

Kaffe releases are also regularly tested against the free software Mauve 
test suite, and the latest CVS head is undergoing a daily testing 
routine[1] on the Apache Gump, thanks to generous contributions from 
some wonderful people in the Apache community. That effort has lead to a 
number of issues in Kaffe and Classpath being detected and fixed, by 
some very nice people on our side, too, and helped improve the quality 
of some the projects being tested as well.

On a side note, the 'working out something about the TCK' part is so far 
working, and seems to be going nicely forward. There is quite a bit of 
good will on the side of the copyright holders of the TCK to remove 
barriers to its effective use, afaict.

> Or is the goal to have everything under an Apache v2 license, with no
> compromises? 
> (Stefano said that there is no intention to be incompatible, wheras
> Mladen said that the primary intention is to be ASL v2.)

I believe that those members of the Apache community that had a chance 
to collaborate/discuss/work with the members of GNU Classpath community 
have a good understanding of the size of the tasks involved, and what is 
needed to fullfil them.

That being said, reusing the nice work done by the ASF on the APR for 
the low level portability work to platforms outside the POSIX realm, for 
example, would sound pretty attractive for Kaffe, for example, as soon 
as the ASL2/GPL2 incompatibilty is fixed. While Kaffe currently has 
threading implementations over posix, win32, oskit and beos, for 
example, being able to enhance those implementations with a commonly 
maintained, liberally and GPL-compatibly licensed layer would be pretty 
nice and useful.

In parctice, a good way to meet more of the Classpath developers is to 
join the IRC channel #classpath on irc.freenode.org. The kaffe 
developers are on #kaffe on the same channel, and the gcj team is on 
#gcj on the irc.oftc.net server. Beware, though, the talk on #kaffe and 
#classpath is pretty blunt at times, as Simon Phipps found out. But he 
has a strong skin, and we are all huggable hackers, afaict. In 
particular in combination with nice food and beverages. :)

>>It's clear we're all not going to see eye-to-eye on license  
>>philosophy.  I'm hoping that we can find ways to work together where  
>>those differences don't get in the way of doing something productive.
> Classpath is a GNU project, but it is NOT under the GPL. It's GPL
> +exception, which is a far more liberal license than the GPL, or LGPL
> even. I suggest everyone here read the actual GPL+exception license and
> understand that the differences are a lot smaller than they probably
> thought. 

The concept of using the GPL with a suitable linking exception is 
something that has been used in core toolchain components and libraries, 
like libgcc and libg++, that have been used to develop both free and 
non-free software in C and C++ for the last 10 years at least on dozens 
of platforms.

In fact, afaik all of the non-GPLd software in existance written in the 
C and C++ programming languages for the GNU/Linux platform managed to 
avoid being involuntarily 'assimilated by the GPL collective' despite 
depending on code that was licensed under the GPL with appropriate 
exceptions. :)

dalibor topic

[1] I can remeber that since about 2000, at least.

[2] http://brutus.apache.org/gump/kaffe/buildLog.html

View raw message