Google is Forcing Routebuilder to Shut Down(medium.com)
medium.com
Google is Forcing Routebuilder to Shut Down
https://medium.com/@andrewcmartin/google-maps-is-forcing-routebuilder-to-shutdown-615ce42f413a
195 comments
Hahaha. We have been through this with AdSense. Without the negative PR Google would have never replied. This is also a good lesson for the aspiring Play Store Android developers.
An oldie but a goodie:
Are You a Sharecropper? If you’re developing software for the Windows platform, yes. Or for the Apple platform, or the Oracle platform, or the SAP platform, or, well, any platform that is owned and operated by a company. They own the ground you’re building on, and if they decide they don’t like you, or they can do something better with the ground, you’re toast. They can ship their own product and give it away till you go bust, then start charging for it; and use secret APIs you can’t see; and they can break the published APIs you use. All of these things have historically been done by platform vendors.
https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePl...
Are You a Sharecropper? If you’re developing software for the Windows platform, yes. Or for the Apple platform, or the Oracle platform, or the SAP platform, or, well, any platform that is owned and operated by a company. They own the ground you’re building on, and if they decide they don’t like you, or they can do something better with the ground, you’re toast. They can ship their own product and give it away till you go bust, then start charging for it; and use secret APIs you can’t see; and they can break the published APIs you use. All of these things have historically been done by platform vendors.
https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePl...
The issue that this application, for example, wouldn't exist at all if it couldn't rely on Google's services. (Unlike, say, most Facebook games). So the option is either build nothing or build something and risk it being taken away.
What specifically does the OSM platform and related projects lack that it requires? I mean, yes: Google Maps is the premier consumer mapping service out there, but it's not like the market is completely unserved by free alternatives.
The app was written a decade ago; likely there wasn't any available APIs the OP could have used (or he may not have been aware of them if they existed). Now he doesn't have time to transition to a new set of APIs.
Yeah plenty of alternatives now but does it really matter in this situation? Not really in my opinion.
Yeah plenty of alternatives now but does it really matter in this situation? Not really in my opinion.
So what's the issue here? Apps do not continue to exist in perpetuity without maintenance. If he can't afford the maintenance cost (understandable) then the app is going to eventually stop working anyways.
> So what's the issue here
OP wants a violation exception? Hardly seems like a worthwhile enough service though at least in my opinion.
> Apps do not continue to exist in perpetuity without maintenance. If he can't afford the maintenance cost (understandable) then the app is going to eventually stop working anyways.
Not really. If the API version he's using doesn't stop working there is no real reason why it couldn't just continue to work for a very long time (maybe even forever depending on how browsers evolve). It's not like software just randomly stops working forever after a certain period...well maybe in 2038 but in general simple applications (like this one) are not a big deal to keep up and running for seemingly forever.
OP wants a violation exception? Hardly seems like a worthwhile enough service though at least in my opinion.
> Apps do not continue to exist in perpetuity without maintenance. If he can't afford the maintenance cost (understandable) then the app is going to eventually stop working anyways.
Not really. If the API version he's using doesn't stop working there is no real reason why it couldn't just continue to work for a very long time (maybe even forever depending on how browsers evolve). It's not like software just randomly stops working forever after a certain period...well maybe in 2038 but in general simple applications (like this one) are not a big deal to keep up and running for seemingly forever.
10 years is a pretty good run for software with external dependencies. Eventually something will change from beneath you, that's the rule of software.
I have a dozen or so websites currently running on a Raspberry Pi that I got during one of those "free rpi colocation" promotions that were around when it first came out. Now the host has decided they can't afford the free colocation any more. So I have to find those websites a new home, even though most of them are not actively developed. That's software, there's always maintenance.
I have a dozen or so websites currently running on a Raspberry Pi that I got during one of those "free rpi colocation" promotions that were around when it first came out. Now the host has decided they can't afford the free colocation any more. So I have to find those websites a new home, even though most of them are not actively developed. That's software, there's always maintenance.
> If the API version he's using doesn't stop working there is no real reason why it couldn't just continue to work for a very long time
That's sort of insane. We aren't talking about a static library here. Of all the public web APIs available in 2007, how many are still alive? Maybe 5%? Less? Google Maps is one of a tiny, tiny set of still-relevant products that still support their decade-old interface.
And don't get me wrong: it's a great product. But getting back to the discussion, it's a proprietary product, and anything built on it needs to be aware of the inherent business risk if, some time over the next decade, the API provider decides to terminate support. They did.
That's sort of insane. We aren't talking about a static library here. Of all the public web APIs available in 2007, how many are still alive? Maybe 5%? Less? Google Maps is one of a tiny, tiny set of still-relevant products that still support their decade-old interface.
And don't get me wrong: it's a great product. But getting back to the discussion, it's a proprietary product, and anything built on it needs to be aware of the inherent business risk if, some time over the next decade, the API provider decides to terminate support. They did.
> That's sort of insane. We aren't talking about a static library here. Of all the public web APIs available in 2007, how many are still alive? Maybe 5%? Less? Google Maps is one of a tiny, tiny set of still-relevant products that still support their decade-old interface.
You never stated you were referring to ONLY public web apis. In fact you simply said "Apps". But even if you really meant only public web apis there is precedent (Google's many APIs) where APIs will continue years and sometimes even decades. Is it unlikely? Probably, depending on what you're doing, but certainly not impossible nor "insane".
As a software developer who's seen web apps function for a decade + with little to no changes (one of which actually did rely on a third party API) I fail to see how anything I stated was "insane". Not everything has to have major breakages every 6 months.
You never stated you were referring to ONLY public web apis. In fact you simply said "Apps". But even if you really meant only public web apis there is precedent (Google's many APIs) where APIs will continue years and sometimes even decades. Is it unlikely? Probably, depending on what you're doing, but certainly not impossible nor "insane".
As a software developer who's seen web apps function for a decade + with little to no changes (one of which actually did rely on a third party API) I fail to see how anything I stated was "insane". Not everything has to have major breakages every 6 months.
Your comment didn't argue against anything the parent said. What exactly is "insane"?
Too bad that's a very outdated way of thinking. Today there is just no getting around "Sharecropping". If you want your app in front of actual people you're going to use a platform owned by Google, Apple, Microsoft or Blackberry. Sure the web is still a place where you're not really a "Sharecropper" but compared to native solutions the web doesn't give you everything you need for a fully integrated and awesome user experience.
As much as I'd love for this to not be true it is and there isn't a way around it. Even if you used an abstraction so you never technically write code specific to Apple, Google, etc in the end it's still going to be deployed to their platforms via their stores. Unless, of course, your market is strictly the tiny niche of jailbreaks / manual installers of software.
As much as I'd love for this to not be true it is and there isn't a way around it. Even if you used an abstraction so you never technically write code specific to Apple, Google, etc in the end it's still going to be deployed to their platforms via their stores. Unless, of course, your market is strictly the tiny niche of jailbreaks / manual installers of software.
It is not outdated, but _prescient_. Any third party (company, or otherwise) that you depend on for your business can elect to make your life more difficult (or nigh on impossible) at any time.
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.
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.
Any third party (company, or otherwise) that you depend on for your business can elect to make your life more difficult (or nigh on impossible) at any time.
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.
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.
Colo your hardware, run open source software, and don't tie in to external services. Most mobile apps can be mobile-web optimized, as a fallback if App stores shut you out.
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.
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.
...except get discovered by customers who look to the app store for trust.
I guess I'm in the minority, but I don't trust jack from the Android store unless I already know the vendor.
Really? If you don't trust app stores and you end up with malware on your phone, how do you expect to be able to write an incredulous blog post?
> Colo your hardware
That's still sharecropping.
That's still sharecropping.
Not quite. You can just move your hardware if something goes south. There is no proprietary magic sauce you are depending on from the colo. That's similar to saying everyone that uses electricity from the grid is sharecropping.
Sharecropping literally means farming on someone's land and paying rent.
HN's famous pedantry shines again.
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.
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.
We need to rethink how we assign the intangible digital "property" that is intrinsic to the Information Age. Little guys are getting raked over the coals by the incumbents because our legal system is not equipped to handle these issues fairly.
How would you suggest it be handled in this case? Does the author have a right to access to the Google Maps API even if Google itself offers a similar product? He admits in the article that his product is basically a wrapper for a more full-featured Google alternative.
My opinion on this is still very much in development, so I don't suggest that this is the only right answer.
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.
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.
> 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.
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.
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.
>Except when a tenant is kicked out of their apartment with no notice, they might literally die. When Routebuilder gets shut down ...
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.
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.
>Except when a tenant is kicked out of their apartment with no notice, they might literally die.
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.
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.
That's a little dramatic. Change the example of an apartment eviction is too distracting -- when I worked retail, vendors would lease end end caps.
If some jackass took the display down, an auditor would find it and we would get sued. The customer had recourse.
If some jackass took the display down, an auditor would find it and we would get sued. The customer had recourse.
They're paying for the end caps. Routebuilder isn't paying for the Maps API.
A good legal situation might be separating the part of Google that provides services from the part that uses them.
The part of Google that uses the services provided by the Maps provider would have to play by the same terms as any competitor.
The part of Google that uses the services provided by the Maps provider would have to play by the same terms as any competitor.
It's called signing legally binding contract on using API between Google and Routebuilder with costs, availability and interface specified. Contracts like this are getting signed all the time - for well known examples look at Microsoft/Bing providing search results to Yahoo and Stripe providing CC processing to Starbucks. You do not need a new law for that.
Yeah, if you have enough clout to get Google or any other API vendor to care and make a special contract for you, then great.
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.
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.
I think API access is closer to commercial lease than residential ones. Commercial leases are way less regulated than residential ones - generally it's expected that if you sign commercial lease, you know what you are doing.
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?
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?
I disagree with you that fewer APIs would be offered, but for argument let's run with that.
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?
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?
Exactly, right now, the closest to a contract we have is the Terms of Service. And the ToS is, by design, entirely in the provider's favor (whoever it is) and not in yours. And there's no possibility to negotiate.
Bringing the concept into the digital realm is quite simple. If you have physical possession of the data, then it's your "property". Kind of like regular property. Disk is cheap and data can be mirrored easily, so it's never necessary to rent your digital "primary residence" or "business headquarters".
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.
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.
If this is the case, then that's just sad. What have we done to ourselves?????
it doesn't seem all that different from being an employee
How does sharecropping sound compared to working for free on an opensource project controlled by a large corporation?
How exactly would an open source project be controlled by a large corporation? The furthest they could go is a CLA, and even that wouldn't prevent forking.
They could be controlled in the sense that they control what patches go into the code base like with Android.
Sure, you can always fork the project and make your own, but I'd argue the project is controlled by the corporation.
Sure, you can always fork the project and make your own, but I'd argue the project is controlled by the corporation.
Imagine Android, but with Google using its position to set the direction based on its business interests instead of in full collaboration with the open source community.
That's exactly what Google does... In fact, they don't even develop publicly. They push new releases out to open source after a big fanfare announcement of everything they developed behind closed doors. Hardly open source, and primarily directed by Google's business interests.
Does this apply to Android App development? This is scary.
Android developers (iOS developers too) are randomly and arbitrarily purged from the Play Store (and Apple App Store, respectively) with reckless abandon. Even though sideloading is a thing on Android, if Google bans you, you're basically put out of business. There are literally dozens of these cases you can find on the Internet.
Google often does this with no warning, and no real process for appeal unless an Android blog like Android Police decides to write an article about it. Bad press is basically the only way to appeal.
Google often does this with no warning, and no real process for appeal unless an Android blog like Android Police decides to write an article about it. Bad press is basically the only way to appeal.
[deleted]
Just because Routebuilder was never called out for violating the ToS doesn't mean it wasn't. Nor is there a "statute of limitations" for violations. What's even more insidious is that the "duplicating GM functionality" is a) vague and b) a moving target. Just because Routebuilder wasn't violating a decade ago doesn't mean it's not violating now.
This is the risk you take building something on top of an API—access can be cut off at any time.
This is the risk you take building something on top of an API—access can be cut off at any time.
i think the point of the article, or at least our interest in it, is that this is a terrible business arrangement. if you can't look at past tolerance as evidence of acceptable use, then you effectively can't ever afford to invest in building a business unless you're lawyered-up
and that's bad for tech, and bad for america
and that's bad for tech, and bad for america
Why is any other business obligated to help you invest in building your own business?
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.
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.
> Why is any other business obligated to help you invest in building your own business?
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.
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.
Sorry, but if we just look at the Google Maps API as an example, it would be a HUGE stretch to consider them a common carrier. The mapping data industry has huge competition right now. We're not even in the same realm of consideration for "regulation" of an API. That is ridiculous.
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.
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.
> We're not even in the same realm of consideration for "regulation" of an API. That is ridiculous.
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.
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.
Attitudes like:
> 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.
> 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.
The grandparent was saying why Google should be less ambiguous: because more people will build on top of their apis if the legal situation is predictable. The comment was written from the point of view that Google is setting up bad incentives if they want developers to use their apis, not that developers have a moral right to Google being reasonable.
There is a bunch of laws that govern what someone who has innovated, developed, and authored can and can't dictate; they're called "intellectual property laws". Even if they've collected it, Google does not own information about the road system; facts themselves, like "Road A exists at lat X and long Z", cannot be copyrighted.
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.
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.
by attempting to block what is otherwise public and freely available access to non-copyrightable information.
Mapping data is not "non-copyrightable information".
Mapping data is not "non-copyrightable information".
"Mapping data" is too broad of a term, because it probably includes a lot of copyrightable information. However, the factual basics, like GPS coords, are not copyrightable.
An individual data point maybe not, but even something like "there is a road between X1,Y1 and X2,Y2" you can't just extract from Google Maps and put in OSM, at least not multiple times. There are surprisingly few generally usable data sources (some government datasets that have been put under open licenses, Microsofts permits to use Bing's aerial photography as a basis for OSM, ...)
The answer is: it's very complex and subtle, and it varies by country. OSM'ers have been all through this is this is what brought about the ODBL.
I'm not sure if OSM really needs to be as cautious as they are. I don't see how you could argue that "Main St begins at X1, Y1" and "Main St end at X2,Y2" is a single copyrightable work instead of 2 separate non-copyrightable facts. The sentence or package which contains these two separate data points may be a unique work that qualifies for copyright protection, but the raw data points aren't once you separate them out.
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.
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.
Google has clear TOS that disallow copying data so it isn't just about copyright, and EU database rules are anyway a much bigger concern than US copyright law.
OpenStreetMap needs to be useful for everyone, not just people in jurisdictions with more liberal copyright laws.
OpenStreetMap needs to be useful for everyone, not just people in jurisdictions with more liberal copyright laws.
But you can't really separate these datapoints, at least not in a legally safe manner. If you take a "work", reduce it down to the basic data it probably was created from and rebuild a basically identical work, how do you defend against the claim that you copied it? You could try to go through multiple steps, done by different entities, and hope to hide that way, but coordinating that makes you vulnerable again.
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.
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.
If all you have is a compilation of facts, then yes, people can copy the data points one by one, alter the format slightly, and have a wholly separate work that has no legally recognized parentage. This is why you don't see a lot of plain collections of facts for sale.
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.
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.
No protection for compilations of facts is not the case everywhere.
https://en.wikipedia.org/wiki/Database_Directive
http://ec.europa.eu/internal_market/copyright/prot-databases...
https://en.wikipedia.org/wiki/Database_Directive
http://ec.europa.eu/internal_market/copyright/prot-databases...
You seem to say those are the only two options. There's clearly a third one: use the API and, if they suddenly enforce the excessively onerous terms, go public in an effort to make them back down from public pressure.
This has been shown viable time and again, with App Store rejections and the like. It is obviously high-risk but sometimes worthwhile.
This has been shown viable time and again, with App Store rejections and the like. It is obviously high-risk but sometimes worthwhile.
Yes. The current legal situation with access to online resources is an absolute, unmitigated disaster.
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.
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.
Scraped content is one thing, but most APIs require a unique key. Forget "trying to get to you": they already know everything they need to know to cut off your API access.
Break their mobile apps. Use their own API key against them. Also break their websites.
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).
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).
A rotating schema of pirated API keys seems even less sustainable than just risking use of a proprietary API. Not something on which I'd want to build a business either. At some point, the effort of reverse engineering exceeds that of actually building the damn thing for yourself.
The reverse engineering can be automated (as the official apps have to use the key at some point), and as the official app won’t get cut off from support, you can just continue using the latest version of it.
Yeah, but you can usually acquire an network of API keys without making the connection obvious (depends on their API access policies of course) and rotate them as appropriate. Also, many APIs offer the same data through a public interface that can be accessed by scraping, so you can scrape and avoid identifying yourself.
My advice is: Obey robots.txt and provide a real user agent. End of story. Seriously.
This is a little paranoid if you're at least trying to stay within the TOS and not overtly get in a fight with the big entity whose API you're using.
(And having the LLC gives you great protection against lawsuits!)
(And having the LLC gives you great protection against lawsuits!)
LLCs do not protect against tort liability. They'll pierce the veil. See Facebook v. Power Ventures, Inc., where the founder was found personally liable for 3 million dollars in damages despite the fact that he was a) accessing Facebook on a specific user's behalf at their request and therefore was essentially a browsing device and b) was not violating copyright by any reasonable standard (Ticketmaster v. RMG is not reasonable) since the content he was downloading was owned by the user requesting the download.
>> This is the risk you take building something on top of an API—access can be cut off at any time.
This simply cannot be stressed enough.
This simply cannot be stressed enough.
It's worth expanding that this is a very broad spectrum of software.
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.
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.
Free software ameliorates this problem. The code is free to live on independent of its authors or parent organization. Sun may or may not have killed its business by making all of its software open and free, but the community benefited from that immensely when Oracle took over. We don't have to start from scratch, just have to use free software.
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.
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.
I think this shows when you should be particularly worried about vendor (supplier?) lock-in: if it would hurt you more than it would others, including the vendor.
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.
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.
> 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.
Well, Valve was, justified, worried about that, and built SteamOS.
Well, Valve was, justified, worried about that, and built SteamOS.
I wrote this 1689 days ago: "Why should anyone ever use a Google API ever again?" http://googlecode.blogspot.co.at/2011/05/spring-cleaning-for...
Still true.
HN discussion: https://news.ycombinator.com/item?id=2592399
HN discussion: https://news.ycombinator.com/item?id=2592399
Why should anyone ever use a Google API ever again?
Because you get a free high quality Maps API to use for a decade? What else would you have used in 2006?
Because you get a free high quality Maps API to use for a decade? What else would you have used in 2006?
Back in 2006 a bunch of us were building OSM precisely so this wouldn't be a problem in the future. But I take your point.
Because your options are usually:
1. Try to do it yourself or find another service, which will usually result in much higher cost and a worse implementation, or 2. Use the Google API, with the cost of lock-in.
I think the best solution is to always wrap the Google API with a generic facade, so if you do have to replace the API with something down the line it is at least possible. There are some APIs out there that already do this (e.g. http://mapstraction.com/ )
1. Try to do it yourself or find another service, which will usually result in much higher cost and a worse implementation, or 2. Use the Google API, with the cost of lock-in.
I think the best solution is to always wrap the Google API with a generic facade, so if you do have to replace the API with something down the line it is at least possible. There are some APIs out there that already do this (e.g. http://mapstraction.com/ )
Well, as long as people do #2, no competitors can do #1.
The best option would be for Google to get no business anymore, and for people to rely on, preferably open, competitors.
Google’s business isn’t built upon providing data.
Almost everything Google does is forcing people to enter data for them, or scraping other people’s data, and then using that for profit.
From ReCaptcha to MapMaker, from the Knowledge Graph to their new imache captchas.
(IMHO, user-generated data like training data for neural networks, OCR data, or geodata, should be illegal to use for profit under proprietary licenses, with no opt-out. If you want to use data generated by users, you should have to provide it under a copyleft license. For free. Otherwise we have another Antitrust situation, like here.)
The best option would be for Google to get no business anymore, and for people to rely on, preferably open, competitors.
Google’s business isn’t built upon providing data.
Almost everything Google does is forcing people to enter data for them, or scraping other people’s data, and then using that for profit.
From ReCaptcha to MapMaker, from the Knowledge Graph to their new imache captchas.
(IMHO, user-generated data like training data for neural networks, OCR data, or geodata, should be illegal to use for profit under proprietary licenses, with no opt-out. If you want to use data generated by users, you should have to provide it under a copyleft license. For free. Otherwise we have another Antitrust situation, like here.)
How do you balance your suggestion of requiring user data be shared with maintaining user privacy?
The idea is that any user supplied data has to be separated into two groups: Privacy relevant information, which has to be stored encrypted, and can not be used for advertising, for training models, etc – like communications, private messages, email, etc.
And into user-supplied not-privacy-relevant data. The results of users filling out captchas, classifying info for training of neural networks, the data from Google’s MapMaker, etc.
In the case where these two sets of data overlap, privacy is more important, but on request, the company has to hand out every data you ever gave them in a machine-readable format. So if you decide to leave facebook, they have to give you a .zip with your photos, your posts as xml, etc.
And into user-supplied not-privacy-relevant data. The results of users filling out captchas, classifying info for training of neural networks, the data from Google’s MapMaker, etc.
In the case where these two sets of data overlap, privacy is more important, but on request, the company has to hand out every data you ever gave them in a machine-readable format. So if you decide to leave facebook, they have to give you a .zip with your photos, your posts as xml, etc.
The problem is there is a lot of gray area. In fact I think there is probably more utility in spelling out the cases where privacy is not a concern. Captcha is a good, specific example. However releasing that training data would break the system for everyone. What are some others? Is Google takeout up to par with what you're suggesting?
Google takeout is not nearly good enough, but an acceptable first step.
For captcha, the system has been broken for a long time. Specifically, you can outsource captcha solving to people in third world countries for tenthousands of captchas per dollar.
For captcha, the system has been broken for a long time. Specifically, you can outsource captcha solving to people in third world countries for tenthousands of captchas per dollar.
> For free. Otherwise we have another Antitrust situation, like here.)
Which anti trust situation?
Which anti trust situation?
There is a good reason why everyone here on HN considers any startup that might potentially compete with Google dead in the water – or, when Google starts a product, any companies that operated in that business previously are seen as dead.
Google uses predatory pricing (financed by having all parts of their company make losses except for a select few), Google uses their market might in one business to create a monopoly in others, like every time you searched with Firefox you used to get a banner ad "upgrade now to chrome". The cases where Google was literally scraping content from competitors and displayed it without a link back – the current Antitrust trial with Yelp!, where Google scraped reviews, and displayed them in Google places comes to mind. (And when Yelp! complained, Google threatened to throw them out of the results)
And yes, Google’s Maps API is another such situation. Maps is installed by default on all Android devices, giving it a huge boost for apps embedding it. Google Maps is making losses everywhere, breaking laws (see StreetView) and is still running.
At this point everyone still using Maps should switch to competitors, because otherwise we’ll get a situation where Maps becomes again a monopoly.
Google’s long-term strategy seems to be "get a monopoly for everything".
Every monopoly is an Antitrust situation, and Maps is steering right into one.
Google uses predatory pricing (financed by having all parts of their company make losses except for a select few), Google uses their market might in one business to create a monopoly in others, like every time you searched with Firefox you used to get a banner ad "upgrade now to chrome". The cases where Google was literally scraping content from competitors and displayed it without a link back – the current Antitrust trial with Yelp!, where Google scraped reviews, and displayed them in Google places comes to mind. (And when Yelp! complained, Google threatened to throw them out of the results)
And yes, Google’s Maps API is another such situation. Maps is installed by default on all Android devices, giving it a huge boost for apps embedding it. Google Maps is making losses everywhere, breaking laws (see StreetView) and is still running.
At this point everyone still using Maps should switch to competitors, because otherwise we’ll get a situation where Maps becomes again a monopoly.
Google’s long-term strategy seems to be "get a monopoly for everything".
Every monopoly is an Antitrust situation, and Maps is steering right into one.
> There is a good reason why everyone here on HN considers any startup that might potentially compete with Google dead in the water
It is good that you have asked EVERYONE in HN and you KNOW as a fact that everyone thinks the same you think
> Google uses predatory pricing So you can link to any ruling stating that Google uses predatory pricinc, thing that it is ilegal. Because you can prove it and it is not just your subjective opinion
> the current Antitrust trial with Yelp!, where Google scraped reviews, and displayed them in Google places comes to mind. (And when Yelp! complained, Google threatened to throw them out of the results
Which anti trust trial?
> very monopoly is an Antitrust situation,
No, it isn't
It is good that you have asked EVERYONE in HN and you KNOW as a fact that everyone thinks the same you think
> Google uses predatory pricing So you can link to any ruling stating that Google uses predatory pricinc, thing that it is ilegal. Because you can prove it and it is not just your subjective opinion
> the current Antitrust trial with Yelp!, where Google scraped reviews, and displayed them in Google places comes to mind. (And when Yelp! complained, Google threatened to throw them out of the results
Which anti trust trial?
> very monopoly is an Antitrust situation,
No, it isn't
> Which anti trust trial?
I guess you haven’t followed the news? the current EU antitrust trial against Google, which was started after dozens of US companies had complained about Google’s abuse of monopoly.
I guess you haven’t followed the news? the current EU antitrust trial against Google, which was started after dozens of US companies had complained about Google’s abuse of monopoly.
Oh, no, I have followed the news.
The only anti trust probe is the one regarding Google Shopping.
Can you link to any trial involving Yelp or other companies?
Perhaps the one that has to follow the news is you, not me. or perhaps you're mixing your desires with reality
The only anti trust probe is the one regarding Google Shopping.
Can you link to any trial involving Yelp or other companies?
Perhaps the one that has to follow the news is you, not me. or perhaps you're mixing your desires with reality
It's all well and good to say "never use a Google API again because they might eliminate for any reason at any time" but there might not be an alternative. It's hard to get the data. Concentration of data is made concentration of wealth through APIs (or, slightly more indirectly, through the apps that use the APIs, perhaps internally). No-one concentrates data more thoroughly than Google (it's hard to appreciate how much data Google has; it started with scraping the web, but now they have real-time data on millions of sites through analytics, pictures of streets, WiFi ssid against lat/lon, and of course detailed video-viewing habits).
The short-term consumer cycle is feeding a long-term data cycle that strongly favors consolidation. That's bad. Personally I think it's okay to "feed the beast" for a little while, but as soon as you get uptake and can afford the time you can and should stop feeding the beast.
The short-term consumer cycle is feeding a long-term data cycle that strongly favors consolidation. That's bad. Personally I think it's okay to "feed the beast" for a little while, but as soon as you get uptake and can afford the time you can and should stop feeding the beast.
What vendor's APIs would one use instead? Or does this just collapse down to "Don't use other company's APIs?"
Depends. If they are the only providers, you might want to avoid it. Take OSM - you could use the API with leaflet and their server, but if they can no longer afford the hosting costs and close the service, you could download a copy of the database yourself, and host your own copy.
As a rule of thumb, try to use something standardized, with more than one implementations.
As a rule of thumb, try to use something standardized, with more than one implementations.
That's a good policy (while noting the fact that setting the risk slider that conservative greatly curtails the software one is willing to create).
Well, that might be true. But if you base your whole project around somebodies service, and they change the ToS, or shut it down, what right do you have to complain? On the other hand, if you use GMaps only on the contact page - no big harm done. It's all about trade-offs.
The conservatives might want to contribute a little to a FOSS alternative, that might be of lower quality - and benefit all as a result. And cover all their bases as well.
The conservatives might want to contribute a little to a FOSS alternative, that might be of lower quality - and benefit all as a result. And cover all their bases as well.
It should be quite easy to port your app to use leaflet.js[1] and openstreetmap/mapbox.
[1] http://leafletjs.com/
[1] http://leafletjs.com/
I second this as a frequent user of leaflet and openstreatmap. I started using both about 2 years ago and it's remarkable how much progress has been made in such a short amount of time.
I agree, these are fantastic projects/technologies that offer even more configurability than the Google Maps API. Porting the central part of a large company may be a challenge though, since Google Maps is so integrated into the site.
I used to provide support on the Google Maps for Work API (any opinions are my own etc.)
My best guess is that because the site is offering very similar functionality to what is provided by the Google Maps API Drawing Tools [1] is the reason you've been flagged. The Elevation chart appears to be the same as the sample provided in the API documentation [2].
Yes, you offer additional functionality with the sharing of the routes and other features on the site. The flagging of sites for TOS violations can be a bit peculiar at times.
For reasons that I shouldn't get in to, I'd guess you won't much of a reply if you try and discuss this notice by replying via email. I'm not sure who the current Maps API Developer Relations contact is but they would be your best bet for any proper discussion.
[1] - https://developers.google.com/maps/documentation/javascript/... [2] -https://developers.google.com/maps/documentation/javascript/...
My best guess is that because the site is offering very similar functionality to what is provided by the Google Maps API Drawing Tools [1] is the reason you've been flagged. The Elevation chart appears to be the same as the sample provided in the API documentation [2].
Yes, you offer additional functionality with the sharing of the routes and other features on the site. The flagging of sites for TOS violations can be a bit peculiar at times.
For reasons that I shouldn't get in to, I'd guess you won't much of a reply if you try and discuss this notice by replying via email. I'm not sure who the current Maps API Developer Relations contact is but they would be your best bet for any proper discussion.
[1] - https://developers.google.com/maps/documentation/javascript/... [2] -https://developers.google.com/maps/documentation/javascript/...
"One option for me would be to rewrite routebuilder to run on another mapping platform, but with an infant at home and a full-time job, I frankly don’t have the time or energy."
- Open source it (with or without the wrapper to Google Maps).
- Open source it (with or without the wrapper to Google Maps).
Unfortunately I'd say the headline on the linked Medium.com post (by the creator of Routebuilder) is a bit misleading.
I feel for the author, but Google is not "forcing Routebuilder to shut down." Google is instead telling the owner of Routebuilder to find another API to use. Routebuilder can find another API, pay to license data, etc. There are alternatives rather than "shut[ing] down."
I know this probably sucks for the author, but this is the risk you take when building your product on top of someone else's API without a separate contract in hand--as many Twitter developers found out firsthand a few years ago. Their service, their rules.
I feel for the author, but Google is not "forcing Routebuilder to shut down." Google is instead telling the owner of Routebuilder to find another API to use. Routebuilder can find another API, pay to license data, etc. There are alternatives rather than "shut[ing] down."
I know this probably sucks for the author, but this is the risk you take when building your product on top of someone else's API without a separate contract in hand--as many Twitter developers found out firsthand a few years ago. Their service, their rules.
Isn't that a bit of a semantic nitpick? They're telling him to rework his site (or his business model) in fourteen days. Whether they have the right to treat developers on their platform like crud or not, it doesn't change the fact that he is effectively being shut down.
If you had a dog walking service with a route that crossed my property without permission, and after some time I asked you not to do so, you might write a blog post trumpeting: "Property owner is shutting me down." But others might disagree.
There may be ways to preserve the viability of your dog walking service. You can enter into an arrangement with me to use my property (which might include a nominal fee), you can take a different route (inconvenient for you and your customers, but not my problem), etc.
If the only way you can run your dog walking service is to take a shortcut across my property without my permission, well, then the world is sending you a message about the viability of your business.
Again, the mere fact that you and your dogs have grown accustomed to crossing my property does not mean I'm "shut[ing] you down." And next time, maybe you should secure written permission before starting a business based on the assumption that you'll have the right to use someone else's property forever without paying.
There may be ways to preserve the viability of your dog walking service. You can enter into an arrangement with me to use my property (which might include a nominal fee), you can take a different route (inconvenient for you and your customers, but not my problem), etc.
If the only way you can run your dog walking service is to take a shortcut across my property without my permission, well, then the world is sending you a message about the viability of your business.
Again, the mere fact that you and your dogs have grown accustomed to crossing my property does not mean I'm "shut[ing] you down." And next time, maybe you should secure written permission before starting a business based on the assumption that you'll have the right to use someone else's property forever without paying.
I definitely think we'd be in a much better place if people building on platforms had the ability to negotiate for some level of assurance of continuity. It's important for people to have confidence in the platforms they build on.
As an update, Google has backed down, and said they made an error, and they won't force RouteBuilder to shutter in the next two weeks. But it sounds like the developer has learned his lesson... as time permits, he's going to start working on moving to another platform.
As an update, Google has backed down, and said they made an error, and they won't force RouteBuilder to shutter in the next two weeks. But it sounds like the developer has learned his lesson... as time permits, he's going to start working on moving to another platform.
I don't think Google is in the wrong here:
If you have a route between two points 'white dots' appear in the route, then you can drag and drop those around to manually change the route, to share the URL you can either copy the url at the top bar or just click the 'share' option inside the hamburger menu, which gives you a minified link.
In the end, although it's an inferior(?) implementation, Google allows you to do the exact same thing. I think the ToS call mentioned is essentially appropriate.
Although it is a bit of a dick move, but in the end it is their api.
If you have a route between two points 'white dots' appear in the route, then you can drag and drop those around to manually change the route, to share the URL you can either copy the url at the top bar or just click the 'share' option inside the hamburger menu, which gives you a minified link.
In the end, although it's an inferior(?) implementation, Google allows you to do the exact same thing. I think the ToS call mentioned is essentially appropriate.
Although it is a bit of a dick move, but in the end it is their api.
It's a vastly inferior implementation. Despite what the screenshot in the post hints to, the actual implementation only lets users connect the pins by straight lines. It doesn't follow roads and it doesn't do navigation. The reason for that is explained in the FAQ.
So it's more or less what anybody would do on day 2 of learning the Google Maps API, plus the save routes (cough...) thing. With that I don't intend to show disrespect for the author, because it has been going on for 10 years with people using it. Much better than anything I built for myself. I'm surprised that Google is going after him. If that "re-implements or duplicates" anything that Google does then almost everybody should receive a letter like that.
My guess is that the usage counter for this site eventually reached some limit (10 years for that), a program noticed and the legal department sent a semi automatic mail without an assessment of the service. Still it's probably in their right to do so and it's another reason to use Open Street Map to build this kind of services. Example: http://cycle.travel/ which does real routing. Furthermore OSM has many offroad tracks and it could make happy the kind of people using routebuilder.
So it's more or less what anybody would do on day 2 of learning the Google Maps API, plus the save routes (cough...) thing. With that I don't intend to show disrespect for the author, because it has been going on for 10 years with people using it. Much better than anything I built for myself. I'm surprised that Google is going after him. If that "re-implements or duplicates" anything that Google does then almost everybody should receive a letter like that.
My guess is that the usage counter for this site eventually reached some limit (10 years for that), a program noticed and the legal department sent a semi automatic mail without an assessment of the service. Still it's probably in their right to do so and it's another reason to use Open Street Map to build this kind of services. Example: http://cycle.travel/ which does real routing. Furthermore OSM has many offroad tracks and it could make happy the kind of people using routebuilder.
The most interesting part about this story for me is that Google reached out to them and didn't simply ban them without a notice or explanation.
But it's completely unilateral. They're ignoring him otherwise.
OP said:
> I have tried emailing the Google Maps team to plead my case, but my correspondence went unanswered.
Where did they write?
How many times did they write?
How long ago did they write?
Did they try any other means of contact?
Did they try to go through, as only one example, linkedin and find someone that way (or any other way of researching a party that might be willing to help)?
It's unclear the effort that was put in here. Maybe it was maybe it wasn't. We don't have enough detail. Simply saying "my correspondance went unanswered" as much as we may think Google doesn't care doesn't prove that point.
I actually from time to time write to companies to try and sell them things. I put in effort and it appears that that greatly increases the chance that they will buy what I am trying to sell to them (meaning a decision maker not a clerk or the person who sorts thorough the spam). And email more than one time for that matter. And if it's really important try a phone call.
> I have tried emailing the Google Maps team to plead my case, but my correspondence went unanswered.
Where did they write?
How many times did they write?
How long ago did they write?
Did they try any other means of contact?
Did they try to go through, as only one example, linkedin and find someone that way (or any other way of researching a party that might be willing to help)?
It's unclear the effort that was put in here. Maybe it was maybe it wasn't. We don't have enough detail. Simply saying "my correspondance went unanswered" as much as we may think Google doesn't care doesn't prove that point.
I actually from time to time write to companies to try and sell them things. I put in effort and it appears that that greatly increases the chance that they will buy what I am trying to sell to them (meaning a decision maker not a clerk or the person who sorts thorough the spam). And email more than one time for that matter. And if it's really important try a phone call.
nathancahill(1)
open > proprietary: If you want routing (and elevation and a time-distance matrix) based on open data, via an API with liberal licensing, all based on open source code that you could run yourself if you wanted, you may want to take a look at Mapzen's Turn-by-Turn routing. We built it to get away from this kind of thing.
more here: https://mapzen.com/projects/valhalla docs: https://mapzen.com/documentation/turn-by-turn/ API: https://mapzen.com/developers/
more here: https://mapzen.com/projects/valhalla docs: https://mapzen.com/documentation/turn-by-turn/ API: https://mapzen.com/developers/
Mapzen seems like a good idea, but I can't help but wonder (with respect): Can a developer expect it to be here in 2026?
Seems like someone integrating against an API has the choice of "Use one from a big company with a proven business model and risk their TOS changing to have it taken away" vs. "Use one from a firm with only a few years of history and risk them going dark one day (or changing their TOS)."
In this specific scenario, I'm not sure that this solution would guarantee the developer could have avoided this failure mode.
Seems like someone integrating against an API has the choice of "Use one from a big company with a proven business model and risk their TOS changing to have it taken away" vs. "Use one from a firm with only a few years of history and risk them going dark one day (or changing their TOS)."
In this specific scenario, I'm not sure that this solution would guarantee the developer could have avoided this failure mode.
A great question. That's why we make all the underlying source code open, including chef and docker config info for people to build it themselves if they want or need to.
https://github.com/valhalla/
We at Mapzen are explicitly designing our projects to outlast us (if necessary).
https://mapzen.com/blog/our-magna-carto
https://github.com/valhalla/
We at Mapzen are explicitly designing our projects to outlast us (if necessary).
https://mapzen.com/blog/our-magna-carto
Id just like to say that I really like the design of your site, and logo in particular. Well done.
There's also: Project OSRM: https://www.project-osrm.org/
and GraphHopper https://graphhopper.com/
And for the UI, you can use https://github.com/perliedman/leaflet-routing-machine
all of which you can self-host using OpenstreetMap data.
and GraphHopper https://graphhopper.com/
And for the UI, you can use https://github.com/perliedman/leaflet-routing-machine
all of which you can self-host using OpenstreetMap data.
You're right, it's a bit of Catch-22. But the benefits of using the open approach though is that it helps promote them which could help get them marketshare/mindshare and help bring attention/support to them. At least that's what i'm hoping would be the case.
Don't trust for profit organizations. Google might project itself as champion of open source but the reality is their revenue, is a result of standing on open source. Without gnu and Linux they will not even exist.
When they needed google maps users they opened up. But given their profit motive they will have to shut down others which conflict with their profit.
Its better to port service to something open source, like openstreetmap. Google is turning into, do every evil to generate value for shareholders.
I think RMS fears of closed source js are true. It's like Windows Binary blobs.
I've tried using OpenStreetMap -- but it doesn't seem to know the names of places I go to, or sometimes even the area I'm in when I type certain city names.
maps.google.com works great though. I wish I wasn't supporting Google's massive operations but it is convenient to use.
maps.google.com works great though. I wish I wasn't supporting Google's massive operations but it is convenient to use.
Do you mean you're using the map on https://www.openstreetmap.org/ to search for things? This map isn't really meant to be searched, and the usability is generally terrible, I'm not sure why they keep it up on the website. Zooming in over my workplace (in Miami, FL) and searching "Pizza" brings up results for Italy and Nigeria.
OpenStreetMap is a great datasource and set of APIs though, on which other people have built really useful map applications. But OSM itself is not an attempt to compete with all of Google Maps, just to provide high quality tiles, path/nodes and place database to developers.
OpenStreetMap is a great datasource and set of APIs though, on which other people have built really useful map applications. But OSM itself is not an attempt to compete with all of Google Maps, just to provide high quality tiles, path/nodes and place database to developers.
Yep. osm.org's search is only a placename search, basically.
What's the open source alternative to maps.google.com then? Or is it just not yet built?
Anyone can contribute to OpenStreetMap.
So if you find something missing, you may consider spending the time to add the missing information so that we can have maps that are owned in common: https://en.wikipedia.org/wiki/Open_Database_License
So if you find something missing, you may consider spending the time to add the missing information so that we can have maps that are owned in common: https://en.wikipedia.org/wiki/Open_Database_License
The point is that osm.org is not intended for end users. I learned it the hard way ;)
And osm.org just shows the data best for mappers.
Also the address search is good but not perfect due to lack of data but also limited software.
But the nice thing about OSM as a developer is: you can do anything with this data. Build your own address searcher, routing engine and mapping stuff etc.
Also the address search is good but not perfect due to lack of data but also limited software.
But the nice thing about OSM as a developer is: you can do anything with this data. Build your own address searcher, routing engine and mapping stuff etc.
Have you looked at http://www.geonames.org/ ?
I've used this for a place database and really liked it. They provide data dumps of the database (as well as diffs between previous dumps) so we don't need to rely on their web APIs, and still have the data in case geonames ever shuts down. They also offer a paid service, which should guarantee some sort of protection against a random shutdown.
AFAIK they don't have path/street data, just a massive location dataset, so you can't use it for directions by itself.
AFAIK they don't have path/street data, just a massive location dataset, so you can't use it for directions by itself.
Honest question: why Google couldn't exist with FreeBSD instead of GNU and Linux? I assume that only GCC would be used in that case.
During time when Sergei and Larry wrote code for Google. It won't have been possible for them to survive without huge costs, if not using gnu tools and many gpl utilities, bsd code is their but not as much at that time. Moreover using bsd and then earning by making it closed source is even worse without contributing back. Indeed for that matter even today they won't survive without gpl code. The amount of gpl code used within Google compared to the code they contributed back you will still see a huge gap.
Nul ne peut se prévaloir de ses propres turpitudes.
No one can prevail that a successful lasting violation of law worth recognition of it as an accepted legal usage.
(Except if you are rich and have guns because when it comes to owning lands, occupying long enough a place is legally owning).
I do agree that the ToS are shit. They were since the beginning. What new brands are doing is called : claiming rights on the second creation.
They give you proprietary shovels with open API to rush for gold, and once you have taken the risks and you can make money they can decide to let you live or not.
People laughed at me 10 years ago with this topic.
Entrepreunariat is about being a jake of all trades. You cannot be weak neither in coding, nor economy, nor business, nor accounting, nor legal contracts. You skipped "the leg days" of business. Reading the contracts and evaluating the risks, assessing the uncertainties. And you failed.
Well. Blame it on you and your blindness. Don't appeal to my pity.
Vae Victis. That is the way of business, and you should take responsibility for your own bad choices and understand that with great power comes more painful arrows in the knees.
All people supporting your claims should rather also think of the consequences of sustaining unsound business practices. If you would win, it would be yet another loss for all of a fair competition on the market.
I actually love your idea and have a lot of respect for your realization. Building is great. Making lasting products and risk management is even more important.
So, please shutdown your site and share the depressing conclusions you will come to. Learn like a true entrepreneur, and go back to work with your newly acquired knowledge, and think of whether or not you can rebuild your product on better foundations.
Success is not what make business man. It is overcoming your failure. The only true capital of a business man is fortitude.
(Except if you are rich and have guns because when it comes to owning lands, occupying long enough a place is legally owning).
I do agree that the ToS are shit. They were since the beginning. What new brands are doing is called : claiming rights on the second creation.
They give you proprietary shovels with open API to rush for gold, and once you have taken the risks and you can make money they can decide to let you live or not.
People laughed at me 10 years ago with this topic.
Entrepreunariat is about being a jake of all trades. You cannot be weak neither in coding, nor economy, nor business, nor accounting, nor legal contracts. You skipped "the leg days" of business. Reading the contracts and evaluating the risks, assessing the uncertainties. And you failed.
Well. Blame it on you and your blindness. Don't appeal to my pity.
Vae Victis. That is the way of business, and you should take responsibility for your own bad choices and understand that with great power comes more painful arrows in the knees.
All people supporting your claims should rather also think of the consequences of sustaining unsound business practices. If you would win, it would be yet another loss for all of a fair competition on the market.
I actually love your idea and have a lot of respect for your realization. Building is great. Making lasting products and risk management is even more important.
So, please shutdown your site and share the depressing conclusions you will come to. Learn like a true entrepreneur, and go back to work with your newly acquired knowledge, and think of whether or not you can rebuild your product on better foundations.
Success is not what make business man. It is overcoming your failure. The only true capital of a business man is fortitude.
Well said, learn and look forward, that's the only way.
[deleted]
What's the whole story here? Is it because he created a way for people to create routes, and is not using the official Google Maps API method for creating/showing routes? If he just altered his app to use Google's approved method, would he be fine?
They are not routes. They are pins connected by straight lines. The screenshot in the post doesn't reflect the reality of the service. Try clicking on NYC, Washington DC, Detroit and Boston and see the route. Prepare to do some swimming :-)
That's by design. From the FAQ:
> How come if I click on two points along a curvy road, the line doesn't follow the curvature of the road?
> Two reasons. First, Google doesn't provide an interface to the road data, so I have no way of knowing if you clicked on a road or not, nor do I know where the road twists and turns.
> Second, many people create routes that go off-road (e.g. to plot a hiking path). These people wouldn't want RouteBuilder to follow along a road anyway.
From the wording of the mail and of the ToS [1] I don't think that it would make any difference if he used the Google Directions API [2]. Actually, after reading that letter I wonder what developers can use that API for, if not for eventually getting that letter.
[1] https://developers.google.com/maps/terms#section_10_4
[2] https://developers.google.com/maps/documentation/directions/...
That's by design. From the FAQ:
> How come if I click on two points along a curvy road, the line doesn't follow the curvature of the road?
> Two reasons. First, Google doesn't provide an interface to the road data, so I have no way of knowing if you clicked on a road or not, nor do I know where the road twists and turns.
> Second, many people create routes that go off-road (e.g. to plot a hiking path). These people wouldn't want RouteBuilder to follow along a road anyway.
From the wording of the mail and of the ToS [1] I don't think that it would make any difference if he used the Google Directions API [2]. Actually, after reading that letter I wonder what developers can use that API for, if not for eventually getting that letter.
[1] https://developers.google.com/maps/terms#section_10_4
[2] https://developers.google.com/maps/documentation/directions/...
Google Maps already provides a way for you to share routes, Routebuilder is duplicating that functionality (even if it makes it easier) which is a violation of Google Maps' ToS.
> Google Maps already provides a way for you to share routes
Does it? Where?
Map Maker doesn't do what the article claims it does. It doesn't try to reproduce Routebuilder at all. It allows you to fix errors in Google Map's data, it isn't useful for creating new custom routes for specific purposes (e.g. races, sightseeing, etc).
Does it? Where?
Map Maker doesn't do what the article claims it does. It doesn't try to reproduce Routebuilder at all. It allows you to fix errors in Google Map's data, it isn't useful for creating new custom routes for specific purposes (e.g. races, sightseeing, etc).
Here is an example of a Google maps route from Providence to Boston for bicycling, https://www.google.com/maps/d/edit?hl=en-US&mid=zH358fz1z920...
The author might have been thinking of the similarly-named "My Maps".
Being better than Google is clearly a reason Google would want to shut you down.
Email from Google doesn't state what feature(s) they feel is replicated by the site, which is strange.
I wonder if it has something to do with elevation? For some reason it seems GMaps is very protective about elevation data; if the site recently gained some momentum and they noticed many elevation requests, maybe it could explain this sudden (late) reaction?
I wonder if it has something to do with elevation? For some reason it seems GMaps is very protective about elevation data; if the site recently gained some momentum and they noticed many elevation requests, maybe it could explain this sudden (late) reaction?
I'm not even sure how the site differs from a site like http://www.gmap-pedometer.com/ (afaik it also allows the share the routes).
Currently your site is violating the terms of google map usage. you can not ask them to allow you to keep on violating their terms.
The better solution would be to write them the letter to allow you to implement the functionality of your own with in some specific time period (may be 1 month)
Then, Create your own solution on some open standards or tech I recommend you to use openstreetmap mbtiles(http://wiki.openstreetmap.org/wiki/MBTiles) I have worked with them, they are tricky but really great.
The better solution would be to write them the letter to allow you to implement the functionality of your own with in some specific time period (may be 1 month)
Then, Create your own solution on some open standards or tech I recommend you to use openstreetmap mbtiles(http://wiki.openstreetmap.org/wiki/MBTiles) I have worked with them, they are tricky but really great.
Why, exactly, can't he ask them if can keep on violating their terms?
I don't get this attitude, Google is well within their rights to shut him down. He's well within his rights to ask for forgiveness and to complain about Google if they don't.
They're a corporation, not some feudal lord that is owed fealty.
I don't get this attitude, Google is well within their rights to shut him down. He's well within his rights to ask for forgiveness and to complain about Google if they don't.
They're a corporation, not some feudal lord that is owed fealty.
Google Map and its services are the intellectual property of google.They may setup any rules and terms they want for their service regulation(also to prevent any misuse of service).
Yes, yes. We all agree on that. By why are you saying that " you can not ask them to allow you to keep on violating their terms". Why is asking them for an exception forbidden?
Pretty sure that Under Armor's MapMyFitness webapp has a route builder that uses the Google Maps API as well
I used to use http://runningmap.com/ to plan out routes for short-distance running in my neighborhood; but they stopped updating the site and my guess is their API key had gotten revoked as well.
"These people have forgotten that all application interfaces ... used to be “richer environments,” and the users abandoned them by the millions, in favor of the browser, the moment they got a chance"
And then they abandoned the web browser in even larger numbers to download "apps," which provided a richer environment to interact with their portable personal computer (or "smartphone").
Web browsers absolutely suck for UI, and they're not redeemed by their lack of complexity. When there is a easy, viable, alternative to a web browser for a program to run on users's computers you'll see browsers dropped, and hopefully go back to what they were intended for - browsing interlinked documents.
And then they abandoned the web browser in even larger numbers to download "apps," which provided a richer environment to interact with their portable personal computer (or "smartphone").
Web browsers absolutely suck for UI, and they're not redeemed by their lack of complexity. When there is a easy, viable, alternative to a web browser for a program to run on users's computers you'll see browsers dropped, and hopefully go back to what they were intended for - browsing interlinked documents.
Hmm, what about the Gmap Pedometer? http://www.gmap-pedometer.com
There is nothing on that site, or its forum, about any impending shutdown.
Been using that (on and off) for a very long time. The changelog goes back to mid-2005; just months after Google Maps was announced.
This site lets you build routes and save them as permanent objects that you can share links to. It's useful for runners, cyclists, etc.
Just trying RouteBuilder: looks like a knockoff of Gmap Pedometer, only capable of connecting straight line segments (doesn't follow roads). That is irrelevant though; both sites basically wrap Google Maps in the same way.
There is nothing on that site, or its forum, about any impending shutdown.
Been using that (on and off) for a very long time. The changelog goes back to mid-2005; just months after Google Maps was announced.
This site lets you build routes and save them as permanent objects that you can share links to. It's useful for runners, cyclists, etc.
Just trying RouteBuilder: looks like a knockoff of Gmap Pedometer, only capable of connecting straight line segments (doesn't follow roads). That is irrelevant though; both sites basically wrap Google Maps in the same way.
This is the very early signs of a trend that is going to grow - the conversion of private conquest of the Internet into public goods.
Google has two huge advantages in search - they have scraped links off every web page, which can be replicated (see Bing, DuckDuckGo) and they have user behaviour visiting those pages (did they immediately return to results page after hitting ,#1?)
There are good arguments to be made that both data sets are public goods, and indeed that it was unfair to use user generated content / data without licensing
There are of course arguments to the contrary. but googles jewels are too valuable to be left alone for lomg
Google has two huge advantages in search - they have scraped links off every web page, which can be replicated (see Bing, DuckDuckGo) and they have user behaviour visiting those pages (did they immediately return to results page after hitting ,#1?)
There are good arguments to be made that both data sets are public goods, and indeed that it was unfair to use user generated content / data without licensing
There are of course arguments to the contrary. but googles jewels are too valuable to be left alone for lomg
I'm unclear as to how the Google's ToS are being violated. He's not reimplementing anything that Google has provided.
If I want to create a route from my condo down to the walking path, along the path to the high school, and back to my place there is not a way to do this within Google Maps.
I use this service quite frequently when traveling and my training schedule says "2.0 mile run" or whatever. I can create a circuitous route starting/ending at my hotel. Not a way to really do this in Google Maps. So, again, how is clause 10.4(c) being violated?
If I want to create a route from my condo down to the walking path, along the path to the high school, and back to my place there is not a way to do this within Google Maps.
I use this service quite frequently when traveling and my training schedule says "2.0 mile run" or whatever. I can create a circuitous route starting/ending at my hotel. Not a way to really do this in Google Maps. So, again, how is clause 10.4(c) being violated?
Maybe I misunderstood your example but I've always found this to be pretty easy in Google Maps. I just picked a random spot on the map where there was a park (with some walking paths) and made a custom route. Took longer to pick a location for the example than it took to make the map: https://goo.gl/5TcdGz
I must be dense then. I'm unable to figure out how to do this.
Open Google Maps in a browser. Enter your starting location. Find points along your path, right click, and choose "add destination". Repeat until you have your path. Then you can click and drag the blue line of the path if you want to take a different route than the one that is auto-generated. If you choose "walking" instead of driving or transit it will include any walking paths in the database.
>One option for me would be to rewrite routebuilder to run >on another mapping platform, but with an infant at home >and a full-time job, I frankly don’t have the time or >energy.
Just install UMap instead.
https://wiki.openstreetmap.org/wiki/UMap
https://github.com/umap-project/umap
Just install UMap instead.
https://wiki.openstreetmap.org/wiki/UMap
https://github.com/umap-project/umap
Do no evil, except for fucking over developers left and right.
I wonder how easily they could switch to open street map.
Not a lawyer.
My gut feel is Google writes their TOS that are concrete enough to be enforceable at some basic legal level, but vague enough to be a catch-all enforcement.
It's crummy that Google is claiming that Routebuilder is violating their ToS, but not telling them how it's violating or why they have deemed Routebuilder a violate of that specific ToS clause.
It definitely feels like large company bullying tactics, which are hard for small/medium and independent companies to fight, without investing (read: wasting) money on legal fees.
This is less about "oh if you don't like the terms, build it yourself" but rather the spirit of which Google was founded.
Facebook and Twitter have pulled this same nonsense as well: encourage all developers build their apps on top of their platforms, to help grow the active user base. Once they become critical mass/gate keepers, swing the doorshut for all except those who are willing to do everything that they are asked of.
The kick in the balls is how Google built their organization on top of open-software, but now has adopted the same corporate policies that closed/proprietary software vendors like MSFT have used.
"Do no evil."
My gut feel is Google writes their TOS that are concrete enough to be enforceable at some basic legal level, but vague enough to be a catch-all enforcement.
It's crummy that Google is claiming that Routebuilder is violating their ToS, but not telling them how it's violating or why they have deemed Routebuilder a violate of that specific ToS clause.
It definitely feels like large company bullying tactics, which are hard for small/medium and independent companies to fight, without investing (read: wasting) money on legal fees.
This is less about "oh if you don't like the terms, build it yourself" but rather the spirit of which Google was founded.
Facebook and Twitter have pulled this same nonsense as well: encourage all developers build their apps on top of their platforms, to help grow the active user base. Once they become critical mass/gate keepers, swing the doorshut for all except those who are willing to do everything that they are asked of.
The kick in the balls is how Google built their organization on top of open-software, but now has adopted the same corporate policies that closed/proprietary software vendors like MSFT have used.
"Do no evil."
Once you're no longer the underdog, your views on the world shift 180 degrees :) But worry not, everyone is riding a "sine wave" - Google comes, Google goes. There's some physics theory that applies here - entropy, I guess.
"What goes up must come down."
― Isaac Newton
― Isaac Newton
Just move on to Open Street Maps.
Isn't this interesting.
Effectively Google are saying that they have rights over the design of the API interface.
Yet isn't that their argument in the Oracle Java case, that an API itself isn't a protectable thing?
Effectively Google are saying that they have rights over the design of the API interface.
Yet isn't that their argument in the Oracle Java case, that an API itself isn't a protectable thing?
No, this has nothing to do with intellectual property rights.
Google is not claiming any legal right to prevent anyone from creating something that looks like Google Maps. They're simply saying that they don't have to give you the Google Maps API for free to do so.
Also, this is about a user interface, not an API.
Google is not claiming any legal right to prevent anyone from creating something that looks like Google Maps. They're simply saying that they don't have to give you the Google Maps API for free to do so.
Also, this is about a user interface, not an API.
Well there are other apps that perform similar as op's, for instance the software Tyre - which they charge for by the way. Looks like you've gotten too popular...
How is Routebuilder different from http://www.gpsvisualizer.com/?
It used to be that Google didn't play dirty.
When did that change?
When did that change?
since they removed the 'do not be evil' slogan? just move to openstreetmap and ditch google map api.
When Larry Page became CEO, basically.
I can't tell how this Routebuilder thing is any better than just right clicking and 'distance to here'?
There is an option in the context menu on maps.google.com "Measure distance" that it overlaps with even more. No obvious way to share the measured Google path though.
For crying out loud. They have billions and billions of dollars of cash on hand. Just do the right thing and buy the company. It looks good for them, it looks good for you, it looks good for the ecosystem. Just buy them!
How would that be the right thing for Google? They don't need Routebuilder, and they don't need the PR boost. Google certainly doesn't need to set a precedent that any company that depends on their APIs can expect to be acquired if they violate their TOS long enough.
Anyone still finds Google relevant for anything? They are making sure nobody wants to be their friend again. Search got so bad in the past few years ("bbut our metrics show it's more relevant than evar!") that DDG doesn't even have to try. Sad.
Lately if I want to watch YouTube, I have to agree to their privacy policies. If I turn off everything, I have to do the same a few days later. Antipatterns everywhere...
What happened to you guys? We want the great old Google back please!
Lately if I want to watch YouTube, I have to agree to their privacy policies. If I turn off everything, I have to do the same a few days later. Antipatterns everywhere...
What happened to you guys? We want the great old Google back please!
Sorry, but this is absurd. DuckDuckGo is nowhere near Google in terms of revenue, brand trust, and most importantly: search result relevance.
The point is that DDG is now "good enough". I am also a bit unhappy they are embracing some approaches that made Google worse though... And Google - the only profitable part is their search + ads. If they let this slip, what would remain? A hollow shelf like when SUN imploded?
This is exactly the reason why Playa's building Terms of Service that are friendly to developers. I got tired of people building great apps, only to have the platform shut them down, or worse, blatantly rip them off.
Our platform promises never to compete with anyone building working products on top of the platform. I want people to do well, grow a business, and build something with their time that works for them.
Playa is made by hackers, for hackers.
I asked for feedback on some of these concepts a couple of weeks back, add to it if you'd like and help lay down the foundation:
https://docs.google.com/document/d/1AgYQ3f61Yrk_HXSbdZtCRyiu...
Our platform promises never to compete with anyone building working products on top of the platform. I want people to do well, grow a business, and build something with their time that works for them.
Playa is made by hackers, for hackers.
I asked for feedback on some of these concepts a couple of weeks back, add to it if you'd like and help lay down the foundation:
https://docs.google.com/document/d/1AgYQ3f61Yrk_HXSbdZtCRyiu...
It took Google a decade to decide this site was violating the Terms of Service. Routebuilder does one narrow thing, it's not like they've creeped into Google's territory over the years. Something's fishy -- someone on slashdot suggested that it could be because of google's new fitness trackers (http://fit.google.com) that they're flushing out any sites at all similar. If that's the case, then sites like routebuilder should be grandfathered into the TOS.
I would call that business as usual, more than fishy - those megacorp (MS, Apple, Google) have a long track of killing competitors before entering their space if at all possible, even if that means acquiring the whole business to close it down.
A violation is a violation, period. Yeah maybe it sucks but it violates their terms, what do you expect? It's not going to be grandfathered in. No one does that because now you have exceptions to your terms of service. Likely it was a violation back in 2006 as well in which case there would obviously be no exceptions granted anyway.
It's not like Google had the website sitting in a queue to be checked for violations and it took a decade to get to it. They likely hadn't looked at it at all, didn't run an audit on it etc. Google is a big company, is it really that unreasonable that it may have taken a decade before finding the violation?
It's not like Google had the website sitting in a queue to be checked for violations and it took a decade to get to it. They likely hadn't looked at it at all, didn't run an audit on it etc. Google is a big company, is it really that unreasonable that it may have taken a decade before finding the violation?
Could it not be moved to Mapbox or OSM directly?
From the article: "One option for me would be to rewrite routebuilder to run on another mapping platform, but with an infant at home and a full-time job, I frankly don’t have the time or energy."
And Google's given him a mere fourteen days to rework around a different API. For a program so hinged on an API like this, I imagine the amount of work to do that is probably quite significant.
Or MapQuest. People forget about them but they have open maps.
MapQuest's open mapping initiatives are basically becoming a wrapper around Mapbox. I wouldn't build anything on MapQuest Open today, sadly.
Are you sure they are using Mapbox (the commercial service)? I thought it was all based on OpenStreetMap data.
Previously they ran their own stack based on OSM data, but they're now moving to use Mapbox's stack (which of course is also founded on OSM):
https://www.mapbox.com/blog/mapquest/
https://www.mapbox.com/blog/mapquest/
I read that link but it doesn't say anything about MapQuest Open using Mapbox and only discusses their consumer product: http://www.mapquest.com
MapQuest Open is separate from their main product and commercial developer offerings: http://open.mapquest.com
I don't see anything on the MapQuest Open website that indicates they use Mapbox to serve their OSM tiles.
MapQuest Open is separate from their main product and commercial developer offerings: http://open.mapquest.com
I don't see anything on the MapQuest Open website that indicates they use Mapbox to serve their OSM tiles.
Hi everyone, Google Product Manager for Maps APIs here. We are not revoking Routebuilder’s access to the Maps API. Unfortunately, we mistakenly sent a letter to Routebuilder saying that they were in violation of the Google Maps API terms of service. This was an error. Once the developer contacted us about this issue, we replied apologizing for the misunderstanding and confirming that we would not be revoking his access to the Maps API. (He contacted us on Friday, we replied on Monday, the blog post was published on the weekend.)
We’re really glad he let us know so we could fix the issue and we encourage any developers that have issues in future to reach out to us so we can help. Developers who want to contact the Google Maps APIs team: Stack Overflow and our issue tracker forum (https://code.google.com/p/gmaps-api-issues/) are both monitored by the Google Maps team weekly.