The Wayback Machine - https://web.archive.org/web/20170630082449/http://www.advogato.org/person/robilad/diary.html?start=46

Older blog entries for robilad (starting at number 46)

Is Java open source now or what?

James Gosling wrote in his weblog "If we do something to make Java even more open-source than it is already, having safeguards to protect the developer community will be something we pay a lot of attention to."

Well, I'm a curious person. I'm usually up-to-date with what's happening in the Java world, so I figured I must have missed the day Java became open source. Alas, I decided to put the great James Gosling to a test. My tools will be the Open Source definition version 1.9 and the Sun Community Source License version 2.3.

Since James talks about making Sun's Java implementation "even more open-source", let's see how open source Sun's code already is, by checking each clause of the open source definition against the SCSL.

Open Source Definition vs. SCSL

* Free Redistribution

Nope.

* Source Code

Doesn't allow free redistribution, so redistribution in source code fails, too.

* Derived Works

Nope.

* Integrity of The Author's Source Code

Doesn't allow free distribution of separate modifications either.

* No Discrimination Against Persons or Groups

I guess it passes that one, yay!

* No Discrimination Against Fields of Endeavor

Nope. Explicitely limits fields of endeavor to research, commercial use, or internal use.

* Distribution of License

Nope. The TCK license comes with what's effectively a NDA.

* License Must Not Be Specific to a Product

I guess it passes that one, yay!

* License Must Not Restrict Other Software

Nope. Once you've agreed to SCSL, you can't distribute non-compliant software. So you couldn't redistribute kaffe, gcj, or even more up-to-date versions of Xerces if they break tests in the TCK.

* License Must Be Technology-Neutral

Nope. It's a click-wrap license. It even has a pointless [ACCEPT] [REJECT] at the bottom

Total: 2 out of 10.

I'd guess that Sun's java implementation is slightly more open source than my Microsoft Windows 98SE installation CD-ROM. I haven't bothered to check the Microsoft Windows 98SE EULA, though, so I may be wrong.

Protecting Java developers with SCSL: The Top 5 Safeguards

But wait, there is more. The SCSL is a fascinating read if you're into mind-boggling legalese that's being marketed as 'sort of open-source'. I'll do you the favour and post the funniest bits and pieces on how the SCSL protects the Java developers.

Top 5: Debugging your Java code can violate the license

People often think that the SCSL is there to prevent forking and stealing of Java. That's not the whole deal, as the following exhibit from the SCSL shows:

GLOSSARY, 1:"Commercial Use" means any use (excluding Internal Deployment Use) or distribution, directly or indirectly of Compliant Covered Code by You to any third party, alone or bundled with any other software or hardware, for direct or indirect commercial or strategic gain or advantage, subject to execution of Attachment D by You and Original Contributor.

So let's say you're writing a J2SE application for a customer, and debugging it in one of those friendly IDEs that allow you to trace through system library code. You see in system code why it breaks, and discover there is some facet of the API that was not well documented in the J2SE docs, that breaks your code. You fix your code to work around it, and ship it to the customer.

Congratulations, you've just violated the SCSL, unless you've got a commercial license use with Sun, since your use of SCSL covered code is no longer limited to your company.

You'd need to enter a real, written contract with Sun, that costs hard cash, indemnifies Sun, allows them to inspect your bookkeeping, and a lot of other interesting things. Of course, the commercial license in Attachment D does not really allow you to debug Sun's code anyway.

Top 4: All Your Java Are Belong To Sun

GLOSSARY, 13. "Modification(s)" means (i) any change to Covered Code; (ii) any new file or other representation of computer program statements that contains any portion of Covered Code; and/or (iii) any new Source Code implementing any portion of the Specifications.

13(i) is your normal copyright law. 13(ii) is your normal copyright law with an extra spin: it tries to prohibit fair use by claiming that containing *any portion* of SCSL covered code turns your code into a modification of SCSL covered code.

Given that you're writing your code in java, chances are that any class you write shares a certain amount of text with some SCSLd covered code, simply because they are written in the same programming language. So 13(ii) covers pretty much all java code ever written by anyone who licensed code under SCSL. To put more graphically, GLOSSARY,13(ii) == All your Java are belong to us

Let's get to 13(iii), which is a little more convulted. It says any *new* Source Code implementing *any portion* of the *Specifications*. New code is quite obvious, so it coveres all new code you write. Then we have a clarification, it's any new code you write that implements any portion of some specs. "implementing any portion of specs" doesn't say 'extending Object is OK', it says "there are some specs, you implement any single bit out of them, your code is covered". Both the JDK API spec and the JLS cover java.lang.Object's method signatures. If your code extends java.lang.Object, it implements "a portion" of the JLS and JDK API, since you can call the methods covered by the Object API on it. If that's too far fetched for you, take classes implementing the Serializable interface, or your classes extending SCSL covered classes, and overriding methods in them.

But the really convulted part of 13(iii) is in the reference to "Specifications". If we look up "Specifications" in the glossary, we'll find

GLOSSARY, 21. "Specifications" means the specifications for the Technology and other documentation, as designated on the Technology Download Site, as may be revised by Original Contributor from time to time.

This clause gives the copyright owner (or whoever hacks the site) a backdoor to revise the specifications, and claim violation afterwards, even if you were compliant originally. The license does not specify the "Technology download site" precisely (with some URL) anywhere. It does specify the community source download site, but that one has no JDK specs. Beautyful.

Top 3: Shut up, And Don't You Dare To Write Tests

One of the cute things about Sun's Java implementation is that Sun has apparently written a huge set of test cases to verify the conformance of their implementation to the API specification. At least that's what the rumour says. If someone who licensed the TCK would really tell you if Sun's own VM passes the tests, he'd have to kill you, according to the license.

ATTACHMENT E TECHNOLOGY COMPATIBILITY KIT, 1. TCK License.:

b) TCK Use Restrictions. You are not authorized to create derivative works of the TCK or use the TCK to test any implementation of the Specification that is not Covered Code. You may not publish your test results or make claims of comparative compatibility with respect to other implementations of the Specification. In consideration for the license grant in Section 1.a above you agree not to develop your own tests which are intended to validate conformation with the Specification.

That's a NDA, as far as I can see it. You can not talk about your TCK results. You can not say that you're more TCK compatible than Sun for example, even if it was true. Noone can check how TCK compatible Sun's implementation is, and publish their findings.

So you can't take IBM's and Sun's runtimes and see which one is better wrt to TCK compliance on your particular system. Now you may be asking: why should I care, Java works everywhere ?

Except that it doesn't. It usually takes me a few minutes to crash Sun's. I bet it passed the TCK on the particular operating system version they tested it on last year, but operating systems change, security patches get applied, and whoops, the rock-solid JVM is no more rock-solid. But you can not test your client's specific os+vm setup with JDK TCK and share that information with your client, without breaching the TCK license. Beautyful.

On a side note, I especially appreciate the 'you may not write your own tests' clause. If you write your own test to find a bug in Sun's code that violates the spec, and submit a bug report to the BugParade, and have licensed the TCK, you've breached the license.

Top 2: Show Me Your Code, Or Else

Beside claiming ownership to all the code anyone who licensed the J2SE code from Sun, the SCSL has also a second ace up its sleeve to protect the mean Java developers from themselves: requiring access to all your extensions' interfaces. With your TCK due in 90 days. Or else.

3.e) Extensions. (i) Covered Code. You may not include any Source Code of Community Code in any Extensions; (ii) Publication. No later than the date on which You first distribute such Extension for Commercial Use, You must publish to the industry, on a non-confidential basis and free of all copyright restrictions with respect to reproduction and use, an accurate and current specification for any Extension. In addition, You must make available an appropriate test suite, pursuant to the same rights as the specification, sufficiently detailed to allow any third party reasonably skilled in the technology to produce implementations of the Extension compatible with the specification. Such test suites must be made available as soon as reasonably practicable but, in no event, later than ninety (90) days after Your first Commercial Use of the Extension. You must use reasonable efforts to promptly clarify and correct the specification and the test suite upon written request by Original Contributor. (iii) Open. You agree to refrain from enforcing any Intellectual Property Rights You may have covering any interface(s) of Your Extension, which would prevent the implementation of such interface(s) by Original Contributor or any Licensee. This obligation does not prevent You from enforcing any Intellectual Property Right You have that would otherwise be infringed by an implementation of Your Extension.

Basically, this means your extension's specification must be published "free of all copyright restrictions with respect to reproduction and use", and so must be the TCK, i.e. the test code for your library. Why Sun fails to provide their TCK under similarly liberal terms is a very interesting question.

Anyway, for some added fun, 3.e.iii prohibts enforcing the GPL on your Java libraries if you agree to SCSL.

Top 1: All Your Libraries Are Nothing But Simple Extensions

Oh, and of course, the term Extension is so broadly worded that it covers all Java library code licensees ever wrote:

9. "Extension(s)" means any additional classes or other programming code and/or interfaces developed by or for You which: (i) are designed for use with the Technology; (ii) constitute an API for a library of computing functions or services; and (iii) are disclosed to third party software developers for the purpose of developing software which invokes such additional classes or other programming code and/or interfaces. The foregoing shall not apply to software development by Your subcontractors to be exclusively used by You.

(i) covers all java code, (ii) reduces coverage to exported (i.e. public/protected) members, (iii) reduces coverage to libraries.

Unless the library code you ship to your clients consists of package-private classes and methods, you have to disclose your APIs and *write a freely available TCK* for it. I've never seen such things for most of the Java code out there, which strikes me as mildly weird. If the SCSL is so cool, you'd expect a lot of people documenting their "extensions", no?

Bonus Top For Consultancies: Keep Off The Javax

Oh well. So you decide to give up writing Java library code just to have it owned by Sun, and go into consulting to sell code other people wrote to your clients. No go, the SCSL has a weird package naming clause, that doesn't allow you to use what Sun considers to be its own namespace turf.

3.e.(iv) Class, Interface and Package Naming. You may not add any packages, or any public or protected classes or interfaces with names that originate or might appear to originate from Original Contributor including, without limitation, package or class names which begin with "sun", "java", "javax", "jini", "net.jini", "com.sun" or their equivalents in any subsequent class, interface and/ or package naming convention adopted by Original Contributor.

The great thing about that clause is that it actually prohibits the distribution of J2EE servers with Sun's JVM by licensees of J2SE source code under SCSL.

A J2EE server implements packages in the javax namespace by definition. So going from 'start enterprise Java consulting' to 'jail' takes three simple steps:

  • Step 1: license J2SE source code under SCSL
  • Step 2: Distribute JBoss to your client with Sun's JVM
  • Step 3: go to jail for voilating 3.e.iv.
Keep Trying, James

A license that's so broadly (and poorly, in my opinion) worded that it allows such (unintentional, I assume) interpretation should be reworded in a cleaner fashion, really. It's very, very far from open source. It doesn't even protect Java developers from anything, it just puts them under extra legal risk, and makes abstruse claims of code ownership, not unsimilar to those of SCO in the IBM case.

While I don't think Sun's management would try to enforce the SCSL to the letter, it would be quite funny if Microsoft bought Java from a bankrupt Sun, and then went ahead to enforce the SCSL against developers who accepted the license if they wouldn't switch to dotNet.

Meanwhile, ...

There was a new GNU Classpath release that looks very good. A new Kaffe OpenVM release is in preparation, too.

No "safeguards", there, though. We couldn't make either "even more open-sorce" then they already are, being licensed under GPL(Kaffe) and GPL+linking exception(Classpath).

Kaffe OpenVM

Helmer and Guilhem are working their way through interesting bugs in the core. I'm meanwhile syncing Kaffe up with GNU Classpath's latest changes, and contributing some small fixes back. Thanks to Eclipse, I got quite a few imports cleaned up, so that's slowly going back into GNU Classpath.

Movies

"Triplettes de Belville" was quite enojable. Good music, straight story, nice refences to Tati, a few good jokes.

Kaffe OpenVM

Well, tempus fugit, and all that. In the last three weeks we got a few new developers on board. There is doogie, who has almost single-handidly beaten a few thousand warnings into the ground last week. And there is Jim Huang, who's been testing a lot of interesting stuff with Kaffe in preparation for an interesting Kaffe Multi-Media Project.

Thanks to jpick, we've got a release plan for 1.1.5. It's due in three weeks. As usual, there is a ton of things I'd like to see happen before the release. I've been hacking on A,C,F and I from that list, and it looks like I'll be able to get gjdoc into kaffe very soon now, mostly thanks to efforts from Arnaud Vandyck on integrating libxmlj into GNU JAXP.

In other news, Guilhem has been quite busy recently fixing kaffe's kjc, java.text implementation, NIO, and almost everything else he could get his hands on. He's a great hacker to have on board. I was also pleased to see Helmer return with a series of patches, to improve ARM support, among other things, and Ito tracking down a few ugly bugs.

24 Mar 2004 (updated 25 Mar 2004 at 17:57 UTC) »
Kaffe OpenVM

After wrestling with the automake warnings, I decided I had some bigger fish to fry, and went after the gcc warnings. Using some nice autoconf machinery from the AC Archive I extended our configure script to add as many gcc warnings as I consider useful.

The reason for this is that kaffe seems to happily crash on so many platforms. So instead of chasing them all down with gdb, I decided to take a more indirect approach to debugging, and start fixing all the ugly, nasty hacks in our code first, before I even think about wielding the debugger on them.

Of course, the initial results are disappointing yet promising. Today I've only barely scratched the surface of the few thousand or so warnings to fix, but it's fun, in a laid back way. You look at code, try to figure out what the compiler means, and when you notice that the compiler's right, chuckle, and move on to the next fix.

Kaffe OpenVM

Patch queue is going down, somewhat. I've been wresting with some odd platforms like sparc-netbsd and sparc-openbsd in order to get Kaffe up and running there with the help of Riccardo Mottola. There is some progress, and there are many interesting compiler warnings to look into. Ultimately, this work should result in a better, cleaner kaffe core.

I've also taken a shot at reducing the immense number of warnings autotools (automake 1.8.3 and autoconf 2.59) generate whenever I regenerate the build system. Most of the warnings come from third party m4 files, like the ones distributed with libtool or gettext. So today I wrote a simple script that copied each m4 file to its own directory, renamed it to configure.ac, called autoupdate on it, and moved it back. It mostly worked, except for a bug or two in autoupdate. I'll push the fixes upstream later. but first I want to squish the warnings produced by gettext m4 macros and libtool.m4.

In other news, it seems like SwingWT could run on Kaffe. That would give us another interesting alternative for those applications using Swing.

18 Mar 2004 (updated 18 Mar 2004 at 20:47 UTC) »
Kaffe OpenVM

Gradually working off the patch queue. Some nice stuff is coming in for JNI, due to Jim Huangs inverstigations into running SwingWT and recently JSDL on Kaffe. He's gradually showing up soft spots and solution, thus helping Kaffe's JNI evolve into a good choice for applications that need a little bit of JNI.

Other than that, I've been playing with MIPS2Java, and converted a SPASS MIPS binary into a Java class capable of running on Kaffe. It ran faster than on Sun's JDK for a simplistic test on a pelletier problem. That is quite fascinating to me, since Kaffe doesn't have a hotspot jitter. It's also an order of magnitude slower than the native code. I haven't tried recompiling the class with gcj, though.

As the next step, I took Portable Dot Net from dotGNU, and started (automatically, of course) turning it into java classes, in order to bridge that seemingly huge rift between Dot Net and Java, allowing a Dot Net runtime to run on a java runtime. Like a primitive IKVM in reverse. I've so far managed to convert the tools, and the runtime itself, but haven't started to build the class library, which I expect to be the interesting test if the concept can work, in practice.

hp's article on Java and other nice languages

While I'm typing this, my fellow GNU Classpath hackers are busy creating and improving a free software Java class library that's not only licensed under more reasonable terms then the non-free implementation, but also rivals it in terms of performance and aims to be the better choice in the long run.

Almost every free software implementation of a Java runtime out there (and a few non-free ones) is using GNU Classpath as the Java class library of choice, including even IBM's own JikesRVM. The progress GNU Classpath has made in the last year alone through this immense cooperation effort is mind-blowing. Nowdays, you can not only run tools like Ant or Tomcat on free runtimes like Kaffe OpenVM, you can also run complex enterprise applications like OfBiz and Eclipse.

If people write *portable* java code, and stick to the implemented classes or work together with the GNU Classpath developers on implementing the missing bits, like Havoc suggests, I think free java runtimes could turn 'write once, run anywhere' from an over-hyped marketing joke into reality.

Unfortunately, some open source java projects don't write portable code. They use internal classes in sun.* packages, which makes them about as portable as Microsoft applications using undocumented Win32 functions. Some people write code that only works because their unwritten (and often unwarranted) assumptions about the runtime their code was written on held true. It's the same with C, or C++: writing portable code takes care in any language.

But, the good thing about the free runtimes is that they can take Java applications where no other runtimes can take them: you can compile things down to native code, run it on non-mainstream platforms like embedded PowerPC chips without an FPU, combine Java code with .Net ... And the great thing about it is, that most of the free Java runtime developers are not building their own little lock-in solutions, but are instead cooperating on creating a larger playground for everyone, by sharing knowledge and code.

I boldly predict that Java-Gnome on free runtimes will rock the Linux application world in the years to come. Java-Gnome applications are going to make sure free Java becomes a success on the desktop. Free software enterprise applications like OfBiz, JBoss, Jonas etc. will do the same for the server side. The major stumbling stone right now is the unportable java code in popular free software libraries and applications like OpenOffice.org, and people using features that are not implemented in free runtimes yet. Those are technical and educational problems, that can be solved with a little bit of good-will from all parties.

If the non-free java runtimes ever become free software, it will be because the alternatives becoming good enough to surpass them, not because of third parties begging the copyright holders to free them from the shackles of the restrictive licenses. There is no interest for Sun in a free software Java implementaion right now. If the alternatives start making inroads onto the server side, they may be inclined to reconsider their licensing scheme. Just like Trolltech did, when alternatives to Qt started becoming useable to create whole desktop environments, let alone applications. So if we want a free software Java platform, our best bet is not writing open letters to Sun, and begging them to donate code, but working on a better, freely licensed implementation instead. In the long run, "Le mieux est l'ennemi du bien". We can chose to attempt to reach the best, or to take what others assure us is good enough on their restrictive terms.

That aside, it would be great to see Sun and IBM take the plunge and turn their Java runtimes into free software today rather than tomorrow. But there is no business case in it for them, as far as the responses to the open letters go.

On the other side of the Java runtime world, free runtime developers collaborate between each other, and there is a lot of interest in better cooperation with the projects over the language fence (Mono, dotGNU, parrot). I believe that in a few years, the debate 'Java, C++ or C#' may look like an anachronism from the old days, when such questions were relevant, before free software implementations weren't superior to non-free ones. Just like the question 'Solaris, GNU/Linux or Windows' is gradually turning into a sure shot for GNU/Linux.

Kaffe OpenVM

Kaffe 1.1.4 is out, finally. A lot of work on small bug fixes, and cleaning up the source code went into that, but nevertheless, there are still some challenges left for the new hackers, like fixing all the broken debian non-mainstream ports.

FOSDEM

Been there, seen it, it was great. I loved meeting all the great developers on different free runtimes, and even some first-generation kaffe hackers like DV. After seeing the energy there, how far we got with cooperation on GNU Classpath, and how much interest there is in even closer cooperation between different free runtime developers, I believe that the future belongs to free java runtimes.

It was like seeing the *BSD, Linux and Hurd people coming together to work out a way to produce an Ueber-UN*X.

Kaffe OpenVM

My attempts to fix the bizarre 'function object code gets partially overwritten by garbage in middle of execution' bug on Cygwin, have turned up that the bug is even more bizarre than I thought originally. I thought I'd blame it on some bad array index in some C code. But the object code for the function gets partially overwritten before main is called at all. Now I am really, really puzzled.

Recentlog Threads

dwmw2: If you're sharing the repository on every single line you change, sure. But if you prefer to work locally with the copy in your own versioning system until your changes stabilize, then the RCS tags differ in not very meaningful ways.

I've never used -ko to import text sources, so feel free to call me a veggie ;) Isn't the effect that CVS treats the file as binary? I wouldn't want to have large, whole file diffs, on each checkin on the imported files if I'm tracking another project's progress in my CVS. But hey, I admit that I haven't read the Cederquist yet, so I may be completely wrong ;)

Kaffe OpenVM

With the next developer release, 1.1.3 out of the door, the focus goes back to bug fixing, patching up platforms like m68k-netbsd, or cygwin, and improving support for Eclipse, as well as getting JBoss 3.2.x to run better.

Tomcat 5 is also on the list of apps, I'd like to see running well on the next release, due in 2 months.

Currently I'm fighting with a really bizarre crash on Cygwin : a function gets its first few bytes modified somehow. No idea why it happens, but the disassembly when I get the SIGSEGV is different from the disassembly before I run kaffe. Setting watches on the function didn't help.

The other bizarre problem is some broken assembler code on m68k, well hidden in a C macro. So now I'm slowly turning macros into inline functions and silently cursing whoever decided against using inline functions in the first place.

RCS tags are evil

RCS tags are those cute $Date, $Id, $Log etc tags you find in people's source code. The upside is that they are meant to give you easy access to versioning information. The downside is that they give you tons of bad diffs as soon as there is more than one person working on the project, or even worse, another project decides to import your sources.

RCS tags in CVS projects don't give you anything that the cvs command can't tell you on demand, without wasting space with redundant information in source files. RCS tags are so old fashioned, you better get rid of them today before someone looks at your code!

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