GPL v3, the Q&A: part 2- developers

(This is part two of a series. Before going further, you should (at the minimum) read the disclaimer on yesterday’s post and (ideally) make sure you’ve read all of yesterday’s post.)

Q: Has there ever been a sequel that wasn’t terrible?

A: Godfather II and Star Wars II. (I refuse to call it V.) I’m no Coppola, but I hope I’m better than Lucas. We’ll see.

Q: I’m a developer, and my current code uses GPL v2- should I update to the v3?

A: Probably. While the license does not include any huge wins for all developers that would make an upgrade obvious or mandatory, there are small wins here for virtually anyone who seeks to have a functional FLOSS project. In particular, every developer should appreciate the improved (if still imperfect) patent protection, the ability to copy and paste APL-licensed code into your code, and the internationalized legal language, offering them stronger protection outside the US’s copyright system.

In addition, those developers who object to TiVo-ization of their code, or to the use of their code in a DRM system, will like those sections of the new license. As I mentioned yesterday, these sections of the code may not be perfect, but they should go a long way towards ensuring that users of your code always have the right to access it and modify it- something that wasn’t necessarily clear under the old license.

Q: There must be some downsides.

A: Absolutely. I f you adopt now, you’ll be on the bleeding edge- with all that entails. You’ll have to explain the license over and over again to people, explain why you’ve chosen it, and so on. That won’t be fun, and you may lose some contributors over it. There is also the possibility (though small) that you’ll have chosen incorrectly, and that there will be some flaw in the license. While this seems unlikely¹ it isn’t impossible, and you will be taking that risk by switching before the license has been out for a while.

You’ll also lose compatibility with GPL v2- you’ll be unable to copy and paste code from (or to) any part of that huge base which is not under v2 ‘or any later version’. Depending on how you develop, this may be a big downside, or it may not. But it is one to be aware of. (More on this in a later post.) Similarly, if there are applications that link against you or otherwise share your code, and they are not ready to relicense, that may weigh against a relicensing as well, since GPL v2 apps can’t link against GPL v3 apps.²

Finally, there is the DRM and embedding/TiVo-ization language. If your project is heavily used by embedded or multimedia devices, your partners are likely to get very nervous if you start talking about v3. If you yourself take the libertarian or pragmatic developer-centric viewpoint, you may personally be opposed to those new restrictions as well. So those may well be reasons to avoid the license for many projects.

Q: I really want to hose Novell. Should I switch to v3?

A: If you’re looking for some sort of vengeance on Novell, you won’t get it in this license. More on that tomorrow, but nutshell: you’re not getting it. Even if you did, that is a pretty lousy reason to choose a license anyway. With any luck, the GPL (and your GPL’d code) will outlast the current Novell leadership and maybe even Novell. Make decisions based on what is right to protect you, your code, and your users, not on whether or not Novell deliberately circumvented the intent of the old license. (On that ground, hint: this will protect you from at least some Novell-like situations in the future, so if you think what Novell did was a bad idea, you might want to upgrade.)

Q: The kernel folks screamed a great deal about the earlier drafts. How far has the license gone to address their criticisms? Will that impact the uptake of the license?

A: The original drafts of the DRM and embedding license were not exactly models of clarity. As a result of criticisms from Linus and friends, the final draft is a lot more straightforward. The DRM clause now states merely that one can’t claim to be an effective DRM device, for example; previously it actually tried to prevent the construction of such devices. Similarly, the embedding clauses now make clear that what is required is sufficient information to reinstall the software (whatever form that information may take); previous versions had been murky enough that they had been read (incorrectly) to imply that things like developer’s GPG keys had to be revealed.

It isn’t clear that this new clarity will actually help uptake, though. It should reduce the opportunity for FUD, of which there was a fair amount around the first draft. So if people’s decision turns on these clauses, it’ll at least turn on the right issues and not false ones created by poor wording. But the clauses still burden and restrict developers without giving them any clear pragmatic benefits in return. If the pragmatic developer’s bottom line is ‘give us benefits and we’ll use your license’, the clarifications to those clauses will only clarify the situation- they will not substantially change it.

Q: So there are upsides and downsides- how do I pick?
Unfortunately, there is no simple right or wrong answer for this. Every project will have to make their own judgment about the pragmatic costs and benefits, and the political-philosophical implications. Projects who particularly want to get solid patent licenses from their contributors or who are particularly philosophically concerned about user control will probably lean one way, and projects who are worried about the mobile space or whose copyright situations are particularly confused will probably lean another.

Q: That wasn’t helpful at all- I still can’t make up my mind. Should I consider dual licensing with GPL v2 or another free software license?

A: Dual licensing is a mixed bag. On the one hand, it gives more flexibility and choice to your users, and it will reduce uncertainty for your contributors and your users. On the other hand, it gives more flexibility and choice to your users- including the bad guys. In particular, your code is only as protected as the protections of the weakest license you license under. So if you release your code under both GPL v2 and GPL v3, you haven’t gained much- the next person who sells you out on patents or DRM will just say ‘well, I’m using it under v2.’ You can only gain the full protections of v3 if you license only under the v3, or under the v3 plus an even more restrictive (presumably proprietary) license.

The only major advantage to dual-licensing, then, is that other people can reuse your code under the license of their choice. This is not a small benefit- it will be particularly useful for GPL-licensed platform projects which expect to have programs developed on the platform in both GPL 2 and 3. But it isn’t necessarily huge either.

Q: What about ‘or later?’ should I use that? Doesn’t the controversy about this license mean I can’t trust the FSF to make good decisions about GPL v4?

A: The FSF recommends licensing your code under ‘v3 or any later version of the GPL’, just as they have with GPL v2. This cuts two ways. On the positive side, it means that if a problem is found in the license, and people are unable to contact you, they can still use your code under the new, less problematic license. This is arguably exactly what will happen with Novell and the patent clauses of v2 and v3- a problem was found, and those who left their code under ‘v2 or later’ and then dropped off the face of the planet can still have their code be useful for others.

On the negative side, it also means you have to trust the FSF. I do; if you actually take the time to read the four freedoms, it is clear that they’ve done nothing with this license that isn’t exactly in line with the goals they’ve been stating for 20 years. But if aggressively protecting those user freedoms aren’t your cup of tea- and they obviously aren’t everyone’s- you might not want to trust them with GPL 4, and so ‘or later’ might not be appropriate for your code.³

Again, this is a fairly personal decision about risk, reward, and trust. I personally think the FSF is pretty predictable, so I’d license my work under an ‘or later’ clause, but I realize that this isn’t for everyone.

Q: If I do decide to relicense, what are the mechanics of that?

A: The FSF and SFLC will be issuing recommendations on relicensing best practices. My recommendation as of this writing is to wait for them- they are the experts, and have given these pragmatic details a great deal more thought than I have at this time.

Q: You mentioned projects whose copyright situations are particularly confused- what do you mean by that?

A: Take, for example, the kernel. We know much of it is licensed as v2-only, and we know many of their contributors have gone AWOL, or have even passed away. Only one project of that scale (that I know of) has ever tried to relicense (Mozilla) and the process took ages, even though most of the code had a single copyright owner (Mozilla/Netscape). The kernel could well be worse- no single copyright owner, and several times as much code. So talk of relicensing the kernel, especially in the near term, is probably largely academic; pragmatically dual-licensing of some chunks may be the best that can be expected.

The kernel is not alone- many large projects (like GNOME) don’t do copyright assignment, and so any attempt to relicense would involve a long time spent relicensing, and potentially even an effort to rewrite old code whose authors could not be contacted. This may well limit the impact of the license- v2 may remain the defacto license of older projects, with newer projects moving to v3. We’ll see.

Q: Bottom line for developers?

A: The advantages to the license are not huge, but they are real, and my guess is that within a few years it’ll be the default license for most new free software projects, as v2 is now. If you choose not to get on that train now, you’ll be in good company, but make sure you understand the license and are doing it for the right reasons- you’ll regret it if you make a kneejerk decision (either way.)

[Thanks to Nicu for the shiny new copyleft logo.]

[see all parts: part 1, part 2, part 3, part 4.]

1. the license has been vetted by a lot of very skilled lawyers and a fair number of common-sensical hackers, and even in the worst case, you should get the same rights and protections you do under v2 [↩]
2. The current FAQ suggests that v2 apps can’t even link against LGPL v3, but SFLC told my committee last week that this would be resolved. [↩]
3. It may be worth noting that even if you dislike the FSF, they are only going to make the license more restrictive- you’re never going to get a more libertarian GPL 4 that says ‘go wild, have a party, do whatever you want to the code.’ That means that if GPL 4 states ‘everyone must pay obeisance to RMS before using the code’ and you’ve used ‘or later’, the worst case scenario is that those people take your code and play with it in their own, small corner. As long as you really believe that fewer restrictions will win out in the marketplace of ideas, you’ve got nothing to lose from ‘or later’- large numbers of hackers will only move to the new license if there are really compelling reasons, no matter what FSF does. [↩]