Facebook’s BSD+Patent license combo fails not because of the license itself but because it ignores the deeper nature of open source.
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. They are using the 3-clause BSD license (BSD-3), a widely-used 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 imcompatibility 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. Their 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 licence and found it delivers software freedom in a way that does not create unacceptable risks. Had Facebook taken the route of seeking OSI approval, they would most likely have discovered the issue they were 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 they 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 turn 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 them, and no-one else in the project, special rights and protections. That makes open source developers nervous, for the same reasons as contributor agreements. 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 yourself 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 licence. 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 specialise 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
While I’ve not been able to find a clear and complete rationale from them, Apache appears to have ruled against Facebook’s license combo because it has a patent grant they consider more restrictive than the one in the Apache License v2. Apache is very keen indeed to be a neutral source of software — a “universal donor” — so terms that militate against this are highly likely to fall foul of their rules. For components intended to be part of their ecosystem, it seems rash to mess with their licensing.
It thus 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 themselves. While they are currently holding firm, I hope Facebook gets it fixed and am willing to help.
Update, September 22: Facebook has announced they will switch React to the MIT license.
(This article was made possible by Patreon patrons. Maybe you should be one too?)
Pingback: Apache Bans Facebook’s License Combo | Meshed Insights Ltd
Pingback: 5 Reasons Facebook’s React License Was A Mistake https://meshedinsi… | Dr. Roy Schestowitz (罗伊)
Pingback: Links 28/7/2017: Suricata 4.0, QML vs. HTML5, LibreOffice 5.4 | Techrights