harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Code contribution to harmony
Date Wed, 09 Nov 2005 16:56:01 GMT
Mark Wielaard wrote:
> Hi,
> On Tue, 2005-11-08 at 16:13 +0000, Stefano Mazzocchi wrote:
>>Tim Ellison wrote:
>>>I'm delighted to be able to make a code contribution to the Harmony
>>>project on behalf of IBM.
>>Let's the harmonization process begin :-)
> Right! I have been thinking on how to move forward with this. And I am
> excited to see some core class library code since that is where my
> expertise is. Obviously we should be able to extend this easily with
> parts of the GNU Classpath library like awt, beans, corba, crypto,
> swing, sql, most of javax, imageio, naming, etc and the 1.5 additions we
> have plus the generic classes from the classpath-generics branch.

Great.  That will be a good opportunity to work together on a class
library componentization story too!

> At the
> same time we can merge the kernel classes to get the best of both
> implementations. But it seems we still have the original roadblock to
> harmony cooperation, the incompatible licenses. Since this contribution
> is marked as ASLv2 which is incompatible with GPLv2 so we won't be able
> to share this easily. So lets try to get that away now.
> Would IBM be willing to assign this code to the FSF for inclusion in GNU
> Classpath or contribute it under a GPL-compatible license like MIT/X,
> W3C, etc. so that it can be mixed and merged with the GNU Classpath core
> library and used in larger GPL-compatible works like gcj, kaffe, etc?

I agree that getting a resolution to the community/licensing differences
would be fantastic.  I don't see that happening quickly, and I don't
want to see the success or failure of a development project gated upon
it.  IMHO resolving license issues is a board-level objective, not a
J2SE-project objective.  We can hack code and live in hope :-)

> That would be really fun. I remember when I joined the GNU Classpath
> group and we merged the libgcj and classpath code bases. That was really
> a good way to lift up both projects since you can compare ideas and code
> to create something that is bigger then the original things. And you
> will always learn things from trying to merge two similar but slightly
> different code bases. I am looking forward to going through each of the
> core packages to see which implementation is best if we can get the this
> license issue out of the way.

I think we should actively seek out opportunities for collaboration.
There is every reason to ensure that we don't end up with gratuitious
architectural differences that prevent users combining code from GNU
Classpath and Harmony.  If it turns out that interoperability requires
releasing some subset of code under a different license then that is a
discussion to be had between the projects (independently of which way
the code is flowing).  I don't think that point has come.


Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message