Older blog entries for robilad (starting at number 58)

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.

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?

Kaffe updates

I'm back in sync with GNU Classpath, so there is a bit of syncing going on with all the other upstreams. Laszlo has sent in a workaround for an ugly Kjc bug, so that the bootstrap works again without an external Java compiler. Another new developer, Noa, fixed a long standing socket problem, so that mauve now runs through on kaffe, again. There has been some progress on the powerpc-jit intergration from JanosVM, too, and I'm hoping to see a patch merging it in soon.

Riccardo has continued shaking out bugs in the builds and the build process on his vast array of platforms, so things are gradually getting better there, on the more exotic *BSD combinations, too. Kiyo has been hacking on NetBSD, too, getting jit3 to work on m68k-netbsd and starting to unify the jit engines on that platform, while Guilhem and Michael Franz did some cleanups for darwin. Michael also provided a new port, for ix86-darwin.

In other jit-related developements, Karl has received the jit4 code from Mike Chen, so there may be some interesting developments ahead. As it includes a port to MIPS, Casey was interested in it, too. But I guess he'll be more busy with real life in the next weeks than with VM hacking. Nevertheless, he delivered an initial implementation for support for signed JARs on the Classpath mailing list, so that will be one more feature to tick off when the patch goes in.

I've played a bit with Tom Tromey's gcjx, and it can build Kaffe's class library! The generated bytecode seems to have a few problems, but I didn't investigate further, and currently I'm stuck as gcjx does not link any more for me due to some g++ weirdness.

Too much exposure

Apparently Kodak is suing Sun for violating some weird patents that seem to have something to do with objects, data, and therefore something to do with Java, according to them. Kodak wants (finger to the lip) one billion dollars.

Sun apparently told Kodak to forget it in 2002 already, but the issue has surfaced up again, and failing to convince Sun to license the patents, Kodak decided to play patent bingo in court.

Therefore Sun decided to show Kodak in court that neither Java infringes, nor the patents are valid. I think it's great that Sun is picking up the fight and will try to invalidate the respective patents. I would have expected to hear a thing or two about it on the usual Sun gossip site from "groklaw's favorite" blogging, ponytailed Sun executive, but he seems to be too busy talking about how miserable IBM, Red Hat, Novell and HP are. Whatever.

Watching A Nordic Mythological Creature From A Safe Distance

Wow, that was an exciting couple of days on the autoconf mailing list when none other but one of the most successful masters of the art of irritating debate, decided to come in for a bit of heat.

He seems to be currently working his way around different programming languages. After successfully alienating both ruby and python communities, he proceeded to get himself roasted by the ocaml developers, not without briefly touching Eiffel and Lisp communities, though. He's through with procedural languages, as far as I can tell, after seing his mark on the C++ and Java newsgroups.

He is inspirational, provoking both anger and mild amusement. The abusive period seems to have kicked in around 1998, and had been going on strong ever since. Given that he has just finished his request on autoconf lists, I'd expect him to either pop in on the m4 mailing lists, or to go straight through to another functional language.

So watch out, if you're in his current target group. Live and let live :)

It ain't Java till it has the RCSID

I've walked up to the Uni today, and read a nice paper from the authors of a nifty static analysis tool for Java, FindBugs. It is a pattern matching based tool, that emmits warnings for popular problems in Java code.

The most interesting part for me was the comparison of bugs found in GNU Classpath, a free software implementation of class libraries for Java, and Sun's own, proprietary JDK 1.5.0. The authors compared classpath 0.08 vs JDK 1.5.0 build 59.

Classpath 0.08 is 457 KLOC, while JDK's rt.jar weighs in at 1,183 KLOC. That's about 2.5 times the size of GNU Classpath's code base. Using FindBugs, the authors found 724 suspicious constructs in GNU Classpath, but they found whopping 3,314 suspicious constructs in JDK's rt.jar. In other words, there are around 4.5 times as many potential problems with Sun's proprietary code as with FSF's free software implementation.

As a free software author, I'd argue that such an apparent quality discrepancy between proprietary and free software implementing the same tasks (core java class libraries), is rooted in the fundamental difference between open and closed software developement models: it is very easy for anyone to fix the bugs in Classpath and get their patches accepted by submitting them to our mailing lists or the Savannah patch tracker, while Sun's openly closed community source effort puts massive barriers in front of potential participants in form of NDAs, indemnification requirements, or even accounting regulations in the source code license, in case that you happen to need one.

As proprietary software goes, the JDK has its share of embarassing code. Check out Sun's programmers making first baby steps with revision control systems in their live code base, back in the mid-90s. Actually, the RCSID fields are in there in JDK 1.4, too. They are probably in earlier versions, as well. So if Sun's claims about their Java compatibility test suite are true, then surely some poor intern must have written tests for those vital parts of the JDK APIs. If you don't have the completely useless RCSID tags as protected fields you are not Java-compatible, right? Binary compatibility would break, and the ghost of 'Write Once, Run Anywhere' would come to claim your bytecodes.

Well, it's not like Sun really cares that much about binary compatibility all the time. All the WORA marketing talk aside, Sun has ocassionally bowed to the pressure of having to fix stupid design mistakes by, well, perpetuating them. Check out the last mouse event for now and for ever. Actually, the value of the constant has changed between JDK releases, as someone invented the mouse wheel without telling JDK developers about it. Instead of dropping the integer constants altogether in favor of an interface that's more flexible and may be able to cope with novel pointer devices without breaking binary compatibility each time someone adds a gadget to a mouse, Sun decided to, well, modify a constant.

Still, my favorite API blunder in JDK is 1337. It's the 53P4R473R from the land without code review, spell checkers, or both. This one has been with us since at least JDK 1.2. Long live Rite Once, Run Anywhere.

So, given all the 'will Sun ever open source their Java code' posturing, I can't help but wonder if I'd really want to deal with one million lines of code that has almost double the defect density of Classpath, with apparently abadoned parts happily bitrotting their way into JDK 1.5 without review. Maybe for those APIs where GNU Classpath doesn't have an implementation yet. But given that GNU Classpath doesn't really have a tradition of accepting poor code, I'd doubt the JDK sources would make it in, without some peer review. It could be the first peer review some of Sun's JDK source code would be getting since 1997, according to RCSID tags.

28 Jul 2004 (updated 28 Jul 2004 at 10:14 UTC) »
The Joys Of Not Having Access To The TCK

I've been trying to figure out what the precise terms of the TCK license in J2SE 5.0 will be for months now. Things are moving slowly, but it looks like Sun may eventually freebeerize the access to their J2SE TCK for 'qualified non-profit entities and individuals'. That would be a great gesture towards projects like GNU Classpath, that strive to be as compatible with the specifications as possible. It's not clear what the precise terms will be, though.

And that's why there are times when I am glad that Kaffe.org doesn't have access to the J2SE TCK. In particular when I look at the current pains some open source J2EE projects are having with their TCK access.

What's a TCK anyway?

A TCK is a 'Technology Compatibility Kit', a test suite for some Java technology specification. The TCK is like a binary oracle of specification compliance: an implementation passes the TCK, and poof! it is magically branded compatible.

Well, actually, for the magic to work, you need to license the TCK, and you usually do that by letting money work its magic. A J2EE TCK was hundred thousand US dollars worth, last time I heard.

TCKs for Free!

Fortunately, thanks to ASF's efforts, there is a nice Compatibility Testing Scholarship Program. The obvious catch seems to be that noone signed up, according to that web page.

J2EE Cert Is Money

That's not exactly true. Two open source J2EE servers, JOnAS and Geronimo signed up for the scholarship, while JBoss, being developed by a for-profit entity, failed to qualify for a free scholarship, and had to pay for the TCK license.

Finally, JBoss passed the TCK, and got certified. Chances are that Gueronimo and JOnAS will follow suit, too. And given that in the J2EE market a certification is an important seal of compatibility, it is a door opener to places that were reserved for non-free software before. Wonderful! Congratulations to JBoss developers! Thanks to Sun for supporting open source J2EE servers by granting them TCK scholarships!

Licenses, Pesky Licenses

Well, it would really be great if things were that simple. But then, there is always the controversional issue of licenses to spoil the fun. And, in all its glory, here it is, the 'NOTICE FROM SUN MICROSYSTEMS' that both Geronimo and JOnAS have on their web pages:

Any redistributed derivative work of the software licensed hereunder must be compatible and branded with the appropriate compatibility logo specified by Sun and licensed by Sun pursuant to a separate Trademark License required to be executed by you with Sun. Redistribution of the software licensed hereunder must retain this notice.

So what does this mean, in real life? It means that you can not redistribute a patched version, of course, unless you happen to be a TCK licensee and the patched version passes the TCK. It may also mean that you can not create packages of the software, as a package could be seen as a derivative work. But wait, it gets better.

Let's say you fetch an uncertified build of Geronimo. Would it be a 'derivative work' of a certified build? If so, are you allowed to redistribute it at all? Probably not, according to this notice.

Let's say you find a security problem in your J2EE server code and the fix uncovers a bug in the TCK. Can you distribute the security patch to protect your users? Probably not, according to this notice, at least not until the TCK is fixed.

And so on. The ASF has figured that out, and is trying to get Sun to reword the notice into something that's not contradicting the open source licenses of the code in question. ObjectWeb has a lengthy wiki page going into some legalese gymnastics of interpreting the LGPL to make it work with the 'NOTICE FROM SUN'. The ultimate answer seems to be that noone knows for sure who can distribute what to whom. Furthermore, for added enjoyment there is a bit of hinting on the JOnAS Wiki that Sun's legal department may feel like enforcing some of their patents or prosecuting potential trademark infringements if one redistributes intermediate, uncertified builds of a J2EE server.

As if that was not enough of legal uncertainity surrounding the poor Geronimo and JOnAS projects, a J2EE certification with the 'NOTICE FROM SUN' may turn out to be a one way street with respect to how the author can license the code. Interestingly, JBoss does not display such a notice, as far as I can tell. It may have something to do with JBoss not going through the scholarship, but buying a TCK license from Sun instead.

I hope the ASF can find a way to convince Sun to protect their trademarks in a different, less cumbersome way. I also hope that the J2SE 5.0 TCK won't come with such a 'NOTICE FROM SUN MICROSYSTEMS'. It would make having the TCK pointless if one would not be allowed to distribute the result, and allow people to redistribute it. That sort of thing simply does not work in open source.

But till then, if you're writing a J2EE server, you may want to consider holding off your TCK scholarship application until the 'NOTICE FROM SUN' gets reworded into something more socially acceptable.

No Meat For Me, Please

There is a whole side issue here, that Sun seems to have overseen. Some people may not be interested in sporting the Java trademark on their software for various reasons. Kaffe is not Java(TM). GNU is not UNIX(TM), and so on. The 'Business Terms' for the J2SE 1.5 TCK seem address that, by not granting any trademark license rights to qualified entities and individuals under the free beer program. That's one half of the story. The other half is not having GPL-incompatible 'STRINGS ATTACHED' notices with the TCK.

Advogato is back!

Everyone's favourite pond in the savannah has returned back to life. Now they are looking for volunteers to help out with mantaining the site.

Movies: Troy

Ah, what a dull work of art! It's almost as good as 'Gladiator' in wooden acting. The story is hacked together, and serves as a thin veil around Brad Pitt's major acting feature in this movie: his naked butt. But as showing Brad Pitt running around naked for three hours doesn't really cut it, there is some jumping around with swords, spears and bows thrown in, and a bit of subtext commentary on invasions for stupid reasons.

Unfortunately, they got the cast completely wrong. It feels like a school theatre group playing 'Illias' on a way too big stage. It only gets funny when it's ridiculous. The whole siege business is turned into a three week long bonfire party. So when the actors act up about the grim nature of war, and the movie tries to weave in a bit of subtext, it just doesn't work that well, when the siege looks like a boy scout day by the seaside.

10 May 2004 (updated 10 May 2004 at 19:25 UTC) »
Pulling a SCO for Fun and Profit

I've looked more closely at the SCSL, since the JavaLobby discussion was still rather unsatifying. This time around, I was interested in what implications SCSL has in real life. Anectodal evidence, in a way.

With something as broad as the SCSL, you probably don't want to scare your customers too much, so you go after a few selected targets. Sun has worked hard to make Java the COBOL of the nineties, i.e. the thing you use to do business. They have succeeded, as far as I can tell.

So I've looked at how Sun has used the SCSL in the Java enterprise field, against Lutris and JBoss.

While I have no inside information on the deals Sun struck with JBoss or Lutris, I do find both cases to be interesting, since they both involve using SCSL as the big stick to put licensees under pressure.

Let's look at Enhydra first. Back in 2001, Enhydra was a rather hip open source enterprise Java application server. It was the flagship open-source product from a small, but successful company. Eventually, Lutris had to pull the open source Enhydra enterprise application server off the web. There is the 'white-washed' press release story, that is all about an amicable agreement among partners. And then there is the story from the trenches that talks about some nice implications of J2EE's SCSL licensing for open source projects and how it can be nicely enforced.

Then of course, there is the big JBoss story from last year. We remember, back then, JBoss was a clean-room Java application server implementation (there is a bit of cute 'Lutris betrayed you' spin in that one).

Back then, Marc Fleury said: "Sun has never accused JBoss of violating any of their licenses, and JBoss is not violating any of Sun's licenses by distributing JBoss." And as JBoss grew stronger, and started to reap the benefit from Enhydra's forced demise, Sun apparently proceeded to the next item on their SCSL enforcement list. Et voila, we had the great flame fest between JBoss and Sun about J2EE TCK, compatibility and what not, until Sun finally invoked the SCSL.

All of a sudden, JBoss gave up the rhetoric, settled an SCSL 'incompatibility' and paid an undisclosed sum of money.

So, while bits and pieces from SCSL may seem like 'nonsense' Sun didn't really have problems in the past enforcing it against their (or their customer's) competitors. In both the Lutris and the JBoss case invoking the SCSL was apparently what broke the camel's back.

Back then, we didn't have 'pulling an SCO' to describe attempting to enforce 'funny' licensing statements, though.

One of the (many, I admit) claims in SCO's law suit was that IBM put code that IBM wrote independantly from SCO's code into Linux and thereby violated the contract they had with SCO.

While such claims seem ridiculous at first, the SCSL apparently gives whoever owns the Java IP the right to claim all sorts of 'funny' things over independant third party Java code.

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