paint-brush
4 Lessons from the ‘React Patent License’ Controversyby@ArielR_IP
3,925 reads
3,925 reads

4 Lessons from the ‘React Patent License’ Controversy

by Ariel ReinitzSeptember 26th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

After weeks of uncertainty and criticism from <a href="https://hackernoon.com/tagged/developers" target="_blank">developers</a> and major Open Source players (including <a href="https://issues.apache.org/jira/browse/LEGAL-303" target="_blank">Apache </a>and <a href="https://ma.tt/2017/09/on-react-and-wordpress/" target="_blank">WordPress</a>), Facebook (‘FB’) <a href="https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/" target="_blank">announced </a>they will be re-licensing their <a href="https://facebook.github.io/react/" target="_blank">React </a>JavaScript library (and other projects) under the popular <a href="https://spdx.org/licenses/MIT" target="_blank">MIT open source license</a>.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - 4 Lessons from the ‘React Patent License’ Controversy
Ariel Reinitz HackerNoon profile picture

Making sense out of the confusion…

After weeks of uncertainty and criticism from developers and major Open Source players (including Apache and WordPress), Facebook (‘FB’) announced they will be re-licensing their React JavaScript library (and other projects) under the popular MIT open source license.

Many developers are breathing a collective sigh of relief. However, discussions surrounding Facebook’s “BSD+ Patents” license revealed several common misconceptions in the developer community regarding open source licenses and patents.

While debate regarding the “BSD+ Patents” license may now be academic, here are a several takeaways developers should keep in mind going forward (whether using React or any open source project):

Disclaimer: I am a Patent Attorney, I do not represent Facebook, this is just food for thought (not legal advice) (did I forget anything?).

1. The difference between copyrights and patents

Software can be associated with two primary types of intellectual property: copyright and patent.

If I write some new code, I own the copyright. That means I (legally) control who can/can’t use my code. By releasing it via open source (‘OSS’) license, I give others the right to reuse my code. In legal terms, I grant others a ‘copyright license’ (a promise not to sue when my copyright is infringed by your use of my code).

Unlike copyright, patents protect new features/functionality. If I develop a new and “non-obvious” feature and receive a patent on it, I can stop others from making, using, or selling products with the same functionality for the ‘life’ of the patent (20 years).

Consider a scenario where you code an existing function from scratch. Since you haven’t used anyone else’s code, you wouldn’t infringe anyone’s copyright. But, if I have a patent on that function, you can still infringe my patent since your product incorporates my patented functionality (even though your code is 100% original and does not infringe any copyright).

OSS licenses are attached to source code and are largely effective at addressing copyright issues. However, since patent rights can extend beyond the actual code being released, treatment of patent rights by OSS licenses is more complex.

Some OSS licenses, such as Apache 2.0 and GPLv3 have specific clauses to address patent rights and provide explicit patent licenses. Other OSS licenses — including MIT — don’t mention patents or patent licenses at all.

2. The MIT license doesn’t mention patents

The brief text of the MIT license doesn’t mention patents anywhere. However, the license does say that the author of the code grants you:

“…permission…to deal in the Software without restriction…”

Many interpret this to implicitly grant a patent license. After all, the author of the code is giving you permission to use the code “without restriction.” In this context, it’s reasonable to assume the author won’t use his/her patents against you to stop you from using the code.

Ultimately, though, this is conjecture. To my knowledge, this issue has never been litigated so no court has conclusively identified such an implied license.

3. MIT’s ‘implied patent license’ may be limited

Let’s assume the MIT license does include an ‘implied patent license.’ How far does the license go? In the case of React, does this implied license apply to all of FB’s patents? Or only some of them?

Since the MIT license is attached to the “Software” (here, React), I’d also expect any ‘implied patent license’ to be limited to patents on ‘the software.’ So:

  • Patents covering functionality provided by the React library itself would likely be covered by the implied patent license.
  • Patents on functionality not provided by React itself would not likely be covered by the implied license.

To illustrate, let’s assume:

(a) You use React (under MIT license) to develop a new VR social networking application, and

(b) FB has patents on (1) React functionality and (2) social networking, VR, etc.

In this scenario, you’re using React so the ‘implied license’ would reasonably protect you from FB’s patents on React functionality. However, FB’s patents on non-React functionality (social networking, VR, etc.) would not likely be included in such a license.

This doesn’t necessarily mean FB would ever try to enforce these (non-React) patents against you. But it does mean they could.

4. Understanding ‘defensive’ patents

Many companies (big and small) maintain patent portfolios for ‘defensive’ purposes. While a patent owner can sue any infringer, patent litigation is expensive. For many companies, the costs of aggressively policing their patents can outweigh the benefits (removing infringers from the market).

However, if a patent owner such as FB is accused of infringing another party’s patent, FB’s can ‘mine’ its own (large) patent portfolio to identify patent(s) the accuser may infringe. These patents can be the basis of a ‘countersuit’. While “two wrongs don’t make a right,” this ‘defensive’ response can be leveraged to settle the original litigation or (ideally) to discourage the lawsuit to begin with. In other words, many companies hold patents not to sue you but to discourage you from suing them.

This dynamic should be considered carefully by companies of all sizes. Irrespective of your thoughts re: software patents, being in a weak position (patent-wise) can leave you vulnerable to attack by competitors with larger portfolios. And, when considering whether and how to initiate patent infringement claims, carefully assess your opponent’s patent portfolio before taking action.

If you enjoyed this article, please recommend it on Medium (clap for it!), and share it on Twitter, LinkedIn, etc.

Feel free to follow me on Twitter and connect with me on LinkedIn.