3 Points to Consider before Migrating Away from React Because of Facebook’s ‘BSD+ Patent’ License
Ariel Reinitz
2.5K7

Jungwoo Hong / Unsplash

There are really three aspects to to your project’s decision (to use React or not based on the BSD+Patents license), and it’s important to consider each of them. You really need to consider which aspects are important to your project’s success — and which ones don’t really matter to you.
(See my new FAQ about the PATENTS issue!)

  • Legal — both details of the license and PATENTS file that Facebook offers React.js under, and some realistic situations where the patent clauses might actually come into play (which is certainly rare in court, but it’s the chilling effect of uncertainty that’s the issue)
  • Technology — are other libraries sufficiently functional to provide the features your project needs? Does a project have the capacity to make a change, if they decided to?
  • Community — how does the rest of the open source community-of-communities see the issue, and care about your choices? This includes both future buyers of a startup, as well as future partners, as well as future talent (employees) or contributors (open source developers).

UPDATE: Facebook has relicensed React.js as well as some other software under the MIT license, without the FB+PATENTS file. That’s good news, in general!

PATENTLY Legal

I’ll start off what is almost certainly the least important issue to consider for your project: licenses and patents.

  • The legal issue is immaterial unless you’ve really thought through your project’s business model and really taken the time to evaluate how any patents you might now or in the future hold play into this. Seriously, before you read about this controversy (and even earlier), how much did you worry about potential future patent claims that might be in the many open source components your company uses?
  • The major legal point that’s worth bringing up as a generality is that including software under a non-OSI approved license always adds complexity, immaterial of the details of the license. In an honest open source world, there is never a good reason to use a license besides one of the OSI-approved licenses. OSI-approval is not a magic stamp; however it does show licenses that are so widely used — and reviewed by lawyers — that there is seen as less risk to everyone else in consuming software under an OSI license.
  • Note: React is not offered under “BSD + Patent” (or more specifically BSD-2-Clause-Patent, thanks SPDX) OSI-approved license. It is offered under the BSD-3-Clause license (OSI-approved), plus Facebook’s own custom-written PATENTS file. It’s the addition of the custom bits about patents — which may be well written, but are different than other well-used licenses — that is the issue. Different licenses mean the lawyers need to spend extra time reviewing them before you can even get an informed opinion.

Technology Changes

If you are not yet using React.JS in your project(s), then now is an excellent time to review the functionality and ecosystems around the similar libraries, like Preact, Vue.js, React-lite, Inferno.js, Riot.js, or other great JS libraries out there.

If you are already using React.JS — like a lot of people — then you should take a brief moment to read up on this licensing issue. Don’t simply listen to the hype pro or con, but think how the issues you’ve read about apply to your project and your goals. React.JS has been using the Facebook PATENTS license for years now, so this is not a new situation and certainly doesn’t mean you need to make any quick changes.

If you are really worried about the legal aspects of the license now, then you need to ask yourself: is it practical for us to change libraries?

  • Is there another open source library that provides sufficient functionality for what your project needs?
  • Do you have the technical capacity — engineering staff (for a company) or passionate volunteers (for an opensource project) — to change your architecture to use a new library?
  • Are there aspects of your project that could work better if you changed to a different library?

These questions probably look familiar to most readers than the license and patent issues. And in most cases, these are the most important questions for your project — your technical capacity to make any changes, and if this is an opportunity to improve things, or if it’s just extra make-work to switch libraries.

Community Expectations

What does your community think about this issue? Again: not just the hype, take the time to think this through. And consider what “community” means to your specific project — VCs to buy your startup, customers to buy your software, contributors to join your opensource project, or developer talent you want to hire for your company. You need to understand who your community is to understand how they will view your decision.

  • If you are a big company, your lawyers have probably already told you what to do. Most likely if you’re already using React.JS, the issue was decided long ago when you first started using it.
  • If you are a startup thinking about VC exits, then don’t worry about the hype. But you do need to do an analysis of how this (old) news affects your project and your specific goals. My bet is that it won’t matter much — any major VC’s lawyers have long known about this issue and already calculated their reaction. More to the point, if you’re looking for a big buyout, at that point you’ll add enough staff to rewrite at the time if you decide it’s necessary (but I bet it won’t be).
  • If you are a software company building a variety of applications, you probably don’t need to worry for existing tools. Certainly consider alternatives for new tools you start.
  • If you are a non-software company, you don’t need to worry about it. React.JS has used this license for ages, so there’s no change (just hype and news about the ASF policy change).
  • If you are an open source project, you’re probably already realizing that many open source contributors expect a level playing field for any software that calls itself “open source”. That means using an OSI-approved license, period. In particular, if your project might intend to ever join the Apache Software Foundation, then you need to consider OSI-licensed alternatives, since the ASF no longer allows React.JS in it’s projects.

What Open Source Means

The big lesson here is: if you expect to play in the open source arena, you need to be honest about what “open source” means. There are a lot of aspects to the definition, but the most important one is publicly providing the source code under an OSI-approved license. React.JS is not offered under an OSI-approved license — and now that people are talking about it, they’re realizing it’s not the kind of open source they expected.

The details of licensing are complex, but rarely matter in a developer’s day to day life. What is important is managing expectations and risk, not just for yourself but for consumers and contributors to your project. Using an OSI-approved license means that the world can easily and quickly understand what you’re offering. Using a custom license means… people need to pause and evaluate before considering contributing to your projects.

Even if you think you have a reason to use a custom license, you probably don’t (other than using a proprietary license, which is just fine too). Stick with OSI, because that’s what the world expects.