We're really excited about this release. I also wrote about how we made the rewrite happen on our Facebook engineering blog: https://news.ycombinator.com/item?id=15339825.
Happy to answer questions if y'all have any. :)
Happy to answer questions if y'all have any. :)
https://medium.com/@leeb/relicensing-the-graphql-specificati...
* I am not a lawyer and this should not be taken as legal advice.
https://github.com/facebook/react-native/blob/master/PATENTS
Community: This license is a legal nightmare. Something needs doing! Facebook: We have done something. Community: Try listening to both sentences next time.
Can you clarify your concerns?
Ultimately the React ecosystem would benefit from the attempt.
Depending on the patent in question, it is possible to be on the hook even if you don't use React.
If you had black and white fair use, for example, you'd just be railing against the fact that courts wouldn't extend it to cover new similar thing X.
Black and white is good for establishing baselines in law (IE "these things over here are definitely okay, and everything else should be judged by these factors" It's rarely that great if you are trying to make a license that stands the test of time and march of technology.
So far, every court ever (and there are quite a lot of them) has said "when you tell people they can use your thing and do what they want with it, you can't sue them later for infringement for doing what you said was okay".
There is pretty much zero precedent on the other side.
In fact, one of the only related pieces of precedent on the other side, which was "attempting to avoid patent exhaustion by contract" was completely and totally overruled by the supreme court last year, where they unequivocably said that sales exhaust patents, no matter what you make a person agree to.
Close enough, I'd say.
> FB could still enforce patents regardless of license
It is widely accepted that the MIT license has an implicit patent grant.
That blog post mentions your featureFlag approach, the initial dogfooding and then the gradual rollout. I'd be very interested to hear on top of that:
1. How did you approach the rewrite on the coding side? What I mean is: Did you just say "Okay, let's start from scratch and use the lessons learned from v1?" Or did you use a specific approach along along the lines of: "Let's structure our code based on these principles and ...?"
2. When you started the rewrite, how did you know in advance and make sure that the rewrite would be faster and have a smaller code-size?
3. Was your focus during the rewrite on a cleaner code base (and the performance improvements followed automatically) or was your focus on speed right from the start?
4. Any other lessons learned during the rewrite? Patterns and approaches that helped/didn't help during the coding?
I always remember how the SQLite author Richard Hipp talked about being able to rewrite major chunks of the SQLite engine due to their test coverage. Their testing page currently says they have 730x more test code than core library code. https://www.sqlite.org/testing.html
Why remove the dist folder that was in prior releases?
Out of curiosity, did you switch to Rollup for the tree shaking optimizer, or for some other reason?
It's just not the way things are done in the JavaScript world.
Don't expect it to magically improve performance though. But the async stuff mentioned in the post will definitely come to RN when it is ready.