An opportunity to understand the GPL license
Featured image: Matt Mullenweg, 2009. Credit: loiclemeur/Flickr, CC BY 2.0.
Every December, I wander over to ma.tt, the blog of WordPress founder Matt Mullenweg, to check what he’s saying about how the CMS will be shaping up in the next year. Despite my cribbings as well as constant yearning to be on Ghost, I’m still on WordPress and no closer to leaving than I ever was. And WordPress isn’t all that bad either (it runs The Wire, for example). In fact, I’m reminded of the words of a very talented developer from earlier this year with whom we at The Wire were consulting. When I brought up the fact that PHP (the programming language on which WordPress is a script) isn’t very conducive to scaling, he replied, “Anything can be built on anything.” So, for all its problems, WordPress does do some other things well that other CMSs might usually struggle with.
Anyway, lest I digress further – On a post on October 28, Mullenweg described the impact of the GPL license on WordPress’s development as “fantastic” – possibly because, as Linus Torvalds, who created the Linux kernel, has noted, the GPL license enforces itself: code derived from GPL-licensed code also has to be GPL-licensed. As a result, those making modifications to WordPress for their own use could not wall themselves off, preventing fragmentation as well as, in the words of University of Pennsylvania law professor Christopher Yoo, persevere in an environment that allows “multiple actors to pursue parallel innovation, which can improve the quality of the technical solution as well as increase the rate of technological change”.
GPL stands for ‘general public license’, and is widely used on the creation, modification, deconstruction, use and distribution of software on the web. Mullenweg’s broader post was actually about him noticing how the UI of the mobile app of Wix, a platform that lets its users build websites with a few clicks, closely resembled WordPress’s own, and how there was – as a result – a glaring problem. In its composition, WordPress uses code that’s on the GPL. GPL’s self-enforcement feature makes it a copyleft license: works that are derived from GPL-licensed work also have to be copyleft and distributed on the same terms. As a result, the code behind Wix’s mobile app had to immediately be made available (by, say, making it available on GitHub) and publicly accessible. It wasn’t.
Last I checked, the post had one update from Wix CEO Avishai Abrahami and 120 comments. And all together, they illustrated how the terms of the license, though written in language that was lucid enough, were easy to confuse and the sort of impedance that poses to its useful implementation. I spent an hour (probably more) going through all of it; if you’re interested in this sort of thing – or learning something new – I highly recommend going through the comments yourself. Or, if you’d like something shorter (but also trying to be wider in scope), you could just keep reading.
The tale has four dramatis personae: the GPL license, the MIT license, Wix’s mobile app and WordPress’s code (plus a cameo appearance by the LGPL license). Code derived from GPL-compatible code also has to be GPL-compatible – a major requirement of which is that: “… you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things” (emphasis added). This is also the clause that’s missing from the MIT license. As a result, code that’s originally under the MIT license can later be licensed as GPL (i.e. its source code made available) but code that’s originally under the GPL cannot later be licensed as MIT (i.e. source code that a GPL license has made accessible cannot be hidden away by the MIT license) – unless all the relevant copyright holders are onboard with the shift.
Paul Sieminski, the general counsel of Automattic – the non-profit company that originally built WordPress – commented on Mullenweg’s post thus: “[Wix would] probably be in the clear if you had used just the original editor we started with (ZSSRichTextEditor, MIT licensed). Instead, Wix took our version of the editor which has 1000+ original commits on top of the original MIT editor, that took more than a year to write. We improved it. A lot. And Wix took those improvements, used them in their app… but then stripped out all of the important rights that they’re not legally allowed to take away. We’re just asking Wix to fix their mistake. Release the Wix Mobile App under a GPL license, and put the source code up on GitHub” (link added). So far so good.
Wix CEO Abrahami’s response – posted on his blog on Wix – though cordial, makes the mistake of being evasive and in denial at once. As many commenters pointed out, Mullenweg’s ask was simple and clearly articulated: bring the source code behind Wix’s mobile app under the GPL and upload it on GitHub. Abrahami, however, defended Wix’s decision to keep the source code proprietary by saying that it only used an open source library modified by WordPress (“that is the concept of open source right?”) for a “minor part” of the app, and that he would “release the app you [Matt] saw as well”. The latter statement should have resolved the dispute because GPL only mandates that the source code be made available when asked for – not necessarily on GitHub. George Stephanis, a developer at Automattic, added: “The source code has to be freely available to everyone that has the software. If you want a paywall, it has to treat the software and source as a unit — you can’t distribute the software, but then charge for the source code.”
Some commenters pointed out that Abrahami may have been confusing the GPL license with the Library GPL (LGPL), and as a result not be entirely clear about the “viral” nature of the GPL license. When code is LGPL-compatible, extensions to the code needn’t be GPL-compatible. For example, in the Wix case, if the WordPress-modified open-source library was LGPL-, instead of GPL-, compatible and the mobile app had used parts of it, then the app’s source code doesn’t have to be GPL-compatible. In colloquial terms, the LGPL doesn’t infect code it is associated with the way the GPL does; it is less “viral”.
Nonetheless, I’d think it’s arguably harder to know Wix’s code has to be GPL-compatible, or even to know what the license on it ought to be, if it isn’t publicly available at all times. In support: the relevant part from the license’s preamble, which I quoted earlier, is “that [the users] know [they] can do these things”. I use the word ‘arguably’ not in the legal sense but in the spiritual one – the spirit being that of the free-software movement. And this is why I’m glad Mullenweg chose to hammer this issue out in public (via his blog) instead of via email. Moreover, I’m also glad that he didn’t initiate legal action immediately either: the conversation between Mullenweg, Abrahami and all the commenters – despite the occasional passive-aggressive animus – deserved to happen instead of the groups splintering off and blocking each other. The open source community always needs more unity.
Then again, the licenses that help sustain these communities could do more harm than good if they become too restrictive – especially when they fall out of step with changing governance practices while striving to keep the open source ideals we’ve associated with Richard Stallman alive even as they don’t offer too much freedom to users, which could result in a proliferation of alternatives that deprive useful software of its coherence. For example, Yoo writes in the paper I quoted from above,
… some restrictions on what people can do with open source operating systems are necessary if consumers are to enjoy the full benefits of competition and innovation. My point is not to suggest that open source software is inherently superior to proprietary software or vice versa. Both approaches have distinct virtues that appeal to different users. Moreover, any attempt to cast the policy debate as a choice between those polar extremes [i.e. open source and modular development] is based on a false dichotomy. Instead, the different modes for producing software platforms are better regarded as occupying different locations along a continuum running from completely unrestricted open source to completely proprietary closed source. Indeed, companies may even choose to pursue hybrid strategies that occupy multiple locations on this continuum simultaneously. The diversity of advantages associated with these different approaches suggests that consumers benefit if different companies are given the latitude to experiment with different governance models, with the presence of one open source platform serving as an important competitive safety valve.
Subscribe to The Wire‘s weekly science newsletter, Infinite in All Directions (archive), where I curate interesting science news, blogs and analyses from around the web.
