Older blog entries for robilad (starting at number 65)

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:

COMPATIBILITY TESTING SCHOLARSHIP APPLICATION FORM

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:

[snip]

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

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

Yes

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.

"COMMERCIAL USE AND DISTRIBUTION OF TECHNOLOGY AND MODIFICATIONS IS PERMITTED ONLY UNDER A SUN COMMERCIAL LICENSE."

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.

Breaking down self-imposed fences

These days, one of the more widely debated questions seems to be: where do you stand on Sun? Is Sun good, evil, or have they simply not decided yet?

Simon Phipps made an interesting blog entry regarding 'framing' of debates. As I've been thinking about the recent eruption of flames in blogs all over the web surrounding Sun recently, I figured I should join in the fun. Without further ado, here is my own take on the debates.

Who profits most from the current Sun vs. the World shouting match?

One thing that had me wondering last week, as the blogging conflict between Sun and the coopetition made their way through the media was: who profits from it?

When you look at the speculation around the OOo status after the publication of the Microsoft agreement, for example, and step back from the context of the current shouting match between Sun and, among others, Red Hat, who is the one that actually profits from casting doubt around the future of OpenOffice.org? Not Red Hat or Novell, as they ship it, and have a few hackers of their own working on it. Not Sun, obviously, as they are the driving force behind OOo, and are doing a very good job on it. Neither IBM, HP, nor Apple have products competing with OOo, and for some of them OOo is the leading full-featured office suite on their platforms so their interest in fudding it is questionable.

The only company that profits from someone throwing mud on OOo is Microsoft.

Aren't Linux vendors all evil and greedy anyway?

When you step out of the context of the current shouting match on street credibility between GNU/Linux vendors, who is the company that profits from GNU/Linux vendors throwing mud upon each other? If the mud that sticks turns out to be something along the lines of 'Red Hat is a bunch of greedy, incompetent, secret customer lock-in fanatics that siphoon off free labor, Sun is a bunch of greedy flip-flopping pseudo-open Microsoft pawns, IBM is a bunch of greedy Java-robbing thieves that publicly pretend to be golden Linux boys while sharpening the knives for Red Hat and Novell' then that leaves one company with a lot of free, negative advertising for their own product line over the apparently equally evil competition.

Why invest in GNU/Linux when all the vendors do their best to mutually assure you that they are all just a bunch of greedy would-be-Microsofts out there looking for ways to lock-in and milk the customer? You might as well buy the real thing for less if you have to pay the 'lock-in' tax anyway [1].

Microsoft have changed their tactics to divide and conquer

I have no idea if Microsoft is really 'framing' the current debates in the communities. But when you look around the accusations being thrown around, the only company that seems to profit from the aura of uncertainity being fabricated around GNU/Linux, OpenOffice.org, Java or Mono is the convicted monopolist with a lot of experience in astroturfing and FUD.

My own theory is that after failing to slash off the hydra's head at the source using SCO, Microsoft has switched over to trying to split the communities into isolated, quarelling fractions. Good old divide and conquer. And it's too easy to fall for it, as it works great with the frankness common among free software developers.

The higher art of trolling is not to postulate that 'Al Gore is a liar'. It is to ask seemingly innocent questions like 'Is Al Gore a liar?' and spice them up with a few quotes out of context, in order to get people to waste their time discussing that question. If a troll is a good one, he'll add some oil into the fire, by later asking questions like 'Did Al Gore really invent the internet?'. It's easy to draw the parallels to the current debates around Sun in the communities.

I'd say the GNU/Linux community[2] is getting trolled big time from outside. The pattern seems to be to give a bait to Sun to elicit an energetic[3] response, then to spoonfeed the response to other GNU/Linux vendors to get them to bash Sun, and to continue in cricles till the flames finally fan out.

Be transparent. Do good. Ignore trolling & heat.

As long as Sun's PR and execs leave something about their commitment to the communities open to interpretation, the trolls will have an easy job baiting Sun about it.[4]

Please don't feed the trolls.

[1] The 'less' referes to Microsoft's TCO marketing campaign.

[2] Which obviously includes Sun.

[3] Depending where you stand, of course. If you are the receiving end, it may look much worse than it is. If you are at the giving end, it may look much better than it is. If you are impartial, the resulting flamefest doesn't leave a good impression on either participating party anyway.

[4] Two points for Sun to work on: please improve your PR to be more transparent to 'the communities' you are in, and please try to work on the defensive attitude as that makes you a very, very easy target to troll.

Kaffe OpenVM updates

Thanks to Stephane's successful experiment with Odonata, a set of pure Java AWT peers, I've found and fixed a small bug in Classpath's 1.0 AWT event handling. That's my first post 0.11 checkin for GNU Classpath, yay!

Powerpc JIT3 for darwin has been merged in from JanosVM. I assume that it will need a bit of work before it is really useable on darwin, so we'll have to see if we can find some volunteers to get it into shape.

In other news, there were some fixes for cross-compilation, freebsd, networking, IPv6, threading, garbage collection, and java logging. I've got the upstreams from GNU Classpath, GNU JAXP, GNU inetlib and gjdoc synced up. Riccardo has turned up build problems on his darwin5 and darwin6 boxes, unfortunately. Chocky popped in on the list to explain why we were having all those problems with getting SP_OFFSET right on arm/xscale. And Noa continued his quest for a better kaffe by provinding a patch to enable XML output of mauve's results. That should make turning mauve results into nice web pages easier.

How Kaffe stole UNIX from SCO

If you want a good laugh, check out the Groklaw summary of the IBM vs SCO hearing on the 15th. There, SCO claims to have the copyright on the following character sequence:

int a,b,c;

and derived works like:

int a; int b; int c;

A quick grep through kaffe's source shows that kaffe, too, stole UNIX from SCO, as int a; turns up a few times in our source code.

I think SCO should be more creative, given that amazing amount of money they burn on their lawyers. They could simply lay claim to all the whitespace in their allegedly owned sources, and point out the verbatim copying that has taken part there. And if they are clever, they could file for copyright on the 'empty work' and then sue everyone else for deriving from their 'empty work'.

One must wonder though, what sort of lawyers SCO has, if they never heard of the standard techniques for determining whether software is derived. Given that int, ',' and ';' as well as the whitespace are syntactic elements of the C language, what precisely is it that SCO claims to hold the violated copyright to? The letters a, b, and c? The concept of variables?

56 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!