This is the risk you take building something on top of an API—access can be cut off at any time.
and that's bad for tech, and bad for america
My advice to anyone building anything significant off an API or scraped access: do it anonymously. Never reveal your real identity. Never use your real IP. Don't process credit cards. Don't register an identifiable LLC. Run it out of China or Russia where American companies will have a hell of a time trying to get to you.
If you depend on one entity's API, that entity is not going acquire you. At best, your product will be ripped off and they'll make you irrelevant. This happens to popular mobile applications all the time.
At worst, you'll get sued civilly, get your wages and bank accounts garnished, lose all of your possessions, and get criminally prosecuted under the CFAA, end up doing some time, and eventually get released with the stipulation that you never touch a computer or access the internet again for the rest of your life.
Unless you can ramp up to doing tens of millions of revenue per year (or have investors willing to pony that up) before the company you depend on notices/decides they don't like you anymore and sends out their law firm, you're dead meat, no matter what the details of your case are and no matter how wrong they are.
These are not problems you want. It's easier to put your service in the onion and run it from there, access all external data via proxy, only accept Bitcoin for payment, and never tell anyone the link to your real-world identity. Granted it takes good opsec to continue this for a long time, which is really hard to pull off, but it may be doable depending on your level of commitment.
(And having the LLC gives you great protection against lawsuits!)
For example, for Google, look at Google Keep – that one leaks API keys directly in the list of accessed URLs, the key has been the same for years, and provides access to Maps and Keep. Same with YouTube (the app packages an API key for the v3 data API) or the WolframAlpha app. Many more apps, from simple "what’s for lunch at my uni’s cafeteria" to Transit apps all leak API keys. Preferably you use the key of an app from the same company which maintains the API, so you can guarantee to always find a recent one.
I spent a few weeks last summer extracting API keys for next to all services out of apps, and breaking some DRM solutions, just to get experience with reversing software (which was something I had a course about at uni at the same time, and the experience helped me with homework).
Obviously, Google and others who have innovated in the space can set the terms of service as onerous or ambiguous as they want to. You can choose whether or not you want to invest in building something around someone else's products.
Don't like the TOS? Develop it yourself or use another product.
See Feist v. Rural Telephone for more on this. The only reason application of Feist is generally limited in cases of online access is because we have a theory that accessing a publicly available database containing phone numbers is akin to accessing someone else's private property, and therefore they can dictate whatever they want under theories like trespass to chattels, whereas consulting a printed telephone book in your home is decidely not accessing the phone company's property.
This is a pernicious, subtle issue now that we're becoming so dependent on online access provided by someone else's servers instead of accessing printed documents that we possess in our homes. Possession is 9/10 of the law, as they say. We need to rethink how "possession" applies to digital resources.
Likewise, there are laws around how much access a private property owner must grant to members of the public, especially if that property owner is running a business that is generally accessible to the public. Private property owners are allowed to declare some people trespassers, but each jurisdiction has different laws surrounding what the public can do on private property and when a trespass is allowable. For example, California's state constitution guarantees the right to hold reasonable protests in private shopping centers that are generally accessible to the public, whether the property owner likes it or not.
No one is saying there is a requirement for another business "to help invest" in any other; there may be requirements not to interfere with someone else's business by attempting to block what is otherwise public and freely available access to non-copyrightable information.
IANAL.
Routebuilder is fortunate that OpenStreetMap has collected much of the same data and that they can just code against a different API and continue to operate.
Mapping data is not "non-copyrightable information".
Open-source projects have a history of being hyper-sensitive to these concerns so that they never have to waste time with lawyers lobbing IP claims. A certain distribution derived from the sources released by a prominent North American enterprise Linux vendor comes to mind, as does WINE's refusal to accept any code from anyone who has any relationship with or connection to Microsoft whatsoever.
OpenStreetMap needs to be useful for everyone, not just people in jurisdictions with more liberal copyright laws.
How could a project like OSM make sure that it didn't happen on a large, clearly violating scale (because many people make copies of small parts, recreating the larger, protected work), especially if it isn't established what an internationally safe standard is.
In practice, you are right, you can copy a single street from google maps to OSM. I bet some mappers in the history of OSM have traced screenshots of google maps or something. But that is only safe because it can't be proven, unless you are unlucky enough to copy a canary.
As far as I know, Google Maps is protected from scripts copying the data points out only by its Terms of Use, which the CFAA basically eval()s into law.
Google Maps won't disappear overnight because they do provide a substantial amount of beneficial proprietary data, like the illustrations and private aerial/satellite imagery (imagery from sources like NASA is public domain), their scripts that allow easy embedding, the ability to connect to one's Google account, and so forth. But there is no legal protection of the raw data points used to build Google Maps as far as I know.
Let me reiterate that I'm not a lawyer and no one should do anything based on my posts.
https://en.wikipedia.org/wiki/Database_Directive
http://ec.europa.eu/internal_market/copyright/prot-databases...
This has been shown viable time and again, with App Store rejections and the like. It is obviously high-risk but sometimes worthwhile.
They aren't, but most businesses are regulated to prevent them from screwing your business.
If were renting a property for my burger stand a fast food giant could not buy the property and evict me without notice.
Common carriers from shippers to telecoms are regulated. Banks and lending are regulated too. Many businesses are regulated. Sure it slows things down, but it also creates stability.
I do not know what fair API use looks like, but some kind of regulation seems likely. Likely the kind of thing in the article will fall into grey areas.
The simple reality is that Google can control in any way shape or form how their API is consumed. Like I said, if you don't like that, don't build your business on the API. You do not have a right to anyone's API, regardless of how important the data is to your pet project or unicorn idea.
This same argument comes up when the Twitter API consumers get all up in arms because the business they built solely on top of Twitter's platform is all the sudden deemed irrelevant because of API access changes or terms of service changes. Tough tootles! And guess what, your API scraping twitter feed re-display iOS app is not innovation!
I personally think that "free APIs" are great, but if you don't have it in your business plan to share a portion of your revenue with external API data providers when they eventually ask, then you are going to get yourself in the position that the OP did.
Why not ? Plenty of financial APIs are regulated (and beyond horrible). The government has decided that anyone with a banking license and a certain amount of money stored at the central bank can use them. And God help you if you try to use the international APIs, they are so incredibly incredibly horrible.
Without this plenty of financial services wouldn't exist, no way would smaller banks be able to operate. Despite how badly designed it all is, without a doubt it is a very good thing that these APIs exist and are regulated.
Maybe regulation of APIs is exactly what we need. Hell, maybe we can even learn from the mistakes in financial APIs first and then regulate these APIs.
> if you don't like that, don't build your business on the API.
Are an impediment to progress when applied unilaterally as you are doing.
This simply cannot be stressed enough.
No one's worried about assembly code for Intel chips, but the next generation could be locked down.
No one's worried about writing C++ for Windows, but technically you're using their APIs and hooks that could be dropped in the next release.
There's iOS, where you're also subject to review and approval.
There's well-known web joints like Google, where this can happen.
Then there's the fly-by-night shops that could just dissolve tomorrow.
The safest thing is to build your own computer from silicon, write your own OS, your own compilers, your own languages, your own software, and your own APIs. Of course, by the time you do that, we'll all be dead. So it's a balancing act. But it's worth illustrating that you're taking for granted that things will remain the same forever, when in reality there's a sliding scale of risk.
Your post also seems to assume that everyone will upgrade to the "next release". On platforms where you get to control your upgrade cycle, people won't upgrade if the upgrade breaks the programs they want to use, and this acts as a check on gratuitous API/ABI breakage.
Microsoft takes this extremely seriously and has hardly any API breakage over the last 20 years because they know that there's a real threat that a competitor could emerge with WINE pre-bundled and take away some market share if they break a lot of programs.
Well, Valve was, justified, worried about that, and built SteamOS.
My shareware Snood clone company is not very worried about Microsoft changing the Windows API, but I'm sure with every release major Windows software suppliers, particularly those reliant on a certain niche feature, certainly are.