Slashdot Mirror

You can include the FSF in the list of authors of GPL programs who disagree with your interpretation.

Yes, I'm aware of this and find this interpretation bizarre in that it is ad hoc and overly specific, whereas the license is written in general terms on principles and isn't limited to technical mechanisms. In particular, any library can be wrapped by command lines or pipes -- why is it that a library that has been wrapped in this way suddenly "mere aggregation"? It doesn't make sense.

At least they have the good sense to say this: "This is a legal question, which ultimately judges will decide."

A common example would be the way many proprietary router web interfaces execute GPL utilities and receive their output via pipes or similar mechanisms.

There's been lots of lawsuits around BusyBox. I don't to what extent they require source releases. You could also read about Jin vs IChessU:

"He also said that they are planning to wrap Jin in a layer that would allow it to be controlled via a socket. This would allow IChessU to write any additions "outside" of Jin, without releasing the source to them. I told Alexander that I believe this would still, most likely, be violating the GPL (GPL FAQ on aggregation)."

The above, perhaps strangely, uses that entry as opposite to "mere aggregation".

Anyways, what really counts is what the license says, what the copyright holder thinks (only he has grounds to sue), and what a judge decides. My interpretation is based on what I believe is a straightforward reading of the license that also follows the intent of the license.

I am a UI designer by trade, and many is the time I have thought about wading in to a F/LOSS project in order to improve the usability of the interface (last one I considered was IPCop).

Perhaps you should actually try before giving up. I'm sure there are many projects out there who would love to have a good UI designer on board. Heck, if you want to help me with my Jin client for chess servers, I would love every bit of what you could offer.

• Chess board diagram composer.
• A GoogleMaps-like GWT library.

Here's the situation. A startup company took a GPL licensed program, made modifications to it and dynamically linked to a proprietary third party VOIP library. Initially they weren't going to release any of their modifications, but after being contacted by the developer they tried to come into compliance. However, the use of the proprietary VOIP library is not compatible with the GPL as they are unable to provide source code for it.

The startup company was the first to sick the lawyers on, but the developer has fought back better. For a while it looked like there was going to be a default judgment in the developer's favor but now it looks like it is going to court.

See http://www.jinchess.com/ichessu/ for more details.

And to demonstrate just how powerful it is, the server-side of my chess diagram composer is a PHP script whose entire function is to create a single ImageMagick command that draws the chess diagram (and pass the result to your browser). Even the piece sets are (pre)rendered from TTFs using ImageMagick.

Just a few hours ago I finished a small, mostly-for-fun project in GWT, and now I see a GWT-related story on slashdot. Surely it's not a coincidence and therefore I must pimp my project: a chess board diagram composer.

And yet some people have a problem understanding that.

Although the content is currently the same, the real URL of my Jin website is http://www.jinchess.com (could an editor please fix it - I think it can handle the residual slashdotting). I'll now get back to reading everyone's comments and reply where I can :-)

Tangentially en topic, but this is a good chance to post my article which slashdot has rejected twice now:

I am the developer of Jin, a client for chess servers, licensed under the GPL. About 6 months ago I was contacted by the Internet Chess University, asking for a commercial license for Jin. After negotiations failed, IChessU decided to nevertheless use Jin, but did not release the full source code of the client they built. I have contacted both the FSF and the EFF, but they were unable to help me because they are not licensed to practice law in Israel (both I, and the owners of IChessU are Israeli). I have no intention of dropping the issue, but I am now stuck with paying a lawyer out of my own pocket, which is very limited. Read the whole story.

The question is then, what kind of protection does the GPL really give the small-time FOSS developer, who can't afford fancy lawyer to enforce it? What does this mean for such developers?

Tangentially en topic, but this is a good chance to post my article which slashdot has rejected twice now:

I am the developer of Jin, a client for chess servers, licensed under the GPL. About 6 months ago I was contacted by the Internet Chess University, asking for a commercial license for Jin. After negotiations failed, IChessU decided to nevertheless use Jin, but did not release the full source code of the client they built. I have contacted both the FSF and the EFF, but they were unable to help me because they are not licensed to practice law in Israel (both I, and the owners of IChessU are Israeli). I have no intention of dropping the issue, but I am now stuck with paying a lawyer out of my own pocket, which is very limited. Read the whole story.

The question is then, what kind of protection does the GPL really give the small-time FOSS developer, who can't afford fancy lawyer to enforce it? What does this mean for such developers?

FICS is not better on the timestamping front though. Their own algorithm, called timeseal is not any more secure than timestamping. I know because I wrote a client for both ICC and FICS.

The article says that no unix chess client comes with integrated timestamping, which is a good reason to plug mine - Jin, which does.

Also, I'm an ICC admin and I can tell you that we're looking into the issue and will probably publish an official response later.

...the misconception that JAVA is very slow. 1.1 was pretty darn slow sure, but...

This is actually not true. The various 1.1 JVMs were fairly slow (at interpreting bytecode) - true. But the graphics were very responsive. In fact, Swing under MS VM is still more responsive than even JDK 1.5. The reason for this is the addition of Java2D (java.awt.Graphics2D and friends) in 1.2. Before Java2D, all the drawing routines were hardware accelerated - after, most of them were done in software (at least initially - in 1.2).

Check out my graphical client for chess servers for a proof. It is 1.1 compatible, so you can compare how it runs in MS VM (or actually any 1.1 implementation) and in the latest VMs. The jin.exe in the windows "version" runs MS VM, if you have it.

Also here are some snapshots of the new and improved Metal Look&Feel and of the GTK+ Look&Feel. You can also see how much antialiasing of bright text on dark backgrounds has improved from (unreadable) 1.4 to (rather decent) 1.5.

Also, Swing seems to be much more responsive! It is therefore my humble opinion that this release is going rock Java.

Also here are some snapshots of the new and improved Metal Look&Feel and of the GTK+ Look&Feel. You can also see how much antialiasing of bright text on dark backgrounds has improved from (unreadable) 1.4 to (rather decent) 1.5.

Also, Swing seems to be much more responsive! It is therefore my humble opinion that this release is going rock Java.

Also here are some snapshots of the new and improved Metal Look&Feel and of the GTK+ Look&Feel. You can also see how much antialiasing of bright text on dark backgrounds has improved from (unreadable) 1.4 to (rather decent) 1.5.

Also, Swing seems to be much more responsive! It is therefore my humble opinion that this release is going rock Java.

Also here are some snapshots of the new and improved Metal Look&Feel and of the GTK+ Look&Feel. You can also see how much antialiasing of bright text on dark backgrounds has improved from (unreadable) 1.4 to (rather decent) 1.5.

Also, Swing seems to be much more responsive! It is therefore my humble opinion that this release is going rock Java.

Also here are some snapshots of the new and improved Metal Look&Feel and of the GTK+ Look&Feel. You can also see how much antialiasing of bright text on dark backgrounds has improved from (unreadable) 1.4 to (rather decent) 1.5.

Also, Swing seems to be much more responsive! It is therefore my humble opinion that this release is going rock Java.

Then why the hell is it so slow?

Two words - "Java 2D", at least as far as user interfaces go. Before Java 2D, in the days of Java 1.1, the JVMs were slow, the garbage collector was slow and synchronous, the synchronization was slow - everything was slow. Drawing on the screen, however, was lightning fast because all of it was hardware accelerated. This meant that the user interface was very responsive, and that is what most users complain about (well, startup time too, which was also much smaller in 1.1). Try running Swing under JDK 1.1 - it's not even comparable to any recent JDKs - it's so responsive you can't tell it from a native UI.

I even have an application for you to try.

If I'd have to name the single most important mistake Sun made that contributed to killing Java on the desktop (not to say that it's completely dead or that it's not the other company we so love to hate didn't have a hand in it), it would certainly be the replacing of the 1.1 drawing API with Java2D. Why is Java 2D slow? Because the API promises things that are hard to implement on different platforms without resorting to drawing everything (or many things) in software.

My own project - A chess client</shameless plug>