Prediction - there will be a Harvard Business Review about Facebook's adventure with licensing. My unproven hypothesis is that they hurt their software's adoption rate because of their licensing.
Personally, I believe MIT is correct. I had moved my company away from React when they had the licensing problems. To me, it feels like they are coming back to the community now.
Of course it hurt their software adoption rate. You have very public spats by wordpress and apache over this. Think of people who couldn't convince their boss to use react / react-native because the legal department saw that PATENTS file and said NO WAY.
I think they are making these moves because they see that they are going to be in a weaker position in the future and need to open their grip on these projects to make sure that other people will use it. Its probably too late though and people are moving off of it to the next javascript framework.
I believe there charges shows not only well intention but also that Facebook actually cares about and listens to the community, which in the long term is many times more valuable for the ecosystem then this particular change in itself.
I totally get that view and it bums me out. I can say there is reasoned debate about the different licenses as you can see in this thread. We've changed an explicit patent grant into a debated implicit one. We thought the first was clearer to folks but when debate turned into action we decided winning the debate wasn't important we should just do what would allow people to use the code. I know big companies can look opaque and self-interested on the outside so I get your view. Just sharing as someone part of the internal discussions what happened and why.
You forgot to mention that the explicit grant came with obnoxious conditions, and those conditions were the crux of the issue. Your characterization of the change says a lot about the internal discussions in which you participated.
I think it's unlikely that Facebook added the PATENTS file in order to make things easier for other companies and not for self-interest. It's an explicit patent revocation, not just grant. If I'm not mistaken, there was backlash against an earlier version of the file as well. Only later they tried to spin it as something they were doing for the public.
+1, this debate has been going on for a long while(6mo-1year?).
Claiming that you decided to change it out of the goodness of your heart seems a bit disingenuous. I get if you needed to clear it with the lawyers/business owners over that time but claiming it was changed on a whim doesn't ring true.
Someone on Reddit argued that the new legal situation is worse because the PATENTS clause provided protection against litigation unless you sued Facebook first. Licensing under MIT, s/he argued, theoretically opens you up to litigation at any time IF Facebook decides to enforce any patents. So I was wondering: as far as you know, does Facebook have any patents on React or React Native?
Some lawyers think the language used in the MIT license implies a patent grant limited to the use of the licensed software. They think it would be difficult for the licensor to give a license on the software from one hand, and claim a patent infringement on the same software from the other hand, but as far as I know, this was never tested in court.
Not to mention the question that the older language had a perpetual patent license for anyone using the software (subject to termination under the now much-discussed rare circumstance of suing FB).
So long as you were using the software under those conditions, it would be an interesting argument for how that patent license could now be unilaterally rescinded. (The new license doesn't say anything about it.)
> Its probably too late though and people are moving off of it to the next javascript framework.
But is there a viable alternative with the same level of features and ecosystem momentum?
GraphQL and React Native, in particular, seem well positioned to dominate their respective niches. That gives React a big advantage, which might counteract the licensing issues, no?
If that were true then why are they changing the licence at all?
They have tooling and are well positioned but what they need is big players to also back them so that people are more incentive to buy in. That is where moving the licence to MIT makes sense.
To buy in for what? If literally everybody apart Facebook stops using React, the project will still go on because it powers a shitload of FB properties.
>But is there a viable alternative with the same level of features and ecosystem momentum?
Does it matter? At some point something else will come along and React will go the way of jQuery. And then something else will come along and supplant whatever supplanted React.
Native is hard, React needed years to get it even nearly right, and it did that with the community's backing. At this point RN features dozens of renderers outside of the mobile space, with some of them made by the very vendors that sell their platforms (for instance Microsofts react-native-windows).
It also irks me that that list was shared as an image. For me, it's just an inconvenience. For others, it's an accessibility problem, at least until OCR is 100% accurate.
/s?
React Native seems to be the only alternative to native apps as of today. Googles Flutter might be a viable alternative if they don't drop it, but it's far from production ready..
I think next in this case was meant like any other framework (Vue or Angular with NativeScript) which is available and doesn't have the license issue, which React had.
Is it identical though? My understanding was that Facebook license preserves Facebook's right to sure you for patent infringement but prohibits you from suing Facebook (and more importantly anyone Facebook designates as its minion) for patent infringement. So your patent portfolio is worthless if you want to use Facebook software because I'd imagine anyone can appeal Facebook for patronage?
I thought it was a good thing personally because patent lawsuits are a waste of everyone's time but apparently enough people disagree.
Not that I know anything. Sorry for rambling. Point is I want to ask the question: are they (practically) identical?
The Apache patent grant and retaliation clause says that if you issue a lawsuit alleging that the licensed software infringes on a patent, then you lose your patent grant to that software.
The old Facebook license said that if you issue a patent lawsuit against Facebook, you lose the license to the software. That is in addition to the retaliation clause about the software itself.
So if you are using any OSS from Facebook, and then Facebook comes in and infringes on some unrelated patent you own, you need to stop using that software before suing or you just don't sue.
It's ironic how one can hold utmost respect for Facebook's libraries, but be vehemently against the actual Facebook web application and their business practices.
Those drug addict musicians that track your every move online, sell your data, make billions from advertising, influence elections. Totally "not at all different".
I like the analogy. Sorta offtopic, but I was thinking about how morally falsy it is to buy albums of those artists, because well, most likely a big part of the revenue will be spent on drugs and on continuing that lifestyle.
Just because you don't like something doesn't mean you think it is immoral.
For example, many people against Facebook simply want to be in better control of their online identities, and have privacy. I am in this boat. I don't think Facebook is 'evil', or sharing my data with 3rd parties is a 'sin'; I just think society would be better off if privacy of this kind were more strongly controlled by individual choice, rather than the whim of a corporation.
Programmers should consider the implications of their actions. Using Facebook's libraries support Facebook. If you don't want to support Facebook, you should prefer alternatives to their libraries whenever possible.
They benefit from other developers using it or they wouldn’t go through the trouble of making it accessible outside of the company.
Access to good talent runs try. Maybe you grow a team of highly talented developers using Facebook’s stack. Facebook is more capable of recruiting them since they’re already familiar with some of Facebook’s stack.
There are interesting reasons why companies expend a lot of resources on free stuff for programmers. If it didn't have a beneficial effect, they wouldn't do it.
Are you sure this move isn't just a business practice we're all too stupid to realize we should be against? I'm not. I'm not touching it. Maybe if it goes GPL.
TL;DR: As far as I can tell, the news here is that Facebook is doing for React Native (& Yoga) what they recently did for React itself. In other words, in the past choosing React for crucial infrastructure put you in position where even if Facebook infringed on your IP, you could not sue them without losing the legal right to use React, potentially crippling your company. So, either use React and create an IP vulnerability with respect to Facebook or don't use React.
Facebook changed that licensing policy for React to a more common license. You could now sue Facebook over some IP issue without losing the right to use React. Facebook could still sue you, of course, but so could any other company. Using React no longer increased your vulnerability with respect to IP or lawsuits pertaining to Facebook.
But Facebook only removed the (claimed) vulnerability-causing license provision for React, leaving it in place for React Native.
And today, they are announcing its removal from React Native as well. Thank you, Facebook.
> In other words, in the past choosing React for crucial infrastructure put you in position where even if Facebook infringed on your IP, you could not sue them without losing the legal right to use React
It hardly matters now, but as gets pointed out every time this gets brought up, this is quite false.
You would lose the legal right to use any patents which Facebook might (or might not!) have on React. You did not lose the seperate BSD license on the actual code with grants you your license to "use react".
> Using React no longer increased your vulnerability with respect to IP or lawsuits pertaining to Facebook.
That's highly debatable. If Facebook does have patents on React (and it is believed they do), then using React, or any technology that uses the same underlying technology does, in fact, increase your vulnerability to IP disputes and lawsuits from Facebook. :) The implicit patent grant in the MIT/BSD license will help, but so did the (now removed) explicit patent grant, so it's hardly clear this is a win on net.
The situation has never been as simple as people seem to wish it was. Software patents are an enormous and (so far) unsolved burden on our industry. At least if you're in countries where they are enforcable (and given the nature of the global legal system, probably even if you aren't).
More importantly, you have more protection with the BSD+Patent Grant than with BSD alone.
With BSD alone, if you infringe on a Facebook patent then you are vulnerable to legal action from Facebook if they deem that you’ve infringed your patent. And regardless of wether you’d infringed or not, such action would still cost a lot of money to fight in court and would cripple most businesses.
People who claim it risks giving up their IP are ignoring the brutal truth that software patents are shit, and if you’re in the software business you’re pretty much guaranteed to be infringing someone elses bullshit patent.
The BSD+Patent Grant was designed to combat the patent trolls, but people lost their minds and now it’s gone.
The BSD licence is objectively worse than the BSD+Patent Grant. If you opposed it, then the only people you’ve helped are the patent trolls.
> The BSD licence is objectively worse than the BSD+Patent Grant.
I'm not a lawyer, but I have heard a few claim the opposite: BSD plus the explicit restricted patent grant was worse than BSD (or MIT) with no explicit patent grant (because many believe it carries an implicit unrestricted patent grant).
> The BSD+Patent Grant was designed to combat the patent trolls, but people lost their minds and now it’s gone.
It was designed for Facebook to fight patent trolls, but not for you.
In comparison with saner license like Apache 2.0, Facebook's license only applied to Facebook.
> The BSD licence is objectively worse than the BSD+Patent Grant.
That is false. Please read up on "implicit patents license".
The issue the Apache Foundation had with the license was that it was incompatible with the Apache license; they weren't making a value judgement about it being good, bad, strong, or weak. Many other excellent licenses are also in "Category-X".
> You would lose the legal right to use any patents which Facebook might (or might not!) have on React.
So a poker bluff that would be Russian roulette without an expensive comprehensive patent search (and researching their patents itself increases your liability; reading about all the ones that you later determine didn't cover React subjects you to triple damages if they covered any of your other tech).
Facebook could also have acquired existing patents at a later date from other companies and individuals and use them go after you if you triggered the revoke terms, so you had to search all patents ever, not just ones that Facebook filed or owned during your initial decision to use the library. You could argue you have to do that anyway, but keeping with the poker bluff analogy, Facebook could know of the patent already, have undisclosed terms that prevented React licensees from being sued by the holder, and have a pre-negotiated option to buy the rights during a licensee revoke event.
So obviously IANAL, but aren't you eliding the fact that the explicit patent grant was revoked on suing facebook for patent infringement? Whereas the implicit patent grant in MIT lacks that caveat?
The explicit grant was revoked in circumstances that are unlikely to matter for the overwhelming majority of users.
The implicit grant doesn't get revoked, but how it works is still unclear. This is true especially (I believe) when it comes to sub-licenseability and patent exhaustion, where the exact mechanics have yet to be worked out in the courts. If I download MIT licensed code, and then distribute it to you, you have a valid license to the copyright on that code, despite the fact that you didn't obtain it from the copyright holder. Do you also have a valid license to any patents on that code? I have no idea, but I know enough to know it's not as obvious an answer as you might guess.
In general, explicit is better than implicit, and settled legal questions are better than fascinating mysteries. These factors weigh in favour of an explicit patent grant. The terms of the explicit patent grant Facebook was using, granted, were quite negative, but on balance I think I (and my current employer) probably were marginally better off with the older license terms. YMMV. :)
You’re not wrong, but it seems more appropriate to applaud desired behavior (positive reinforcement) than to continue to be bitter about past undesirable behavior.
I would recommend taking a look at Litho (Android) and ComponentKit (iOS). Both frameworks by Facebook and inspired by the React component model for pure native development.
Do they plan on unifying them into one framework, or are the platforms different enough that they've given up on having one framework to do everything?
Litho and ComponentKit have similar APIs and we try to bring them closer together, but I'm not sure what unifying them would actually look like. You would still end up with two libraries that target very different languages. React Native is there to stay if sharing logic is more important to you than raw speed.
Ah okay, so they share the basic programming ideology but each is a bit more tailored to their target platform. Is that right? The advantage then being that it's easier to write versions for Litho and ComponenentKit than it is to write Java/Kotlin and Objective-C/Swift versions.
The goal would be a higher amount of code sharing and perhaps a more consistent way to organize data and logic across platforms.
React Native runs a JS VM in a separate thread and communicates to the native platform code (Java and objective c) to tell it where to draw things. The native code then passes things like touch events back to the JS thread.
I want to replace the JS thread with native code to hopefully increase performance and gain advantages from Rust such as its nice type system and the Cargo ecosystem.
I have a proof of concept running Tokio and Serde to talk back and forth on Android between Java and Rust but it doesn't do much yet. Needs a lot more time to get anything serious going.
That sounds super cool! I was looking into writing Rust bindings to Yoga myself but then saw your library. I'd love to read a post about what you're doing once you've made sufficient progress with it.
I'm not on the Yoga team but work with them quite closely. There are no active plans for adding CSS Grid support mostly because the spec is kind of awkward with the ASCII-art style definitions that are very reliant on CSS as the source language. Personally, I've been warming up to the idea of using CSS Grid for UIs more and more lately after reading this post on Mozilla Hacks[0], but we haven't had many requests for adding it otherwise.
Some are of the opinion that MIT includes an implicit patent grant/license. Googling around I don't see many references to support this, but there are a few:
1. Actually, pretty much any serious patent licensing lawyer believes there is a grant (either explicit or implicit), because there is tons and tons and tons of caselaw on implicit patent grants (and the related principles of exhaustion), and while they don't include the word "software", the circumstances are otherwise identical. The others are mostly unable to admit it due to their client lists.
The number of lawyers i know who actually disagree in practice, and seriously believe it, is zero.
A significant number even believe there is an explicit grant.
That's because MIT explicitly does not mention copyright, so it may not even need an implied license.
it just says "to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so""
IE it says "whatever rights you need to use, copy, modify, blah blah blah, you get those".
Other licenses explicitly identify copyright rights, etc.
You'd be super hard-pressed to argue this is trying to talk about only copyright (meaning it's not even an implicit grant, but an explicit one).
2. As mentioned, it has been well tested in pretty much every other respect, just not for free software.
IE people giving stuff away, even under licensing agreements, even for free other things, other things under free for use license grants, etc
Like you can't actually find a case that doesn't find an implied license in the standard MIT license kind of circumstances.
That said, implied licenses do suck, and are limited in various ways.
Regarding the MIT license, I know one lawyer who disagrees in practice but I'm not sure if that lawyer seriously believes it. That lawyer is associated with an effort by some companies that have traditionally used standards-setting activity as a patent license revenue generating activity, to argue that open source licenses can legitimately preclude any grant of patent license, explicitly or implicitly (that is, that an open source license can be a pure copyright license). Part of that effort is an attempt to argue, based for example on historical evidence or on a policy basis, that certain widely-used open source licenses, like the MIT license, are susceptible to the "copyright only" interpretation.
My co-worker Scott Peterson has given a lot of thought to the issue of the MIT license as explicitly embodying a patent license grant; I am hoping he will publish an article on this in the near future.
I really hope Scott posts his research. I know he's given this a lot of thought and looked through a lot of precedent on this issue.
Honestly, he was the one who convinced me that there really is nothing out there to hang your hat on when it comes to suing people for patent infringement in MIT licensed software.
Since it wasnt clear from my post above, I buy all of this. But since IANAL, and I couldn't easily find a credible patent lawyer who has written publicly about this, I think it's reasonable to be measured in the claims I made. That said, you're obviously personally more familiar with the situation and having seen you around here before I'd give some weight to what you're saying. It's still a shame that it's difficult to find any public references. I also think it's a shame that there hasn't been a direct legal test/precedent for applying MIT style implicit grants to software. It might be a no brainer extension of existing precedent but to a lay person like me that doesn't quite sound like a sure bet.
Granted, the whole patent thing seemed a bit overblown to me. For the vast majority of companies, it's always seemed like you would probably have much bigger things to worry about if you thought protection from Facebook legal over UI patents was your main concern.
While I love reading DannyBee's opinions and am inclined to believe what he says, it's unfair to shoot down parent with an argument from authority; DannyBee did not actually cite any cases to highlight the precedent on implicit patent grants, which is exactly parent's point - it is very difficult to find publicly available information on this, aside from informal commentary.
How much do you want and in what area?
Googling "federal circuit implicit patent grant" will find you tons of free sources, as will "Federal circuit exhaustion".
Like i said, it just doesn't say "software" on it.
But it's not like this is fresh snow. People have been dealing with this in every facet of thing for years.
There's plenty of caselaw even on things like "person gives away free samples, later tries to sue for patent infringement" or "person gives gift, later tries to sue for patent infringement and "person licenses !software, later tries to sue for patent infringement".
If you have access to lexis or something, it's all neatly organized too :)
If you don't, here's a reasonable case to start on exhaustion:
Exhaustion of patent rights applies even when it's given away free:
"In summary, we hold that patent exhaustion principles
apply equally to all authorized transfers of title in
property, regardless of whether the particular transfer at
issue constituted a gift or a sale. "
Note: All the parts in the article that talk about restricting use post-sale are now invalid.
The supreme court held, last year, that post-sale restrictions cannot be imposed, exhaustion still occurs,
too bad, so sad. (http://www.ipwatchdog.com/wp-content/uploads/2017/05/Supreme...)
Now remember, it doesn't matter if it was sold sold or given away,, i just gave you precedent saying it applies just as well to a gift.
So those are out the window too.
That's just on the exhaustion side, even without finding an implied license (which are closely related).
There really is just no precedent to hang your hat on that says "yeah, you can give people stuff, tell them they can use it, and then sue them for patent infringement".
It doesn't matter if it's an implied grant, exhaustion, you name it.
There is just no case out there that says "yeah, that's okay".
Uhh..wow, thank you. I didn't actually expect you to do the work for me(not your job/it's why I said I believed you in the initial post), I was just making a point that others might be skeptical.
I guess I was googling for the wrong term - implicit patent license leads to a very different set of speculative answers compared to "implied patent grant" and "federal circuit exhaustion".
Yep. Would be quite an interesting argument to make that removing a file serves as an effective means of unilaterally rescinding a perpetual patent license.
This is actually a concern of mine as well.... that for the user, facebook’s act of removing the patents file could be worse than if the patents file was never even there to begin with. That removing the file doesn’t revert it to potentially implicit, but instead is seen as explicitly revoking. But I don’t think that’s how it should go, especially since they also switched over to MIT license in the process. But I’m also not a lawyer and probably have zero credibility writing about any of this.
Are licenses retroactive? If I used a version of React that was BSD, deployed it into a bundle.js and never touched it again, did I at one point have an agreement with a BSD + Patents, and now an MIT license?
This was going to end in one of two ways: either the Facebook source-available projects would switch to a community-approved license OR the community would migrate to something else like the VueJS ecosystem. And between those two, FB definitely benefits more from being the stewards of technologies that people will continue to use.
i think the point is that all react-likes were (with high probability) infringing on at least one of facebook's patents. People were free to move to vue or whatever, but licensing wouldn't have mattered because they would still have been infringing on a software patent that didn't belong to them and that they hadn't licensed.
the closest comparison i can think of is like the mp3 patent situation. Up until this year you were free to use LAME non-commercially even though its technology was covered by patents held by fraunhoffer & thomson.
even though vue's api is different from react's in lots of significant ways, it's not really clear that vue doesn't infringe on some of facebook's patents anyway (at least i don't know what the patents are) but the impression you get from reading every single post by an ex-fb (or current) employee is that using other react-like library put you in a similar legal situation as commercial users of LAME: while it was highly unlikely that facebook would take any action against your hackathon heroku app, it was never clear that any of those libraries (or their users) were free of actual risk. At least users of react were assured they weren't going to be sued regarding any of those vdom patents held by facebook.
We recently shipped a music making app which uses React Native for the UI, which is visually fairly rich and non-standard, including real-time rendering of shaders at 60fps responding to user input using gl-react-native and regl, and overall have been very pleased with the speed at which React Native allows you to iterate and the polish/smoothness of the resulting app; not to mention the fact that it allows us to easily make use of web developers’ existing CSS skills (as compared to writing a native app).
The fairly straightforward bridging between React Native and native code has allowed us to have an audio engine running in C++ and to communicate with it in both directions in real-time without significant overhead.
That’s not to say it’s been 100% straightforward, there were definitely a few rough patches along the way, but overall I would definitely use it again. I can easily believe that e.g. 18 months ago it may have been a much rougher experience which may explain your thoughts though!
> communicate with it in both directions in real-time without significant overhead
Doesn't all the communication have to be done by passing JSON-encoded messages between threads? So compared to calling a function on the same thread, there is very significant overhead, especially if you want to pass large data structures (which would have to be serialized) or if the calling thread needs to block waiting for the answer.
But as long as you stick to send small and asynchronous messages, it doesn't have a significant impact on the user experience, I suppose.
Yep - C++ is generally used for audio programming because you can write code that is real time safe for use on the audio thread (low latencies mean you might have 5ms to fill a buffer with fairly intense calculations required for a modern synth, so any waiting for locks, memory allocation, GC pauses etc. can be disastrous and lead to audible glitches). On top of that there’s a huge amount of code and libraries for audio stuff written in C++ - we used JUCE which provides a lot of helpful abstractions and cross platform compatibility.
Exact opposite experience. After being a mobile dev for 8+ years and making all of my most recent apps in RN, including a rewrite of one that was many years old, you're wasting your time if you still write native code instead of RN. It's just better in every single way and is an incredibly impressive, stable piece of technology.
I got just a taste of RN recently. The thing that stood out the most about it to me is being able to iterate through debug cycles at a much higher speed compared to native debugging.
You probably have an advantage coming from a native background. The main thing i've been battling when it comes to React Native is that to do things really well, you do need to be able to dive into native code from time-to-time. It's definitely true that you can write simple apps with just the React layer, but I think people greatly underestimate the amount of work it takes to build an app that actually feels native.
Can you make a native button in React Native yet? When I first tried it, there was no button component at all; later, they added a component[1] that emulates (almost correctly) the look and feel of a native button but is not actually native.
I tried to implement a native Android button component myself (i.e. hook it up[2] using Java code), but the problem I ran into was that for the button to compute its desired size, React Native wants to do the measurement step on the JS thread, before the actual button is created (so it can't be asked for its size). And the built-in components' implementation of measurement looked really complicated, so I gave up on it.
I had the experience of taking React Native to production in an Enterprise-level environment once.
My team first experimenting with RN on 0.8.0. What I found impressive was that some of the experimental code we wrote in RN proved stable enough, that it was still the same on production level builds using RN version 15.x eighteen-months later.
I'm not saying RN is THE solution, but I for one would stand to vouch for it for both top-quality UI output but also for ease of development.
That being said, there's so much cross-platform work going on, who knows where the industry will be years 2 years from now.
Personally, I believe MIT is correct. I had moved my company away from React when they had the licensing problems. To me, it feels like they are coming back to the community now.