Cancel

Sarah Gooding

Facebook to Re-license React after Backlash from Open Source Community

Facebook has announced its intentions to re-license React, Jest, Flow, and Immutable.js under the MIT license. React community members began rallying around a petition to re-license React after the Apache Software Foundation (ASF) added Facebook’s BSD+Patents license to its Category X list of disallowed licenses for Apache PMC members. Facebook’s engineering directors officially denied the request in mid-August, citing the burden of meritless patent litigation as the reason for keeping the patents clause.

Facebook moved forward on this decision in full recognition that it might lose some React community members as a consequence. Many open source project maintainers began to look for alternatives. In a surprising move, Matt Mullenweg announced that WordPress would also be parting ways with React and planned to remove it from the upcoming Gutenberg editor.

Mullenweg’s decision to drop React from consideration for WordPress was likely an influential factor in Facebook’s eventual about-face on the topic of re-licensing the project. Facebook’s announcement on Friday acknowledges that the company failed to convince the open source community of the benefits of its BSD + Patents license:

We’re relicensing these projects because React is the foundation of a broad ecosystem of open source software for the web, and we don’t want to hold back forward progress for nontechnical reasons.

This decision comes after several weeks of disappointment and uncertainty for our community. Although we still believe our BSD + Patents license provides some benefits to users of our projects, we acknowledge that we failed to decisively convince this community.

The React 16 release, slated for this week, will ship with the updated MIT license. Facebook declined to respond to our request for further comment and said their post is the only public statement they will be providing.

It’s not yet clear whether WordPress will continue on with React, picking up where the team left off on Gutenberg, or shift to another library. Core contributors had originally decided on React while attending WordPress’ community summit in Paris last June, although this decision had not yet been made public when the greater open source community started petitioning Facebook to re-license React.

“I’m just so tired of this drama,” Gutenberg engineer Riad Benguella said. “We spent days and days thinking about the best framework for WP, and this change will just add more thinking, complexity, and uncertainty to our decision. I’m just tired of all this…we all have to rethink everything.”

Mullenweg, who had previously penned a several-thousand word unpublished announcement about how WordPress would be adopting React, did not confirm whether WordPress is still examining other libraries.

“Our decision to move away from React, based on their previous stance, has sparked a lot of interesting discussions in the WordPress world,” Mullenweg said in a post published to his blog this weekend. “Particularly with Gutenberg there may be an approach that allows developers to write Gutenberg blocks (Gutenblocks) in the library of their choice including Preact, Polymer, or Vue, and now React could be an officially-supported option as well.”

The regularly scheduled core JavaScript meeting is set for Tuesday, September 26 at 15:00 GMT and contributors plan to discuss the role a JS framework will play in current and future core focuses. The time has been changed to be two hours later than originally planned in an effort to accommodate more contributors across various timezones.

Category: ,
Tags: , ,
14

14 responses to “Facebook to Re-license React after Backlash from Open Source Community”

    • Don’t celebrate prematurely.

      Facebook’s decision to adopt the MIT license – which doesn’t include a patent grant – rather than the Apache license – which includes a weaker patent provision than the original BSD + Patents license – solves one patent issue while raising another.

      The problem is that by choosing this approach, Facebook does not convey with the MIT license any patent grants as they would have under the Apache.

      If Facebook has patents that read on React, in other words, users of that software are not given an explicit license to them via MIT, only an untested implicit license.

      So now how “glad” are you now?

      Create forum topic from comment

  3. This doesn’t change my mind. They can change the license back for later versions, which would then require a fork.

    It is also very telling that they didn’t go with the Apache 2.0 license, which would actually be good for WordPress’s use of React. Going with the Apache license would have been a much stronger move.

    Apache License 2.0 explicitly lays down the grant of patent rights while using, modifying or distributing Apache licensed software; it also lists the circumstances when such grant gets withdrawn.

    That part of the license could end up being important. The fact that no patent grant exists in the MIT license leaves a lot of room for Facebook to act here.

    With the new license it still makes sense to move to something else, like Vue.

    Create forum topic from comment

  4. Core contributors had originally decided on React while attending WordPress’ community summit in Paris last June, although this decision had not yet been made public when the greater open source community started petitioning Facebook to re-license React.

    Grrr…. Open is good, right? Except…

    To be really clear what annoys me is the lack of transparency here. A lot of people were spending time thinking about this, debating the merits, advocating for one thing…. when all along a decision was made. Then Matt reversed it (which I agree with and is decision I think he should stick with).

    I get that some things will happen behind the scenes but when a decision is made it should be made public.

    Create forum topic from comment

    • That’s a fair point, Rick, we’re always aiming to be more open with the decision making process. It’s kind of boring process thing, but since you asked, let me lay out a rough timeline of how this all happened: 🙂

      There were several discussions on JavaScript frameworks in May, starting around mid-May, with the outcome at the end of May being to review the discussions at the WCEU Community Summit. (The Summit intentionally tries to include a wide range of contributors, with varying points of view, who can ultimately make decisions as representatives of their team. You can read more about it here.)

      Fast forward to mid-June, the outcome of the Summit was that React was the best technical choice, but the patent grant was a concern, and the wider WordPress community felt strongly about being able to use the tools they’re most familiar with.

      Now early July, the announcement post was drafted, and we’d just started privately reaching out to contacts at Facebook, to work on the final blocker of the patent grant. Right about that time, the whole Apache/React thing happened, which unfortunately lead to Facebook deciding that they didn’t want to change their patent grant.

      I understand that the period of silence here was frustrating, but adding to the public pressure on Facebook would not have been a wise choice – there was already plenty of public pressure. Under the circumstances, our voice wouldn’t have mattered so much.

      Ultimately, the outcome has been quite positive for the WordPress community, and the wider Open Source world – Facebook have chosen to relicense React under the MIT license, there’s significant interest from a wide range of JavaScript frameworks in prioritising interoperability, and Gutenberg’s work on framework agnosticism gives them a practical testbed for improving interoperability.

      If you’re interested in more closely participating in these discussions, you’d be well served by attending this week’s JavaScript meeting, where the primary topic will be continuing the framework discussion. If you’re unable to attend at that time, you should post a comment on that post, or on the summary post that will appear on make/core shortly after the meeting.

      I’d also note that, just because Facebook have changed the React license, the ultimate decision will not necessarily be to use React. React certainly has some technical strengths, but there are also good arguments for Vue or Preact. Similarly, there’s a good argument that Web Components (probably via a framework like Polymer or Stencil) is a better match for WordPress’ open web philosophies.

      All up, though, I wouldn’t worry too much about this decision. The far more important part is that you’ll be able to write Gutenblocks using whatever framework you prefer, and this focus on interoperability will drive WordPress’ JavaScript development for many years to come. 🎉

      Create forum topic from comment

      • While all of this is exemplary in that it stresses reasonableness and thoughtfulness, it dresses up the troubling parts of how decisions have been made.

        > “I wouldn’t worry too much about this decision”

        The impression I get here and from other comments made by other core developers is this:

        “Don’t worry your pretty heads about how core developers chose to alter the project, that’s of no concern to you”

        It is disingeneous to claim that the tooling choices made in core merely impact the work of core developers and yet this is repeatedly how some have framed this.

        We know that we have choices that raise the barrier entry more than is the case with other choices. We can speculate that raising this barrier may deter future contributors and those simply trying to grapple with core code as they learn how it works. The latter group seems to have had no representative in this debate because they are taken to be the unimportant. How learnable and accessible core code is matters. There is should be no jump in complexity just because something is core code vs a plugin or theme.

        I have seen very few if any core developers really seem concerned about this beyond lip service. Instead we get something along the lines of ‘tough shit’ because perceived level of complexity that is being introduced just doesn’t register as such or is deemed a reality of life in JS (and after all if it’s good enough for a big chunk of the JS community…).

        Concerns from some of our best educators about the technical difficulty of React might have been noted but clearly haven’t factored in much.

        And this is not a necessarily a choice about mere technical merits of tools either, yet we continue to be told it is. The fact that this decision is framed as such (a technical decision) is designed to divert attention from other aspects. If the only blocker was the license, it stands to reason that most in core were fine with the ideological fitness of React, being a FB project, which to be quite frank is a despicable entity not least for undermining the open web and profiting off the demolition of democracy and privacy.

        And think about this for minute. Before the license debacle, React had been annointed and would have been annointed sooner if not for objections made largely by others. If there had been little noise about the license and the Apache foundation hadn’t ruled against React, we’d have been apparently content to go along with it. It appears it was the noise that bothered core devs & Matt, not the license itself or why the license was there in the first place (the artifact of a corporation defending its interests).

        This too me is alarming, because it means at the very heart of WordPress our compass was aligned in violent opposition to things that were supposed to be important. Inclusiveness, a level playing field, commitment to the values of an OSS movement and a general aim to endeveour to empower its users.

        Meanwhile there had been little explanation why React was a special technical fit for WordPress – it simply owned the matter by being the dominant tool in use. Yet we’re instructed to believe that React was the technically superior choice (as if self evident). Instead we got marginal/weak arguments about bus factor and the sheer size of an ecosystem.

        While I am glad that there seems to be a lot of focus on making things framework interchangeable, while thought goes into making an unopionated API to interface with, it does not address most of the concerns of using React in the first place.

        Core developers and Matt should be the principal decision makers. It’s not something I quarrel with, I think this type of meritocracy has served WordPress very well. But it also means we trust you to make decisions that serve the whole community in alignment with the project. I have never doubted that decision making process until React came along. I have also taken note that many core developers feel like vocal developers are impinging on their territory without the necessary credentials, inviting mockery and sneers for expressing views and preferences. I think this has been one of the most disappointing things about this process.

        I’m pretty sure FB’s move to go with MIT was very much because WP, Matt & co tipped the balance. It’s a big win for the OSS community. But I hope this doesn’t turn in to a back patting exercise in which we happily U-turn and double down on pre-made tooling choices that formalise a tie between WordPress and FB while rendering core code even less approachable than it already was.

        Create forum topic from comment

      • All up, though, I wouldn’t worry too much about this decision. The far more important part is that you’ll be able to write Gutenblocks using whatever framework you prefer, and this focus on interoperability will drive WordPress’ JavaScript development for many years to come.

        Yay for having 2 versions of react, a bit of jQuery, 2 versions of Vue enqued by 5 plugins resulting in 10 requests, some other libraries loaded on the Post edit screen. This is not a good thing. You saying that this is good to me just sounds like you can’t defend the decision to go with React given the support for Vue so you try to supplicate critics by not taking a stand. This is even worse than going with pure React.

        Create forum topic from comment

      • The impression I get here and from other comments made by other core developers is this:

        “Don’t worry your pretty heads about how core developers chose to alter the project, that’s of no concern to you”

        First off, I apologise for giving that impression – I certainly had no intention of minimising yours or anyone’s concerns about this. I’m strong believer in all of us being able to have a respectful dialogue about these kinds of decisions. 🙂

        How learnable and accessible core code is matters.

        I absolutely agree! Core is currently really hard to contribute to, it’s very rare for folks to make the jump from occasional contributor to regular contributor. Gutenberg is an excellent opportunity for us to reset that.

        There is should be no jump in complexity just because something is core code vs a plugin or theme.

        I almost entirely agree with this, too. 🙂 I should note that there are three different APIs I’m thinking of when I say this:

        – The third party framework API. This should only ever be used directly in one place – the WordPress element. The WordPress element exposes and translates selected parts of the framework, nothing in Core or plugins should ever talk directly to the third party framework. This abstraction treats all frameworks that plugins use equally, and gives us the freedom to change the third party framework in the future, if we need to.
        – The WordPress element API. This is used for implementing UI components within Gutenberg – buttons, panels, form fields, and the like. More complex plugins can also implement and use these components in their UI. There’s ongoing work to ensure that these components can be used in any framework.
        – The Gutenblock API. This is a higher level API again, allowing plugin developers to implement blocks in a simple and accessible manner. All of Gutenberg’s blocks are implemented using this API.

        So, I agree that anyone contributing blocks or components to Core should be able to do it as easily as they build them for their own plugins. The glue that makes this possible will likely be trickier to contribute to, but that seems like a reasonable tradeoff to provide a great experience for the all plugin developers and most Core contributors.

        If the only blocker was the license, it stands to reason that most in core were fine with the ideological fitness of React, being a FB project, which to be quite frank is a despicable entity not least for undermining the open web and profiting off the demolition of democracy and privacy.

        I don’t think this is entirely fair. Every corporation will have politics that we disagree with, judging their projects through that lens just means we’re cutting off all possible avenues to help change those politics.

        Before the license debacle, React had been annointed and would have been annointed sooner if not for objections made largely by others. If there had been little noise about the license and the Apache foundation hadn’t ruled against React, we’d have been apparently content to go along with it.

        As I mentioned in my parent comment, we’d already started reaching out to Facebook before the Apache foundation thing happened, we weren’t aware that they were having an internal discussion about it. As Matt mentioned in his earlier post:

        Core WordPress updates go out to over a quarter of all websites, having them all inherit the patents clause isn’t something I’m comfortable with.

        I think there’s an important distinction to be made between the practical, legal effect of the patent grant, which patent legal experts tend to agree would’ve had no practical effect; and the philosophical issue of that patent grant. The GPL3 and Apache2 licenses have similar patent grants, the difference is the breadth of the revocation clause. It’s clear that even if there’s no practical difference, there’s certainly a difference in how that difference is seen. I agree that it felt like a step too far in Facebook’s favour, with nothing given in return.

        Meanwhile there had been little explanation why React was a special technical fit for WordPress – it simply owned the matter by being the dominant tool in use.

        I agree that there hasn’t been enough discussion on why React was considered the best technical fit. It’s briefly covered here, but I think it’s important that, when Gutenberg finalises the framework, the decision is accompanied by a comprehensive document on why that framework was chosen.

        Core developers and Matt should be the principal decision makers. It’s not something I quarrel with, I think this type of meritocracy has served WordPress very well. But it also means we trust you to make decisions that serve the whole community in alignment with the project. I have never doubted that decision making process until React came along.

        I truly thank you for that trust – it’s critical for WordPress to be able to grow and evolve. We try to treat appropriately, but clearly erred in this situation. Regardless of which framework Gutenberg uses, I do hope that we’re able to win back that trust. 🙂

        Create forum topic from comment

      • Yay for having 2 versions of react, a bit of jQuery, 2 versions of Vue enqued by 5 plugins resulting in 10 requests, some other libraries loaded on the Post edit screen. This is not a good thing.

        Within Gutenberg itself, any library your plugin uses will be loaded, but these libraries are all quite small – Preact is 3KB, Vue is 20KB, React is 35KB, Polymer is also around 35KB. Even assuming a site has plugins installed that create blocks with every possible framework, this is still a fairly small addition. Of course, these files are rarely downloaded, as your browser is probably already caching a copy of them.

        On top of that, the Gutenberg team are investigating loading Gutenblock components asynchronously, to ensure that sites with lots of blocks, or particularly heavy blocks, can get the same editing experience as everyone else.

        Of course, the better solution is to reduce the number of frameworks being used – this seems like an area where plugin development best practices will evolve to make use of the latest version of frameworks, and potentially from a common source, for more comprehensive caching.

        You saying that this is good to me just sounds like you can’t defend the decision to go with React given the support for Vue so you try to supplicate critics by not taking a stand. This is even worse than going with pure React.

        Vue was far from the only framework being advocated for, though many of the discussions have been framed as a “Vue vs React” thing. Far from being that, I think the clearest thing to come from these discussions is that people want to be able to develop against the framework they’re most comfortable with, and I agree with that they should be able to. Core doesn’t need to force this decision upon them.

        Create forum topic from comment

      • Within Gutenberg itself, any library your plugin uses will be loaded, but these libraries are all quite small – Preact is 3KB, Vue is 20KB, React is 35KB, Polymer is also around 35KB. Even assuming a site has plugins installed that create blocks with every possible framework, this is still a fairly small addition. Of course, these files are rarely downloaded, as your browser is probably already caching a copy of them.

        Regarding requests yes and no I’d say. But potentials of conflicts etc is probably the main issue.

        Vue was far from the only framework being advocated for, though many of the discussions have been framed as a “Vue vs React” thing. Far from being that, I think the clearest thing to come from these discussions is that people want to be able to develop against the framework they’re most comfortable with, and I agree with that they should be able to. Core doesn’t need to force this decision upon them.

        Not the only one but the one with almost majority behind it.

        Create forum topic from comment

      • the practical, legal effect of the patent grant, which patent legal experts tend to agree would’ve had no practical effect

        I know it’s not the main focus of this discussion, but let’s just set the record straight. “Patent experts” agree on no such thing; it’s just that one person’s blog post has been quoted by multiple other outlets. That doesn’t multiply the number of patent experts holding the opinion.

        In any event, that view was based largely on the premise that no-one is going to want to get into litigation with a corporation as powerful as Facebook. But that’s just speculation with no evidence to support it.

        In fact, if a developer finds that his or her intellectual property has been used by Facebook, that claim would probably be worth hundreds of millions (if not billions) of dollars. Even the most impecunious developer would have no difficulty at all in finding an attorney willing to represent him or her on a contingency fee basis.

        Create forum topic from comment

      • @Gary thank you very much for a thoughtful response.

        I only want to expand a bit on 3 points you’ve made.

        I think there’s an important distinction to be made between the practical, legal effect of the patent grant […]

        Agree on the distinctions you make but even assuming the legal effect of the clause, or the philosophical point about it, the license also had a very real practical consequence in forcing some businesses to employ legal counsel in order to make those determinations for themselves, while leaving those without the resources or presence of mind at a disadvantaged position.

        Every corporation will have politics that we disagree with, judging their projects through that lens just means we’re cutting off all possible avenues to help change those politics.

        I do agree with the general principle here and we are quite lucky that many internet giants are contributing to OSS and adding lots of value that way. And I very much welcome any positive influence WP has on other companies in terms of encouraging everyone to be good citizens and stewards of the web. But I don’t view this as an issue about politics or differing viewpoints coming from a company. FB is a corporation with business incentives that are objectively and demonstrably deleterious to the open web as well as its users (and I would argue, society as a whole), it threatens the well WP depends on to thrive. Its influence is far too big and should not be made even bigger. And those business incentives are not subject to influence or mollification from projects like WordPress.

        Furthermore, letting FB shape the web even to the point of affecting the code base of perhaps the most special OSS project in the world (WordPress) is not just deflating, to me it is heretical. I know most other developers wouldn’t go so far and judge React in a more neutral way, I don’t judge that, but that doesn’t make it a good fit for a project like WordPress.

        As I mentioned in my parent comment, we’d already started reaching out to Facebook before the Apache foundation thing happened

        Not withstanding that, Matt’s unpublished React announcement post preceded a lot of good discussion that has been happening only after React was rejected and it is generally admitted that any alternative to React that was being discussed before May had the deck stacked in its favour due to many practical reasons. Now we are seeing far more thought going into choosing a way forward, discussions that wouldn’t have happened if the hoopla around licensing hadn’t unfolded.

        In any case, I’m still very pleased that we’re now investing more time in the decision and that there is a strong commitment to making the APIs not entirely dependent on the usage of one particular 3rd party framework.

        Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.