Brain dump: notes and questions arising from “Facebook’s BSD-3 + strong patent retaliation” license
This is a living document and I will keep updating it as necessary
I wrote a piece a few days ago that I didn’t expect to go viral. I do apologise if you feel I’m not managing communication correctly, I’m not accustomed to receiving so much feedback at once, nor putting myself in the spotlight.
I’m not sure where all this will lead, either. But I do hope it sparks some changes in OSS policy — to the better.
That is, if you ever hope to be acquired by a larger companymedium.com
I have received a lot of questions and comments over the past two days. Since these are repeated over and over again, I am summarising my rationale in this article, along with questions that I would love Facebook to answer.
I’m a backend and distributed systems engineer: I do not hold any vested interest in any frontend framework nor the frontend business.
Let’s do this by parts. First, I discuss why you don’t need to be a lawyer to understand software licensing (and why that’s a good thing). Second, I talk about the unique vantage point of OSS developers. Finally, I jump into the meat of the matter: the notes and questions.
Not a lawyer
Note that I am not a lawyer, and I never discussed Patent Law in my article.
I am a volunteer (committer and PMC member) in two projects in the Apache Software Foundation (although I’m not very active as of these days) — of which, by the way, Facebook is a Platinum sponsor, donating at least US$100,000 / year.
I do not represent the Apache Software Foundation in my views. I haven’t even read the discussion about this topic inside the community. These views are 100% personal.
But let me state one thing clearly: I do not think you need to be a lawyer to discuss software licensing. Much like an HR Director doesn’t need to be a lawyer to understand labour law.
About developers understanding licensing terms
You will find that developers affiliated to Foundations like Mozilla, Eclipse, Apache, etc. tend to be cognizant about license terms — with varying degrees of knowledge.
Especially those not backed by a company. They tend to enjoy the OSS culture and can be genuinely interested in software licensing affairs.
In fact, have a look at the high quality of the discussion between devs on this infamous #10191 React issue. This is Github, folks, a place for developers, not lawyers.
I’ve always been particularly interested in these topics myself. My career has revolved around OSS for the last ~10 years — as a result of personal choice.
In fact, I firmly believe that we, as software engineers, should make a collective effort to understand the license terms of the software we adopt. That will help us make better decisions, as well as being beneficial for the industry as a whole.
Maybe this public debate will trigger that movement, who knows.
Beware of logical fallacies
If you discard my arguments solely alluding to the fact that I’m not a lawyer, you are incurring in a logical fallacy called Genetic Fallacy.
Conversely, if you take someone else’s opinion for granted just because they are a lawyer, you may be committing another fallacy called Argument from Authority.
My notes and questions
Definitions (in my own words)
- patent rights grant: providing a licensee the right to make, use, transfer, etc. the software covered by any patents;
- defensive termination: terms under which the aforementioned grant is revoked if the grantee initiates some action that would somehow harm the grantor.
The controversy and the licensing aspect
- Patent right grants are good.
- Defensive termination is OK and understandable as well — most licenses that grant patent rights include them: Apache Software License v2, Mozilla Public License, CDDL. [MIT license does not include a patent grant. As such, it offers no guarantees concerning patents to the licensee.]
- The controversial point in this debate is under which circumstances the patent right grant is terminated (i.e. the terms of defensive termination).
- Commonly used open source licenses (ASLv2, MPL, CDDL, etc. not MIT) use weak patent retaliation (WPR).
- What does WPR do? Let’s say Project X is the licensed work. WPR means that if you use (Project X), and suddenly you claim that (Project X) infringes a patent of yours, you automatically lose the patent right grants for (Project X) — completely understandable, in my opinion.
- With MPL you also lose the copyright license, but they give you a grace period of 60 days to migrate away. This is harsh, but it is at least scoped to the project itself, unlike strong patent retaliation. It could be understandable depending on which projects, e.g. if Google is using Firefox internally and they claim that Firefox violates some patent of Chrome, then after 60 days, they are no longer allowed to use Firefox internally.
- Now, let’s rephrase and fill in (Project X) with ‘React’.
- With weak patent retaliation that would result in: “If you use React and you sue Facebook over React, you lose the patent grants for React”.
- That would be a fair deal in my view. In fact, these are the terms that most corporations releasing Open Source software apply (see point #11).
- However, the whole point of the debate is that Facebook does not use this clause, but instead uses strong patent retaliation clause.
- Strong patent retaliation means that the termination clause is no longer scoped to Project X (React), but is triggered by ANY patent assertion claim you initiate against Facebook — whether related to React or not.
- If that weren’t enough, one credible source (Heather Meeker — a lawyer that represents Facebook on OSS affairs) appears to indicate the termination would apply no matter if you end up suing them or not — the mere act of accusing their products could mean you lose the patent right grant. [UPDATE: “to accuse” has a different connotation in Spain vs. the US, so it’s possible that accusing their product entails formally filing a suit — not sure — clarification needed].
- She states the following: “Unless a company decides to sue Facebook (or accuse its products), the termination trigger has no actual effect.” [UPDATE: please take this part with salt, based on the note above].
- So following the “fill in the blanks” approach, let’s replace ‘Project X’ with strong patent retaliation.
- “If you use React, and you initiate any patent assertion claim (as defined in the PATENTS file) against Facebook (whether React-related or not), you lose the patent right grants for React.” — these are the terms of strong patent retaliation.
- The same goes for: React Native, GraphQL, Jest, Flow, Relay, immutable.js, Caffe2, Reason, Shimmer, and more.
- This is what creates the asymmetry of power and leverage for Facebook, that folks like me are worried about.
What are other companies doing?
Facebook is nearly alone in their usage of BSD-3 + strong patent retaliationmedium.com
- I analysed the licenses 75+ open source projects by 35 companies. They all use ASLv2, MIT, MPL, BSD-3… Either with weak patent retaliation clauses, or no patent rights grant at all (MIT).
- None other except from Palantir, appears to use Facebook’s approach.
- So based on my examination, Facebook appears to be almost alone in their stance. If you know of any other company using strong patent retaliation in their OSS projects, let me know.
Some context: the clause was introduced almost 3 years ago
Facebook introduced this clause almost 3 years ago. They claim the following:
We believe that if this license were widely adopted, it could actually reduce meritless litigation for all adopters, and we want to work with others to explore this possibility.
If this license model cures the big evil of meritless patent litigation, why has practically no other corporation has adopted it yet?
What lawyers say
The opinion across lawyers appears to be divided. Obviously, you should check with your own lawyer if you’re concerned.
Some say the clause would not be enforceable, some say that Facebook doesn’t hold patents for React, some say that they couldn’t hold those patents because they’ve already disclosed prior work (what about development in works — where the patent application may be filed before making the work public?), other try to justify Facebook. (I’m trying to gather the URLs of the references — please bear with me: it’s work)
All these stances beg the question.
If there is consensus that these clauses are useless in practice…
Why is Facebook so adamant about keeping these licensing terms, in the first place, if they can allegedly not enforce them anyway?
NOTE: On the other hand, I believe some lawyers do argue that the PATENTS rider is an annex of the LICENSE itself, and when the rider stipulates “the license granted hereunder” it refers to the entire BSD-3 license, hence the copyright license would be revoked as well.
As I said before, I am not a lawyer. But truth is that Google is using React under these terms, and I assume they wouldn’t if the latter was the case (maybe this was for the older version of the PATENTS rider?).
“But Facebook contributes so much to Open Source”
Yes, they do. React and GraphQL particularly have been revolutionary in the frontend and API spaces, respectively.
However, so do Google, Microsoft, Twitter, Docker, IBM… and none of their projects wields a strong patent retaliation clause.
The closest I have seen is Google Golang’s BSD-3 + weak patent retaliation clause.
“Facebook is donating so much work, surely they deserve something in return”
When a company open sources work, it is not an act of philanthropy, it is not altruistic charity.
If they manage to kindle a community, they get a lot in return: contributions, improvements, bug reports, enhancements, trained resources, tooling, an ecosystem.
That’s why companies open source projects.
Look at the entire ecosystem that React has kindled. Do you think Facebook is not benefitting from it? This is a screenshot is a portion of >5,500 pull requests in facebook/react.
Granted some of these PR are internal to Facebook, but a large number are from outside contributors — based on my observation.
I was hoping to get some real numbers of inside vs. outside contributors. Unfortunately the GitHub advanced query syntax doesn’t allow me to narrow down to PRs submitted by authors not belonging to the Facebook organisation 😑
NOTE: I tried using Github’s GraphQL API to retrieve a count, but they do not support that filter criteria either. Maybe I will write a little script against their APIs if need be.
[23rd August 2017 13:15 BST]
Update: I’d like Facebook to explain the dynamics by which this clause actually deters “patent trolls”
Facebook asserts that the ultimate reason behind the strong retaliation clause is to deter patent trolls.
What is a patent troll?
Patent trolls are also called Non-Practicing Entities, Patent Assertion Entities or Patent Holding Companies. Wikipedia states the following:
Patent troll is a categorical or pejorative term applied to person or company that attempts to enforce patent rights against accused infringers far beyond the patent’s actual value or contribution to the prior art, often through hardball legal tactics […]. Patent trolls often do not manufacture products or supply services based upon the patents in question.
How does this license it stop them?
Normally, a patent troll is an opportunistic company whole sole raison d’être is to hoard patents in order to assert them at a later stage, under dubious circumstances and practice.
They do not normally engage in the IT business. If they did, they probably wouldn’t be a patent troll: it would be a legitimate/meritful patent dispute.
So… why would such a dubious, passive & non-practising company be using React, Jest, Flow, Immutable.js, etc. to begin with?
Something doesn’t add up.
[26th August 2017 12:00 BST]
Potential patents covering React and GraphQL
(granted or applied for)
Out of curiosity, I searched Google Patents for patents assigned to Facebook, Inc. While scanning the results, many things caught my eye. Once filtered, I believe at least three patents are of relevance. There may be more I dismissed.
Also, there may be more patent applications that have been filed, but not yet published.
- Automatic overdraw reduction before rendering (US 20170221242 A1, status: application) => this patent could cover a part of React’s or React Fiber’s rendering algorithm. In fact, it goes so far as to mention React as an embodiment. It was filed for February 1st, 2016, and published in August 2017.
- Graph Query Logic (US9646028 B2, status: granted) => this patent definitely covers GraphQL. It was filed for in August 2012, before it was in the public domain. It might be scoped to the context a social networking system, though.
- API version testing based on query schema (US 9400822 B2, status: granted) => this patent also covers an algorithm of GraphQL. It also seems scoped to the context of a social network, though.
Once again, I am not a lawyer and I cannot attest to the applicability of these patents. However, I am an engineer and I can understand the methods and inventions being described, and I am confident they relate to the technical domains of React and GraphQL.
This article will likely be updated
As I stated in the opening, this article will probably be updated further.
If you enjoyed this article, please recommend it on Medium (clap/heart it!), and share it on Twitter, LinkedIn, etc.
I’m starting a magazine for high-quality Blockchain & Crypto content. Please check out consensusX, and follow us ;-)