Bradley M. Kuhn

• Contact
• Blog  
• Interviews / Articles  
• Software
• Résumé

GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I'd Be Worried

Thursday 13 November 2008 by Bradley M. Kuhn

Since the release of GPLv3, technology pundits have been opining about how adoption is unlikely, usually citing Linux's still-GPLv2 status as (often their only) example. Even though I'm a pro-GPLv3 (and, specifically, pro-AGPLv3) advocate, I have never been troubled by slow adoption, as long as it remained on a linear upswing from release day onward (which it has).

Only expecting linear growth is a simple proposition, really. Free, Libre and Open Source Software (FLOSS) projects do not always have the most perfectly organized of copyright inventories, nor is the licensing policy of the project the daily, primary focus of the developers. Indeed, most developers have traditionally seen a licensing decision as something you think about once and never revisit!

In some cases, such as with many of the packages in FSF's GNU project, there is a single entity copyright holder with a policy agenda, and such organizations can (and did) immediately relicense large codebases under GPLv3. However, in most projects, individual contributors keep their own copyrights, and the relicensing takes time and discussion, which must compete with the daily work of making better code.

Relicensing from GPLv2-or-later

GPLv2-or-later packages can be relicensed to GPLv3-or-later, or GPLv3-only, basically instantaneously. However, wholesale relicensing by a project leader would be downright rude. We're a consensus-driven community, and any project leader worth her title would not unilaterally relicense without listening to the community. In fact, it's somewhat unlikely a project leader would relicense any existing GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that matter) without the consent of the contributor who holds those copyrights. Even though that consent isn't needed, getting it anyway is a nice, consensus-building thing to do.

In fact, I think most projects prefer to slowly change the license in various subparts of the work, as those parts are changed and improved. That approach saves time from having to do a “bombing run” patch that changes all the notices across the project, and also reflects reality a bit better⁰.

Of course, once you change one copyrightable part of a larger work to GPLv3-or-later, the effective license of the whole work is GPLv3-or-later, even if some parts could be extracted and distributed under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have started taking patches licensed under GPLv3-or-later have effectively migrated to GPLv3¹. This fact alone, BTW, is why I believe strongly that GPLv3 adoption statistics sites (like Palamida's) have counts that underestimate adoption. Such sites are almost surely undercounting this phenomena. (It's interesting to note that even with such likely undercounting, Palamida's numbers show a sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

Relicensing from GPLv2-only

Relicensing from GPLv2-only is a tougher case, and will take longer for a project that undertakes it. Such relicensing requires some hard work, as a project leader will have to account for the copyright inventory and ensure that she has permission to relicense. This job, while arduous, is not impossible (as many pundits have suggested).

But even folks like Linus Torvalds himself are thinking about how to get this done. Recently, I began using git more regularly. I noticed that Linus designed git's license to leave open an easily implemented possibility for future GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for GPLv3-relicensing left open.

Not Rushing Is a Good Thing

Software freedom licenses define the rules for our community; they are, in essence, a form of legislation that each project constructs for itself. One “country” (i.e., the GNU project) has changed all its “laws” quickly because it's located on the epicenter of where those “laws” were drafted. Indeed, most of us who were deeply involved with the GPLv3 process were happy to change quickly, because we watched the license construction happen draft-by-draft, and we understood deeply the policy questions and how they were addressed.

However, most FLOSS developers aren't FLOSS licensing wonks like I and my colleagues at the FSF are. So, we always understood that developers would need time to grok the new license, and that they would prefer to wait for its final release before they bothered. (Not everyone wants to “run the daily snapshot in production”, after all.) The developers should indeed take their time. As a copyleft advocate, I'd never want a project to pick new rules they aren't ready for, or set legal terms they don't fully understand yet.

The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and reasoned approach. Pundits can keep saying that the new license has failed, but I'm not going take those comments seriously until the pundits can prove that this linear growth — a product of each project weighing the options slowly and carefully to come a decision and then starting the slow migration — has ended. For the moment, though, we seem right on course.

---

⁰Merely replacing the existing GPLv2-or-later notice to read “GPLv3-or-later” (or GPLv3-only) has little effect. In our highly-archived Internet world, the code that was under GPLv2-or-later will always be available somewhere. Since GPLv2 is irrevocable, you can't take away someone's permanent right to copy, modify, distribute the work under GPLv2. So, until you actually change the code, the benefit of a relicense is virtually non-existent. Indeed, its only actual value is to remind your co-developers of the plan to license as GPLv3-or-later going forward, and make it easy for them to license their changes under GPLv3-or-later.

¹I also suspect that many projects that are doing this may not be clearly explaining the overall licensing of the project to their users. A side-project that I work on during the weekends called PokerSource is actually in the midst of slow migration from GPLv3-or-later to AGPLv3-or-later. I have carefully explained our license migration and its implications in the toplevel LICENSE file, and encourage other projects to follow that example.

Posted on Thursday 13 November 2008 at 12:31 by Bradley M. Kuhn.

Submit comments on this post to <bkuhn@ebb.org>.