You may choose to depend on a vendor to an extent, but structure your application in a way that a sudden change in the rules would not be the end of you; e.g., there is more than one cloud provider on which one can use the same Docker images to deploy an application. And you may choose a business where there are no options _other_ than to depend on a third party; e.g., you wish to sell a native iOS application to iPhone users.

Risk is still risk: a potential pitfall or peril. Sometimes the risk is great enough, compared with the potential return, that the only way to win is not to play. Regardless, this article discusses a set of risks which exist now more then ever; to enumerate and understand these risks is not outdated thinking, it's just good business.

This applies to so many things involving computers, and of course most aspects of modern life.

Back in the good (bad?) old days there were no such things as "personal" computers. We created our programs on punched cards and trudged down to the computer center to run them.

And that, to me, was what I hated the most about the computers of the time. I was dependent on the good graces of the University to get a few precious minutes of computer time to use to run my programs.

So, when the first usable PCs were invented, people flocked to them. 8K bytes of RAM meant you could run a BASIC interpreter on your own computer. Once you bought it, you could use it as much as you wanted to, for any reason that you wanted to. Period.

It's unfortunate that so much of modern computer life once again depends on the good graces of others.

I like native apps mostly for their speed, but unless you're doing something requiring a sensor on the phone, mobile web can do it all.

That's still sharecropping.

The use of the term in this context is calling out the specific vulnerability of using the walled gardens of Facebook/Google/Apple and the other behemoths. By your literal correctness of the term, there is no possible way to operate on the internet, since you don't own the land and the network cables from your servers to the clients.

Pulling one's head away from their rear end provides the vision that relying on specific vendor platforms, with their own goals and interests sometimes counter to yours, is different from using a colocation for servers.

But here's a potential solution: since API clients are essentially renting the vendor's platform and launching businesses based on this, there needs to be some legally-enforced stability. I would like to see something like a landlord-tenant relationship. Both parties have responsibilities and expectations and the lease can't break the fundamental rules in the law, which usually includes mandatory notice periods to terminate tenancy if a tenant is month-to-month, a prescription for informing the landlord of maintenance issues and giving him time to repair, a legally protected remedy if the landlord fails to repair something that he's legally obligated to maintain (like withholding rent), and finally, an eviction process that the landlord can use to force the tenant out of the property when he's been found in violation of the lease.

I think this sort of relationship should exist at a minimum. It would make it so Google et al couldn't just kick you off whenever they got bored and decided your product was cool and they didn't have anything to do with their 20% time so they're gonna clone it, they could only cut you off at the conclusion of your contract. If there's a legitimate reason to kick someone off the API before this time, they can take it to an API tenancy court and get the judge to sign off on the access key's eviction (which should be thousands of times more practical for both parties than the current route, which is a CFAA lawsuit).

The ability to "buy land" on the platform and own an API key that can't be deprived from you would be interesting too, but I'm not sure on the details of how that would work right now.

Except when a tenant is kicked out of their apartment with no notice, they might literally die. When Routebuilder gets shut down (with at least 2 weeks notice if not more, according to the article), someone organizing a marathon might... have to use a different, also free service?

And let's not forget that Google is a private enterprise offering an absolutely insane amount of data and access for free. The bar for "legitimate reason" to revoke API access is (and should be) legally no higher than "Google wants to." They actually go quite a bit above and beyond by having Terms that you can read and that as far as I can tell they abide by.

The owner of Routebuilder loses income, gets evicted, and might literally die.

The impact might be small on Routebuilder's end users but destroying someone's business is destroying someone's business even if their business value was trivial.

I don't mean to equate becoming homeless with getting your business wrecked (though they're often connected), but I don't think there's an argument that something has to literally make someone homeless before it can be regulated. Stable business relationships are important.

>The bar for "legitimate reason" to revoke API access is (and should be) legally no higher than "Google wants to."

This would still be open to them in a lease situation; it would simply have to be planned and occur according to at least the law's minimum notice periods.

If some jackass took the display down, an auditor would find it and we would get sued. The customer had recourse.

The part of Google that uses the services provided by the Maps provider would have to play by the same terms as any competitor.

Most tenancies are also dictated by a separate legally binding contract (the "lease"). The reason the law addresses tenancy separately, even though most landlords and tenants sign leases, is so that there's a baseline if no contract is provided or if the contract is unconscionable. The law also provides a custom-tailored process to address issues of non-compliance with that type of contract (eviction) instead of sending it through conventional civil court, which wouldn't resolve that type of issue efficiently.

These custom-built paths in law are useful. We have these to make sure things are as fair as possible for all involved parties in common arrangements, because just falling back on hastily-written contracts isn't always the ideal solution. API tenancy is becoming a common arrangement.

Maybe it's too specific though, you could be right about that. Maybe there's a more abstract level at which we can conceptualize digital property rights that would solve API tenancy issues as well as other digital issues.

If state sets onerous reqirements on API, most companies will just stop provide it for free or at all. Why do you want to commit long term resources to something that does not make you any money and sets you up for legal problems if you want to make changes?

Is it possible possible that the increase stability of those APIs still offered would be more valuable than the less stable but more numerous API environment we have now?

If somebody attempts to prevent you from storing things as such, say through propaganda about imaginary property or post-hoc "TOS" enforcement, they're not going to be friendly to any definition of property that gives you power. So it makes sense to go with the definition that's directly enforceable.