Over React? Open source licensing, Facebook, WordPress, and patents

WordPress came close to leaving behind the React framework. We interviewed developer Gary Pendergast to dig into why, and how WordPress, Facebook, and the Apache Software Foundation brought this issue to a head, and what we can learn from it.


In the summer of 2017, a lively open source licensing debate was happening: the React framework had become one of the most popular frameworks in existence, but was React’s open source license open enough for developers to trust it? Developers were worried whether they could use it without legal repercussions from Facebook, the primary maintainers of React.

The complexity arose because, while the React project adopted the popular and well-known BSD free software license, they also adopted an additional, unusual patent grant which worried developers.

Facebook’s “BSD+Patents” license had been a part of React for some time, but high-profile projects did not begin to consider removing React until the Apache Software Foundation labeled it a Category X license, or license that may not be included within Apache products. This, followed by Automattic (the primary company behind WordPress) deciding to pull React from its open source projects, ultimately lead to Facebook dropping the patent clause and using the standard MIT license — not only for React, but a number of other open source projects they maintain, as well.

Obligatory shot of MacBook with code on it

Chain Reaction

There still seems to be a lot of lingering questions around the debate, even though it’s been resolved as a decisive win for the open source community. For example, why did the patent clause exist in the first place? Facebook’s Adam Wolff explained the reasoning, but understanding that explanation requires first knowing why companies need patent clauses in the first place and what does this kind of patent protection even mean?

Facebook didn’t invent the idea of patent protection clauses, but given their access to nearly infinite lawyers and money and being stewards of an increasingly popular front-end framework, it was natural that React users without that access and money would worry about the legal risks. This risk is heightened by many people’s tendency to ignore licenses and terms of service agreements until someone points out on social media what we may have actually agreed to.

Going to the Source

Help! Gary is in Software Jail!

Instead of speculating, I reached out to Gary Pendergast, an engineer at Automattic.

Gary is part of the WordPress core dev community and works on some of the projects where Automattic initially decided to pull React. He offered some insight on why licensing is important for engineers, and how licenses impact his work, part of which powers over 25% of domains on the Web.


How would you explain licensing and its importance to a developer who is either just learning to code or has not been involved with the open source community?

GP: The open source community can be a great place to learn to code, there are countless examples, free code libraries, and wonderful, helpful people to get you going. But all of that is predicated on the idea of giving back some of what you get out.

Writing code is a creative process, in the same way that writing a story, or recording music is, so the code you write is copyrighted to you, so people need to ask for your explicit permission to use that code. Some open source licenses implement an idea called “copyleft”, which allows you to maintain the copyright, but you give everyone permission to freely use the software you wrote. The only reason you can use all of those code libraries is because they’re under an open source license — someone before you has joined the open source community, learned how to do something cool, and released it back freely, in a way that benefits everyone.

So, licensing is important, because it lets you be the person who helps those who’ll come after you. There are a range of established open source licenses that will share the things you create in whichever way you’re comfortable with.

What projects are you working on at Automattic that are affected by the licensing of React?

GP: I’m fortunate enough to be sponsored full-time to contribute to the open source community — while I’m employed by Automattic, my work is entirely focussed on building cool things to give away for free.

Right now, I’m working on a project called Gutenberg, which, at the core of it, is a big re-architecture of how WordPress manages content in a website. The first part of that involves rewriting WordPress’ post editor into a modern JavaScript app, which uses React to render the interface. That’s the part which was seriously affected by React’s license.

Why would React’s license matter on a project that uses React?

GP: One thing you will find in the open source community is that people get very passionate about software licenses. It’s not really surprising, the freedoms we enjoy in open source rely heavily on those licenses, people are naturally going to be protective of those freedoms.

In the case of React’s license, the patent grant was the thing that caused the most concern, or at least, one particular clause in the grant, which allowed Facebook to revoke the patent grant under some limited circumstances. There were some interesting arguments suggesting that this clause had very little practical enforceability, and others arguing that the patent grant was a net benefit, but the concern wasn’t really about whether this clause could be enforced. Most of the disagreement was about the “vibe” of the thing — this clause felt a bit like Facebook was trying to get the benefits of the open source community, while avoiding giving back.

For a project using React, if we were to assume a worst case interpretation of the patent grant, React could easily be seen as a trojan horse — React is a wonderful tool to use, but it potentially gave Facebook an unfair way to attack competitors. If you were a startup that held software patents, and Facebook violated those patents, then suing them for patent violation could result in the React patent grant being revoked, even if the original patent violation had nothing to do with React. While this is a fairly unlikely scenario, the fact that it was possible made people uncomfortable.

React had the patent clause as part of its license for nearly three years up until they changed it to MIT. Why did it take this long for Automattic to take this stance?

GP: Automattic has been using React for years on other projects. For example, Calypso is an open source project, using React, that powers the interface you see when you manage your site on WordPress.com. Our legal team evaluated the patent grant in the React license at the time, and decided that it wasn’t a concern for the company. Partially because of the questionable enforceability of it, but primarily because Automattic doesn’t collect software patents, so is never going to be in a position to be suing Facebook for patent infringement.

In Gutenberg, however, there were different priorities, particularly as this code would be rolled out to over a quarter of the web. The WordPress Core team didn’t feel that we could make the same decision for the entire WordPress world.

What would the consequences be of pulling React out of those projects if Facebook were to hold their stance on keeping the patent clause? How significantly would this have delayed releases of those projects?

GP: For Gutenberg, the impact wouldn’t have been huge, though that’s mostly because it’s architected with situations like this in mind. Over the years, we’ve found that WordPress often outlives the libraries it depends on, so we usually spend time on ensuring we can swap them out at a later date if we need to. In this case, components in Gutenberg don’t use React directly, they talk to a thin wrapper around it, so the task of replacing React would’ve been relatively simple, particularly if we were to replace it with a React-compatible framework, such as Preact.

The Calypso project doesn’t have that abstraction layer, so it would have taken significantly more effort, though it’s an effort we were willing to make. From a strictly business viewpoint, Calypso has no need to maintain compatibility with WordPress, so didn’t necessarily need to have chunks of it rewritten. Part of being a good citizen of the open source community is to play nicely with others, however, even if it requires effort on your part. So, we would’ve taken the time to do that, because it’s the right thing to do.

Do you consider this the best outcome for this situation? Do you think MIT was the best choice, given how many licenses are out there?

GP: I’m happy with the outcome here, React moving to the MIT license means that it can easily be used in any open source project, without concern that React’s license may not be compatible with your particular open source license.

The one down side of the MIT license is that it doesn’t include a patent grant at all. The best possible outcome probably would’ve been to use a standard open source license like Apache 2.0, which includes the patent grant, but heavily restricts the circumstances under which that grant can be revoked. Similarly, a better outcome may’ve been if the React patent grant was changed to remove (or reduce) the revocation clause. There’s basically no practical difference, however. Even assuming Facebook hold any patents on React, it would be an extremely poor business decision for them to try enforcing those patents.

Literally another MacBook with code on it

Lessons Learned

As more companies become stewards of widely used open source projects, these important discussions around licenses will continue, as will the need for new developers to learn about the impact of open source licensing. The biggest takeaway from this whole thing though, is the importance of considering the impact of your choice of license on downstream users. Even with the best of intentions, we saw in this example, the clear need to balance your own interests with the needs of others who you’re intending to help by making your project open source.

Those of us on the Glitch team have thought about these issues extensively. Recently, we launched an update to the editor allowing the addition of an open source license to a project with just a click. Software licenses are typically represented as text or Markdown files in a project, so they were always able to be added manually, but this update makes the process even simpler.

Besides making the process more efficient, it is our way of facilitating the education of licensing and its importance to software development—especially open source software. We hope this will help the Glitch community not only be more knowledgeable and involved in the open source community, but in the discussions around open source licensing that are sure to continue in the future.

If you’d like to learn more about software licensing, read our post ‘Why Add a License to your Open Source Project?