Hi Mark, On Thursday 24 October 2002 18:03, Mark Wielaard wrote:
> On Wed, 2002-10-23 at 18:21, Andy Walter wrote: > > [...] we are very interested in joining your project. > > That would be very nice! I'm glad to see that we are welcome here. > For license questions you will have to contact [EMAIL PROTECTED] since > they can give you advice on legal issues. Thank you for the pointer. I will contact them soon. > The GNU Classpath license does > indeed allow certain kinds of derived works that are not Free Software. > This was done because we felt that in the end this would benefit > users/developers the most since it would result in having more free > software available. But we do prefer working with Free Software and we > will certainly not promote proprietary closed source software. No problem. I understand that you don't promote closed source software and didn't expect that. We try to be as open as possible, i.e. we prefer standard interfaces to proprietary ones whereever possible. Maybe, the sources of our VM will one day be open as well but I don't expect this so soon. Even if you convinced me (what might not be that difficult) this would be not sufficient ... However, I managed to convince the rest of aicas that at least merging the API would be a great thing to everybody. I'm afraid more is not possible at the moment. > So I would ask you kindly to only distribute you VM as free software. > See for example Ada Core Technologies <http://www.gnat.com/> for an > example of a commercial Free Software business. Or of course > http://wonka.acunia.com/. Of course, I know Acunia and that there are other open source VMs. They have different business models. There is a binary version for Linux on our homepage which is legally, but not functionally, restricted to 30 days. Currently, more is really not possible. > > The easiest way would be if we could get write access to the repository, > > so that we can provide code and bug fixes directly. (Of course, we intend > > to give something back Classpath). Providing the code to a maintainer > > would be okay for us, too. > > I saw that Brian already send you the information on how to contribute > (see also http://www.gnu.org/software/classpath/doc/hacking.html#SEC2) > It would be nice if you have CVS access to integrate changes yourself > since merging changes from others does sometimes take a long time since > we have only that many developers. Sure, this is the easiest way for everybody. We use our own repository here and intend to synchronize with the Classpath CVS about twice in a year. > > In our developer branch, we replaced our own Java API (expect from > > java.lang and java.awt*) by GNU Classpath, to see whether there are any > > unexpected problems. The result looks quite good: We didn't encounter > > much problems and in Classpath, much more packages are implemented. > > Very nice. What tests did you use? You'll probably happy to read that our testsuite is based on Mauve. :-) We have added some tests and included a small script-driven framework for our nightly builds. Currently, we are not happy with the generated statistics yet, which are rather primitive at the moment. However, one of our employees, Denis Theinert, is assigned to improving this. The result should be a statistics that says "Test ABC, which ran perfectly the day before, failed last night" - and vice versa. We didn't contact the Mauve developers so far, but as soon as our testsuite works the way we like it, we plan to contribute to Mauve as well. However, we have not finished the integration of all Classpath packages. There are some slight problems with java.io. I'm sure we can handle this within a couple of days. I just wanted to contact you as soon as possible to see your reactions. If our legal guys do not agree (what I neither hope nor expect) we could easily switch back now without having wasted much work. [...] > The native libraries of libgcj are already much better being more > platform-independent. Sadly we don't even have a plan on how to merge > these libraries yet. (libgcj uses the CNI interface for most native code > since JNI is much to slow for them). The native interface is always a problem. JNI is probably slow on every Java Virtual Machine. We have our own (internal) interface as well which is much faster but not very nice to use, because the developer has to take care about too many things. Whenever possible, we prefer JNI. If performance becomes too poor, we probably rewrite some methods in JBI (our interface), but even in that case we'd continue to support the JNI methods, of course. > > What do you think? Are we welcome? > > Sure. I look forward to working with you. Great. So do I. Kind regards, Andy. -- aicas GmbH * Hoepfner Burg /"\ ASCII Ribbon Campaign Haid-und-Neu-Stra�e 18 * 76131 Karlsruhe \ / No HTML or RTF in mail http://www.aicas.com X No MS-Word in mail Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 / \ Respect Open Standards _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
