(optional) have defensive patent clauses (if you want to discourage your users from suing you over patents)

Here’s the problem: historically, there hasn’t been a license that meets all of those needs. No license gives both #1(a) and #3, because FSF has historically considered patent termination an incompatibility with GPL v2. BSD/MIT does #1, but doesn’t do 3 – and may not give you confidence about patents (#2).

BSD doesn’t give patent confidence?!?

You might be surprised when I say the BSD license may not give users confidence around patents. You’re not alone! El Camino Legal writes:

I’ve never heard any lawyer postulate that [the BSD license] does not grant a license to fully exploit the licensed software under all of the licensor’s intellectual property. … Developers-licensees (or, more to the point, their lawyers) have traditionally been very confident that the BSD License does not leave room for a licensor to successfully sue under patents.

I personally think a court should and probably would read the BSD license in this way. But I — and many other FOSS experts — are not “very” confident about this, especially for clients at high patent risk for some reason.

Why not? In short, the BSD license does not actually say “you have a license to use our patents” — it just says “you can use our software”. Courts should in this case say “of course allowing you to use their software also allows you to use their patents”. (In US patent law, this is called an implied license.) But whether a court will do this varies from country to country, and even court to court. And in an era (hopefully ending soon!) of mass litigation over software patents, some large companies — and individuals — reasonably want more confidence than that.

Don’t over-react by deleting all your BSD-license code! BSD’s implied patent license is probably fine, the vast majority of the time. But if you use BSD-licensed code and face increased patent risk (say, you compete with the author, and they have a lot of patents) then it is reasonable to investigate more. And if you publish code under BSD there is no harm, and some potential benefit, in resolving the uncertainty up front with explicit patent language. This is exactly what Facebook seems to have tried here.

Is it well-written?

Since (until recently) there were no standard permissive licenses with an explicit patent license, concerned companies have used custom-drafted licenses. Unfortunately, virtually no one gets new open licenses right on the first try. For example, Google revised their WebM patent language after early feedback from the open license community. And even the most careful open license drafters have a clause they regret. (Ask me over a beer sometime.)

Given that history, it isn’t surprising that this new license is somewhat inelegant. For example, El Camino is correct that the “Necessary Claim” language comes from standards rather than software. (I suspect Facebook got it from either the Apache license and the WebM patent grant.) I’d personally add that “for the avoidance of doubt” is usually not good practice. And I’m curious why they called this an “additional” grant in the title of the document ­— on the one hand, that could be read to acknowledge the implicit grant in the BSD license (great!), but on the other hand it could be read to weaken the value of the termination clause (not so hot). (And of course, Facebook also had some second thoughts, updating the license to allow countersuits – against themselves!)

Is it open?

El Camino’s blog post has gotten attention in large part for claiming that the React license is not open source. Respectfully, I think they’ve gotten this wrong, and I want to correct the record.

Their claim that React is not open source hinges on the definition of a “fee” in section 1 of the Open Source Definition. The Definition says:

The license shall not require a royalty or other fee for such sale.

El Camino argues that the React license clause that requires you not to sue Facebook over patents is a “fee”, since the licensee “pays a price… not… paid with money” to use the software. This interpretation is not unreasonable! Giving up your options is, indeed, a “price” in some sense.

However, the OSI and the broader open source community have always interpreted “fee” to mean monetary payment. This is reflected in the annotatedOpen Source Definition, which states that this clause “require[s] free redistribution” (emphasis mine).

More conclusively, the GPL (indeed, all copyleft licenses) also require you to give up some options — the option to make proprietary derivatives! If “fee” was defined as “giving up options”, then the GPL would never have been treated as an open license. Instead, GPL has always been considered open by the Open Source Initiative — pretty conclusive evidence that “fee” means monetary payment.

And of course, as El Camino noted in an update to their original post, OSI approved similar patent language when they approved MPL 1.1.

I’m not going to firmly claim that the React license is compliant with the Open Source Definition, since it hasn’t gone through a full OSI review. But I think the concern raised by El Camino is based on a (well-intentioned) misunderstanding of the Open Source Definition, and the language would likely pass an OSI review for OSD compliance.

Is it a good idea?

Of course, a license can meet the requirements of the Open Source Definition and still not be a great idea. For example, when drafting MPL 2.0 we realized that narrowing MPL 1.1’s patent termination clause would encourage use in some cases while not hurting Mozilla’s contributors. I suspect that, overall, React’s license would be better if it made the same change. But, again, “you might not want to use it if your company is a frequent patent litigator and/or huge Facebook competitor” is not the same as “not open”.

License protects users, not just Facebook

It is important to note that there are two key ways that this clause protects React’s users, not just Facebook.

First, there is the obvious one: this gives users a very explicit patent license. If Zuckerberg retires tomorrow (or, um, sells their open source components to Oracle) React’s users will still have a very clear license to those patents.

Second, this clause gives Facebook the ability to protect React users who are sued over React-related patents, not just Facebook. Would Facebook actually protect React users that way? No idea! But if I’m a troll and considering suing React users en masse, this language at least gives a reason to pause and think twice. (MPL 2.0’s patent retaliation clause, canceling not just the patent license but also the copyright license, would have even more teeth – something for Facebook to consider if they revise this again :)

Bottom line

Is the React license elegant? No. Should you be worried about using it? Probably not. If anything, Facebook’s attempt to give users an explicit patent license should probably be seen as a good faith gesture that builds some confidence in their ecosystem.

But yeah, don’t use it if your company intends to invest heavily in React and also sue Facebook over unrelated patents. That… would be dumb. :)

“Since (until recently) there were no standard permissive licenses with an explicit patent license”

Are you referring to the ALv2 here? If not, then how does its clause (3) not provide the patent license that you’re discussing in this article?

And my more pertinent question: is there a specific difference between the ALv2 patent license, and that of the React license? Or, in other words, can you provide a guess on why React didn’t simply choose the ALv2?