5 reasons Facebook's React license was a mistake

Facebook's BSD+Patent license combo fails not because of the license itself, but because it ignores the deeper nature of open source.

Subscribe now

Get the highlights in your inbox every week.

In July 2017, the Apache Software Foundation effectively banned the license combination Facebook has been applying to all the projects it has been releasing as open source. It is using the 3-clause BSD license (BSD-3), a widely used Open Source Initiative (OSI)-approved non-reciprocal license, combined with a broad, non-reciprocal patent grant, but with equally broad termination rules to frustrate aggressors. The combination represents a new open source license, which I've termed the "Facebook BSD Plus Patent License" (FB+PL), and to my eyes it bears the hallmarks of an attempt to be compatible with both the GPL v2 and the Apache License v2 at the same time, in circumvention of the alleged incompatibility of those licenses.

The use of the license by Apache projects is still in play, but the reason I believe Facebook has made a mistake may not be immediately obvious to ever-pragmatic software developers. For example, lawyer-turned-coder Dennis Walsh says of the issue, "there's no there there." His point is that the combo affects only use of the particular software project you're using to which it is applied, and the consequences of withdrawal of the patent grant are exceptionally unlikely to be serious for another patent holder. He concludes:

Facebook wants to make open source software and not be sued—a noble goal. To that end, they can use some harsh clauses. But in this case, for the practical and legal reasons outlined above, it's hard to find any teeth behind the bite.

Dennis is probably right. But that's beside the point. Facebook's rookie mistake of inventing its own open source license is always a bad idea. There are a range of important considerations that are not about the immediate risks or the specific instance. Facebook's license action hits pretty much all of them.

License approval matters
Use of a non-OSI-approved license means legal review is always required for corporate use, just as it would be for any proprietary license. OSI license approval matters because it provides developers with an indication that community review has verified the license and found it delivers software freedom in a way that does not create unacceptable risks. Had Facebook taken the route of seeking OSI approval, it would most likely have discovered the issue it was causing and avoided it at the outset. There is actually an OSI-approved license that achieves Facebook's apparent goal (the BSD Plus Patent License). It was submitted and approved quite recently and looks a reasonable alternative Facebook could consider adopting.

Less permission-in-advance
It's not just license approval that matters. Any kind of uncertainty concerning the freedom to innovate gets in the way of developers wanting to use code. An ambiguous term that relates to usage will need disambiguation before use—a step that amounts to seeking permission to proceed. For the same reasons public domain is bad for developers, using terms that require permission to be sought before proceeding chill adoption. By adding a Facebook-specific legal document to the project, every corporate developer will now need to reach out to a legal adviser before they can proceed. Even if the answer turns out to be "yes, OK," they still had to stop and seek permission. And as Aaron Williamson points out, that may not be their reaction.

Uneven playing field
The patent grant Facebook uses gives it, and no one else in the project, special rights and protections. That makes open source developers nervous, for the same reasons as contributor agreements do. The whole value of software freedom to an open source project is it creates a safe space where everyone is equal and protected from everyone else's motivations. Carving out extra rights for you alone is sociopathic, and sadly, the community has plenty of examples of unequal rights being eventually abused.

Implied grant voided
Many open source legal authorities believe that by granting permission to use software for any purpose, even licenses with no mention of patents grant an implied patent license. By adding any form of external patent grant, Facebook indicates it does not believe that grant is (at best) sufficient or (at worst) exists. Lawyers who specialize in open source see that as an unwarranted escalation by Facebook. That's why approval of CC0 at OSI was abandoned, for example.

Apache rules
Although I've not been able to find a clear and complete rationale, Apache appears to have ruled against Facebook's license combo because Facebook has a patent grant Apache considers more restrictive than the one in the Apache License v2. Apache is keen indeed to be a neutral source of software—a "universal donor"—so terms that militate against this are highly likely to fall afoul of its rules. For components intended to be part of its ecosystem, it seems rash to mess with Apache's licensing.

Thus it makes no sense to argue that, because the risk is small, the matter is trivial. Behaving in a way that ignores the five community norms I've listed above helps no one, not even Facebook. While it is currently holding firm, I hope Facebook gets it fixed, and I am willing to help.

Topics

About the author

Simon Phipps - Computer industry and open source veteran Simon Phipps started Public Software, a European host for open source projects, and volunteers as President at OSI and a director at The Document Foundation. His posts are sponsored by Patreon patrons - become one if you'd like to see more!
Over a 30+ year career he has been involved at a strategic level in some of the world’s leading...

2 Comments

You say "use of the license by Apache projects is still in play". This is incorrect. The issue is settled and the Facebook licensing using BSD plus a patents clause is now category X. That means that no Apache project can make a release with react or similarly licensed dependencies.

Footer

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.