React Native and Yoga Both Given MIT Licence by Facebook(github.com)
github.com
React Native and Yoga Both Given MIT Licence by Facebook
https://github.com/facebook/react-native/commit/26684cf3adf4094eb6c405d345a75bf8c7c0bf88
123 comments
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 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.
Actually we just thought it was a shame that people wouldn’t use it because of the license. Not much more complicated than that.
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.
Great work!
Great work!
If they had changed the license when the community asked, that would have been listening to the community, but they didn't.
Changing the license because people are leaving the project only shows that FB cares about itself.
Changing the license because people are leaving the project only shows that FB cares about 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.
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.
I suspect that given Facebook's history with patents it has probably been in the works a long time to make this change.
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.)
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?
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.
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 then they wouldn't get the free labor of the community.
I think we are saying the same thing. Which part of what I said do you disagree with?
>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.
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.
Yes because if I need to build something right now it does not really help me that there will be something in the future to replace React.
What's the next JavaScript framework for non-web mobile apps though?
Oh, it's 2018, nobody uses React Native anymore.
We're using Weex [1] or NativeScript [2] now.
[1] https://weex.incubator.apache.org/
[2] https://www.nativescript.org/
We're using Weex [1] or NativeScript [2] now.
[1] https://weex.incubator.apache.org/
[2] https://www.nativescript.org/
You mean, you do that? I don't get it otherwise.
http://www.npmtrends.com/react-native-vs-weex-toolkit
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).
A couple of them here: https://pbs.twimg.com/media/DUF19IlXcAE2UC6.jpg:large
Can't imagine why anyone would willingly want to wait another 4-5 years until Weex is where RN is today.
http://www.npmtrends.com/react-native-vs-weex-toolkit
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).
A couple of them here: https://pbs.twimg.com/media/DUF19IlXcAE2UC6.jpg:large
Can't imagine why anyone would willingly want to wait another 4-5 years until Weex is where RN is today.
You mind sharing the list on https://pbs.twimg.com/media/DUF19IlXcAE2UC6.jpg:large
?
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.
Anyway, here's the list (I tested all the URLs):
Windows: https://github.com/Microsoft/react-native-windows
macOS: https://github.com/ptmt/react-native-macos
Linux (Qt): https://github.com/status-im/react-native-desktop
AR: https://github.com/HippoAR/react-native-arkit
VR: https://facebook.github.io/react-vr/
TV: https://github.com/react-tv/react-tv
Shell consoles: https://github.com/Yomguithereal/react-blessed
Word: https://github.com/nitin42/redocx
PDF: https://github.com/diegomura/react-pdf
3D: https://github.com/Izzimach/react-three
Sketch app: http://airbnb.io/react-sketchapp/
Keynote: https://twitter.com/nishb1/status/913744410537537536
Hardware: https://github.com/iamdustan/react-hardware
Samplers: https://twitter.com/GabeRicard/status/911989894267973633
Anyway, here's the list (I tested all the URLs):
Windows: https://github.com/Microsoft/react-native-windows
macOS: https://github.com/ptmt/react-native-macos
Linux (Qt): https://github.com/status-im/react-native-desktop
AR: https://github.com/HippoAR/react-native-arkit
VR: https://facebook.github.io/react-vr/
TV: https://github.com/react-tv/react-tv
Shell consoles: https://github.com/Yomguithereal/react-blessed
Word: https://github.com/nitin42/redocx
PDF: https://github.com/diegomura/react-pdf
3D: https://github.com/Izzimach/react-three
Sketch app: http://airbnb.io/react-sketchapp/
Keynote: https://twitter.com/nishb1/status/913744410537537536
Hardware: https://github.com/iamdustan/react-hardware
Samplers: https://twitter.com/GabeRicard/status/911989894267973633
/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..
And what is this next JavaScript framework?
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.
Except now React doesn’t have a license issue, so they took a step backward for nothing. Heads must be rolling.
The irony being that the Apache license has an identical clause.
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?
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.
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.
agreed - that sentiment carries to all of us software-engineers working in the Silicon Valley Peninsula.
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.
Community: All this FUD about your library licensing scares me.
FB: OK, we'll remove the part all the FUD is about.
This guy: Here's some entirely baseless FUD to replace the FUD you removed.
FB: OK, we'll remove the part all the FUD is about.
This guy: Here's some entirely baseless FUD to replace the FUD you removed.
It's not at all different from loving music written by drug addicts whom you wouldn't want as friends. Software developers are people too.
Those drug addict musicians that track your every move online, sell your data, make billions from advertising, influence elections. Totally "not at all different".
Good point. Also, almost 100% of the time, the actual musicians get peanuts. Taylor Swifts are 1/10^8.
Out of all the music I listen to on purpose, maybe 20% is popular. I doubt the artists behind the other songs I listen to are multi-millionaires.
Out of all the music I listen to on purpose, maybe 20% is popular. I doubt the artists behind the other songs I listen to are multi-millionaires.
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.
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.
- React -> Vue, Mithril, etc.
- React Native -> Weex, NativeScript
- Reason -> Elm, Purescript, Scala.js, Typescript
- etc.
- React -> Vue, Mithril, etc.
- React Native -> Weex, NativeScript
- Reason -> Elm, Purescript, Scala.js, Typescript
- etc.
How exactly using a library supports them?
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.
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.
Yes, but the benefit is not from people just using the library.
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.
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.
That last paragraph is the very definition of Stockholm Syndrome.
Facebook is an $0.5T company built on open source. Without open source, Facebook would not have been possible.
Facebook is an $0.5T company built on open source. Without open source, Facebook would not have been possible.
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.
This is correct, for what it's worth.
> 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).
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.
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).
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).
It does not look like this was ever tested by actual court case so I guess it is hard to argue either way.
Please leave such opinions to actual lawyers.
Apache placed React's BSD + PATENTS in "Category-X", banning it from being used in Apache projects:
https://react-etc.net/entry/apache-foundation-bans-use-of-fa...
> 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".
Apache placed React's BSD + PATENTS in "Category-X", banning it from being used in Apache projects:
https://react-etc.net/entry/apache-foundation-bans-use-of-fa...
> 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".
> Apache placed React's BSD + PATENTS in "Category-X", banning it from being used in Apache projects:
The GPL, LGPL, and AGPL are also in that list, so by itself this isn't much of an indictment of the license itself.
https://www.apache.org/legal/resolved.html#category-x
The GPL, LGPL, and AGPL are also in that list, so by itself this isn't much of an indictment of the license itself.
https://www.apache.org/legal/resolved.html#category-x
Please leave such opinions to actual lawyers.
[deleted]
> 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 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. :)
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. :)
Neat! Yoga is a great library, I wrote Rust bindings for it:
https://github.com/bschwind/yoga-rs?files=1
I eventually want a React Native esque framework but written in Rust instead of JS. Still a ways away though, I don't have much time to work on it.
https://github.com/bschwind/yoga-rs?files=1
I eventually want a React Native esque framework but written in Rust instead of JS. Still a ways away though, I don't have much time to work on it.
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.
What would be the point of having React Native for Rust if Rust itself is already native? Having a DOM API available in Rust?
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.
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.
Yeah I should probably write a post to get more of the concrete ideas out there, I'm afraid I don't have enough time to work on it right now.
However, another contributor to my repo is doing some interesting work with Yoga here (though it's not quite related to cross-platform mobile apps):
https://github.com/victorporof?tab=repositories
I say "contributor" but he's basically the one doing the heavy lifting on the bindings lately
However, another contributor to my repo is doing some interesting work with Yoga here (though it's not quite related to cross-platform mobile apps):
https://github.com/victorporof?tab=repositories
I say "contributor" but he's basically the one doing the heavy lifting on the bindings lately
Was just reading about yoga. Since you’re familiar with it, do you know if there are plans to support css grid?
I don't think there are any plans to but facebook has so many engineering resources that they may just add it one day.
For now it's just Flexbox and I think that covers most developers' needs.
For now it's just Flexbox and I think that covers most developers' needs.
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.
[0] https://hacks.mozilla.org/2018/02/css-grid-for-ui-layouts/
[0] https://hacks.mozilla.org/2018/02/css-grid-for-ui-layouts/
Does MIT encompass BSD?
If it doesn't then surely they can't just re-license code that was contributed by others without their permission.
I'm not fundamentally against this and I doubt anyone cares in practice, it just doesn't seem right in terms of the contributor's rights.
If it doesn't then surely they can't just re-license code that was contributed by others without their permission.
I'm not fundamentally against this and I doubt anyone cares in practice, it just doesn't seem right in terms of the contributor's rights.
If you contribute to fb open source you need to sign a CLA: https://code.facebook.com/cla/individual
Wait, they're getting rid of the patents grant?
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:
* http://en.swpat.org/wiki/Implicit_patent_licence
* https://en.wikipedia.org/wiki/MIT_License#Relation_to_Patents
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.
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.
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.
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.
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.
You're replying to a lawyer in the Open Source Program Office at Google:
https://www.pli.edu/Content/Faculty/Daniel_Berlin/_/N-4oZ1z1...
If there's anyone I'd expect to have a handle on open source law, it's him.
https://www.pli.edu/Content/Faculty/Daniel_Berlin/_/N-4oZ1z1...
If there's anyone I'd expect to have a handle on open source law, it's him.
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.
Well the main thrust of his post (as I understood it), was contained within the first sentence:
> I couldn't easily find a credible patent lawyer who has written publicly about this
Since DannyBee is quite possibly a "credible patent lawyer", then the above poster is getting what he asked for.
> I couldn't easily find a credible patent lawyer who has written publicly about this
Since DannyBee is quite possibly a "credible patent lawyer", then the above poster is getting what he asked for.
Yeah I think this is fair. Although it might have helped to preface with that. Nonetheless, a small amount of egg on my face.
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:
http://www.cafc.uscourts.gov/sites/default/files/opinions-or...
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. "
Here's an older article with a ton of cites: https://www.finnegan.com/en/insights/the-u-s-supreme-court-c...
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".
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:
http://www.cafc.uscourts.gov/sites/default/files/opinions-or...
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. "
Here's an older article with a ton of cites: https://www.finnegan.com/en/insights/the-u-s-supreme-court-c...
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".
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".
Thank you for bringing actual legal knowledge to this forum rather than the usual armchair lawyering we get.
They’re not getting rid of a patent grant. They’re getting rid of the PATENTS file. Semantics here actually matter.
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.
[deleted]
[deleted]
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?
No. You’d have to re-download/deploy it.
IANAL
IANAL
say what you will about Facebook, this is a huge gift.
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.
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.
People are addicted to using. With no real production.
[deleted]
What is yoga?
The flexbox implementation that react native uses for layout.
Yoga just got a brand new website with a flexbox playground if you are interested: https://yogalayout.com
It has quite strong adoption already: YouTube, Facebook's own apps of course, Airbnb, Amazon. See https://www.appbrain.com/stats/libraries/details/yoga/yoga for more details (I'm one of appbrain's developers).
I'm not surprised, React Native doesn't work nearly as well as you'd think. This is basically a piece of software you'd have to give away (IMHO).
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.
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.
In my experience, this is completely wrong.
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!
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.
Or did they do something to improve this lately?
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.
Or did they do something to improve this lately?
An audio engine in C++?
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.
Is there? What would that huge amount of code meant to you?
It means you can build on top of other people’s proven abstractions rather than writing your own buggy ones ;)
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.
It all comes down to the navigation. Use a native navigation, then you're good to go!
https://github.com/ueno-llc/react-native-starter
https://github.com/ueno-llc/react-native-starter
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.
[1] https://facebook.github.io/react-native/docs/button.html
[2] https://facebook.github.io/react-native/docs/native-componen...
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.
[1] https://facebook.github.io/react-native/docs/button.html
[2] https://facebook.github.io/react-native/docs/native-componen...
I have 9 years experience developing for iOS and my take is completely opposite.
If you know native SDK RN gives you nothing and takes a lot away.
osquery was also relicensed (to Apache 2.0 and GPLv2) in https://github.com/facebook/osquery/pull/4007.
[deleted]
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.