Software Freedom Law Center

January 27, 2009 by Bradley M. Kuhn

Welcome (Finally!) to the GCC Runtime Library Exception

For the past sixteen months, we've had a bit of a “mini-GPLv3 process” among folks at the FSF, SFLC, the GNU Compiler Collection Steering Committee (GCC SC), and the GCC community at large. We've been drafting an important GPLv3 license exception (based on a concept by David Edelsohn and Eben Moglen, that they invented even before the GPLv3 process itself started). Today, that GCC Runtime Library Exception for GPLv3 went into production.

I keep incessant track of my hours spent on various projects, so I have hard numbers that show I personally spent 188 hours — a full month of 40-hour weeks — on this project. I'm sure my colleagues have spent similar amounts, too. I am proud of this time, and I think it was absolutely worthwhile. I hope the discussion gives you a flavor of why FLOSS license exception drafting is both incredibly important and difficult to get right without the greatest of care and attention to detail.

Why GPL Exceptions Exist

Before I jump into discussion of this GCC Runtime Library exception, some background is needed. Exceptions have been a mainstay of copyleft licensing since the inception of the GNU project, and once you've seen many examples over many years, they become a standard part of FLOSS licensing. However, for the casual FLOSS developer who doesn't wish to be a licensing wonk (down this path lies madness, my friends, run screaming with your head covered!), exceptions are a rare discovery in a random source file or two, and they do not command great attention. An understandable reaction, but from a policy perspective, they are an essential part of the copyleft system.

From the earliest days of the copyleft, it was understood that copyleft was a merely a strategy to reach the goal of software freedom. The GPL is a tool that implements this strategy, but like any tool, it doesn't fit every job.

In some sense, the LGPL was the earliest and certainly the most widely known “GPL exception”. (Indeed, my friend Richard Fontana came up with the idea to literally make LGPL an exception to GPLv3, although in the v2 world, LGPLv2 was a fully separate license from GPLv2.) Discussions on why the LGPL exists are beyond the scope of this blog post (although I've written about them before). Generally speaking, though, LGPL is designed to be a tool when you don't want the full force of copyleft for all derivative works. Namely, you want to permit the creation of some proprietary (or partly proprietary) derivative works because allowing those derivations makes strategic sense in pursuing the goal of software freedom.

Aside from the LGPL, the most common GPL exceptions are usually what we generally categorize as “linking exceptions”. They allow the modifier to take some GPL'd object code and combine it in some way with some proprietary code during the compilation process. The simplest of these exceptions is found when you, for example, write a GPL'd program in a language with only a proprietary implementation, (e.g., VisualBasic) and you want to allow the code to combine with the VisualBasic runtime libraries. You use your exclusive right as copyright holder on the new program to grant downstream users, redistributors and modifiers the right combine with those proprietary libraries without having those libraries subject to copyleft.

In essence, copyleft exceptions are the scalpels of copyleft. They allow you to create very carefully constructed carve-outs of permission when pure copyleft is too blunt an instrument to advance the goal of software freedom. Many software freedom policy questions require this fine cutting work to reach the right outcome.

The GCC Exception

The GCC Exception (well, exceptions, really) have always been a particularly interesting and complex use of a copyleft exception. Initially, they were pragmatically needed to handle a technological reality about compilers that interacts in a strange way with copyright derivative works doctrine. Specifically, when you compile a program with gcc, parts of GCC itself, called the runtime library (and before that, crt0), are combined directly with your program in the output binary. The binary, therefore, is both a derivative work of your source code and a derivative work of the runtime library. If GCC were pure GPL, every binary compiled with GCC would need to be licensed under the terms of GPL.

Of course, when RMS was writing the first GCC, he realized immediately this licensing implication and created an exception to avoid this. Versions of that exception has been around and improved since the late 1980s. The task that our team faced in late 2007 was to update that exception, both to adapt it to the excellent new GPLv3 exceptions infrastructure (as Fontana did for LGPLv3), and to handle a new policy question that has been kicking around the GCC world since 2002.

The Plugin Concern

For years, compiler experimentalists and researchers have been frustrated by GCC. It's very difficult to add a new optimization to GCC because you need quite a deep understanding of the codebase to implement one. Indeed I tried myself, as a graduate student in programming languages in the mid-1990s, to learn enough about GCC to do this, but gave up when a few days of study got me nowhere. Advancement of compiler technology can only happen when optimization experimentation can happen easily.

To make it easy to try new optimizations out, GCC needs a plugin architecture. However, the GCC community has resisted this because of the software freedom implications of such an architecture: if plugins are easy to write, then it will be easy to write out to disk a version of GCC's internal program representation (sometimes called the intermediate representation, or IR). Then, proprietary programs could be used to analyze and optimize this IR, and a plugin could be used to read the file back into GCC.

From a licensing perspective, such an optimizing proprietary program will usually not be a derivative work of GCC; it merely reads and writes some file format. It's analogous to OpenOffice reading and writing Microsoft Word files, which doesn't make it a derivative of Word by any means! The only parts that are covered by GPL are the actual plugins to GCC to read and write the format, just as OpenOffice's Word reader and writer are Free Software, but Microsoft Word is not.

This licensing implication is a disaster for the GCC community. It would mean the advent of “compilation processes” that were “mixed”, FaiF and proprietary. The best, most difficult and most interesting parts of that compilation process — the optimizations — could be fully proprietary!

This outcome is unacceptable from a software freedom policy perspective, but difficult to handle in licensing. Eben Moglen, David Edelsohn, and a few others, however, came up with an innovative idea: since all binaries are derivative of GCC anyway, set up the exception so that proprietary binary output from GCC is permitted only when the entire compilation process involves Free Software. In other words, you can do these proprietary optimization plugins all you want, but if you do, you'll not be able to compile anything but GPL'd software with them!

The Drafting and the Outcome

As every developer knows, the path from “innovative idea” to “working implementation” is a long road. It's just as true with licensing policy as it is with code. Those 188 hours that I've spent, along with even more hours spent by a cast of dozens, have been spent making a license exception that implements that idea accurately without messing up the GCC community or its licensing structure.

With jubilation today, I link to SFLC's announcement, the announcement from the FSF, the FAQ and Rationale for the exception and the final text of the exception itself. This sixteen-month long cooperation between the FSF, the SFLC, the GCC SC, and the GCC community has produced some fine licensing policy that will serve our community well for years to come. I am honored to have been a part of it, and a bit relieved that it is complete.

Posted by Bradley M. Kuhn on January 27, 2009

Tags: gpl, copyright, licensing, gnu, exceptions

January 15, 2009 by Bradley M. Kuhn

Launchpad's License Will Be AGPLv3

Last week, I asked Karl Fogel, Canonical's newly hired Launchpad Ombudsman, if Launchpad will use the AGPLv3. His eyes said “yes” but his words were something like: Canonical hasn't announced the license choice yet. I was excited to learn this morning from him that Launchpad's license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application that we designed the AGPLv3 for, and Launchpad is rapidly becoming a standard in the next generation of Free Software project hosting. Over the last year, I've felt much trepidation that Launchpad would be “another SourceForge”: that great irony of a proprietary platform becoming the canonical method for Free Software project hosting. It seems now the canonical and the Canonical method for hosting will be Launchpad, and it will respect the freedom of network users of the service.

Given that they'd already announced plans to liberate Launchpad, it's not really surprising that Canonical has selected the AGPLv3. I would guess their primary worry about releasing the source was ensuring that competitors don't sprout up and fail to share their improvements back with the community of users. AGPLv3 is specifically designed for this situation.

I'm glad we've made a license that is getting adoption by top-tier Free Software projects like this one. Critics keep saying that AGPLv3 is a marginal license of limited interest. I hope this license choice by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are helping make this happen.

Posted by Bradley M. Kuhn on January 15, 2009

Tags: agplv3, ubuntu, licensing, launchpad

January 14, 2009 by Bradley M. Kuhn

LGPL'ing of Qt Will Encourage More Software Freedom

The decision between the GPL or LGPL for a library is a complex one, particularly when that library solves a new problem or an old problem in a new way. TrollTech faced this decision for the Qt library, and Nokia (who acquired Trolltech last year) has now reconsidered the question and come to a different conclusion. Having followed this situation since even before Qt was GPL'd, I was glad that we have successfully encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this subject, entitled Why you shouldn't use the Lesser GPL for your next library. A few times a year, I find myself rereading that essay because I believe it puts forward some good points to think about when making this decision.

Nevertheless, there is a strong case for the LGPL in many situations. Sometimes, pure copyleft negatively impacts the goal of maximal software freedom. The canonical example, of course, is the GNU C Library (which was probably the first program ever LGPL'd).

Glibc was LGPL'd, in part, because it was unlikely at the time that anyone would adopt a fully FaiF (Free as in Freedom) operating system that didn't allow any proprietary applications. Almost every program on a Unix-like system combines with the C library, and if it were GPL'd, all applications would be covered by the GPL. Users of the system would have freedom, but encouraging the switch would be painful because they'd have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite some time, as our community slowly replaced each application with freedom-respecting implementations. In the meantime, better that proprietary software users have a FaiF C library and a FaiF operating system to use (even with proprietary applications) while work continued.

We now face a similar situation in the mobile device space. Most mobile devices used today are locked down, top to bottom. It makes sense to implement the approach we know works from our two decades of experience — liberate the operating system first and the applications will slowly follow.

This argument informs the decision about Qt's licensing. Qt and its derivatives are widely used as graphics toolkits in mobile devices. Until now, Qt was licensed under GPL (and before that various semi-Free licenses). Not only did the GPL create a “best is the enemy of the good” situation, but those companies that rejected the GPL could simply license a proprietary copy from TrollTech, which further ghettoized the GPL'd versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL yields an important side benefit. While the proprietary relicensing business is a common and legitimate business model to fund further development, it also has some negative social side effects. The codebase often lives in a silo, discouraging contributions from those who don't receive funding from the company who controls the canonical upstream.

A change to LGPL sends a loud and clear message — the proprietary relicensing business for Qt is over. Developers who have previously rejected Qt because it was not community-developed might want to reconsider that position in light of this news. We don't know yet how the new Qt community will be structured, but it's now clear that Nokia, Qt's new copyright holder, no longer has a vested interest in proprietary relicensing. The opportunity for a true software freedom community around Qt's code base has maximum potential at this moment. A GUI programmer I am not; but I hope those who are will take a look and see how to create the software freedom development community that Qt needs.

Posted by Bradley M. Kuhn on January 14, 2009

Tags: gpl, licensing, lgpl, qt

December 24, 2008 by Bradley M. Kuhn

It's a Wonderful FLOSS

I suppose it's time for me to confess. For a regular humbug who was actually memory-leak-hunting libxml2 at the office until 21:30 on December 24th, I'm still quite a sucker for Frank Capra movies. Most people haven't seen any of them except It's a Wonderful Life. Like a lot of people, I see that film annually one way or the other, too.

Fifteen years ago, I wrote a college paper on Capra's vision and worldview; it's not surprising someone who has devoted his life to Free Software might find resonance in it. Capra's core theme is simple (some even call it simplistic): An honest, hard-working idealist will always overcome if he never loses sight of community and simply refuses any temptation of corruption.

I don't miss the opportunity to watch It's a Wonderful Life when it inevitably airs each year. (Meet John Doe sometimes can be found as well around this time of year — catch that one too if you can.) I usually perceive something new in each viewing.

(There are It's a Wonderful Life spoilers below here; if you actually haven't seen it, stop here.)

This year, what jumped out at me was the second of the three key speeches that George Bailey gives in the film. This occurs during the bank run, when Building and Loan investors are going to give up on the organization and sell their shares immediately at half their worth. I quote the speech in its entirety:

You're thinking of this place all wrong. As if I had the money back in a safe. The money's not here. Your money's in Joe's house; that's right next to yours. And in the Kennedy house, and Mrs. Macklin's house, and a hundred others. Why, you're lending them the money to build, and then, they're going to pay it back to you as best they can. Now what are you going to do? Foreclose on them?

[Shareholders decide to go to Potter and sell. Bailey stops the mob.]

Now wait; now listen. Now listen to me. I beg of you not to do this thing. If Potter gets hold of this Building and Loan there'll never be another decent house built in this town. He's already got charge of the bank. He's got the bus line. He got the department stores. And now he's after us. Why?

Well, it's very simple. Because we're cutting in on his business, that's why, and because he wants to keep you living in his slums and paying the kind of rent he decides. Joe, you had one of those Potter houses, didn't you? Well, have you forgotten? Have you forgotten what he charged you for that broken-down shack?

Ed, you know! You remember last year when things weren't going so well, and you couldn't make your payments? You didn't lose your house, did you? Do you think Potter would have let you keep it?

Can't you understand what's happening here? Don't you see what's happening? Potter isn't selling. Potter's buying! And why? Because we're panicking and he's not. That's why. He's picking up some bargains. Now, we can get through this thing all right. We've got to stick together, though. We've got to have faith in each other.

Perhaps this quote jumped out on me because all the bank run jokes made this year. However, that wasn't the first thing that came to mind. Instead, I thought immediately of Microsoft's presence at OSCON this year and the launch of their campaign to pretend they haven't spent the last ten years trying destroy all of Free Software and Open Source.

In the film, Potter eventually convinces George to come by his office for a meeting, offers him some fine cigars, and tells him that George's ship has come in because Potter is ready to give him a high paying job. George worries that the Building and Loan will fail if he takes the job. Potter's (non)response is: Confounded, man, are you afraid of success!?

It's going to get more tempting to make deals with Microsoft. We're going to feel like their sudden (seemingly) positive interest in us — like Potter's sudden interest in George — is something to make us proud. It is, actually, but not for the obvious reason. We're finally a viable threat to the future of proprietary software. They've reached the stage where they know they can't kill us. They are going to try to buy us, try to corrupt us, try to do anything they can to convince us to give up our principles just to make our software a little better or a little more successful. But we can do those things anyway, on our own, in the fullness of time.

Never forget why they are making the offer. Microsoft is unique among proprietary software companies: they are the only ones who have actively tried to kill Open Source and Free Software. It's not often someone wants to be your friend after trying to kill you for ten years, but such change is cause for suspicion. George was smart enough to see this and storm out of Potter's office, saying: You sit you around here and spin your little webs and think the whole world revolves around you and your money! Well, it doesn't, Mr. Potter!. To Microsoft, I'd say: and that goes for you, too!

Posted by Bradley M. Kuhn on December 24, 2008

Tags: social justice, microsoft

December 9, 2008 by Bradley M. Kuhn

One gpg --gen-key per Decade

Today is an interesting anniversary (of sorts) for my cryptographic infrastructure. Nine years ago today, I generated the 1024 bit DSA key, DB41B387, that has been my GPG key every day since then. I remember distinctly that on the 350 MhZ machine I used at the time, it took quite a while to generate, even though I made sure the entropy pool remained nice and full by pounding on the keyboard.

The horribleness of the recent Debian vulnerability meant that I have spent a much time this year pondering the pedigree my personal cryptographic infrastructure. Of course, my key was far too old to have been generated on a Debian-based system that had that particular vulnerability. However, the issue that really troubled me this past summer was this:

Some DSA keys may be compromised by only their use. A strong key (i.e., generated with a ‘good’ OpenSSL) but used locally on a machine with a ‘bad’ OpenSSL must be considered to be compromised. This is due to an ‘attack’ on DSA that allows the secret key to be found if the nonce used in the signature is reused or known.

Not being particularly hard core on cryptographic knowledge — most of my expertise comes from only one class I took 11 years ago on Encryption, Compression, and Secure Hashing in graduate school — I found this alarming and tried my best to do some ancillary reading. It seems that DSA keys, in many ways, are less than optimal. It seems (to my mostly uneducated eye) in skimming academic papers that DSA keys are tougher to deploy right and keep secure, which leads to these sorts of possible problems.

I've resolved to switch entirely to RSA keys. The great thing about RSA is its simplicity and ease of understanding. I grok factoring and understand better the complexity situation of the factoring problem (this time, from the two graduate courses I took on Complexity Theory, so my comfort is more solid :). I also find it intriguing that a child can learn how to factor in grade school, yet we can't teach a computer to do it efficiently. (By contrast, I didn't learn the discrete logarithm problem until my Freshman year of college, and I still have to look up the details to remind myself.) So, the “simplicity brings clarity” idea hints that RSA is a better choice.

Fact is, there was only one reason why I revoked my ancient RSA keys and generated DSA ones in the 1990s. The RSA patent and the strict licensing of that patent by RSA Data Security, Inc. made it impossible to implement RSA in Free Software back then. So, when I switched from proprietary PGP to GPG, my keys wouldn't import. Indeed, that one RSA patent alone set back the entire area of Free Software cryptography at least ten years.

So, when I decided this evening that I'd need to generate a new key and begin promulgating it at key-signing parties sometime before DB41B387 turns ten, I realized I actually have the freedom to choose my encryption algorithm now! Sadly, it took almost these entire nine years to get there. Our community did not only have to wait out this unassailable patent. (RSA is among the most novel and non-obvious ideas that most computer professionals will ever seen in their lives). Once the RSA patent finally expired⁰, we had to then slowly but surely implement and deploy it in cryptographic programs, from scratch.

I'm still glad that we're free of the RSA patent, but I fear among the mountain of “software patents” granted each year, that the “new RSA” — a perfectly valid, non-obvious and novel patent that reads on software and fits both the industry's and patent examiner's definition of “high quality” — is waiting to be discovered and used as a weapon to halt Free Software again. When I finally type gpg --gen-key (now with --expert mode!) for the first time in nine years, I hope I'll only experience the gladness of being able to generate an RSA key, and succeed in ignoring the fact that RMS' old essay about this issue remains a cautionary tale to this very day. Software patents are a serious long-term threat and must be eradicated entirely for the sake of software freedom. The biggest threat among them will always be the “valid”, “high quality” software patents, not the invalid, poor quality ones.

⁰ Technically speaking, RSA didn't need to expire. In a seemingly bizarre move, RSA Data Security, Inc. granted a Free license to the patent a few weeks before the actual expiration date. To this day, I believe the same theory I espoused at the time: their primary goal in doing this was merely to ruin all the “RSA is Free” parties that had been planned.

Posted by Bradley M. Kuhn on December 9, 2008

Tags: encryption, security, technology

December 4, 2008 by Bradley M. Kuhn

The FLOSS License Drafter's Responsibility to the Community

I finally set aside some time to read my old boss' open letter responding to criticisms of the FDL process. I read gladly his discussion of the responsibilities of software freedom license stewardship.

I've been involved with the drafting of a number of FLOSS licenses (and exceptions to existing licenses). For example, I helped RMS a little with the initial FDL 1.0 drafting (the license at issue here); I was a catalyst for the creation of Artistic 2.0 and advised that process; and, I was heavily involved with the creation of the AGPL, and somewhat with the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed when kibitzed by a user who just downloaded the program and is missing something obvious, we license drafters are human and often have the “did this person even read all the stuff we've written on this issue?” knee-jerk response to criticism. However, we all try to put that aside, and be ready to respond and take seriously any reasonable criticism. I am glad that RMS has done so here. The entity that controls future versions of a license for which authors often use an “or later” term holds great power. As the clichéd Spiderman saying goes, with great power, comes great responsibility.

The FSF as a whole, and RMS in particular, have always know this well and take it very seriously. Indeed, years ago, when I was still at FSF, RMS and I wrote an essay together on a closely related issue. This recent response on FDL reiterates some of those points, but with a real-world example explaining the decision making process regarding the reasonable exercise of that power to, in turn, grant rights and freedoms rather than take them away.

The key quote from his letter that stands out to me is: our commitment is that our changes to a license will stick to the spirit of that license, and will uphold the purposes for which we wrote it. This point is fundamental. As FLOSS license drafters, we must always, as RMS says, abide by the highest ethical standards to uphold the spirit that spurred the creation of these licenses.

Far from being annoyed, I'm grateful for those who assume the worst of intentions and demand that we justify ourselves. For my part, I try to answer every question I get at conferences and in email about licensing policy as best I can with this point in mind. We in the non-profit licensing sector of the FLOSS world have a duty to the community of FLOSS users and programmers to defend their software freedom. I try to make every decision, on licensing policy (or, indeed, any issue) with that goal in mind. I know that my colleagues here at the SFLC, at the Conservancy, at FSF, and at the many other not-for-profit organizations always do the same, too.

Posted by Bradley M. Kuhn on December 4, 2008

Tags: agplv3, gpl, licensing, fdl

December 1, 2008 by Bradley M. Kuhn

AGPL Declared DFSG-Free

Late last week, the FTP Masters of Debian — who, absent a vote of the Debian developers, make all licensing decisions — posted their ruling that AGPLv3 is DFSG-Free. I was glad to see this issue was finally resolved after months of confusion; the AGPLv3 is now approved by all known FLOSS licensing ruling bodies (FSF, OSI, and Debian).

It was somewhat fitting that the AGPLv3 was approved by Debian within a week of the one year anniversary of AGPLv3's release. This year of AGPLv3 has shown very rapid adoption of the AGPL. Even conservative numbers show an adoption rate of 15 projects per month. I expect the numbers to continue a steady, linear climb as developers begin to realize that the AGPL is the “copyleft of the Cloud”.

Posted by Bradley M. Kuhn on December 1, 2008

Tags: agplv3, debian

November 20, 2008 by Bradley M. Kuhn

podjango: A Minimalist Django Application for Podcast Publishing

I had yet to mention in the SFLC blog (although it is elsewhere on the site) that we've started a podcast. I found myself, as we launched the podcast last week, in a classic hacker situation of having one project demand the need to write code for a tangentially related project.

Specifically, we needed a way to easily publish show notes and otherwise make available the podcast on the website and in RSS feeds. Fortunately, we already had a few applications we'd written using Django. I looked briefly at django podcast, but the interface was a bit complicated, and I didn't like its (over)use of templates to do most of the RSS feeding.

The small blogging application we'd hacked up for this blog was so close to what we needed, that I simply decided to fork it and make it into a small podcast publisher. It worked out well, and I've now launched a Free Software project called podjango under the AGPLv3.

Most of the existing code will be quite obvious to any Django hacker. The only interesting thing to note is that I made some serious effort for the RSS feeds. First, I heavily fleshed out the minimal example for an iTunesFeed generator in the Django documentation. It's currently a bit SFLC-specific, but should be easily abstracted. I did a good amount of research on the needed fields for the iTunes RSS and Media RSS and what should be in them. (Those feedforall.com tutorials appear to be the best I could find on this.)

Second, I did about six hours of work to build what I called our ominbus RSS feed. The most effort went into building an RSS feed that includes disparate Django application components, but this thread on query set manipulation from django-users referenced from Michael Angela's blog was very helpful. I was glad, actually, that the ultimate solution centered around complicated features of Python. Being an old-school Perl hacker, I love when the solution is obvious once you learn a feature of the language that you didn't know before. (Is that the definition of programming language snobbery? ;)

It also turns out that Fabian Scherschel (aka fabsh) had started working on on a Django podcast application too, and he's going to merge in his efforts with podjango. I preemptively apologize publicly, BTW, that I didn't reach out to the django-podcast guys before starting a new project. However, I'm sure fabsh and I both would be happy to cooperate with them if they want to try to merge the codebases (although I don't want to use a non-Free software platform like Google Code to host any project I work on ;). Anyway, I really think RSS feeds should be implemented using generators in Python code rather than in templates, though, and I think the user interface should be abstracted away from as many details for the DTD fields as possible. Thus, it may turn out that we and django-podcast have incompatible design goals.

Anyway, I hope the code we've released is useful, and I'm glad for Fabian to take over as project lead. I need to move onto other projects, and hope that others will be interested in generalizing and improving the code under Fab's leadership. I'm happy to help it along, so please subscribe to the mailing list if you're interested.

Posted by Bradley M. Kuhn on November 20, 2008

Tags: agplv3, podcast, podjango

November 13, 2008 by Bradley M. Kuhn

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

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). (As a plug for SFLC, if you're a project that wants to get this done, you should write to <help@softwarefreedom.org>.)

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 SFLC and the GNU project 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 by Bradley M. Kuhn on November 13, 2008

Tags: agplv3, gpl, copyright, licensing, gnu

November 4, 2008 by Bradley M. Kuhn

AGPLMail: Taking steps toward FaiF “Cloud” Applications

Ben Webb (aka bjwebb) has announced the launch of a project called AGPLMail.

bjwebb has been asking me questions on and off on IRC about starting this project, and I am very glad to see his announcement. He asks in his blog post am I doing something valuable?. My unequivocal answer is yes!

As developers, we have to clone each application that has become a standard in “the Cloud” and make sure there is a Free-as-in-Freedom (FaiF) equivalent. We need readers and signers of the Franklin Street Statement to get to work writing FaiF applications that embody its ideas. That's the only way we will meet and overcome the challenge of truly distributed network services that respect user freedom and autonomy.

It's tough to always be playing catch-up, but the Free Software world has shown that we “get there in the end”, and that the final result is something that really respects the freedom of the users. I'm glad bjwebb is taking a stab at the FaiF Web 2.0 mail client, and I hope others will help him make it better.

As a final note, I wanted to point out the admirable humility bjwebb has shown in putting his code out there. What he's looking for is others to join him on the journey and try to make the application into something interesting. He doesn't purport to have the answers, but he's certainly asking the right questions in the best possible way for a developer — putting some code out there under a Free license and asking his peers to give him some feedback!

As a side note, I should mention that I've already told bjwebb that, due to my anti-PHP bigotry, I'm the wrong person to ask if his code is any good. I leave it to those who have more open minds about PHP to lend him a hand. ;)

Posted by Bradley M. Kuhn on November 4, 2008

Tags: agplv3, netservices