tecosystems

Two Open Source Licensing Questions: The AGPL and Facebook

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

In many settings, open source licensing today is considered a solved problem. Not only has the Open Source Initiative (OSI) largely contained the long feared issue of license proliferation, the industry has essentially consolidated around a few reasonably well understood models.

Copyleft licenses such as the GPL, which require users who would distribute the software to demonstrate reciprocity by making available their changes under the same license (hence the usage of reciprocal to refer to these licenses) exist at one end of the spectrum. So-called permissive licenses, which include the Apache, BSD and MIT licenses, and generally ask very little of users of the code, are at the opposite end. In between are MPL-style licenses, which more selectively apply copyleft-style reciprocity requirements.

In spite of this maturity of model and understanding of approach, however, questions about open source licensing persist. In almost every case, the questions are a product of the difficulty commercial entities have in balancing business interests or revenue models with the realities of open source licenses. Certainly this is the case for hybrid licenses, which have been discussed in this space previously.

It’s also true of two of the more visible recent open source licensing issues to emerge.

  • The first of these centers around a piece published by Black Duck in mid-August. Entitled “The Quietly Accelerating Adoption of the AGPL,” it argues that the Affero version of the GPL – a variant in which the GPL’s reciprocal provisions are applied to hosted software – is seeing increased adoption over time. The theoretical intent of the license is to ensure that large service providers such as Amazon, Facebook, Google or Microsoft either don’t use the software without contributing back to it, or repurpose the software into SaaS businesses that can be forked and compete with the open source project they began as. For those interested, more detail on the AGPL can be found here or here.

    The claimed growth for the AGPL would be surprising because in our surveys, which notably rely on Black Duck data, we’ve seen no such spike. Black Duck’s piece cites among other numbers the growth in volume, with AGPL licensed assets having grown from 1000 or so projects to around 8000. Which indeed sounds impressive. But context is important. At RedMonk, we’re generally less interested in the raw project totals than their relative share. We assume most major licenses will grow, because open source itself is growing. What would convince us that the AGPL is in fact seeing a spike in adoption would be metrics that suggest that it’s growing relative to its peers. Over the last seven years, for example, the MIT license has jumped from 8% usage to 29% usage. Anecdotally, we have not seen anything like this for the AGPL, and Black Duck’s own numbers, in fact, do not suggest this. They show the AGPL still having less than one percent usage relative to its peers, and basic math says that 8000 projects out of at least two million surveyed means that the AGPL’s total market share is around .004%. If you’re looking for signs that the AGPL is breaking out, then, watch for changes in that number. Until then, it will be considered in this space as a niche license whose major project adoption is the exception to the rule.

  • The second and more complicated question being asked concerns the July decision by the Apache Software Foundation to disallow a license created by Facebook they refer to as “BSD + Patents.” This license was applied to several popular projects, React and RocksDB among them, making them ineligible for inclusion in ASF projects. In the aftermath of this decision, RocksDB was relicensed but Facebook declined to change React’s license. As I said at the time, this was a decision – and a message – that I would have advised Facebook against if they were a client of ours.

    The first mistake Facebook made, as Simon Phipps has said, was in not pursuing an OSI certification for their license. Both because the issues would have been surfaced earlier, and because industry consensus is that the OSI is the arbiter of open source licenses broadly. Violating that consensus is not a step that should be taken lightly, particularly for an entity with the visibility of Facebook.

    Second, there are already multiple existing licenses with patent protections – the Apache and BSD+Patent (not a typo, that’s actually a different license than Facebook’s BSD + Patents). Facebook’s argument for its more onerous patent protections would presumably center on the outsized target Facebook’s business has become: “As our business has become successful, we’ve become a larger target for meritless patent litigation. This type of litigation can be extremely costly in terms of both resources and attention.” Absent context, this seems reasonable. The reality, however, is that with the exception of Palantir, virtually no other provider requires a similar licensing model. Which means that the burden is on Facebook to explain why it employs a model that none of its peers seem to require.

    It is certainly possible, as Facebook has argued, that the issues involved with its unique license are theoretical and/or unlikely to occur. In one conversation with a client around a specific product, I made that exact argument. But if we think of legal documents as programs that have to clear a compiler, it’s not difficult to understand why this license is a non-starter for some communities. To its credit, Facebook seems to recognize this, acknowledging that it may “lose some React community members because of this decision.”

    The question I would ask Facebook is the basis of why its legal risk is asymmetrically higher than its peers, because it’s not clear that the benefits to the company’s approach here outweigh the real and observable costs. And while I can’t build the case for that myself, if Facebook can, its outbound messaging should clearly communicate why its uniqueness calls for a unique license – and then submit that to the OSI.

These specific issues aside, of course, the real difficulty isn’t with these licenses. It’s getting developers to use a license at all. But that’s a problem for another day.

Update: A few hours after this piece was posted, Matt Mullenweg of Automattic announced that – in spite of the company’s legal opinion that the patent issue would not present a risk – the core WordPress project Gutenberg along with its Calypso project were going to be rewritten to remove React and replace it with a different, unspecified library. This is a decision with major implications, and supports only one conclusion: if you’re going to deny yourself access to a quarter of the world’s websites on the basis of patent protection unique to the industry, the reasoning for it had better be bulletproof.

Disclosure: Amazon, Google and Microsoft are RedMonk clients. Black Duck and Facebook are not currently clients.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *