May 14

Allison Randal

Allison Randal

GPLv3, Clarity and Simplicity

The first I heard about plans for a GPLv3 revision was from Bradley Kuhn early in 2005 at a meeting I organized for The Perl Foundation (a public review of the Artistic License 2.0). My first thought was "Great! We can finally clean up some of those ambiguities in the GPL, and make it easier to understand and more legally precise." These were my primary goals in driving the Artistic 2.0 revision, so it's understandable that I expected something similar from the GPLv3. I don't know that clarity and simplicity was ever a goal that Richard Stallman, Eben Moglen, or any of the GPLv3 team desired to achieve. Looking at the near-finished draft, I have to say it's unlikely that they ever considered simplicity a priority, if they considered it at all.

I can't fault them for failing to achieve a goal they never had in the first place. But clarity and simplicity are important goals for an open source license.

The audience for an open source license is not just lawyers, it's the whole open source community. In the same way that it's important to have the source code broadly accessible, it's important to have the terms of the license broadly accessible. Power should not be held by a small elite group of lawyers. Every individual should be enabled to comprehend the terms of the license, and make informed decisions about the software they use and the license they choose to release their own software. Power in the hands of individuals is one of the core tenets of freedom. The language choices of an open source license can support that freedom, can empower the users and the developers. The GPLv3 doesn't.

On the purely practical side, the more dense the legalese, the more likely it is to have unintended side-effects. Humans, even highly trained lawyers, make mistakes. The harder it is to decode the meaning of a particular section, the more likely it is that the people drafting it will miss a glaring hole in the terms. Every hole they try to patch with bandages of additional verbiage introduces new ambiguities, more holes, and more chances for malicious misinterpretation of the language. It's better to strip down to the simplest, clearest, most legally precise, and legally concise phrasing possible. This is closely related to the development principle of "Do the simplest thing that could possibly work." Developers know that if you have a 2000 line program and a 200 line program that do exactly the same thing, the 200 line program will be easier to maintain and easier to debug, and generally more reliable too.

I'm sympathetic to the perspective that added verbiage in the license can act as an embedded FAQ, guiding the interpretation of the core terms. But the interpretation of the GPLv2 depends heavily on the unwritten case history of GPL enforcement. From the FSF's conversations with Committee A, it sounds like they plan to take the same approach with the GPLv3. With so much of the interpretation external to the license text anyway, there's really no benefit to cramming it full of FAQ information. A clear and simple license with a separate explanatory FAQ would be far more effective.

I'll leave you with some license text I drafted during one of the Committee A conference calls last year. I extracted the essential terms of the GPL into a greatly simplified form, and polished it with Roberta Cairney (primary legal counsel for the Artistic License 2.0). I hope that someday we'll have a Creative Commons of open source licenses as simple as this one, and simpler. For now, consider it a plain English guide to the terms of the GPLv3.

The goal of this License is to promote the freedom of all users to share and change free software.

"You" means any individual exercising the rights granted in this License.

The "Work" means the work of authorship distributed under this License. A "Modified Work" means any altered version of the Work.

The "Source Code" for a Work means the preferred form of the Work for making modifications to it. "Object Code" means any non-source form of a Work.

“Distribute” means copying a Work or Modified Work, making it available to the public, and enabling other parties to make or receive copies. It does not mean sublicensing.

1) You may use the Work, without limitation.

2) You may Distribute the Work as Source Code, provided that you:
a) make the Work available under this License,
b) retain all of the copyright notices and warranty disclaimers of the original Work unchanged in the distribution, and
c) provide to the user any information necessary to install modified versions from the Source Code.

3) You may Distribute a Modified Work as Source Code, provided that you prominently note the changes you made and provided that you satisfy the requirements of section 2.

4) You may Distribute a Work or Modified Work as Object Code, provided that you satisfy the requirements of sections 2 or 3, and provided that you make the corresponding Source Code available to the user under this License.

5) You may charge any price or no price for each Work or Modified Work that you Distribute, and you may offer support or warranty protection for a fee.

6) Aggregation of the Work with other separate and independent works on a volume of storage or distribution medium does not cause this License to apply to those other separate and independent parts of the aggregate.

7) You are not permitted to Distribute the Work or Modified Work in a way that denies the users any of the rights granted in this license. You are not permitted to impose a fee for the rights granted in this license. You are not permitted to limit operation or modification of the Work or Modified Work as a means of enforcing your legal rights or the legal rights of any third party against any users of the Work or Modified Work.

8) By Modifying or Distributing the Work or Modified Work, you indicate your acceptance of this License, and all its terms and conditions. You may contact the copyright holder of the Work directly and arrange terms to use, distribute, or modify the Work other than those of this License.

9) Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's patent claims in its contribution, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contribution.

10) The permission granted by this License to distribute or modify the Work will terminate if you bring a legal action for infringement of any patent claim licensable by you that is applicable to any element of the Work or any Modified Work, against anyone based on their use, modification or distribution of the Work or a Modified Work.

11) The permissions granted under this License cannot be terminated as long as you are in compliance with this License. If you violate this License, and you do not correct the violation and return to compliance within 30 days after receiving notice of the violation from the copyright holder, the permissions will terminate as of the end of the 30 day period.

Warranty and Liability:
12) There is no warranty for the Work, to the extent permitted by applicable law. Unless otherwise stated in writing, the copyright holders and/or other parties provide the Work "as is" and without warranty of any kind, either expressed or implied, and the excluded warranties include without limitation implied warranties of merchantability and fitness for a particular purpose.

13) Unless required by applicable law or agreed to in writing by a copyright holder, in no event will any copyright holder, or any other party who may modify and/or distribute the Work under this License, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the Work, even if such holder or other party has been advised of the possibility of such damages.

tags: open source  | comments: 20   | Sphere It

Previous  |  Next

0 TrackBacks

TrackBack URL for this entry:

Comments: 20

  Nelson Minar [05.14.07 08:25 AM]

I worked hard to open source academic projects I worked on at the Santa Fe Institute (1996) and MIT (1999). In both cases the easy part was convincing my manager to open source the code; the hard part was convincing the lawyers that the GPL was a reasonable license. It's very hard to read for a layman, and even a well meaning and knowledgable lawyer seems to have a hard time with it. The LGPL in particular is ridiculously complex. That's a good thing about the MIT and BSD licenses; they're quite simple.

  licensevscontract [05.14.07 04:47 PM]

Free software is dirt-simple to express in a license. Here you go:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so.

I just took the main paragraph of the Expat license and trimmed it slightly. This is a complete free software license: it gives the recipient all the four freedoms. I wouldn't want to use it as a developer, but as a user there's absolutely no problem with it. It even sounds like legalese.

That's 61 words. By contrast, just the legal terms of GPLv2—not counting the preamble and appendix—weigh in at 2021 words. That's more than 30 times bigger! Why is the GPL so much longer? Can't we make it simpler?

The BSD license don't do any of the same things as the copyleft GPL.

  Allison Randal [05.14.07 05:53 PM]

It's true that you can't randomly delete text from a license and expect it to have the same effect, the same way you can't randomly delete code from a program and expect it to work the same way.

You can, however, carefully craft a license to keep the same legal force while simplifying the language. The GPLv3 could have made great progress in this area with very little additional effort.

A few comments on the Groklaw article you quoted:

You can use simple language if all the participants have shared understanding.

No, actually you can use simple language if you specify the legal details in the license and leave the explanations to a separate document.

We could describe that class [of software] in plain English, but then the judge may not make the connection... Calling out the law directly eliminates that risk.

Actually, calling out particular laws in a particular jurisdiction directly ties you to a specific set of judgments that may be overturned or superseded later. It's a quick path to obsolescence, not to mention problematic for international application.

  Rufus Polson [05.14.07 07:58 PM]

Sounds as if your input in developing the wording might have been valuable. Given that you seem deep in the Free software community and the process was very open, you could have been involved. Pity you chose not to.

  chromatic [05.15.07 12:00 AM]

Rufus, Allison is on GPLv3 Committee A.

  Roy Schestowitz [05.15.07 01:40 AM]

Allison, just don't give Eben /too/ much of a hard time. ;-) I think he has had enough of the GPLv3 and we truly need that licence out the door to defend our software.

  G Fernandes [05.15.07 02:17 AM]

Well, simplicity and clarity may be noble goals. But simplicity is a little bit of a red herring. A complex problem can only be simplified so much - not more. Any more "simplification" would result in denial of complexity. When one does that, one runs the risk of not completely solving the problem one has set out to solve.

So while your points may well be valid, you need to balance it with the requirements of Free Software - the four freedoms. If your license can not reasonably guarantee the four essential freedoms in any court room across the world, your license is moot.

  Gerv [05.15.07 02:52 AM]

This reminded me of Joel's famous article on the Netscape/Mozilla rewrite, worth quoting at length:

As a corollary of this axiom, you can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."

Why is it a mess?

"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for."

The idea that new code is better than old is patently absurd. 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. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Is GPLv3 longer than GPLv2 in part because we're inserting 15 years worth of bug fixes? And would replacing it with something "clean and simple" be the equivalent of a code rewrite, with the above potential disadvantages?

  Allison Randal [05.15.07 01:20 PM]

Is GPLv3 longer than GPLv2 in part because we're inserting 15 years worth of bug fixes? And would replacing it with something "clean and simple" be the equivalent of a code rewrite, with the above potential disadvantages?

The GPLv3 is a complete rewrite, not a simple application of bug fixes. It's a classic case of the second-system effect. There's a real need for a cleaned up version of the GPLv2, but the GPLv3 doesn't meet that need.

Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed.

This is where we stand with the GPLv2. It's tested and has known bugs with known workarounds, which pretty much guarantees it will continue to be used for many years to come.

  Allison Randal [05.15.07 01:38 PM]

Roy, I admire Eben, and I certainly appreciate the work he and others have done on the GPLv3. But, it's important for people to realize that this license has fundamental problems that will not be fixed before it's released. The most likely result of this is a sudden proliferation of copyleft licenses in the next 10 years, each one attempting to solve some part of the failures of the GPLv3. It's really unfortunate, and could have been avoided.

  Roy Schestowitz [05.15.07 02:46 PM]

Good point, Allison. I guess the recent developments just gave me a reason to want to rush things.

  Allison Randal [05.15.07 04:22 PM]

Rufus, as chromatic pointed out, I'm on Committee A. I've been involved in the process from the very first public announcement, and was aware of the revision before most others outside the FSF.

Last year I sent comments on the importance of simplicity and clarity to Committee A and members of Committees B and C along with a copy of this simplified license as in illustration of what could be possible. It sparked some good discussion, the response was positive, and I noticed the FSF at least talking about clarity in the license after that. I was hopeful that the substantial work that went into the license late last year and early this year would show progress in this direction, but it didn't.

  Allison Randal [05.15.07 04:37 PM]

A complex problem can only be simplified so much - not more. Any more "simplification" would result in denial of complexity.

I absolutely agree. In one of my regular talks (about language design), I outline two principles: the Principle of Simplicity and the Conservation of Complexity (also known as the Waterbed Theory of Complexity). In a nutshell, the Principle of Simplicity is that all other things being equal, a simpler solution is a better solution. The Conservation of Complexity states that a certain degree of complexity is necessary to solve a given problem, and that simplifying one part of the system will tend to increase complexity in another part of the system (satisfying the total level of necessary complexity). The two principles are in constant balance. The trick is to find the sweet spot between simplicity and complexity for a given problem, to identify and remove unnecessary complexity, and to choose the most appropriate locations for the necessary complexity in a particular solution.

Condensing my comments down to a single sentence: A large part of the complexity of the GPLv3 is either unnecessary or would be more appropriately located in an FAQ.

So while your points may well be valid, you need to balance it with the requirements of Free Software - the four freedoms. If your license can not reasonably guarantee the four essential freedoms in any court room across the world, your license is moot.

The simplified license does satisfy the four freedoms. It has fundamentally the same legal impact as the GPLv3, including the requirements for installation information and the stand against external agreements putting additional restrictions on the rights granted by the license (Microsoft/Novell patent agreement). The simplified license is offered as proof that the GPLv3 could have been much simpler and still accomplish the same goals. Even if the GPLv3 had only made if half-way from where it is now to the simple alternate, it still would have been a huge improvement.

  Rob Myers [05.16.07 03:37 AM]

I've seen complaints from lawyers that GPL 2 is too simple.

The GPL is a legal tool. It must be as complex as it needs to be in order to be legally effective. Your proposed "simplification" still contains legalese and multi-stage structure. It contains terms made up by the FSF, terms from American law, and terms that are from law in other jurisdictions. It doesn't define all its terms. This is incoherence and incompleteness, not simplicity.

Including FAQ-type clarifications or legally redundant information in a license can be very useful. This is because as you yourself observe the license will not be read only by lawyers. If you look at the OGL and CC-BY-SA, the one without a clause explaining why you have to hold enough rights to license the work is the one with more trouble with unauthorised contributions. You cannot achieve this with unwritten internal guidelines.

You are simply mistaken in your claim that the GPL 3 could be so much simpler. Your simplified version already has unintended consequences and it makes sense only because the GPL 3 drafts explain its hidden complexities. If the license went to court you couldn't appeal to the GPL 3 drafts, a FAQ, or internal documents except as indicating intent. The license is the place to explain the agreement.

If you want a legally unintimidating representation of the GPL, try the Creative Commons version:

  Allison Randal [05.16.07 12:20 PM]

The GPL is a legal tool. It must be as complex as it needs to be in order to be legally effective.

Agreed, of course.

Your proposed "simplification" still contains legalese and multi-stage structure. It contains terms made up by the FSF, terms from American law, and terms that are from law in other jurisdictions. It doesn't define all its terms.

This pretty much exactly describes the GPLv3. I did draft the simplified license to closely follow the GPLv3. If I were drafting a copyleft license from scratch I would make some different choices.

You are simply mistaken in your claim that the GPL 3 could be so much simpler.

Please do go through the GPLv3 one sentence at a time and demonstrate to me why each sentence is legally necessary and couldn't be simplified.

  Daniel Robbins [05.18.07 12:03 AM]

I wholeheartedly agree with your post. The GPL version 2 is a very imprecise and convoluted license, and thanks to this we now have different camps of people in the free software community who believe that they grasp the elusive "proper" interpretation of this license, and are in a position to enlighten others about what the license really means.

Unfortunately, the only opinion that really matters is the one that holds up in the legal system, and the GPL v2 is not serving the community well by containing these ambiguities.

One has to wonder at this point if the GPL v3 is intentionally ambiguous. Maybe the FSF likes to be in the position where they get to be the priesthood who have the secret knowledge of how the license should be properly interpreted. That's a cynical view, but I really don't see the GPL v3 as a step forward.

I was actually impressed with Microsoft's new Shared Source licenses, which all fit on less than a page and are easy to understand. I think the people who worked on these licenses "got it" and made it a priority to write them in such a way so that they could be read and understood by the community. See them here. Kind of amazing to see that at least in the case of licensing, Microsoft's Shared Source team is ahead of the FSF when it comes to understanding the needs of the free software ecosystem. Now let's hope they can begin to translate some of this competence into other areas of their organization where it is greatly needed.

  Brian Sniffen [05.18.07 05:43 AM]

Under your simplified license, can't I charge $1 for my modified Emacs and $1B for the source code? The "overcomplicated" GPL3 at least makes it clear that I can't.

  Sam Greenfield [05.18.07 09:12 AM]

Disclaimer, I am not a lawyer.

A 200-line program may be easier to understand and debug than a 2000-line program, but the GPL isn't a program. Rather than comparing the GPL to a program, it might make more sense to draw an analogy between the GPL and specifications. Specifications need to be detailed an comprehensive so that two different people reading the same specification do not come up with incompatible implementations. Similarly, the GPL needs to be comprehensive so that two different people reading the license do not come up with two different interpretations. This may make for a very long license (or specification), but the details are important.

If the legalese of the document is too dense, then associated documents can be written to allow folks to better understand the license. However, I think the preamble already serves as your "plain English guide to the terms of the GPL." Not only does it explain the intent of the GPL, but also it sets a groundwork for understanding should there be any ambiguity in the explicit terms and conditions.

[Brian's comments are on the money by the way. In fact, there doesn't appear to be anything in your "simple" license that would prevent me from distributing the source encoded on base-64 and printed out on a dot matrix printer.]

  G Fernandes [06.11.07 02:30 AM]

[QUOTE]The simplified license does satisfy the four freedoms. [/QUOTE]

This is a license we're talking about. Not easy-reading. Unless it is enforceable in any court of law, your argument is moot.

  G Fernandes [06.11.07 02:43 AM]

... and by enforceable, I mean it should be able to protect by legally discouraging, attacking or defending any current or foreseeable encroachment on any of the four freedoms, in any court of law across the world.

Post A Comment:

 (please be patient, comments may take awhile to post)

Type the characters you see in the picture above.