the gpl is fatally flawed, though the flaws were not obvious until online service became as prominent as they now are. attempts to update the gpl for “the cloud”, like the agpl, only serve to exacerbate the problem. more permissive licenses, such as bsd, mit, and apache, are less troublesome, though still lacking in certain areas, as i will explain.

the original intent of the gpl was to ensure users of software had access to the source so they could inspect it, fix it, and modify it for their needs, irrespective of the desires, or continued existence, of the software vendor. a noble goal motivated by the best of intentions and much excellent software has been produced under the gpl, with linux being the highest profile project.

with the widespread adoption of online services, a weakness in the gpl was exposed: because online services never handed software over to users, they were not obligated to share the source with them. the affero variant of the gpl closes this apparent gap by requiring source disclosure even when the software is provided as a service rather than as object code.

however, the agpl simultaneously makes itself unattractive to service providers who are rightfully concerned about contamination of their proprietary code such that they must release it. this is, in fact, the goal of the gpl and its variants: it acts as a virus to force the release of ever more source. the gpl serves to rigidly control what you can and cannot do with software covered by it, and is thus the license equivalent of digital rights management.

this leads to a related problem. the gpl produces, in practice, a two-tiered structure dividing those who control a software project from those who merely contribute to it. those in the former group are free to create a dual-license: those who want to use the software for non-commercial purposes can do so freely, but those wanting to use the software commercially must pay. the latter group cannot do this, regardless of how much they may have contributed to the project (though, of course, they could create a new project and rewrite all encumbered components). even worse, in a complete subversion of the intent of the gpl, a company can now make open source closed to its users simply by paying for a license. the license intended to protect the rights of users is instead being optimized for the rights of developers.

when the gpl is abused like this, as it is more and more frequently, the most obvious difference between it and the permissive licenses is a matter of who decides who gets paid. under the gpl, that control rests only with the project owner, just like content drm. under a permissive license, anyone can decide.

however, another, more troubling issue looms: content is at least as important as code, but open content licensing, like creative commons, and open source licensing are treated independently. as a result, vendors can adhere to both the letter and the spirit of an open source license, whether the gpl or something more permissive, yet users may have little control over the content managed by the software. as one concrete example, amazon made certain changes to linux for their kindle reader and, as required by the gpl, released those changes. however, the actual kindle application code is closed source and the content users purchase is accessible and transferable as seen fit by amazon or the publishers.

this is the real licensing hole. most users have little interest in source code access for the applications that manage their content, but they have intense interest in access to their content. if i store my personal photos on a photo site and attach all sorts of description and tag information to them, can i easily download them, with all the metadata, when i want? if i purchase books for my electronic book reader, can i easily back them up, transfer them between my devices, and continue to access them even if the company from which i purchased them goes out of business? these applications are empty shells, of no use to anyone, without their content.

the open source community needs to recognize the weaknesses, in practice, of licenses like the gpl and focus attention not on further controlling how people can use code, but, in the spirit of the user freedom, on ensuring access to their content.

this post was greatly improved by input from my reviewers, andrew and coda.

emil makes a very good point about constraints on project owners running off and selling contributed code. this does not invalidate my point that the gpl and its variants are being twisted in favor of developers vs. the original purpose of protecting users. i’ve updated the post to reflect his feedback.