Older blog entries for robilad (starting at number 67)

Cleaning up a bit after the Harmony announcement

As half the Slashdot surfing world has probably noticed, there is a new proposal for an Apache project to implement a VM and a set of class libaries, and all that under the Apache umbrella.

Ok, as I am involved in both in Kaffe OpenVM and GNU Classpath, which do pretty much the same thing, and my name is on the list of people who said they'd be interested in committing to an apache licensed implementation as well, ... you may be thinking that there is something pretty crazy going on involving huge amounts of free crack straight from the Sun headquarters as the Apache license version 2.0 and the good old GPL version 2 do not mix well. Well, it's not really that hot material for conspiracy theories.

First of all, what's happening? Well, the some people within the Apache Software Foundation, an organisation that's been quite successful at writing, maintaining and encouraging donations of Free Software written in the Java programming language eventually started thinking that a full J2SE implementation might be a good thing to have under Apache's umbrella as well, beside a huge chunk of the stack above it.

I guess working up with Kaffe and GNU Classpath developers to work on making GNU Classpath work well on the latest CVS snapshots of various free software using Apache's Gump as a permanent regression test engine has probably encouraged people to dip into the GNU Classpath runtime community. Hacking on VMs and class libraries is fun, and the GNU Classpath developers are a great bunch to work with (and party).

While I guess that idea has been going on for a while in the Apache community, my impression is that due to the sheer size of the task, people initially expected some donor to show up, and develop code collaboratively, rather than doing it all from scratch. That obviously did not happen in the last 10 years so my impression might be way off. But for all the rumours about three-letter vendors releasing their runtimes as Free Software, the ASF would have seemed as the logical partner to team up with, for all the ASF's good working relations with those vendors.

Meanwhile, something happened. Some of us witnessed the literal rise from runtimes like Kaffe out of ashes in the last two years due to an increasing amount of cooperation of Free Software runtimes around GNU Classpath as an efficient, quickly growing backbone.

So, pretty rapidly we're getting somewhere. Kaffe and Gcj are getting good enough for distributions like Debian, Ubuntu and Fedora to start shipping normal java applications, because increasigly stuff just works. In fact, it is actually starting to work increasingly well.

Beside just the cooperation on the class libraries, tromey and I have talked a bit on an off on GNU Classpath mailing lists and IRC about getting the verifier from gcj merged into Kaffe, as it would seem to make sense to get one verifier right and collectively maitain it, rather than maintaining several ones. Along the same line went some ideas to revive the kaffe gcj bindings now that gcj4 offers binary compatiblity. Which eventually ended up in the general idea of turning a VM into a set of losely coupled components with clearly defined interfaces for people to plug into. Not that it hasn't been done before, I know.

There is not much code for this yet, but the current Kaffe-gcj bindings could eventually serve as one possible blueprint for such interfaces for execution engines, for example. The multiple garbage collector integration work in Kaffe done by Guilhem could serve to find out what GC interfaces one needs, and so on. Contributors to make these things happen right now would be very welcome.

So, during my recent trip to CafeBrasil, I had the opportunity to see a beatiful coutry, with wonderful energetic people, who were very enthousiastic about Free Software. I also had the opportunity to talk a bit about Kaffe, GNU Classpath, gcj, and how it all fits in and works. I believe we have something great going with GNU Classpath, that links so diverse projects as Mono, and JNode, SableVM and JikesRVM.

I also had the opportunity to talk about the VM-component interface ideas with people outside GNU Classpath, in particular with Geir from Apache. A modular VM platform would make it easier to get one's VM going, and that sounded interesting, given ASFs lack of a runtime. I also proposed to Geir adopting IKVM and thus Mono into the Apache tribe, but that's not how the ASF works.

For someone unfamiliar with the consensus, procedure oriented style the ASF goes after doing things, coming from the 'let's get things done the obviously right way' school of thought, the way the ASF works can seem a bit bizarre. There are committees. And roles in them. And something that amounts to a soul searching phase that happens during the consensus build up. That's not a bad thing, but it may confusing to watch.

In this case, some people from the ASF and the FSF have begun talking to make the Apache license GPL compatible, and adressing ASF's concerns regarding the LGPL. Kaffe provided an initial reason for people to get together, as some components from Apache (kerberos) would be interesting missing complement parts to Kaffe, and it would be interesting to try to leverage Apache's Portable Runtime to abstract some of the platform specifics away.

Alas, Kaffe being an independent project, neither FSF nor ASF really had a case at hand to more effectively discuss the things, so by ASF wanting to work on a Classpath runtime, the both organisations have a stronger focus towards the goals. At least I'd hope so. ;)

Ok, now, the way those things work can also be very upsetting. I didn't have a chance to see the announcement before Geir sent it out to the PMC list. So I guess it's easy to imagine my surprise on IRC when questions started flowing in. WTF?? WTFFFF????? Where Is The Free Crack???? sort of questions. And with a good reason.

The way the proposal is stated, it sounds as if Apache will just out of nothing, with people's help churn out a full J2SE 5 environment, all things included, because some of the existing code is not licensed under the Apache license. Having developed a strong Anti-NIH stance hacking on Kaffe, I can with a certain amount of assurance say that implementing j2se 5 takes years of a dedicated team to get the VM somewhat useful and then again another bunch of years to get the class libraries implemented. There is a reason why Kaffe, gcj, essentally everyone in GNU Classpath runtime family who one had their own class library either got rid of it, or merged it with GNU Classpath. The reason is that implementing all of J2SE 5 class libraries on one's own in spite of a liberally licensed FSF implementation is for most uses I can think of pointless.

The same goes for VMs in general, I think. GNU Classpath has more than 20 differnt runtimes using and contributing to it. So the natural choice seems to be to me for Apache to pick one and bless it eventually. That didn't happen because that's not how Apache seems to work: there first needs to be a concensus on who, what and how before such a decision can be made. And given that procedure, no VM could have been picked, so the dicussion proposal says 'make one's own'.

What the hell am I doing there, then, not being an Apache? Well, two things: a) trying to help bring ASF and FSF closer together, and ASF using and contributing to FSF's class libraries would be a pretty good thing to happen no matter which path towards a runtime they chose, and b) the ASF can reach a wide audience among developers programming in the Java programming languge that so far has either not heard, or been sceptical about Free Software runtimes based on GNU Classpath. For whatever reason the ASF seems to evoke much less fear and terror in some circles than the FSF, which may make working with those circles through the ASF easier.

Kaffe 1.1.5 out of the door

This is already a bit of old news, as jpick and me pushed the release out last week, before I headed off to Brasilia for CafeBrasil to talk continuously for a week or so about Kaffe OpenVM, GNU Classpath, GNU gcj and all that. 1.1.5 is notable for being the 'Duke Nukem' of Kaffe releases, the one that was 'coming soon' for a loong while, and finally made it into a nice, big, fat release.

In the year since Kaffe 1.1.4 was released, the lines of code count more than doubled, with around one million new lines of good source code from the various upstream projects, like GNU Classpath, GNU JAXP, GNU Crypto, and gcj The merge with GNU Classpath is now almost finished, with around 20 files left over to switch. That means we're almost 99% there, finally. It's been a long ride, and now we have a new shiny AWT implementation based on gtk, and the GNU Classpath 'good-looking' Swing working out-of-the-box in kaffe, just like all the various integrated upstream projects, like Tritonus for sound support, GNU Crypto for JCE, Jessie for JSSE, GNU inetlib for URL handlers, etc.

My plan for the future (i.e. this year ;) is to turn Kaffe from a melting pot and integration hotbed of class library development into the same 'bleeding edge' intergration facility for virtual machine components. Some work on that has begun on Kaffe's core, and ultimately the idea is to be able to plug in parts of other excellent runtimes, like gcj, or JamVM into Kaffe and vice versa. If it works out, it will turn into a GNU Classpath VM framework, that would allow people to bootstrap their VM from state-of-the-art spare parts.

Of course, now that I've spent more than a week away from CVS, I've seen that those amazing Classpath hackers have pushed further ahead and added a lot of new exciting code, like a unified IO encoder/decoder framework, and progress on CORBA and Swing. It's great to come back and see a huge lump of nice code sitting in the CVS ready for merging. Thanks a lot to everyone hacking on Kaffe and GNU Classpath, you folks seriously rock.

Assimilating NetBeans from Within

Continuing on the path to world domination for GNU Classpath using runtimes, the necesaary steps have been made to make Kaffe's CVS head work within NetBeans 4. It turned out that I just had to make Kaffe output -version information in a suitably JDK-ish way for NetBeans to be able to parse it.

While still only running on non-free software, it works suprisingly well as a way to use Kaffe to build and run Java programs that will work on free software. In all its glory it looks like this.

This is the first step towards getting NetBeans to run on a fully free software stack and smashing yet another Java trap. Thanks to Tim Boudreau, the NetBeans lead for talking me into playing with it. I hope some NetBeans hacker takes it up from here, and makes it possible to build, run and distribute NetBeans on a fully free stack.

17 Mar 2005 (updated 17 Mar 2005 at 19:30 UTC) »

Welcome to the Java Melodrama Show!

Today's headlines in the Java world herald the arrival of nothing less than a new era in Java ... licensing. The latest announcements from the innovative leaders in both proprietary and open source software license production, have been brought to the general blogging public today via a widely reported teleconference. Sun announced that they will announce yet another license for their source code later, maybe. In the long standing tradition of sweet license names like "scuzzle" or "cuddle", the new license will be pronounced "jewel", and written as JIUL.

So what's wrong with the current license, SCSL, cuddly nicknamed scuzzle and a jewel in Sun's crown? Hailed by Sun on its arrival back in 1998 as a blend of the best aspects of the proprietary and Open Source license models, the license failed to gain support, and has been widely debunked as as far from being open source as it gets without explicitely writing a license that violates each and every clause of the OSI definition.

After announcing that they will switch away JINI from the dreaded SCSL, Sun are now considering moving away from the SCSL for Java as well. In the words of Graham Hamilton:

"I expect SCSL will fade out. We're probably not going to do (J2SE) 6.0 under SCSL," Hamilton said.

Still, Hamilton believes the license is superb:

[SCSL] was intended to be the wonderfully perfect license, designed to cover all cases," Sun VP of Java Graham Hamilton said. "The problem was, everything was all wrapped up in one enormous license, and if you would hire battalions of lawyers, you would find that the license was great. The trouble is, most people don't want to hire battalions of lawyers and find SCSL is too complicated, so there hasn't been much adoption."

Hear, hear. The SCSL 'too complicated'? Most people don't want to hire an army of lawyers? How bizarre! What would James Gosling say to that?

""It's amazing how complicated most open source licenses really are," Gosling said. "And there's a growing number of them -- and they're all hard to decipher. Maybe I'm just an amused armchair quarterback, but I think it's funny, sitting where I am, having watched Sun get all the grief for supposedly complicated licenses, when you consider how truly gnarly some of these open source licenses are. They started out simply, like the BSD license, then the Stallman license ... then they all kind of swirled together. Now some of them have 'contamination' clauses in them -- the GPL is the poster child for that," Gosling said.

There you go: SCSL is just 'supposedly' complicated, with your handy 'battalions of lawyers' you should be able to decode it just fine, so what's your problem? Don't have an army of lawyers at your disposal? Sheesh. No wonder commercial Java users have trouble understanding you funny open source 'advocates'.

"By and large, they're actually somewhere between uninterested and hostile to the sort of wild and wooly world of open source," Gosling said.

And don't forget, kids, it's the open source licenses that are 'truly gnarly', not the other way round!

In fact, all those wild and wooly open sources are just causing so much trouble to poor companies:

"They're causing so much chaos in companies, who tell me: "(Open source licenses) are just too vague. I can't tell you what they mean. A court of law couldn't figure this out.' It's just a mess, and they're going to be a heartache for years to come."

And, besides:

'Gosling questioned the value of some existing open source licenses, such as the Gnu General Public License."A lot of the open source licenses are not very well written," Gosling said.'

It's them! Look there! Over there! The open source licenses are complicated and vague and ill written! Not the SCSL! Why can't you people see what's good for you: An army of lawyers! :)

But fortunately, someone is there to the rescue from that crazy, mad open source chaos and anarchy. Never missing an opportunity to desperately try to rub a bit off the street credibility from the 'wild and wooly' open source world onto the proprietary implementation that he helped create, 'Gosling described Sun's approach as "closed open source."'

No kidding. I'd describe it as "try all possible closed source licenses randomly till you stumble into one that fits by accident, while desperately pitching it as 'open source' to whoever will still listen", but what do I know anyway, I just get to see the impressive end results of Sun's approach.

So, on to the new licenses. In a brave effort to simplify the licensing of the Java technology, Sun created not one, not two, but 3 (in words: three) 'new' licenses to govern different fields of use and goals. That's a pretty impressive and unique effort at simplifying a software license by creating more clones of the same.

One of them is of course every Java researcher's favourite JRL license, which has, despite being a huge flop ever since it was introduced in 2003, been repeatedly re-pitched every few months as 'new'. The other 'new' license is the JDL, which is also not that new any more, and is just another SCSL-clone with the most obvious problems papered over.

The only really new thing that was announced today was that Sun will announce the third 'jewel' license sometime next month. Apparently that license will allow for internal use and modification. While Hamilton calls that 'an experiment', he also has a few words of warning for those that are too eager to take that offer literally:

"There's a lot of scope for companies getting into trouble if they get too enthusiastic about making their own versions of J2SE," Hamilton said. "We don't think it should be our job to tell them what risks to take."

Play it safe, kids. Don't get too excited, and you'll be all right.

And that's all for tonight, on the Java Melodrama Show, we'll finish with your moment of Zen:

Gosling described Sun's approach as "closed open source."

22 Feb 2005 (updated 23 Feb 2005 at 01:07 UTC) »

Ever since Sun's 1.5 (or 5.0, or whetever their funny marketing division decided to call it these days) came out, I've been wondering what the actual terms of access to the compliance test suite will be.

I was pretty disappointed when it turned out to be a mostly useless 'Read only' license. Judging by non-existant mailing list traffic on Sun's jck's project mailing lists, noone bothered to take Sun up on that offer for all the obvious reasons. I guess it was meant to be as yet another useless Sun PR stunt anyway, as Sun's Chief Java 6 dude, Graham Hamilton, happily ignored all comments made by me about the TCK release on his cutsey blog on java.net. Awesome display of skill in avoiding engaging in a dialogue there, I must admit. Calvin Austin, who brought Java 1.5 to life, had a lot more style, but he doesn't work for Sun any more.

Alas, beside having a licensing division that regularly churns out funny licenses, and a marketing division that has problems refraining from applying the term 'open source' to clearly non-open souce software like JAI or ImageIO, Sun also has a something pretty cool: a TCK Scholarship for 'qualified individuals' and organisations. ObjectWeb and the Apache Software Foundation went through that scholarship dance to get the J2EE compliance test suite, and ObjectWeb's Jonas has recently passed the tests. Encouraged by those successes, and by a lot of good conversation with Javali's awesome Bruno Souza, and Sun's energetic Onno Kluyt, I have sent in my TCK scholarship application, so that we can eventually have mutual compatibility between Sun's proprietary implementation of the Java specifications and Kaffe and other GNU Classpath virtual machines and runtimes.

This is the first step. Onno has acknowledged receipt of my application from Sun's side, so it's now up to the TCK Scholarship Board to decide if the Kaffe/Classpath application is worth support. Then it will be up to Sun to propose the terms for such access.

The application looks like this:


This form is for applications for no-cost access to TCKs for Sun-led JSRs in the Java Community Process. Please read the requirements for qualified efforts which can be found at http://java.sun.com/scholarship/.

Send the completed form and any supporting documentation to: tck-review-board@sun.com.

Section I. Identification

I.a Name of organization: (leave blank if applying as individual)

I.b Address: (leave blank if applying as individual)

I.c Contact person: The TCK Review Board requires a single point of contact for the applying organization.

Dalibor Topic

I.d Address: [snip]

I.e Email address: robilad@kaffe.org

I.f Phone number: [snip]

I.g Fax number:


I.h Request is for organization or for individual: Organization / Individual


Section II. Status Information

For organizations: (leave blank if applying as individual)

II.a Describe the legal status of your organization.

II.b Provide a link to or describe your organization's bylaws.

II.c Provide a link to or describe your organization's decision making process.

II.d Describe the nature and source of your organization's funding.

For individuals:

(leave blank if applying as organization)

II.e Employment information:

- Employed by:

- Freelance:

- Self-employed:

- Other:

Student at the Universitaet des Saarlandes, Saarbruecken, Germany. Student assistant at the Max Planck Institut fuer Informatik in Saarbruecken, Germany.

II.f Are you applying as individual contributor to a group effort: Yes / No


II.g If yes, describe group

Kaffe.org is a project implementing a free software virtual machine.

I'm one of the current leading contributors to the Kaffe.org project.

Kaffe.org cooperates with many other free software projects in its area.

It successfully acts as a melting pot for integration of various free software efforts related to the implementation of tools and libraries which are useful in the context of the java programming language.

Among the projects Kaffe developers cooperate with are

I am looking into collaborating with other projects implementing parts of the class libraries specified by JSR 176, including:

Kaffe.org is being developed in an open, collaborative fashion by a diverse group of core developers and contributors since 1996. All of the development communication takes place in the open on publicly accessible mailing list, and IRC channels, with daily snapshots available from cvs, ftp and through various websites.

A lot of the code in Kaffe comes from generous contributions by other free software projects, with whom I'm very pleased to have the opportunity to collaborate, sharing bug fixes and improvements.

For quality insurance the various groups collaborate on the free software Mauve test suite which contains more then 25.000 tests and various modules for testing core class library implementations, byte code verifiers, source to byte code and native code compiler tests.

Mauve also contains the Wonka visual test suite and the Jacks Compiler Killer Suite.

All tests and test results are openly shared between the various groups which use the results to improve their compatibility with each other. Mauve is distributed under the GPL.

I hope that one day it would become possible to combine the tests and results of the TCK with this larger effort to create a truly open compatibility kit, available to anyone, anywhere to freely evaluate compatibility claims.

Besides these regression and unit tests the Kaffe.org project is involved in real world application testing such as Eclipse, Jonas and the Apache Jakarta suite through Apache Gump running on Kaffe at http://brutus.apache.org/gump/kaffe/ . Kaffe.org is one of the most widely distributed environments for execution of Java applications on many GNU/Linux distributions and other free software operating systems.

Section III. Project Description

III.a Name of project: Kaffe.org

III.b If applicable, web site or url: http://www.kaffe.org

III.c Description of project:

Kaffe.org is a free software project that is implementing a virtual machine, class libraries and development tools to allow execution and development of programs written in the Java programming language.

Kaffe is licensed under the GNU General Public License. Parts of it are licensed are different, GPL-compatible, free software licenses. It doesn't contain any source code from proprietary implementations.

Kaffe is a very portable, modular runtime that has been ported to more than 50 different platforms. It runs on alpha, arm, ix86, x86-64, ia64, mips, m68k, sparc, sh, s390, pa-risc, and powerpc architectures, and on operating systems ranging from GNU/Linux, NetBSD, FreeBSD, OpenBSD to RISC OS, Cygwin and Solaris.

It has several execution engines, allowing for lean and fast Just-in-Time compilation on many platforms. Its performance is in general among the best free runtimes, and is expected to improve further as improvements from various Kaffe forks are merged back in into the main tree.

For class libraries, Kaffe has chosen GNU Classpath, and work is under way to fully convert Kaffe to use GNU Classpath out of the box. GNU Classpath currently implements around two thirds of the J2SE 5.0 APIs according to the japitools comparison page at http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath.html. Kaffe is now, save for two dozen classes, using GNU Classpath for its core library. It also includes code from the other projects mentioned above that implement other parts of the J2SE APIs which have not been contributed to or implemented in GNU Classpath yet.

As the number of implemented classes and methods grows steadily, it is becoming more and more important to ensure compatibility between different runtimes. So this effort would be directed at fixing the compatibility deviations in existing code, and ensuring that new code complies with the specifications.

III.d Schedule. Describe the timeline for the project, eg when is the anticipated ship date, what stage is it now (alpha, beta, early access etc):

Kaffe 1.1.5 is expected to be released in February, and following releases will follow a two month cycle. The TCK passing release would become Kaffe 2.0.

Section IV. TCK

List the JSR(s) you are requesting TCK access for. Indicate for each whether you are also requesting to receive support:

JSR 176. Yes, I'd like to receive support.

This process is new to all of us in the Kaffe community so any advice or assistance is greatly appreciated.

Section V. Additional information

Provide any additional information or links to web sites or documents that may be helpful to the Review Board in considering your application:

I hope that the work on creating a free software, fully compliant Java implementation can be conducted in the most open fashion possible, without the need to erect communication barriers between contributors that have been granted access to the TCK and those that have not been granted such access.

I intend to closely collaborate with the Bruno Souza and the Javali project (http://www.javali.org.b) as well as SouJava (http://www.soujava.org.br) on this task.

The SouJava is the largest Java user group world-wide, and it is a member of the JCP (http://www.jcp.org). Bruno Souza is the leader of the JUGS community on Java.net (http://www.java.net), the founder of SouJava, and a famous Java evangelist.

In considering your application the Scholarship Review Board may contact you with questions for clarification or additional information.

Thank you,
The Compatibility Testing Scholarship Review Board.

Let's see if Sun's test suite is really as good as Gosling would like me to believe.

Updated: HTML-ized all the links thanks to mjw, and finished the paragraph about Sun's PR stunts.

I didn't realize GNOME had an Advogato blog applet. Very nice!

Well, for a first applet post, what could be more approapriate then a movie review!

As our cable TV connection thingie is down atm, my girlfriend has moved to watching all the nice things she has recorded on video but never actually had the time and passion to watch. That naturally leads to quie a few pearls being discovered, rediscovered, and the ocassional tape being ceremonially buried. The movie I'm talking about is of the latter kind.

Now, I have the kind of luck, that ocassionally steers me to see watch embarassingly bad movies, like Troy, Hulk, or similar movies that fit so well with other four letter words. But I've got trouble remembering when was the last time I saw something so really, truelly bad that matched 'Beowulf', the climax of Christopher Lambert's career as the master of cheese.

'Beowulf', the movie, is loosely based on 'Beowulf' the epic. There are folks with the same name running around and killing people in both. Only that the movie is set in some kind of a bizarre parallel universe that's a cheap cross from whatever was left from some D&D movie set, and random garbage from the techno-trash heap of the 90s. Infra-red telescopes & swords, anything goes. It's like 'Blade' in worse.

Ah yes, the acting. Christopher acts his way so tragicomically into fight situations in which some poor stunt double needs to flick-flack all over the set, always ending up being wiped off his feet in the end. I'm sure there is a deeper message in that, but it goes under in the very, very cheap CGIs used. And ... it's soo bad.

Other actors also perform equally 'plan9 from outer space' like: with lethargic, fatalist faces, they work their text off, and it seems as if everyone was having a really bad time making that movie. The camera loves the talents of the 'actresses' on the set, and the crew have done their best to put them in spotlights. One of the actresses gets to show off her talents in a soft-core scene that's supposed to be some sort of a succubus-and-lover tete-a-tete with the sleeping lover. The scene is so 'good', that it has been cut and pasted verbatim in another part of the movie.

Oh, yes, CGIs. Well, Grendel, the monster, is some poor chap in a latex rubber costume that makes him look like a small rip-off from Godzilla. In order the make that less obvious, I guess, the directory had some really bad blur effect added to all scenes with Grendel. It's optically ... awful.

So, if you want to see what 'plan9' would have looked like if it was made in the 90s, don't hesitate to enjoy an evening with Lambert's 'Beowulf'.

Now I just wish someone would make a movie with Lambert, Van Damme and Stallone, the three kings of cheese. That would probably undercut everything I've seen.

Kaffe OpenVM

Ah, the smell of build breakage in the morning! I've revamped the build system to rearrange the class library build to go first, followed by JNI header generation and then the rest of the VM. That and the revamping of the bootstrap process allowed me to get rid of a few jars in the CVS, and simplyfy things considerably. There is still a bit of fallout from that change in the Kaffe tinderbox, as I need to rip out a few overdesigned parts of the build system as well, but it feels good to undo one's mistakes and make 'make dist' work fine again.

It's all work that needs to be done for Kaffe's 1.1.5 release. My task list includes fixing rmic, merging in zip from classpath, fixing cross-compilation problems, and making it all build smoothly

Make distcheck is a different issue, as we have one regression. Currently something pretty bizarre is haunting Classpath's Calendar and Data formatting classes on Kaffe and causes that regression test to fail. Ito Kazumitsu is trying to track the bug down, though.

On the bright side, there is major progress on the GUMP thanks to all the great GNU Classpath hackers. Today, more than 25% of all open source java projects in the GUMP can build and run their tests sucessfully on kaffe from CVS head on x86-linux. Time to fix the issues of the second quarter!

15 Dec 2004 (updated 15 Dec 2004 at 11:44 UTC) »
A license for each season

Sun's legal division must have been pretty busy lately, churning out not one, but three licenses in the shortest period of time: the CDDL, which may be used for the upcoming OpenSolaris code, the JDL and the latest newest 'Read-Only" license.

Being a Java developer, I'll kindly let others have a go at dissecting the CDDL, while I turn my attention to the JDL and the "Read-only" license.

The JDL, or 'Java Distribution License', seems to have been made with commercial distibutors in mind, as it bundles the TCK and the RI under one inseparable entity, and effectively prohibts open source implementations of the specification once one accepts the JDL. It has the usual problems of the Java Research License (JRL), including the overreaching definition of modifications, and commercial use. The gradual improvement vs. the JRL is that this license means one gets the TCK, and may even use the RI commercially, within certian limits. I won't go into the details here, as every project adopting the JDL seems to end up having its own version of it, and these may differ. Not really that interesting, as baby steps towards a more open licensing of Java technology go.

The Read-only license is, on the other hand, the funniest license I've come accross in the last couple of weeks. It's the codification of 'look, but don't touch' into a simple, straightforward license agreement. It is a software license agreement that does not allow you to use the software. It is a source code license agreement that prohibits compiling the source code, or executing it in any way.

"Read-only" license sounds less ambiguous than 'Shared Source', or similar marketing labels usually applied to pseudo-open software. That's actually quite cool, as many closed license these days come with pretty bombastic names that don't even remotely mean what they say. Also cool is Sun for the first time, ever, licensing their TCK under a zero cost license, and addressing tainting of developers that have had the pleasure to read, only such source code.

Nevertheless, the license is pretty absurd. Beside all the cheap shots one could make advising Sun to upgrade to a "Delete-only" license, one thing is particularly absurd: the clause for confidentiality. Let alone that test suites in general are not superb alien technology from the future, but just a series of simple, boring pieces of code to execute a method, or two, and evaluate the results according to what a spec says, and the specs being tested are supposed to be open standards, what sort of a confidential secret could one obtain by reading, only, through test suite code?

On the positive side, beside the license being pretty absurd and rather useless, I don't have much to complain about, which is a major progress from the usual license agreements surrounding Java technology. That's quite a bit of progress, I guess.

LGPL & Java

rcastro: Check out David's article on LGPL & Java from the latest GNU bulletin. Yes, the LGPL works they way most people think it works.

24 Nov 2004 (updated 24 Nov 2004 at 00:05 UTC) »
Boston Free Runtimes Summit

It's been great fun to catch up with the other free runtime developers. Gcj and GNU Classpath are making massive progress, as the demos showed, in particular Graydon's Swing demos, Tromey's blazing fast eclipse and Fitzsim's videostreaming Fluendo applet via gcj.

It's been very nice to finally meet some of the people I only knew from online discussions in person. Bruno Souza shared his passion and energy about the brazilian free Java projects under the Javali umbrella, and Geir Magnusson Jr. explained how the things worked out on Apache's side, with an in-depth look at how the Geronimos and the Apache Software Foundation dealt with TCK access and the strings attached to it (NDAs). Danese Cooper explained how the OSI works and how corporations tick, while Onno Kluyt, Sun's JCP guy, explained a bit how things (ought to) work from Sun's perspective.

I was in particular glad for the opportunity to speak to Onno in person about the things that I don't like in SCSL, JRL, JSPA and all those weird legal agreements surrounding Java(TM) technology. It's been an interesting day-and-a-half of discussion about how to deal with compatiblity and free software licensing and whether or how to work around or with Sun. I am interested in having Sun pull along with free runtimes, so I was glad that someone from Sun was officially invited.

Among things we ended up discussing was what would happen if I applied as a qualified individual for a 1.5 TCK license for the whole GNU Classpath/GNU JAXP/GNU Crypto/Jessie/GNU inetlib/Tritonus/... conglomerate I've been slowly merging into Kaffe. Since officially the 1.5 TCK should now be available for independant implementations, I may try to see how willing Sun is to consider dozens of compatible, independant, free software (as in GPL, for example), J2SE 5 implementations as something positive and worth supporting with a J2SE TCK scholarship.

Other ideas were floated around too, like establishing a Kaffe presence on java.net, Sun's community site, or applying for an ObjectWeb membership, who have managed to strike a scholarhip deal for a J2EE TCK.

I've talked to many gcj developers about bringing Kaffe and gcj a bit closer together by merging in more of gcj's code into Kaffe. I was very happy to meet Rob Gonzales, Kaffe's verifier guy, and we had some good time discussing a verifier merge from gcj into Kaffe with Tom Tromey. Other ideas I discussed were merging in libffi, and gcjx, and of course the upcoming gcj binary compatibility ABI.

Fernando Nasser and Paul Nasrat presented on JPackage, which has come a very long way. JPackage includes working support to build things from source, as RPMs, has found a way to deal with the Maven issues, has started to support gcj-ed packages, and seems like a pretty good way to deal with packaging Java applications and libraries. Very impressive.

Watching the Mauve, GNU Classpath, gcj and JPackage presentations was a bit like watching a long piece in tetris slowly slide into place to complete four rows at once. There was a considerable amount of jaw-dropping on the first day. Miguel's Mono presentation afterwards lacked a bit of the usual esprit that goes with it.

Finally, I was able to meet Michael Hind, and see his presentation on JikesRVM, a pure Java, yet blazing fast free runtime. It's been a pleasure to chat with Michael, Steve from Intel, and other runtime developers that don't frequent the usual IRC channels.

And last but not least, Ean Schuessler was around, and we really missed Arnaud for a Kaffe Debian packaging session. Instead, Ean showed me his impressive work on OfBiz, and explained me how things are moving forward in Brazil, along with Bruno.

I probably forgot to mention a thing or two from the tightly packed summit. I'm sure others will blog about it, though :)

Yet another Sun license

So finally, after rumours going around for a loong while, Sun published the source code for J2SE under an alternative license, the JRL.

Executive summary: It's still useless. ;)

All in all, it's still a long shot from meeting the open source definition. It appears to be the research section of the old SCSL, repackaged under a new name, with a few ambiguities resolved, and a few of the most hillarious pieces removed. If in doubt, ask your lawyer, I'm not one.

The JRL has been presented back at last year's JavaOne with a big marketing stunt, and failed to impress the research community back then. To quote Danese Cooper, Sun's open source diva:

"IMHO (and IANAL) the JRL doesn't actually represent much of a change of terms from what the research and academic community could do under SCSL (there are some small changes around export), but it does clear away all the language in SCSL that is confusing, if you are only planning to engage in research."

Nothing substantial seems to have changed. But it's a step ahead for Sun on the road to freedom without fear.

If you want to do research without tying yourself down, there is GNU Classpath. It is licensed under a free software license, and is actively used by many research projects like JikesRVM, ORP, or OVM.

Without further ado, let's jump right into the JRL with

The Open Source Definition vs JRL 1.5 shootout

1. Free Redistribution

Nope. It explicitely 'excludes use or distribution for direct or indirect commercial (including strategic) gain or advantage.

2. Source Code

Nope. See above.

3. Derived Works

Nope. See above.

4. Integrity of The Author's Source Code

Nope. It doesn't allow distribution for 'indirect strategic advantage' as patch sets either.

5. No Discrimination Against Persons or Groups

Yay, it passes that one!

6. No Discrimination Against Fields of Endeavor

Nope. Research only.

7. Distribution of License

Nope. The rights are non-transferable, thus each recepient needs to agree to JRL explicitely by click-through prior to distribution.

8. License Must Not Be Specific to a Product

Yay, it passes that one!

9. License Must Not Restrict Other Software

Nope. By claiming all implementations of the Technlogy to be Modifications, the license demands that cleanroom implementations that you distribute be licensed under JRL as well.

10. License Must Be Technology-Neutral

Nope. It's a click-through license.

2 out of 10. Still as low as the SCSL. Far from meeting the open source definition.

On the other hand, there is a bit of improvement. JRL removes a lot of cruft from the SCSL which makes it easier to dig through it. So I'll give the 'best of legalese' from the JRL.

No matter where or how you put it, it's covered by the JRL

The JRL claims patent-like protection on the code, by declaring "(b) new source or object code implementing any portion of the Technology." to be a Modification. The copyright holder there claims any expression that implements any portion of the technology to be a modification, even if the new implementation shares no code with the JRL'd implementation. So if you ever intend to work on a free software implementation of anything, you should stay away from it.

It also means that all your code using the Technology must be licensed under the terms of the JRL. Extending a class in order to use it means that your new class implements the API of its superclass, which is a portion of the Technology, thus it's a Modification.

Would you like some indirect strategic advantage with that?

"Research Use expressly excludes use or distribution for direct or indirect commercial (including strategic) gain or advantage."

That's perfectly ambiguously worded. It's a joker card to sue at will.

It has the same sort of problems like the SCSL: it's pay to play, as soon as you try to do something that might give you an 'indirect strategic advantage', like fixing a bug.

Fortunately, this time it's spelled out in uppercase letters for those folks that don't like reading the small print.


Got it, now?

We don't need no steenkin URLs

"Technology Site" means the website designated by Sun for accessing the Technology.

No URLs here. So the copyright holder could at any time say 'uh, that was not the Technology Site, it was an unofficial beta ... this one is the Technology Site!'.

The JRL community: an exclusive members-only club

"A. License Grant. Subject to the conditions contained herein, Sun grants to You a non-exclusive, non-transferable, worldwide, and royalty-free license to do the following for Your Research Use only: "

So let's say you're doing research on Java. You finish your PhD, your work turns out to be useful. While you head for a greener pasture, the rest of your research group would like to use it for their own research.

They are not allowed to unless they accept the JRL as well because your license is not transferrable.

Furthermore, since your license is non-transferable, your peers can only reproduce your findings if they, too, agree to be bound by the license. That means you and your peers have to chose if you want to be in the JRL research community, or outside it. If you end up on different sides of the fence, it is going to be very painful to do research together, as you can not reproduce the results of the poor fellow trapped inside the gated JRL community. That effectively devaluates his research work.

Trust no one

"2. Share source code of the Technology alone, or with Modifications, with other Licensees;"

You may only give them access if they license the Technology from Sun by accepting the JRL. Of course, the catch is that only Sun knows who accepted the JRL.

So you can't put your sources on a conference CD, online, or share it freely with other researchers. You have to personally see them clicking on the 'I Accept' button of the JRL or you'll be in danger of violating the license.

You can have it any color as long as its black

"3. Distribute object code of the Technology, alone, or with Modifications, to any third parties for Research Use only, under a license of Your choice that is consistent with this License;"

That's a recept for spending your scientific career in courts, arguing whether your own license is consistent with the JRL or not, rather than actually doing research.

Afaict no OSI certified license is consistent with the JRL, as no OSI certified license mandates that you only distribute your code to JRL licensees. It wouldn't be OSI certified, then. ;)

You can use my research, just sign here

The JRL propagates in a fascinating way: all source code you publish must be under the JRL, and so must be the binaries, unless you can come up with a license that says the same as JRL with different words.

You may only distribute to other licensees. That's means that everyone you distribute your code to must be a member in the 'anonymous JRL licensee club' prior to your act of distribution. It appears like an attempt to try to force people to sign up for the JRL to use each other's research. Research-friendly licenses don't do that.

We might let you get away with it this time

" and publish papers and books discussing the Technology which may include relevant excerpts that do not in the aggregate constitute a significant portion of the Technology."

I'm glad that the license allows licensees to actually publish papers and books on the research they've done.

Of course, the 'relevant excerpts that do not in aggregate consitute a significant portion of the Technology' is another joker card to sue at will if your paper or book includes a few lines of the JRL'd code. The license does not define 'significant' in any way.

Igor, go fetch the brain

"B. Residual Rights. You may use any information in intangible form that you remember after accessing the Technology, except when such use violates Sun's copyrights or patent rights."

Translation: You don't have to fry your brain after looking at JRL'd code, but it would help. Make sure that you ask your IP lawyers after each use of JRLd sources what you may remember, as they are the only ones likely to be able to decode the patents.

If things go bad for you, you may also have to convince a judge in court that some new code you wrote after seeing the JRL'd code is not literally copied, but is actually in 'intangible form that you remember'. Good luck, you may need it.

Afaict, agreeing to JRL makes you employable only to those companies that have a Sun commercial license for the technology you agreed to, if your work is related to it.

Now it's here, now it's gone

"1. If any portion of, or functionality implemented by, the Technology becomes the subject of a claim or threatened claim of infringement ("Affected Materials"), Sun may, in its unrestricted discretion, suspend Your rights to use and distribute the Affected Materials under this License. Such suspension of rights will be effective immediately upon Sun's posting of notice of suspension on the Technology Site."

Translation: the copyright holder can terminate your license at any time if they feel like it.

As they don't feel like telling you where the 'Technology Site' is, the only thing that's certain is that once you've accepted the JRL, is that you've accepted the JRL. Anything else is subject to a notice of suspension to an ominous web site without a URL.

58 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!