Hi, Paul from the Open Source Team here at Meta. HHVM is still in use and there are no changes to the level of maintenance the open source project gets. There's no conspiracy, no quiet quitting. The reality is that we just had some issues that affected our automatic syncing a little while back and HHVM got stuck. Since use outside of Meta is relatively low, unsticking it was just lower priority.
But we see that you've noticed and I think the folks working on HHVM internally will get that corrected soon!
I'm a mixed of confused and optimistic about this project.
On one hand, I would absolutely hate for someone to force me to use one tools, opinions for everything I do in a project.
On the other hand, if I just start a new job and I need to get producing, I'd rather have one big tool that just makes JavaScript work. Versus 4 different tools with a bunch of different limitations.
I have full confidence that the people working on it can deliver an incredible product. I have severe doubts that this will be sustainable as a business though, which really sucks
Hi, Paul from the React team here. There have been lots of questions about the license+patents combo we use. Recently our legal team answered some of those questions.
That FAQ is missing the most important question, which is raised by the article, on whether the license will terminate if you sue (not counter-sue) facebook for patent infringement unrelated to React. That is, does using React give facebook the right to infringe on any of my patents?
> Does using React give Facebook the right to infringe on any of my patents?
Yes, which is why Facebook's lawyers refuse to answer that question directly and instead obfuscate things by talking about "retaliation".
The Apache 2 license covers, in full, every public goal Facebook legal has stated they have and is 100% ethical. That Facebook refuses to use the Apache 2 license indicates they have additional, private, goals they do not want to own up to publicly.
Is there any talk within Facebook on amending this clause or moving React to a standard license? I believe it's stopping a lot of large companies (whom the patent clause could actually affect) from using React, and all other like-licensed Facebook software.
IANAL but my interpretation of the clause based on comments / links is that it aims to protect Facebook by reducing patent lawsuits in general. If that is actually valid, I would expect there would be many people who are for the terms internally. Am i fully misinterpreting here?
Facebook patents that apply to React will also very likely also apply to Vue or any other virtual DOM library. Using Vue makes you more vulnerable, not less, since you no longer have the protection of the React.js patent grant.
You made this assertion before, but it's wrong and dangerous. Without knowing what the patents are, you cannot possibly say whether or not OTHER technology is infringing on it. It is especially bad considering you are not a lawyer, nor have professed any familiarity with the patent process.
It is a moderate, but known, amount of work to look through FB's patents, assess which are likely around React, and read through the claims. Considering it's possible, I certainly think that it's reasonable to ask you to do the work, or stop making the assertions.
"If you or your agent or exclusive licensee
institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of Polymer or any code incorporated within this implementation of Polymer constitutes direct or contributory patent infringement, or inducement of patent infringement, then any patent rights granted to you under this License for this implementation of Polymer shall terminate as of the date such litigation is filed."
I dont see how is that similar to react. It makes way more sense and is closer in spirit to apache I think.
"If you or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of Polymer or any code incorporated within this implementation of Polymer constitutes direct or contributory patent infringement, or inducement of patent infringement, then any patent rights granted to you under this License for this implementation of Polymer shall terminate as of the date such litigation is filed."
Polymer license only concerns itself with itself. FB license concerns all patents you and FB might have in addition to patents/righs concerning the react code itself.
There is a big difference, although it might not look like that.
"against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that THIS IMPLEMENTATION OF POLYMER or OR ANY CODE INCORPORATED WITHIN this implementation of Polymer".
I know I ask much of you but you can do it.
BTW. congratulations on copy pasting the text I pasted above...
Then it should stop you from using software from EVERY large company... many choose Apache 2, which has similar provisions which include revoking your copyright license... MS and Google both include similar provisions in most of their permissively licensed software tools/libraries.
Hi Paul, why not address the real issue in the FAQ? As it stands now, using React in a project essentially nullifies any patent protections a company may have against Facebook. If I were to use React to build a successful product that fits into Facebook's business plan, there is nothing I could do to prevent them from stealing my concept wholesale.
"Does the additional patent grant in the Facebook BSD+Patents license terminate if Facebook sues me for patent infringement first, and then I respond with a patent counterclaim against Facebook."
No, unless your patent counterclaim is related to Facebook's software licensed under the Facebook BSD+Patents license.
What's the 'bad faith' here? That React is a part of a conspiracy to get all their competitors to use and and then engage in some massive patent lawsuit against them all?
Apache 2 (the original React license, BTW) encompasses all of the legal protections and goals Facebook admits to publicly.
The current BSD license plus "additional patent grant", however, grants Facebook additional rights beyond the Apache 2 license that they refuse to admit to in their public communications, including this idiotic "FAQ". That's the "bad faith": Facebook won't publicly own up to why they want a worldwide, royalty free right to use a third-party's patents that have nothing to do with the software Facebook is licensing to them.
They don't own up publicly because it's unethical.
That they won't address the real question everyone is asking, and at this point, staying mum appears intentional and flippant to those asking. All while acting as though they address people's concerns.
I think it's understandable that Facebook want to be protected from the possibility that contributer X contributes code, and then sues Facebook for patent infringement, because the code X contributed was patented. This concern is well addressed by Apache license 2, there was no need for this custom license that goes too far.
The same reason Google has BSD + additional rights grants (though not as restrictive):
We deliberately want people to not be able to sue us for patent infringement without us being able to defend ourselves.
One can argue that facebook's method may be harsher than necessary (our rights grant is pretty much a copy of apache's 2), but i think people do not realize how often google/facebook/etc is getting sued for patent infringement.
Given how popular the software is, it deters people who are not NPE's.
This is critical though. Nobody is complaining about the Google (which is also used by Microsoft and Mozilla) retaliation clauses.
i think people do not realize how often google is getting sued for patent infringement.
Fair enough. If Facebook wants to make a public commitment to not use First Strike, the patent license would be acceptable. They have not, so it isn't.
No we've known and said it for a long time but not very loudly. People haven't used them sparingly and they tend to infect a codebase. Now we're just making a more concerted effort to communicate more broadly that they can be bad.
Thanks for replying -- I assume in whatever planning/architecture meetings went on before react was released that this was a measured decision you all chose to take, weighing the potential dangers less dangerous than the initial usefulness. Is this assumption correct?
If you could do it again, would you leave in mixins or would you keep them out?
It was the right decision at the time - it made React much more familiar for people at FB who were writing PHP/Hack (Dan called this familiarity out in the post). It also enabled some great things that are still awkward with other patterns - https://github.com/reactjs/react-timer-mixin/issues/4 is an interesting case. That functionality is nice and elegant with mixins but not so with classes.
I think if we had to do it again (and get to keep the knowledge of the last few years), we'd probably skip mixins. We'd surely do some other things differently too though :)
Another way, which we actually supported in 0.13, was to turn on "pause on caught exceptions" in your debugger. We throw and catch a warning so that you could catch warnings live. We continue to do that now, just with the added benefit of having the stack trace showing up without needing to pause.
> Might lead to a SpiderMonkey version of Node.js at some point, too.
I worked on that 4 years ago :) <http://zpao.com/posts/about-that-hybrid-v8monkey-engine/>. The Node community at the time wasn't a huge fan, though it's effectively the same thing that MS just did (build a minimal V8 API shim on top of another JS engine). I guess everybody is ok with a little fragmentation now. Our intention was also to try to get this upstreamed, however with low interest and other things to do, we didn't follow through.
I'm excited to see this, and especially to have the MS folks involved with the TC. I'd love to see an engine-agnostic API but realistically I don't think it'll happen, at least not anytime soon. Right now Node itself definitely relies pretty heavily on the V8 APIs. Those APIs can be abstracted for the most part (even if each engine is just shimming those parts of the V8 API) but the other problem is the longer tail of binary npm modules. Right now they have the full V8 API to work with. If they do a shim layer then it will come at cost for every vendor except V8. And then maintaining that layer as V8 changes APIs. If you go the engine-agnostic API route, then you will need coordination between engine vendors. That opens the doors to a multitude of problems.
Also that's going to potentially add a ton of work for people developing libraries. With a single engine behind it, the coding efforts can be focussed on writing and profiling something to be fast on v8. If you get replaceable engines, now developers have to either:
1) Ignore all but V8 (or spidermonkey, or chakra etc.)
2) Create different versions of their libraries for different engines.
( 3ish) write multiple paths in their code depending on the target engine)
I'm not sure exactly where I sit on this one. In many regards I think I like it, allowing developers to use the right engine for the right job, for example. Each engine has its own strengths and it may be that v8 isn't the engine for you / your workload. It's just this could hurt as much as it helps.
Using @zpao's example, most Python developers use CPython and either don't know about PyPy or have never used it. As such, I'd expect most of the long-tail of Python libraries to have been written and tested against CPython.
That hasn't prevented PyPy, IronPython, JPython, etc. from existing/thriving.
Having a decent shim to code against instead of having to deal with the internal gooiness of different JS engines is actually very much preferred. By throwing a shim over the JS execution layer, they actually make the life of extension developers much easier.
iOS and android right now. And yes, native components can be rendered directly with JSX. And you won't need to mix with DOM. <h2> For example doesn't mean anything on iOS.
But we see that you've noticed and I think the folks working on HHVM internally will get that corrected soon!