I’m not so sure it’s as easy as calling this a witch hunt. We have yet (AFAIK) to hear from a patent attorney on the matter.
That being said, if I was working on a project that had the possibility of encroaching on Facebook’s space (which I am) I’d have a difficult time subscribing to any tech produced by fb which wasn’t truly foss, without ANY disclaimers.
I think what fb is doing with react is awesome, but at the end of the day, fb is a business that enjoys dominating markets. So any conflict of interest is taken with more than a grain of salt.
Not saying a witch hunt is what can or should happen, but this thread and others are filled with speculation. I suppose I’d rather err on the side of caution?
We’ve definitely discussed using/switching to a dom-less view layer, but the necessity just hasn’t been there yet. We’ve been moving quickly and it makes onboarding/sourcing potential contributors a bit easier actually. If you know blaze, you know meteor, which means you know our whole stack.
I’ve certainly had my moments of trepidation about blaze and its future, but pulling the trigger on React has given me a bad feeling since it became an option in meteor. (Specific to this project, not in general!)
Unless someone backs up their claim with a link to a clarification by one of Facebook’s lawyers, anyone making assertions for or against this issue is just pulling stuff out of their… hats?
I talked to a few of our lawyers and their answer was basically: Those clauses muddy the licence too much to give a clear answer; any use of Facebook’s OSS would have to be justified and reviewed on a case by case basis.
I personally hate licences which make you waste cycles trying to figure out what the clauses mean and their possible repercussions.
If I were a company of substantial size (think Intel, Google, Microsoft etc) I would think twice before using software released under such a license.
For me it’s a potential showstopper as I’m building a framework (not an end product). By adopting one of the mentioned technologies I would limit my market size as I’m sure some companies are going to have issues with it.
Software patents, at this point, don’t really hold much weight and it seems it’s trending towards holding less and less weight. That coupled with the fact they’ve really pushed this stuff in a “open source” fashion, are all going to make it very hard for them to actually hold a patent against you.
That and the chance your startup gets big enough for facebook to actually care is basically 1 in 100k+
The problem isn’t just in the license wording, it’s in the intent.
It was indeed much more restrictive, and FB loosened it a bit. But they didn’t loosen it completely. That’s a conscious choice.
If you are releasing it to the world as real open source, then you are a team player and looking to share with the community.
If you are releasing it while holding the wheel firmly, then we have to trust you to use your stuff.
Imagine this scenario: the license changes (wouldn’t be the first time) and becomes less permissive. What happens then? It’s not retroactive so your current code is Ok. But you are out of luck for the future. Other open source licenses prevent that, but React’s license does not. Again, intentionally.
This is definitely something to worry about, thanks for pointing it out tidee. Check with your legal team. It may not be a problem for your startup now, but it may become a problem later when you’re potentially being purchased, or your revenue grows out of insignificance. A few minutes of effort now can save you hundreds of hours later when you realize you literally need to rewrite your entire application to not use React. Is that a risk you want to take? That’s for everyone to decide individually,
Note: a couple of these (Mercury and Deku) have options for using JSX to compile JSX-syntax into to the functional form that the library uses, so be careful there. I’m not sure how the React patent license applies to JSX.
So far, of all the options, Riot.js is the only alternative that uses DocumentFragments (read this to see how using DocFrags makes things fast), which make me believe Riot.js may have thought deeper about performance: creating a DOM tree in the live document can cause extra things like rendering to happen. Manipulating DOM in a DocumentFragment prevents extra things like that from happening until the DocumentFragment is attached to the live DOM. I haven’t done any actual performance testing though.
In various places around the web, Mercury shows the fastest performance. It’d be nice to add some of the other alternatives to those tests.
They have tried different technologies and switched often. Seems like they are innovative and nimble. My take is that they had a current problem to solve, and React solved it well today. Tomorrow they might switch to something else.
Do you have their resources to be nimble and switch often?
Again, it’s a business choice. The point is we can’t paint a rosy picture and say all is well. There are risks to consider.
PS: They are using React as they like the data flow (slides 20 - 21)
Two more questions to be fully rational about all this.
1/ What do the others do ? I’ve read a comment saying “what if Facebook decides to change the conditions” ? Hey, what if Apple decides to change the conditions ? What if they decide to make all the things you do on a Mac their own property ? Its just paranoia.
Then 2/ : why targeting React now ? Is that related to the recent certainty that React is here to last, that it recently became more starred on Github than, say, JQuery ? That Google prepares transition for Angular ? That some companies would take benefit from Facebook weakness ? That also is paranoia. Just pick your favorite one.
Exactly. If the conditions are changed to be super restrictive, then it only matters for future software. Laws are only applied retroactively in the positive, not the negative. So start building stuff now before there’s some restriction and you’ll be fine.
Also, there’s an entire thing in law about reasonableness. If Facebook tries to say all React-based software is theirs just because it’s React, that won’t hold up in court. You can’t just stick a clause in that says we own you if you agree.
Note: I’m not a lawyer, I just took a couple classes (Intro, Personal Injury, Copyright and IP)
If the license changes, the previous one(s) only applies to prior versions. If you decide to use newer versions, you have to accept the new license or switch out.
Thought I would clarify this point so it’s not misinterpreted as meaning previous licenses apply forwardly.
