Re: Classpath and Kaffe
On Jun 28, 2000, "Nic Ferrier" <[EMAIL PROTECTED]> wrote:
> I'm confused about TranV's position now... the Kaffe web site says
> that no code contributed to Kaffe will be used by TransV. I don't see
> why not... I certainly wouldn't have a problem with it - they're
> supporting the GPL and I applaud that and want to help.
They must be able to license the code to their customers under
different licenses. Same issue with libgcj: Cygnus (now Red Hat) took
a different approach of requiring copyright assignments, just like
FSF, in order to integrate changes from network contributors.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Classpath and Kaffe
>>> <[EMAIL PROTECTED]> 28-Jun-00 9:42:01 PM >>> >The Classpath GPL+exception is actually a step backwards >as far as Kaffe compatibility goes. It is even more liberal than >the LGPL. Yes. Licences are the problem which seems silly doesn't it. It's all done under the aegis of GNU so why not have a bit more co-operation? It seems that the answer is in copyright. If I write a bit of code and keep the copyright I can licence it under 2 different licences: I could contribute it to Kaffe and Classpath. The one I contributed to Classpath would have to then be assigned to the FSF which might break the contract - I'm not sure. This works as long as there are only small changes... for example my HttpURLConnection could (if both parties want it) go into both. Wholesale changes wouldn't work because of the liceneces. Unless Transvritual could be agreed to combine effort with Classpath and then Classpath could use the GPL. But I'm not suggesting that - I'm just saying on a practical day to day level we ought to work together a bit more (group hug anyone?) >I doubt Transvirtual would want their code subject to >that license where it would be very easy to incorporate >it into proprietary programs without payment. I'm confused about TranV's position now... the Kaffe web site says that no code contributed to Kaffe will be used by TransV. I don't see why not... I certainly wouldn't have a problem with it - they're supporting the GPL and I applaud that and want to help. Nic
Re: Classpath and Kaffe
Stuart Ballard ([EMAIL PROTECTED]) wrote: > 4) Classpath is multi-VM, Kaffe's libraries are (of course) designed for > Kaffe only. Classpath doesn't yet have a Kaffe port, although > periodically people suggest one and it's generally regarded as a good > idea if someone would actually do it. I don't think it's entirely fair to say that Kaffe's libraries are designed for Kaffe only. The vast bulk of the code is fairly generic and the Kaffe libs could probably be ported to another VM about as easy as the Classpath ones. The Classpath GPL+exception is actually a step backwards as far as Kaffe compatibility goes. It is even more liberal than the LGPL. I doubt Transvirtual would want their code subject to that license where it would be very easy to incorporate it into proprietary programs without payment. However, I'm guessing that if some part of the library code was built to be shared between the two, TVT wouldn't be dead set against the more liberal license. That's only my guess though and I'm sure it would depend on the circumstances. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
Re: Classpath and Kaffe
Nic Ferrier wrote: > > Absoluely! I'm working on an HttpURLConnection that does pipelining, > I don't know Classpath already has an implementation but if it hasn't > I would like to donate the same class to both projects. > > It seems mad to me to have any duplication of effort within the free > software community, we have enough problems as it is. I've always felt this about the two projects. The last time I was involved with a discussion of the issue was a long long time ago on the Classpath list, and what seemed to happen was a bit of behind-the-scenes negotiation and failure to come to any agreement. I'd rather see this sort of discussion out in the open, at any rate. The issues as I see it: 1) Merging code is hard in general - not necessarily a big problem; classpath is dealing with it already with libgcj (the merge is currently in progress so now might be a good time to get in... after all, it'd be better to be merging three files at one time than to merge two, and THEN have to go back and add another). 2) Kaffe is GPL, Classpath is GPL+Exception (making it approximately equivalent to the LGPL, except with some differences important to Cygnus as embedded users). Classpath's AWT, which I believe is not yet functional, is un-modified (L?)GPL (for the express purpose of not interfering with TransVirtual's business model, if I remember rightly). This means that Classpath code can be imported into Kaffe but not vice versa, which seems a bit of a shame. 3) Kaffe is copyright various people, in particular including TransVirtual. Classpath is copyright FSF. 4) Classpath is multi-VM, Kaffe's libraries are (of course) designed for Kaffe only. Classpath doesn't yet have a Kaffe port, although periodically people suggest one and it's generally regarded as a good idea if someone would actually do it. None of these issues seem to preclude cooperation between the two - the license issue is probably the biggest problem as no Kaffe code could be merged into Classpath without adding the exception to the license. But I haven't seen any real (public) discussion as to whether/how this could happen... Well, I guess I've set the stage for a real flamefest now... ;) I hope not though - this seems like an issue that could use some *real* debate. Stuart.
Classpath and Kaffe
>>> <[EMAIL PROTECTED]> 28-Jun-00 8:24:44 PM >>> >Note: libgcj is under the GPL with an exception clause; it's >certainly compatible with Kaffe's GPL. As of a few months >ago, I believe the copyright is held by the FSF. Absoluely! I'm working on an HttpURLConnection that does pipelining, I don't know Classpath already has an implementation but if it hasn't I would like to donate the same class to both projects. It seems mad to me to have any duplication of effort within the free software community, we have enough problems as it is. Nic
Re: Classpath and Kaffe
Tim Wilkinson writes: > Also, has anyone got a legal opinion of using the 1.2 spec from Sun to > write an independent implementation of the 1.2 additions? McNealy's minor minions have one to offer: If the judge were to rule against Sun, "that's not a disaster for us, for the following reason -- it is very difficult, close to if not, in fact, impossible, to build an implementation of the Java platform without at least looking at the documentation or its specifications," said Alan Baratz, president of software products and platforms at Sun. "Well, that's Sun intellectual property. And the judge has been very clear about that, that if Microsoft uses the specs or uses the documentation, it is not an independent work," Baratz continued. "Or if Microsoft purchases something from a third party that had used the documentation or the specs, it's not an independent work." >From www.javaworld.com/jw-07-idgns-lawsuit.html. For whatever it's worth in the amazing world of bogus software patents, look and feel, and language turned property. b.
Re: Classpath and Kaffe
Bernd Kreimeier writes: > Tim Wilkinson writes: > > Also, has anyone got a legal opinion of using the 1.2 spec from Sun to > > write an independent implementation of the 1.2 additions? > > McNealy's minor minions have one to offer: > > If the judge were to rule against Sun, "that's not a disaster for us, > for the following reason -- it is very difficult, close to if not, in > fact, impossible, to build an implementation of the Java platform > without at least looking at the documentation or its specifications," > said Alan Baratz, president of software products and platforms at Sun. > > "Well, that's Sun intellectual property. And the judge has been very > clear about that, that if Microsoft uses the specs or uses the > documentation, it is not an independent work," Baratz continued. "Or > if Microsoft purchases something from a third party that had used the > documentation or the specs, it's not an independent work." Sun has an inherent internal conflict of interest with respect to Java. On the one hand, they want Java to be an open standard. On the other, they want to subvert their perceived competitors. I wish they would acknowlege it and come to a resolution one way or another, for their own sake at least. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Re: Classpath and Kaffe
Tim Wilkinson wrote: > Also, has anyone got a legal opinion of using the 1.2 spec form Sun to > write an independent implementation of the 1.2 additions? I've just > ordered the latest spec book from A&W and I'll see what that says but I > believe it's legally scary. There must be a layer of subtlety behind this question that I'm missing. How would such work differ from all of the cleanroom implementations that have been done to date, pre-1.2? Nathan Meyers [EMAIL PROTECTED]
Re: Classpath and Kaffe
Archie, If you thinhk that scry you should see what Sun is saying in the Sun v. M$ in court. Cheers Tim On Tue, 13 Jul 1999, Archie Cobbs wrote: > > Tim Wilkinson writes: > > Just to keep you informed, we just signed a customer who wants RMI > > implemented so we'll be spending some time on the RMI implementaiton > > pretty soon to bring NinjaRMI upto the Sun spec. (at least that in the 1.1 > > at anyrate). > > Cool.. and also cool to hear about java.security.. fortunately Sun has > documented the security stuff pretty well. > > > Also, has anyone got a legal opinion of using the 1.2 spec form Sun to > > write an independent implementation of the 1.2 additions? I've just > > ordered the latest spec book from A&W and I'll see what that says but I > > believe it's legally scary. > > Hmm.. I'm no lawyer, but that seems far-fetched.. you might even > be able to get from Sun a letter to the effect that "It's OK to > implement the Sun spec", because after all this is what they're > claiming they want people to do, being "open" and all. > > Then if they refuse, raise hell and tell the whole world. > > -Archie > > ___ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com >
Re: Classpath and Kaffe
Tim Wilkinson writes: > Just to keep you informed, we just signed a customer who wants RMI > implemented so we'll be spending some time on the RMI implementaiton > pretty soon to bring NinjaRMI upto the Sun spec. (at least that in the 1.1 > at anyrate). Cool.. and also cool to hear about java.security.. fortunately Sun has documented the security stuff pretty well. > Also, has anyone got a legal opinion of using the 1.2 spec form Sun to > write an independent implementation of the 1.2 additions? I've just > ordered the latest spec book from A&W and I'll see what that says but I > believe it's legally scary. Hmm.. I'm no lawyer, but that seems far-fetched.. you might even be able to get from Sun a letter to the effect that "It's OK to implement the Sun spec", because after all this is what they're claiming they want people to do, being "open" and all. Then if they refuse, raise hell and tell the whole world. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Re: Classpath and Kaffe
How far is Kaffe from 1.1 compliance? That is my core question. Thanks, Duncan
Re: Classpath and Kaffe
Just to keep you informed, we just signed a customer who wants RMI implemented so we'll be spending some time on the RMI implementaiton pretty soon to bring NinjaRMI upto the Sun spec. (at least that in the 1.1 at anyrate). Also, has anyone got a legal opinion of using the 1.2 spec form Sun to write an independent implementation of the 1.2 additions? I've just ordered the latest spec book from A&W and I'll see what that says but I believe it's legally scary. Cheers Tim On Tue, 13 Jul 1999, Aaron M. Renn wrote: > > Duncan W. McQueen ([EMAIL PROTECTED]) wrote: > > But I am concerned with the GPL Kaffe. Is it unfeasible to attempt a > > merge of what Classpath has done into Klasses.jar?? > > At this point there is not much reason to do that. While I believe > we do have some things written that are not in Kaffe (principally > 1.2 compatibility stuff) they have not been as actively used as > the Kaffe libs and are probably more buggy. Also, we (Classpath) > are still focusing on providing a runtime environment for Japhar. > That is a higher priority than worrying about trying to make > things work with Kaffe. Though at some point I'm sure we will make > our stuff run with Kaffe, for hack value if nothing else. Finally, > Kaffe has things that work that we do not, notably the AWT (though > I'm working on that for Classpath). > > Whatever the Kaffe people might want to use, however, they are > certainly free to include. > > -- > Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/ >
Re: Classpath and Kaffe
Duncan W. McQueen writes: > Does anyone out there want to help work on implementing some of the > Classpath functionality that is not working in Klasses.jar, into Kaffe? I might be.. I'm currently working on some of the missing JDK1.2 java/util stuff... also I'm interested in getting started on java.security. What in particular did you have in mind, if anything? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Re: Classpath and Kaffe
Does anyone out there want to help work on implementing some of the Classpath functionality that is not working in Klasses.jar, into Kaffe? Thanks, Duncan
Re: Classpath and Kaffe
Duncan W. McQueen ([EMAIL PROTECTED]) wrote: > Is there any work or synchronization between Classpath and Kaffe? Are > there things implemented in Classpath that aren't in Kaffe, and the > same in reverse? The projects are largely separate. We have agreed to work on a joint RMI implementation, but I don't think anyone has done any work here. We started separately and both had done quite a bit of work before we found out about each other. Classpath lacks an AWT implemention, though I am working on that. I think we have better Java 1.2 support than Kaffe. Also, Kaffe's classes lack documentation. There are probably a few other areas of difference but mostly a lot of overlap. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
Re: Classpath and Kaffe
Duncan W. McQueen ([EMAIL PROTECTED]) wrote: > But I am concerned with the GPL Kaffe. Is it unfeasible to attempt a > merge of what Classpath has done into Klasses.jar?? At this point there is not much reason to do that. While I believe we do have some things written that are not in Kaffe (principally 1.2 compatibility stuff) they have not been as actively used as the Kaffe libs and are probably more buggy. Also, we (Classpath) are still focusing on providing a runtime environment for Japhar. That is a higher priority than worrying about trying to make things work with Kaffe. Though at some point I'm sure we will make our stuff run with Kaffe, for hack value if nothing else. Finally, Kaffe has things that work that we do not, notably the AWT (though I'm working on that for Classpath). Whatever the Kaffe people might want to use, however, they are certainly free to include. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
Re: Classpath and Kaffe
>>Plus, TVT needs to own the copyright to any files they sell to >>customers in the custom edition. So unless Classpath was willing >>to grant this right, TVT would have to rewrite everything anyway. >> Classpath is LGPL...Wouldn't it fit in? It's license is freer than Kaffe's. >>-Archie >> >> > ___ > >>Archie Cobbs * Whistle Communications, Inc. * http:// >www.whistle.com
Re: Classpath and Kaffe
But I am concerned with the GPL Kaffe. Is it unfeasible to attempt a merge of what Classpath has done into Klasses.jar?? > >Duncan W. McQueen writes: >> Is there any work or synchronization between Classpath and Kaffe? Are > >Not really. > >> Are there things implemented in Classpath that aren't in Kaffe, and the >> same in reverse? > >Probably (I don't know what's currently implemented in Classpath). > >You could argue that the root of the problem is that Sun never >fully spec'd the JVM, because they didn't specify what the native >methods are (eg, in java.lang.Thread et.al). So Classpath and >kaffe's "JVM API" are different. > >More to the point, they were started as separate projects, and like >most separate projects, there hasn't been a lot of spontaneous >communication or coordination. > >Plus, TVT needs to own the copyright to any files they sell to >customers in the custom edition. So unless Classpath was willing >to grant this right, TVT would have to rewrite everything anyway. > >-Archie > > ___ >Archie Cobbs * Whistle Communications, Inc. * http:// www.whistle.com
Re: Classpath and Kaffe
Duncan W. McQueen writes: > Is there any work or synchronization between Classpath and Kaffe? Are Not really. > Are there things implemented in Classpath that aren't in Kaffe, and the > same in reverse? Probably (I don't know what's currently implemented in Classpath). You could argue that the root of the problem is that Sun never fully spec'd the JVM, because they didn't specify what the native methods are (eg, in java.lang.Thread et.al). So Classpath and kaffe's "JVM API" are different. More to the point, they were started as separate projects, and like most separate projects, there hasn't been a lot of spontaneous communication or coordination. Plus, TVT needs to own the copyright to any files they sell to customers in the custom edition. So unless Classpath was willing to grant this right, TVT would have to rewrite everything anyway. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Classpath and Kaffe
Is there any work or synchronization between Classpath and Kaffe? Are there things implemented in Classpath that aren't in Kaffe, and the same in reverse? Thanks, Duncan McQueen
