Luis VillaRamblings on software, law, and the spaces in between.

(Before going further, you should (at the minimum) read the disclaimer on Monday’s post and (ideally) make sure you’ve read all of the past two posts. (first, second.))

Q: Companies hate this! The sky is falling if the GPL is adopted!

A: Find your calm place. There is no doubt that the new license will create new uncertainty, which companies hate, and that the license seeks to place rights more firmly in the hands of users, which many companies (though not all) hate. So companies have reason to be nervous.

But the license was created with input from an extensive range of companies who both produce and use free software-based products, so I think you’ll find that it really isn’t that bad for companies who are playing by the rules- that is, for 95% of companies, 95% of the time. Remember, this license is (for most purposes) much more evolutionary than revolutionary, so it gives the same rights, sometimes clothed in different languages, in most circumstances. Most companies will not be affected by the tivo-ization and DRM clauses, and will actually appreciate the additional protections of the new license. Especially once companies have had time to digest the license, and to realize that none of the early adopters have turned into a newt, most companies should be fine with the license most of the time.

Q: OK. A little calmer now. My company makes products based on open source components. What are my new risks?

A: Have you burned the boats? If you’ve truly burned the boats, you’re fine- the patent provisions and installation provisions of the license only help you get closer to your customers and differentiate you from competitors and free-riders.

On the other hand, if you or your customers are still relying on some form of proprietary lockin, the picture is much less clear. You have new responsibilities that you may not have previously had. In particular, if you contribute to GPL v3 projects, you have to open up your patent portfolio to those projects and their users, and if you distribute GPL v3 code, you have to give your users the ability to reinstall code that they modify with very few restrictions. These may not be dealbreakers, but if your business model depends on users who are somehow kept under lock and key, you will have to deeply examine the new license, and may have to reconsider basing your business on GPL’d code.

Q: Do I get any benefits to go with those risks?

A: Like everyone else, you should get greater certainty about patents, and greater legal certainty in general as a result of the improved language. The same clauses that protect your customers from you will also protect you from competitors who seek to use some sort of patent or device lockin to compete unfairly against you, so even they aren’t all bad.

You’ll also get more control over trademark as part of the compatibility with the APL- you can explicitly ban use of the trademark by derivatives, among other things. Most community projects are not overly concerned by trademark, but this is clearly important to companies who are trying to build a brand, and more explicitly spelled out now as an optional addition to the license.

You also get the ability to transmit code to contractors without being considered to have ‘conveyed’ the code, allowing you to use consultants and outsourcers to modify your private code forks without accidentally freeing your work. If you sell non-consumer products (IBM S390 servers, for example, or medical devices which might be under government regulation) you are now even allowed to prevent modification/reinstallation by those who you sold servers to.

If you’re using patents or hardware to lock in your customers, none of these things are going to be much solace. But for everyone else, they should be useful compensations which make up for the short-term uncertainty.

Q: Why is Sun seemingly so excited about this? Should I share their enthusiasm?

A: Maybe. Sun is in a fairly unique situation. They badly want to win developer mindshare away from Linux, so becoming More FSF-Free than Linux is a big PR win for them- more so than it might be for most companies who aren’t competing with one of the poster children of open source and with the ghosts of their own proprietary past. In addition, some of the license features which are problematic for many people may be a benefit to Sun. For example, most people will look at v3′s incompatibility with v2 and think ‘what a pain’. Sun, in contrast, might think of that as a benefit, since that would continue to prevent Sun code from being used in the Linux kernel- who have to be seen as a significant competitor for them. Similarly, the new clauses which make embedding and DRM difficult may be seen as a detriment by many developers, but they play very well into Sun’s business model for Java, which is based on licensing into the embedded market. Anything that encumbers Free Java helps drive embedded market revenue for them, so GPL v3 may be preferable to v2 from that perspective.

All that said, we should probably give Sun some of the benefit of the doubt at this point- they’ve freed a lot of code, and by all accounts are trying hard to become a more open company. If they really wanted incompatibility and embedded revenue, they could just stick to the CDDL or a proprietary license. GPL would be a huge step for them, and is a step that the Free Software community should welcome with open arms, even if their motives are not 100% pure.

Q: Should Novell be quaking in their boots?

A: Hard to say. With their recent joint announcement with the EFF¹ they appear to have started the process of really burning the boats. A company fully committed to competing on the basis of quality and service, and willing to say no to customers who ask for bad things, should have very little to fear from GPL v3, and it seems like (belatedly) Novell may finally be headed in that direction.

Q: But Novell are on the hook for the MS deal, right?

A: Yes and no. While a deal like the Microsoft-Novell deal, which induces a third party to grant a non-assert agreement, older deals got grandfathered in- the FSF appears to believe that it is better to have Novell tentatively on our side than actively using their large warchest to fork everything that goes v3.² But it seems unlikely that MS can continue to uphold their part of the deal without licensing their entire patent portfolio to some key technologies like gcc and libc. So MS has a strong incentive to get the deal voided, and even if not, it will expire in the not too far future. (Remember, they negotiated a license which only covers five years of twenty year patents.) If they do renegotiate, the new deal will almost certainly look like the Xandros and Linspire deal, where MS offers indemnification to individual users instead of to all users. This will be acceptable under the new GPL language.

Q: So can we break out the champagne? Is the MS patent threat over?

A: Definitely not. MS can, of course, cease giving out coupons, and try to induce Novell to adjust the deal. Moreover, because of the complexity of the patent language, there is almost certainly another loophole for them to exploit, though it is hard to see what it migh be at this time. They could, for example, offer indemnification directly to customers- which appears to be the route announced in the Xandros and Linspire deals.³ Even if they do continue the relationship with Novell, lots of very big chunks of code that aren’t GPL v3, like the kernel and Open Office, will not be protected. So we’re still dead in their sights, no matter what.

Q: What does MS think, anyway?

A: They are gearing up their FUD machine, of course. Expect the old reliables: GPL is anti-American, GPL will steal your rights, GPL will eat your babies. Expect some new favorites too- lots of talk about how MS ‘builds bridges’, and about how the GPL hates interoperability. Of course, no mention will be made of the tolls that MS wants to charge on those bridges, or of the tons of GPL licensed code which builds bridges both to open standards and (despite the difficulties) to MS ‘standards.’

Q: What about the little guys in the embedded/consulting space? Opened Hand, Fluendo, etc.?

A: Each will have their own sets of problems and evaluations of the license. The new LGPL should allow Fluendo to continue down the mixed proprietary/open path they have chosen. Perhaps a more difficult question is what this will mean for those who are thriving in the embedded phone/handheld device space, like Opened Hand, OpenMoko, etc. The new license would appear to require that they allow modification, even for things like phones- which may be very problematic for networks (despite the out for network service providers included in the license, which allows you to withdraw services from modified devices if the modifications cause problems.) It will be interesting to see what openmoko’s lawyers say- they appear committed to resolving the problems between a locked down network and an open device, but this may be too much even for them to overcome. ⁴

Q: What about Google and other SaaS companies?

A: Nothing here that impacts them; they can continue business as usual. There is a new Affero GPL, which closes the SaaS loophole, but the FSF has made it clear that for now they will use moral persuasion rather than licensing to encourage code to migrate out from behind the closed Google doors. You might call this ‘picking your battles.’

Q: what is the bottom line for companies and the GPL?

A: For most? Simple. If you just use GPL-licensed code (for example, as a server or desktop), you have no worries. If you contribute code to GPL projects, you’re OK, as long as you feel comfortable granting your patents to the version of the project you’re contributing to. If you distribute GPL code as part of a device, you’re also OK, as long as you allow users to modify their devices. These categories cover the vast majority of corporate participants in the existing GPL community.

Despite that, this won’t be a license for everyone; some companies may prefer to stick with v2 or perhaps even use other alternatives instead. Like the choice for developers, the choice will require a case-by-case analysis of the costs and benefits. I do look forward to the day when we have a new license, representing a new and appealing business model which makes these kinds of choices easy, but for right now we’re stuck doing the hard and sometimes unpleasant work of protecting more user rights, and that means compromise and muddiness, not clear wins. Sorry about that…

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

1. which I’m embarrassed I haven’t covered in more detail- it was a bold move by Novell, given their conservative history, and the announcement deserved more attention than it has gotten [↩]
2. This clause also prevents Sun and IBM from having to review every patent licensing deal they’ve ever conducted- which is probably a good thing, since given a choice between ‘pay lawyers to audit and renegotiate potential tens of thousands of contracts’ and ‘skip the GPL v3 party’, they would almost certainly chose to skip the party. [↩]
3. FSF appears to be OK with this, since that route does not break away a chunk of supporters. [↩]
4. Perhaps we’ll have to wait for voip over wimax to get truly open wireless devices. :/ [↩]

(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. [↩]

Q: So why are we here?
A: At the end of this week, after 16 years, the Free Software Foundation should bless version three of the GNU General Public License, the sequel to what is arguably the most widely used and most impactful copyright license ever.¹ Quite literally everyone who makes software – open, proprietary, or web – needs to understand the v3 and figure out if it is evolutionary, revolutionary, or DOA, and how it impacts them as a potential contributor, consumer, cooperator or competitor. This is my small contribution towards that understanding.

Q: Can you summarize this Q&A in a haiku?
A:

new license rolls in
stormcloud- large, complex, strong, dense
scares, but should bring rain

(I really, really wanted to use “Snuffleupagus” in that, but sadly that doesn’t leave many syllables for imagery.)

Q: Why did you feel the need to summarize in haiku?

A: Because this was the longest blog post I’ve ever written. It is now going to be in (at least) four parts over three or four days, so you’ve been warned: you might want to leave off at the haiku :)

Q: Any disclaimers before you get rolling?

A: Tons. I am not a lawyer; whether I’m even a particularly good law student is still up in the air :) Don’t rely on this for legal advice.

I’ve based this commentary on the final discussion draft of the license; changes between now and the final, final version may invalidate some of my claims.

I’ve been on GPL Commitee A, so I’m predisposed to believe the FSF and SFLC’s interpretation of the license. On the flip side, I may not have learned much from that experience; mistakes are my own and may be plentiful.

Finally, I’m currently a Red Hat employee, but this is emphatically not a statement of Red Hat’s policy or interpretation of the license. No one at Red Hat has read this or commented on it beforehand, so again, mistakes are my own and may be plentiful.

Q: Why are we doing all this again? Isn’t GPL v2 reasonably good?

A: As I already mentioned, GPL v2 is almost certainly the most important and successful copyright license ever. By ensuring cooperation instead of competition, it has played a critical role in creating the large and thriving free/open source ecosystem. By providing a robust legal framework, it has provided predictability and protection for everyone who uses it. And by protecting the rights of users, it has done a fairly good job advancing the explicit goals of the authors of the license. So one has to consider it incredibly successful- especially considering that it is a legal document which most lawyers considered insane for a long time, and which still makes many uncomfortable.

That said, the license was written in 1991, and the computer industry has changed a lot since then. Patents have become a much more critical issue for the industry- in 1991, Microsoft had only just begun to understand how important patents would be to locking out new competitors. In 1991, the idea that computers would be the dominant form of media delivery would have been fairly ludicrous, much less the idea that software would be legally protected against “tampering.” And since 1991, the free and open source software community has gone from being a decent number of volunteers and one company, operating primarily on an informal basis, to being millions of volunteers and a multi-billion dollar industry, with all the legal structure, firepower, and infighting that implies. So an update was probably not a bad idea.²

Q: So what should a rewrite have done?
A: That is the million dollar question. While few people think of it that way, the FSF is a user-focused organization. GPL v2, to them, was about protecting the rights of users to control their own computing devices. The pragmatist camp sees GPL v2 as being about the rights of developers to progressively expand the commons and prevent bald-faced exploitation of their labor, a la Apple/BSD. These camps aren’t mutually exclusive- many of the license features which the FSF originally intended primarily to benefit users have been beneficial for developers, and obviously the thriving developer community is beneficial to users. But members of both communities often seem happy to trade away the rights of the other parties if there is a conflict.

Given that broad background, FSF’s specific goals for v3 were to protect user freedoms from ‘new’ threats like patents, DRM, and tivo-ization, while benefiting (or at least not alienating) developers. To the pragmatist camp, if there were to be changes, they needed to make life easier for developers- including not just individuals, but corporations. Since no one could think of any significant way to improve on the old license in that respect, they wanted to focus primarily on simplifying and strengthening what was already there.

Q: Given the success and the controversy of change, has the license really changed that much from v2 to v3?

A: The core goals, methods, and structures of v2 were successful and have been carried over with very few changes. If you use GPL code and do not redistribute it, you still get to do whatever you want with it. If you modify and redistribute GPL code, or build new applications on top of GPL-licensed libraries, you still have to release modifications and derivatives as GPL-licensed source. And you can can still build ‘immoral’ (aka, proprietary and/or DRM) code on top of the new LGPL. Some of the language has been changed enough that these goals may be hard to find in a casual read- but they are very much still there.

Q: What has changed, then?
A: A few major changes (note that some of these have been grossly oversimplified to be audience and scope appropriate; please don’t jump on me when I’ve not noted exceptions, loopholes, etc.) Note that I’ll have more on several of these over the next couple of days.

• internationalization: the new license moves away from language like ‘derivative’ – which comes from US copyright law – in favor of language which does not exist in any system of copyright law. This is excellent in theory- it should make the license more politically palatable and legally enforceable outside the US. In practice no one can really know what courts will think of this until it is tested. ³
• increased complexity: this tries to be a more lawyer-friendly document. It is not clear that it succeeded. Regardless of whether the lawyers like it, it is definitely less clear for hackers and executives on first glance, and that may slow uptake.⁴
• patents, the straightforward part: the license attempts to create an explicit and irrevocable patent grant extending from all contributors to all users. If you contribute a substantive patch upstream⁵, you’re granting a patent license to the whole project. Merely distributing without copyrightable contribution, like IBM does with many GNU tools⁶ still does not grant a license. This should help create more certainty about the patents owned by our major contributors- the folks like Sun, Novell, etc. – but it doesn’t help against those who don’t contribute code, like Microsoft and patent trolls. So the impact is positive but limited.
• patents, the complicated part: a lot of verbiage has been added in an attempt to prevent future blanket indemnifications like the Microsoft-Novell deal, and to ‘trick’ Microsoft into granting us their patents. I won’t go into these in much depth because I’m pretty sure they don’t buy us much – it looks like the Xandros and Linspire deals are already structured to avoid triggering these clauses, and there is no reason to believe that Novell and Microsoft can’t do the same. So net result here is probably that only the worst abuses of the old language, like the current Novell deal, are prevented. Not bad, but not the end of the Microsoft problem by any stretch.
• user control: the new license tries to make it clear that users have the right to control their hardware and software. This takes two forms: first, it forbids a claim by distributors of GPL’d code that the code is part of an ‘effective technical protection measure’ and second, it explicitly guarantees that installation instructions (including all the necessary tools and keys) must be available so that users can modify their software and reinstall it on devices that they own. This language, while not always straightforward, should mean that consumer-level users of GPL v3 code should be able to reliably modify the GPL-licensed code on devices that they own.
• license compatibility: the new license is compatible with the Apache Public License, so if you’re working on GPL v3 code, you should now be able to copy and paste from APL-licensed code. This does not mean that someone working on APL-licensed code can copy and paste from GPL v3 licensed code, though- compatibility with the GPL is always one way. (And the same applies to GPL v2 code- you can’t copy out of GPL v2 code, even into GPL v3 code.)

Q: So did the FSF reach their goals?

A: Since the FSF was in control of the process, the changes have focused on users rather than developers. Developers don’t necessarily fare poorly, but where there is choice between user freedoms and developer flexibility, the balance always tilts towards users. If, despite this, developers choose to use the license, it should give users and developers more certainty about patents, and it should ensure that users have the legal rights to control the devices that they own.⁷ Overall, then, a win for the FSF.

Q: Bottom line- in a year, what are we going to be saying about GPL?

A: Over the next few days I’ll explore the details of how developers and companies might feel about the new license, but I think the bottom line is that within a few years many will switch over. Communities who feel particularly threatened by patents, who badly want to draw from Apache, or who are particularly inclined to protect users and disregard possible costs to developers will adopt it particularly quickly. After that, adoption will slow for a while, but as users, developers, and corporates get comfortable, the various small improvements will gradually make it the default license for a plurality of new open source code, despite the understandable reservations (some well-grounded, some not) that many people currently feel.

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

1. Microsoft’s licenses are possibly more widely used, but only by a handful of pieces of software; the various Creative Commons licenses are probably also more widely used but (for better or for worse) have not yet set billion dollar industries on their ear. Really, we owe to GPL the notion that a copyright license can actually be important at all. [↩]
2. Novell’s decision to expose a real loophole in the patent language of the old license was only icing on the cake; the process was well underway before that happened. [↩]
3. The Creative Commons lawyers think this approach is borderline insane, but their approach- one license per legal regime- drastically increases license fragmentation, which we know is a very real problem. [↩]
4. Note that v2 isn’t nearly as clear as people would like to think- much of the supposed ‘clarity’ is really just the result of living with it and interpreting it for 16 years. [↩]
5. not just any patch; it must be meaningful enough to be copyrightable [↩]
6. edit later: IBM contributes to a number of GNU tools like gcc and classpath, I don’t mean to downplay that. Just that they also distribute the entire GNU user-space stack on AIX, which is the biggest example of ‘simple’ distribution that I know of. [↩]
7. Of course, those new rights only help you if you’re also a hacker, or can afford to pay one to hack for you. But this was a problem with the v2 as well. [↩]