React Native and Yoga Both Given MIT Licence by Facebook

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?

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.

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.

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.

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.

For now it's just Flexbox and I think that covers most developers' needs.

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 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.

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?

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...