harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Wielaard <m...@klomp.org>
Subject Re: The Unofficial "Harmony, Licensing, the Universe and everything" FAQ
Date Fri, 18 Nov 2005 15:50:28 GMT
Hi Tim,

On Fri, 2005-11-18 at 08:53 +0000, Tim Ellison wrote:
> ...and there are other bone fide open source projects that are important
> to Harmony under any number of licenses.  Obvious examples being in the
> VM-space such as Kaffe (GPL) and Jikes (IBM public license).  I believe
> we should play nicely with all of them.

Right! That is also what made GNU Classpath big and strong. Be friends
with everybody :)

> I fail to see how anything other than full license reciprocity will work
> in practice.  Code that can only be passed in one 'direction' (Classpath
> -> Harmony or Harmony -> Classpath) will be forked as soon as the code
> is enhanced or patched by the recipient unless those contributions are
> also multi-licensed.  At best it will be a book-keeping nightmare.

I wouldn't be that afraid. Of course every user has the right to fork
any code they want. But in practice you have lost when you exercise that
right. Then you are on your own. It really only happens when either it
is something you just have to do now and the code just isn't precisely
perfect at this time. (You make a fork, make your own thing and then
contribute that back so you can pick it up next time. This is how lots
of Free Software works. Almost every distribution has their own small
forks of packages, but normally those forks are just temporarily and
things flow back.) Or it happens when communication has completely
broken down. But then you want it to fork. No need to keep on the same
code base and yell at each other all day. It sadly does happen of
course. But in practice when you have a healthy community around your
projects things always work out in the end. Nobody wants to fork, but
everybody wants to have the right to fork just in case.

In a way all these existing projects (classpath, kaffe, gcj, cacao,
jamvm, ikvm, sablevm, etc) are just forks of each other (or mergers of
other projects). And they do even compete! But when you have enough
dedicated enthusiastic people and technical direction around a project
forks and re-merges are just part of the development process. We are
constantly seeing new forks popup and then later merge stuff back in. A
healthy diverse ecosystem is the best cure for fork-angst.

Bookkeeping is an issue. But it is an issue we are dealing with already
anyway. In the end it is just another checkbox.

> It sounds to me like Leo, Cliff, et al have a good handle on the issues,
> and they are doing the right thing by working them out for the generic case.

Yes, I am happy about that. I hope we can show that it can work in
practice with harmony already.



Escape the Java Trap with GNU Classpath!

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

View raw message