There are really three aspects to your projectâ€™s decision (to use React.js 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 the updatedÂ FAQ about the PATENTS issueÂ on Medium!)
- 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).
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.
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.
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 open source 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 about 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 its 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.