Yes - certain filings are confidential while they are 'in process.' They then get released in batches on specific release dates, to the entire world, all at once. In particular, IPO registrations may be done confidentially in early stages. The information that is present in such filings is often valuable.
First, humans are still necessary - to build the factories, to operate them, to act as security guards - and the cost of those humans is still lower.
Second - all the other costs in low wage countries are also a lot lower. Combine that with how absurdly cheap international shipping is and there is no reason to relocate the manufacture of low-margin goods to the US until you are really starting to talk about the costs of automation being so efficient the extra pennies on shipping will make a difference in earnings. Given the expense of maintaining real assets in the U.S., i.e., buildings (utilities, maintenance, insurance, taxes, building), this is likely to be a while.
I agree - I'm an attorney. But are we picking and choosing here? Because my bet is, and has been for quite sometime, that when all is said and done, the 'regulations' we are talking about are those that already exist and are applied to securities.
I would gladly pay a substantial premium for an ISP that was a co-op (i.e., subscribers are also 'owners') or run as a not for profit. Not for profit is probably easier.
Hell, I would donate my time as a lawyer to helping out.
> I thought the whole point of crypto currency was that it WASN'T regulated and so how is the government able to do this, let alone say this with any authority?
The SEC regulates securities. Cryptocurrency (arguably) meets many different definitions that would qualify at as one of several types of security (or future, or commodity). Therefore, the SEC has the power to regulate cryptocurrency.
To put it another way, the government already has authority. Trying to engineer around the authority of the government is the intent of (some) cryptocurrency designers - but it doesn't work that way. For all the same reasons that 'sovereign citizens' are wrong and (comically) misguided.
The government exists. It has authority. Denying either of these two things is utterly and totally delusional - not to mention childish and indefensible. If you really are trying to argue that the SEC has no authority to begin with - well, good luck with that, and have fun talking to your lawyer through bars or reinforced glass.
The debate is about whether cryptocurrency has been adequately designed to legally circumvent the legal requirements that would make it subject to current regulation. In other words, whether, according to the rules of the SEC, it does not meet the SEC's definition of what it regulates (or the FTC's, or the CTFC's for that matter).
As of now, the prevailing legal opinion is that it has not and that cryptocurrency meets many different definitions of security, future or commodity. Is it possible to change this? Possibly, but it is an engineering issue and it requires working within the bounds of the law - not just pretending that these authorities do not and cannot have actual jurisdiction.
It will be quite interesting to see how institutional investors and the CTFC come down on this whole phenomenon. I do not share the unbridled optimism of many of my peers.
I mean on the encrypt side, not the decrypt side. When I try to put text into a react form, react doesn't pick it up - it still uses the original text in the input form. I will definitely look at that code though, thanks!
How did you deal with text injection into react forms on facebook?
Whenever I interact with text in a form field on facebook via a browser extension, it is not picked up by react, and the original text is what is picked up on submission. I've banged my head into this problem repeatedly. Is there an easy fix or is this something much more subtle?
Right, that was my instinct, it is just that the documentation I have seen, including the O'Reilley bitcoin manual, on the coinbase transaction, glosses over this point.
I actually would very much appreciate that. I was just reading Nakamoto's whitepaper on Bitcoin [1] and I understand the hashing. However, the coinebase transaction is still a bit confusing to me. Specifically, to get at precisely this issue - what does the bitcoin itself consist of? It is just the summation of the history of transactions to and from an address? Or is there a numerical value or token that is actually issued during a coinbase transaction, and, if so, how is it generated? This is not apparent to me. I understand that during a coinbase transaction, there is a transaction registered that is issued to the miner and the 'from' address is null - but it is still not clear to me, other than the balance of that transaction, if there is an actual token associated with those coins.
> The number who would have no effective recourse under this license, who would have had effective recourse before, is quite high.
I think that's the rub. If that is the case, then this is certainly very problematic.
In any event, this is certainly a class of licenses that needs to be watched carefully on an ongoing basis and added to the (already substantial) checklist of licenses that need to be carefully considered before being added to any project.
I appreciate your comments and candor on all of this, btw. Thanks again.
You make a lot of good points, but I want to focus on just one.
> This license will not have the effect of stopping patent litigation. Patent trolls don't use React, and most of the danger is still trolls.
I agree. However - implicit in your position (and my apologies if I am reading you wrong) is that there are small players - or any players - who have valid software patents that should be exercised against anyone - much less Facebook. As a general proposition, I'm hesitant to support that.
Let's put it another way - but first get some caveats out of the way: there may be things problematic with this license (your points are highly illustrative - especially about the systematic, higher-order effects). I also think that, as someone in private practice, I'm empathetic to Facebook's attorneys' goals here, and they are likely saving Facebook a whole host of headaches. I am also very well aware of the counterbalancing arguments regarding the duty of good stewardship of the open source community, and decisions like this by gigantic players such as Facebook have lasting effects for the entire community. /caveats
However - defense of the right to pursue infringement litigation over software patents against anyone is simply not a hill I am willing to die on. I am struck, as a result, by confusion at the willingness of open source lawyers to criticize facebook for license limitations aimed at limiting the rights of licensees to initiate patent suits - even if it is a self-serving limitation. My instinct is that, in general, push-back against limitation (even imperfect ones) of the exercise of software patent rights, within the open source community, should be a fairly low priority. I'm happy to stand corrected - it happens often enough.
Let me make a crude analogy - if you believe in certain forms of gun control, this would be the equivalent of a debate about what type of assault weapons may be owned by the public. If you are of the view that no assault weapons (and I am using the term very, very broadly - I'm not interested in the highly technical debates of what constitutes an assault weapon for these purposes) should be owned by the general public, then law banning the ownership of a particular type of assault weapon against by a particular class of owner is not that big of a deal - even if it is crudely implemented. If anything, it may be a step in the right direction. Accordingly, the criticisms of the BSD+Patent license by the open source community strikes me as analogous to criticism of a partial assault weapons ban by gun control advocates - it is a bit of a head-scratcher.
Back to this license, in more concrete terms - I am skeptical of the claim that there exists an entire class of small companies have that meaningful software patent portfolios that can be exercised against facebook, much less anyone, which companies will be disenfranchised of their rights by this license:
* First, software patents are severely diminished in the post-Alice world, as a category, and very likely to be invalidated in an enforcement action, especially against a company as wealthy and sophisticated as Facebook. Patent litigation with Facebook is going to be as scorched-earth as it can get - the arrow of the BSD+Patents license is but one in a quiver that is full of millions in cash and tens of thousands of associate hours.
* Second, if you have the wherewithal to enforce a patent, you have millions of dollars in attorneys fees at your disposal - meaning you are not very small. Patent infringement litigation is called the sport of kings for a reason - it is monstrously expensive (I seem to recall statistics stating that a 'simple' patent claim is on the order of $1.5-3M to litigate to conclusion, per party).
* Third, if you have non-software patents (e.g., medical devices, drugs, chemical compositions, manufacture processes, semi-conductors, etc.) - it strikes me that there is a low (maybe not zero, but low) chance that facebook's BSD+Patents license constitutes a substantial portion of your 'critical' software stack.
* And, finally, if after all this, you are a small startup without a lot of money and you are trying to enforce software patents against Facebook (of all possible litigants, I can think of no larger juggernaut), and react (or any other BSD+Patents licensed software) is a part of your critical stack - there are so many other existential questions about the company's strategy that the particular terms of this license are rather low on the list.
As I said, I am very happy to hear any feedback, and thanks for your thoughtful responses.
Edit / update:
A few notes, in no particular order:
Tl;dr - two main cases here: 1. one is trying to enforce software patents against facebook - I am not going to spend a lot of energy defending the exercise of software patents, generally; 2. one is trying to enforce non-software patents against facebook - I believe there is a low chance that Facebook's BSD+Patents software constitutes a meaningful part of your stack in this instance.
* You are likely viewing this issue from the point of view of someone who chooses what sorts of licenses Google should adopt. I very much appreciate your insight and criticisms from that perspective. However, I am viewing it as counsel to a lot of small companies that have to be nimble - accordingly the scenario in question, where this license is a limitation of a startup's ability to succeed, involves that startup having been misguided into thinking that it is a good idea to sue Facebook for patent infringement over a software patent while also relying on Facebook software as a part of their critical stack. That is... quite a scenario. It reminds me of this scene from Dark Knight:
Lucius Fox: [in his office] Let me get this straight. You think that your client, one of the wealthiest, most powerful men in the world, is secretly a vigilante who spends his nights beating criminals to a pulp with his bare hands; and your plan, is to blackmail this person?
So the concern is that if you are a company with a large patent portfolio, and you sue facebook for patent infringement unrelated to react, facebook will yank your react license?
I have been saying this for quite sometime on this forum - contracts have to deal with ambiguous circumstances and expressly contemplate being resolved in courts. Ambiguity of contracts is a feature, not a bug, as it is in the interest of both parties to be able to argue about certain unanticipated events when they occur.
Quoting my own comments from a while back:
> The vast majority of contracts do not have syntactically testable conditions. They just don't. Whether the conditions in a contract have been met is very often a matter of huge debate - this is what "law suits" are about. Unless you can create a condition that is testable by code, you cannot have a contract that self-enforces with the block chain. The conditions set forth in contracts are extremely complex and reasonable people can differ. I cannot imagine how you would have a contract be triggered on the insolvency of a privately held corporation - good luck defining insolvency and good luck getting access to the underlying books. Copyright infringement is also a preposterous idea - the amount of semantic judgment that must be made to determine if a work is infringing is enormous. Only the very simplest of conditions - comparing numbers, checking the time, can be reliably automated, and if you are getting a lawyer to write your contracts, odds are there is substantially more complexity in the agreements than this, which is why you hired the lawyer in the first place. In addition, a fair portion of contracts that can actually be set up to work this already are - and the blockchain is not necessary. They are things like credit cards and they work pretty good without the blockchain.
https://www.nytimes.com/2017/07/07/business/dealbook/sec-ini...