[kaffe] Relicensing the Verifier, and Turning it On

[Dalibor Topic]

Hi Rob,

rob at kaffe.org wrote:
> Hi all,
> 
> [The first part of this email is about licensing stuff, the last bit is
> more interesting ;)]

Yay, licensing, everyone's favorite ;(

> There are a couple parties interested in using bits of Kaffe's verifier,
> but the GPL is not compatible with their projects' licenses.  In the past,
> I released an older version (of pass 3) for Chris Gray's WankaVM under the
> MIT license, because I had done all of the development and so had the
> copyright.  I would like to do a similar thing with the current
> development snapshot, and would certainly like to release it under
> multiple licenses when I'm pretty content that it's production-ready.

Sounds cool. You will have to make sure that your non-GPLd version is a 
clearly separated work from the rest of kaffe, i.e. doesn't depend on 
other, GPLd code in kaffe, but I assume that you already know that. It'd 
be pointless for Wonka to depend on kaffe's internal data structures 
anyway ;)

> I believe that Helmer, Guilhem, and Dalibor have all done various things
> to the verifier's code since my last relicensing, which means, I believe,
> that I need their permission this time around.  I went through the
> ChangeLogs and didn't find anyone else mentioned, but I wanted to make
> sure on this list, as it's possible that I missed a small contribution
> (the ChangeLogs are mighty long these days).

I think you missed a few :) I used less and searched for 'verif' string 
in ChangeLog and ChangeLog.[5-9]. I found:

2004-04-18  Nektarios Papadopoulos <npapadop at inaccessnetworks.com>

         * kaffe/kaffevm/classMethod.c,
	[snip]
         kaffe/kaffevm/verify.c,
	[snip]
         Fixed various warnings about unused parameters and
         signedness of variables.

2004-04-05  Nektarios K. Papadopoulos <npapadop at inaccessnetworks.com>

         * kaffe/kaffevm/{classMethod,exception,jni,soft,stackTrace,
           support,verify,{intrp,jit,jit3}/machine}.c,
           kaffe/kaffevm/support.h: Fix several warnings.

2004-03-26  Adam Heath <doogie at debian.org>

         * kaffe/kaffeh/main.c,
	[snip]
         kaffe/kaffevm/verify-debug.h,
	[snip]
         Fixed tons of compiler warnings.

2004-03-08  Timothy S. Stack <stack at cs.utah.edu>
	[snip]
         * kaffe/kaffevm/classMethod.c, kaffe/kaffevm/code.c,
         kaffe/kaffevm/verify.c:
         More constant pool and class file checking.
	[snip]

2003-08-31  Timothy S. Stack <stack at cs.utah.edu>

	[snip]
         * kaffe/kaffevm/verify.c:
         Add checks for fields.  Fix error when computing the next PC for a
         WIDE instruction.
	[snip]

2003-05-24 Tim Stack <stack at cs.utah.edu>

	[snip]
         * kaffe/kaffevm/verify.c:
         Tweak to fix compilation when debugging is turned on.
	[snip]

> Anyway, I don't want to pressure anyone into doing anything contrary to
> their convictions.  If you have contributed, and you feel strongly about
> the GPL and so don't want to give permission to relicense, then I'm
> content to continue working on Kaffe's verifier and not relicense it.
> However, I think it ultimately benefits more people if I have the ability
> to give what is mostly my work to whomever will find it useful.

First of all, thanks for doing all that great work, and getting the 
ghastly verifier written :) No small feat, so I can understand why 
people are interested in getting access to the code base on more liberal 
terms, rather then rewriting another verifier from scratch.

I like the GPL quite a bit, myself. With that out of the way, I'd be 
willing to relicense my own changes under a license that made sure that 
I'd be still able to re-merge improvements back into kaffe. While GPL 
guarantees that, that's unfortunately not helpful for Wonka. So, how 
about GPL+linking exception, a la GNU Classpath? Would that be ok for Chris?

> In other news, Helmer created a patch that seems to fix the Circular
> Linking Bug in the class loader I reported earlier (Thanks!).  I've been
> really busy and haven't had much time to play with it, but when the
> patched kaffe is run with -verifyremote as an option I am able to run lots
> of big programs.  As soon as things like Eclipse, Ant, etc., work with
> -verifyremote (just a couple small bugs to iron out, nothing really major
> has been popping up), I suggest that we turn verification on by default in
> the CVS head.  Objections?

No, go ahead. I'd like to have the verifier on by default as soon as you 
feel confident with it, as then it would make sense to start merging in 
gcjwebplugin as well, making kaffe an attractive option for debian & 
others who can't ship non-free runtimes.

> Also, I was wondering how close we are to officially releasing 1.1.5, and
> thus how much time I have to debug so that, potentially, 1.1.5 would have
> verification on be default.  I'm happy to wait for 1.1.6 to do that; I
> mostly just wanted people's opinions.

Jim Pick ultimately decides when we cut the release. He let the CVS go 
open again after cutting the 1.1.5 brach last time around, and I think 
it had a quite positive effect on getting a lot of bugs squished and 
ports improved. While kaffe 1.1.5 has slipped by a fair chunk of time, I 
think it will be a good release, once it comes out and if the CVS head 
proves to be worth pulling over to the 1.1.5 branch. 'Once it comes out' 
usually happens after a two week freeze, so I'd say that you've got at 
least two weeks, as no re-freeze has been announced yet ;) [1]

Given the amount of cool hacking taking place atm, you probably have 
till the end of month ;) That should give me enough time to resync again 
with Classpath, JAXP, inetlib, merge in swing & awt from cp, and 
hopefully merge in crypto & jessie fully, as well as try to get 
gcjwebplugin merged in. Fun, fun, fun :)

cheers,
dalibor topic

[1] Also labelled 'the duke nukem' of kaffe releases on #classpath :)