After an interesting free software licensing event in Helsinki, I got thinking about licence complexity. At the conference, people had two types of questions (a) Why didn't GPLv3 additionally solve X problem? and (b) Why is it so long?
In my presentation, predictably, I gave GPLv3 two thumbs up:
This was followed by a speaker who advocated using one of Microsoft's licences which he said was better because it's simpler. This reminds me of a mistake that Joel Spolsky wrote an essay about:
[...]Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that's kind of gross if it's not made out of all new material ?.
Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes.[...].
I think this applies equally to licences. GPLv2 fixed a lot of social problems caused by how software was could be distributed. GPLv3 fixes more. Microsoft can write a short, copyleft free software licence because (a) No one's ever going to use it anyway, and (b) They don't care if it does the job properly or not. (Note: I don't know if their licence even is a free software licence. Maybe it is, I just haven't looked into it much.)
The GPL, as far as I know, is the only free software licence that has been tested in court, and it's used by more software projects than all other free software licences combined. This gives it's writers a lot of information with which to do bug fixing, and it gives the GPL a massive responsibility to work solidly.
So, for the question: Why didn't GPLv3 additionally solve X problem? There are three possible answers:
- The drafters had to avoid adding requirements only for fixing potential problems. Requirements can backfire, so adding them has to be done carefully. This is the reason that there is no patent retaliation clause in GPLv3: what if it some day prevented a free software developer from using his patents against someone who was harming the free software community?
- Solving problems almost always requires extra words. Everyone wants the GPL to be as short as possible, so the drafters had to stick to only solving the problems that were real, or problems that were simple.
- Some problems can't be solved in copyright licences. The general danger of software patents is one example of a problem that can't be solved by making a change to our licences. The grey areas of what constitutes a derivative work is another example. (Although, the grey areas aren't as big as some people think anyway.) GPLv3 has reduced the grey areas, and it has made sure that the remaining grey areas should be more similar accross country borders than they were in v2, but no free software licence can make the grey areas go away.
As for the other question: Why is it so long?
One answer is that those extra lines are bug fixes.
Another answer is that clarity requires explicit language. GPLv2's concept of "distribution" is defined in GPLv3. For one thing, it's been renamed to "convey", to avoid clashes with existing terminology in law and court precedents around the world. For another, its definition has been made explicit, to avoid relying on existing meanings in law and court precedents, which vary around the world. This bug fix required extra words, but it actually makes the licence simpler to understand reliably. The definition is in the licence, so you should have less need to consult a lawyer in each country.
(If you like this article, Vote on FSDaily.com )
Comments
Analogy is a little flawed...
While I'd be the first to agree that a free software license from the FSF is a lot more trustworthy than one written by Microsoft (understatement!), the analogy with software is a little bit flawed.
Legal documents do resemble software in their precise and formal use of language, but legal documents are interpreted by Human beings, not by computers.
This throws two monkey-wrenches into the "more complex"="better quality" argument:
The first is the assumption that more words will necessarily improve the fidelity of the interpretation. Regrettably, human beings are not as predictable as computers, and can get confused or apply their own biases to the interpretation of the text -- even in a formal court setting. Writing too much can cause extra confusion or cause a reader to skim over text, missing important parts.
The second is that, as the length of the license increases, the burden on licensors, licensees, and legal practitioners to understand and apply the license terms is quickly increased.
Compute cycles are cheap and even "interpreters" don't really interpret the original source files directly, so we don't worry so much about this with programs nowadays. Not with the size of binaries, and certainly not with the size of source code.
But Human time is expensive, and that's what a long license text burns up. So brevity, clarity, and ease of understanding have to be goals for a good license.
(Or if you like, "Humans are poor interpreters of code").
I too approve of the GPL 3.0. It's a big improvement over GPL 2, but it does come at a fairly high cost in understandability and especially brevity.
I still think that the GPL v2 is a beautiful document, and partly because of its brevity. It stands almost as a "constitution" for the Free Software movement -- while the GPL 3.0 reads as a rather mind-numbingly long and detailed piece of legislation.
Which we need when it comes to legal battles. But the GPL v2 is still the document I'd give as assigned reading to people who want to understand what Free Software is.
Change one variable at a time
While I appreciate that the GPLv3 resolved some issues that some developers had with GPLv2 (like Tivoization), it simultaneously made itself less desirable to some developers who didn't agree that those things were problems.
It would be nice to have a GPLv2.1 that just fixed a few of the ambiguities and problems in GPLv2 to bring it in line with experience, rather than also adding a bunch of new issues. I understand the FSF owns the license and wants to express its philosophy in the license, so it's not surprising that they didn't go that way. However, I wish someone would take on writing such a license (perhaps somewhere in the Linux community, which has a somewhat different philosophy that I find more congenial).
I also wasn't very impressed with the public comments process. As far as one could tell from the outside, there was no real evidence that the public comments, as opposed to those gathered in the committees, had any impact. In particular, there were a couple of wording issues identified in the brief final review that seemed to be real issues but were unresolved. It would have been much preferable to have SOME kind of feedback to the public commenters, rather than just silently accepting whatever they said (and, for all we knew, dropping them on the floor).
Reuse can be a problem, too
While Spolsky's note about reusing old code has a lot of useful observations, it's important to consider the other side. The code fixes that represent real experience also make it harder to read the code and, more important, harder to guess whether any particular change for new functionality will work right (because of potential interactions with those hard-to-understand bug fixes). I think those issues would apply equally to licenses, where lawyers are absolutely certain to haggle over any inconsistencies between parts of the license.
There is some literature on the subject of reusing versus rewriting. While the numbers vary, the put a relatively low threshold (like 10-20%) on the point where it is cheaper overall (over the entire lifecycle of the change) to modify or rewrite.
Actually, though, I'm not sure why Ciaran included the point at all, since GPLv3 is essentially a rewrite, rather than modification, of GPLv2...