Thursday, August 23, 2007

Java and the dangers of GPL

Don't get me wrong. I am a GPL fan in spirit when it's combined with a linking exception. Initially I applauded Sun's choice for Java's open-source license. I am also grateful for the monumental efforts of Richard Stallman and Eben Moglen in helping move the world of software forward. However, GPL version 3, released two months ago, suffers from 2 flaws, fatal flaws, fatal not only to the healthy evolution of GPL but also to that of Java.

Flaw #1 - The anti-tivoization clause for consumer hardware is a limitation inimical to free software. I agree with Linus Torvalds that this clause is a critical mistake. I may write about this in more detail later, but for now, consider only how this stunts development of security for distributed applications. My objection is not merely practical. My objection is in principle. Freedom in bits, freedom in property, no control over how I use bits in my own property or how others use them in theirs, that's where this world is heading. Dictating what I can or can't do with the software in certain hardware smells of controlliness (yes, that's a word I just made up, but I bet you know what I mean), inimical to the type of flexibility we need to move this world ahead... fast.

Flaw #2 - Here's the clincher, a flaw that even shows a high degree of, dare I say, hypocrisy (Torvalds dared). The license itself is not open to changes. You will be punished if you use a license with flaw #1 corrected. Richard Stallman and Eben Moglen will not let you fork it. I was shocked to find this out. No free-software heretics welcome. You're locked in for the ride no matter how arbitrary the car driver. This is the GPL trap. (See the video below.)

What to do? Sun currently licenses Java under GPLv2 with the linking exception. I do hope that Sun adds another open-source license for Java and does not merely move to GPLv3 unthinkingly. I also hope that the Creative Commons adds another open-source software license to its repertoire. In the meantime, I'll continue to use Java as is, but I'll be keeping my eye on Apache Harmony, though it's currently lacking a Mac version. In the grid world to come, the freedom to securely ensure that software be accountable is essential, no matter where it runs.

I find it sad since I find exciting value in the GPLv3 apart from these 2 dissuasive defects.

Here is an excellent, informative presentation on GPLv3 given by Sapna Kumar in June to the Triangle Linux Users Group. According to Kumar (1:13:03), Stallman will not let you modify the GPL license on your own even if you call it by another name. The Free Software Foundation enforces this through copyright.


robilad said...

Actually, the author can grant additional permissions on top of the GPL, so that one can in effect fix whatever prohibition in the GPL one doesn't like, by explicitly permitting the restricted activity.

Casey Bowman said...

Actually no, according to Sapna Kumar, the author cannot modify the GPLv3 license. I was surprised by this myself. I had assumed otherwise.

Kumar states (1:13:00), "That's a really good question. The question is, 'Can you change the GPL? Can you strike out part of the GPL ... and say my code is under this license.' The answer is, 'Richard Stallman will not let you.' ... It's open-source software, but not an open-source license. You can't take the license and tinker with it and give it a new name without their permission."

The problem lies in the expense in recreating a time-tested license that does not violate the license's copyright, given the complexity of the license itself. It is absurd, yes I know, when legal language itself becomes subject to copyright.

I personally would prefer it if she were wrong and my argument null and void. Please let me know if you have any information that might prove Kumar's statement or my argument based on it wrong.

robilad said...

You can't change the GPL text itself, but you can add additional permissions, per section 7 in v3, for example. You are confusing two different scenarios: you can always add additional permissions to the GPL in form of special exceptions attached to the license (rather than modifying the license text itself), but you can not modify the license text at will.

The FSF itself has been adding additional permissions to the GPL text since 1991 at least, so while it's a novel concept to some people, it's routinely used by practitioners in the development tools field, like Apple (OS X), Microsoft (SFU), Sun (Linux), IBM (Linux), Oracle (Linux), etc. who all use gcc as the default toolchain for some of their products. And the core libraries of gcc that every application on those operating systems links to are under GPL+linking exception.

Casey Bowman said...

Anyone though can drop the permissions you've added as your code is passed around, as I understand the GPLv3 from reading it directly. Thus there might be later improvements to your code made by someone else that you couldn't adopt yourself if that freedom remained important to you.

My intent is to correct the anti-tivoization clause. Other such imperfections may crop up later, too, where, to my judgment, the code's freedom is restricted.

My sense is that Stallman's idea of what's free and mine differ. I believe strongly in the freedom of bits, but I also believe strongly in property. Just as an owner of an auditorium may allow one speaker the podium and another not, and often does so on the basis of trust or lack of it, without infringing on any speaker's freedom, so, too, software can be fully free even when some hardware is picky. Just because one speaker is allowed to speak in an auditorium, it may not be wise to allow his twin to do so, or his cousin. If someone were to be subject to the condition that he not speak anywhere where his twin brother couldn't speak, this, to my mind, would be a restriction on that person.

If indeed our ideas of freedom differ, then his idea of restriction might be my idea of permission and vice versa. If this is the case, then the GPLv3 would perhaps consider the removal of the anti-tivoization clause not an "additional permission" but a "further restriction", in which case it would actually require that this change be dropped as the code is passed around and modified.

In either case, I would risk not being able to freely use future improvements to my code made by others.

Again, I wish it were not so. Please show that I'm mistaken.

robilad said...

A permission is something that grants additional rights not present in the license, a restriction is something that takes the rights granted in the license away. LGPLv3, for example, is written as a set of additional permissions on top of GPLv3.

While you can strip them away, it's usually rather pointless to do so: you'd be restricting your own rights. Which is why it almost never happens in practice.

robilad said...

I mean, you'd be removing additional rights granted to you by the previous authors. There is no point in doing that.

Casey Bowman said...

Unfortunately I believe my argument stands unscathed.

Please consider the concrete example at hand, that of the anti-tivoization clause. To me, removing that clause is to add permission. To others, its removal may seem like a further restriction.

In either case, someone could add back the anti-tivoization clause.

Judging from the sparks that flew in the debate on this clause, there are some who would do this with zest and without compunction, despite their free-software banner.

This would be one concrete example of the problem. The deeper problem is that the license itself is not open to trial and error evolution and to competing visions of what free-software means.

Greg said...

Adding restrictions means restricting the person licensing the software directly from you.

Adding a permissions means granting further permissions to the person licensing the software directly from you, even if it is permission for them to _restrict_ the rights of people licensing the software from _them_.

So when you say it's OK for TiVo to restrict what their customers can do with your code, you're adding a permission.