1. React source code is licensed under the Modified BSD license.
2. React also comes with a conditional patent grant. Here "conditional" means that the patent grant may terminate under some conditions. It does not terminate 1.
Most BSD and MIT-licensed software you use comes without a patent grant at all.
Thanks - I somehow managed not to look at that (saw it now after Twitter feedback). I can't edit my earlier comments so I'll just amend here instead: There are open source lawyers who consider simple permissive licenses such as Modified BSD and MIT to have an implicit patent grant. The first public discussion I found on this after a quick search is at http://lwn.net/Articles/389016/ - would love to see more and earlier.
If you the licensee also consider Modified BSD to have an implicit patent grant then the React patent grant is much worse for you than if it hadn't existed.
Now, I don't know what makes things "better" for you but from the perspective of most licensees it is probably legally better to have a conditional patent grant than none at all, most of the time. But it will vary depending on, for example, the licensors (their) and licensees (your) patent portfolios and intention to enforce those aggressively as well as your strategies of defense. There's a huge difference between a company such as, say Oracle and Facebook, here.
Granting patents in the context of permissively licensed open source is a generous act and making the grant conditional is a way of not giving up your ability to form the strongest possible defense when you're brought into patent litigation. If you have been following along the recent years events (where is that patent apocalypse, anyone?) then it should be no surprise why companies need to do that.
None of the patent grants you mentioned are as one-sided as Facebook's. My problem is not with a conditional patent grant. My problem is with Facebook preventing React users from defending themselves against lawsuits for unrelated patents.
Apache, GPL, MPL, etc. have retaliation clauses that terminate your patent license only if you sue (or in some cases, countersue) in relation to the covered software. Facebook's patent grant says you can never sue Facebook, while being vulnerable to being sued by Facebook for anything but React.
Thanks for being specific. I agree that Facebook's termination clause is crafted to benefit Facebook more than should they have used similar language to Google's (or APL2.0). A less defensive patent grant would have been more generous.
But I'm not sure I agree with your conclusion though.
Scenario one: MYCOMP uses React in a product, decides to sue FB because FB uses the term "It's complicated" which MYCOMP was granted a patent for by the US patent office (the phrase was translated into a dual-ROT13-machine for the purpose of the patent application). MYCOMP had tried to get FB to pay them a reasonable license fee prior to suing but Facebook neglected. Now MYCOMP does not have a patent grant for their use of React any longer but isn't that then ~similar to as if React didn't have any patent grant to begin with (from a litigation perspective) - like most MIT and BSD licensed software we use? Had I been with BIGCORP I'd have asked the legal folks or our favorite patent attorney but now I'm solo so I'm throwing out the question here for further discussion.
Scenario two: FB sues UCOMP (who uses React in one of their products) for patent infringement of FB's "Send message from client to server" patent (nicely masqueraded in the patent application). UCOMP decides to counter-sue and we have a situation similar to scenario one.
When FB gives you a patent grant, it implies they have patents they could sue people over. An MIT or BSD copyright license alone could mean there are no patents to grant.
I don't understand your claim about redundancy. Amazon says that Glacier "is designed to provide average annual durability of 99.999999999% for an archive", https://aws.amazon.com/glacier/details/#durability. This seems to be the same as for S3 objects. Furthermore, they say that "the service redundantly stores data in multiple facilities and on multiple devices within each facility".
So multiple facilities and multiple devices on the same facility (I guess that means at minimum 4 copies), and a calculated annual durability. Not so secret?
What are Backblaze's (and Crashplan's) redundancy policies?
I don't know if it's really fair to call Verified by Visa two-factor authentication as your card number is just another string (that can be replicated). With Verified by Visa you go from one to two "passwords".
It adds a "something you know" (password, PIN/Password to your token generator) factor to the "something I have" (The card, with numbers on front and back) factor, so I would say it's fair to call it two-factor authentication.
I beg to disagree. The credit card is "something you know" just as much as "something you have", because when used on the web it is just a (copyable) 23 digit number. Whether you remember the number or look it up in your wallet is no different than whether you remember your password or store it on a post-it.
Other things "you have" in popular 2FA solutions are quite different, for instance your mobile phone number identity (for SMS) or your Google Authenticator.
Feel free to open issues and I'm sure it will be addressed.
ng-annotate itself just produces output for input (stdin/stdout or via files) so it does not at all have any trouble participating in a "complex build environment".
it can certainly not support everything, partly because of limitations imposed by static analysis, buy you may be surprised with what it can handle.
Also: For situations where you don't know whether ng-annotate will detect a form or not (assuming you already use ng-annotate for your project), you can use explicitly use /* @ngInject */ or ngInject() to avoid stuttering the array yourself.