Google is Forcing Routebuilder to Shut Down
medium.com
medium.com
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.
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...
Yeah plenty of alternatives now but does it really matter in this situation? Not really in my opinion.
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.
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.
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.
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.
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.
You may choose to depend on a vendor to an extent, but structure your application in a way that a sudden change in the rules would not be the end of you; e.g., there is more than one cloud provider on which one can use the same Docker images to deploy an application. And you may choose a business where there are no options _other_ than to depend on a third party; e.g., you wish to sell a native iOS application to iPhone users.
Risk is still risk: a potential pitfall or peril. Sometimes the risk is great enough, compared with the potential return, that the only way to win is not to play. Regardless, this article discusses a set of risks which exist now more then ever; to enumerate and understand these risks is not outdated thinking, it's just good business.
This applies to so many things involving computers, and of course most aspects of modern life.
Back in the good (bad?) old days there were no such things as "personal" computers. We created our programs on punched cards and trudged down to the computer center to run them.
And that, to me, was what I hated the most about the computers of the time. I was dependent on the good graces of the University to get a few precious minutes of computer time to use to run my programs.
So, when the first usable PCs were invented, people flocked to them. 8K bytes of RAM meant you could run a BASIC interpreter on your own computer. Once you bought it, you could use it as much as you wanted to, for any reason that you wanted to. Period.
It's unfortunate that so much of modern computer life once again depends on the good graces of others.
But here's a potential solution: since API clients are essentially renting the vendor's platform and launching businesses based on this, there needs to be some legally-enforced stability. I would like to see something like a landlord-tenant relationship. Both parties have responsibilities and expectations and the lease can't break the fundamental rules in the law, which usually includes mandatory notice periods to terminate tenancy if a tenant is month-to-month, a prescription for informing the landlord of maintenance issues and giving him time to repair, a legally protected remedy if the landlord fails to repair something that he's legally obligated to maintain (like withholding rent), and finally, an eviction process that the landlord can use to force the tenant out of the property when he's been found in violation of the lease.
I think this sort of relationship should exist at a minimum. It would make it so Google et al couldn't just kick you off whenever they got bored and decided your product was cool and they didn't have anything to do with their 20% time so they're gonna clone it, they could only cut you off at the conclusion of your contract. If there's a legitimate reason to kick someone off the API before this time, they can take it to an API tenancy court and get the judge to sign off on the access key's eviction (which should be thousands of times more practical for both parties than the current route, which is a CFAA lawsuit).
The ability to "buy land" on the platform and own an API key that can't be deprived from you would be interesting too, but I'm not sure on the details of how that would work right now.
Except when a tenant is kicked out of their apartment with no notice, they might literally die. When Routebuilder gets shut down (with at least 2 weeks notice if not more, according to the article), someone organizing a marathon might... have to use a different, also free service?
And let's not forget that Google is a private enterprise offering an absolutely insane amount of data and access for free. The bar for "legitimate reason" to revoke API access is (and should be) legally no higher than "Google wants to." They actually go quite a bit above and beyond by having Terms that you can read and that as far as I can tell they abide by.
The part of Google that uses the services provided by the Maps provider would have to play by the same terms as any competitor.
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.
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.
If some jackass took the display down, an auditor would find it and we would get sued. The customer had recourse.
Most tenancies are also dictated by a separate legally binding contract (the "lease"). The reason the law addresses tenancy separately, even though most landlords and tenants sign leases, is so that there's a baseline if no contract is provided or if the contract is unconscionable. The law also provides a custom-tailored process to address issues of non-compliance with that type of contract (eviction) instead of sending it through conventional civil court, which wouldn't resolve that type of issue efficiently.
These custom-built paths in law are useful. We have these to make sure things are as fair as possible for all involved parties in common arrangements, because just falling back on hastily-written contracts isn't always the ideal solution. API tenancy is becoming a common arrangement.
Maybe it's too specific though, you could be right about that. Maybe there's a more abstract level at which we can conceptualize digital property rights that would solve API tenancy issues as well as other digital issues.
If state sets onerous reqirements on API, most companies will just stop provide it for free or at all. Why do you want to commit long term resources to something that does not make you any money and sets you up for legal problems if you want to make changes?
Is it possible possible that the increase stability of those APIs still offered would be more valuable than the less stable but more numerous API environment we have now?
If somebody attempts to prevent you from storing things as such, say through propaganda about imaginary property or post-hoc "TOS" enforcement, they're not going to be friendly to any definition of property that gives you power. So it makes sense to go with the definition that's directly enforceable.
I like native apps mostly for their speed, but unless you're doing something requiring a sensor on the phone, mobile web can do it all.
That's still sharecropping.
The use of the term in this context is calling out the specific vulnerability of using the walled gardens of Facebook/Google/Apple and the other behemoths. By your literal correctness of the term, there is no possible way to operate on the internet, since you don't own the land and the network cables from your servers to the clients.
Pulling one's head away from their rear end provides the vision that relying on specific vendor platforms, with their own goals and interests sometimes counter to yours, is different from using a colocation for servers.
Sure, you can always fork the project and make your own, but I'd argue the project is controlled by the corporation.
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.
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.
No one's worried about assembly code for Intel chips, but the next generation could be locked down.
No one's worried about writing C++ for Windows, but technically you're using their APIs and hooks that could be dropped in the next release.
There's iOS, where you're also subject to review and approval.
There's well-known web joints like Google, where this can happen.
Then there's the fly-by-night shops that could just dissolve tomorrow.
The safest thing is to build your own computer from silicon, write your own OS, your own compilers, your own languages, your own software, and your own APIs. Of course, by the time you do that, we'll all be dead. So it's a balancing act. But it's worth illustrating that you're taking for granted that things will remain the same forever, when in reality there's a sliding scale of risk.
Your post also seems to assume that everyone will upgrade to the "next release". On platforms where you get to control your upgrade cycle, people won't upgrade if the upgrade breaks the programs they want to use, and this acts as a check on gratuitous API/ABI breakage.
Microsoft takes this extremely seriously and has hardly any API breakage over the last 20 years because they know that there's a real threat that a competitor could emerge with WINE pre-bundled and take away some market share if they break a lot of programs.
Well, Valve was, justified, worried about that, and built SteamOS.
My shareware Snood clone company is not very worried about Microsoft changing the Windows API, but I'm sure with every release major Windows software suppliers, particularly those reliant on a certain niche feature, certainly are.
and that's bad for tech, and bad for america
My advice to anyone building anything significant off an API or scraped access: do it anonymously. Never reveal your real identity. Never use your real IP. Don't process credit cards. Don't register an identifiable LLC. Run it out of China or Russia where American companies will have a hell of a time trying to get to you.
If you depend on one entity's API, that entity is not going acquire you. At best, your product will be ripped off and they'll make you irrelevant. This happens to popular mobile applications all the time.
At worst, you'll get sued civilly, get your wages and bank accounts garnished, lose all of your possessions, and get criminally prosecuted under the CFAA, end up doing some time, and eventually get released with the stipulation that you never touch a computer or access the internet again for the rest of your life.
Unless you can ramp up to doing tens of millions of revenue per year (or have investors willing to pony that up) before the company you depend on notices/decides they don't like you anymore and sends out their law firm, you're dead meat, no matter what the details of your case are and no matter how wrong they are.
These are not problems you want. It's easier to put your service in the onion and run it from there, access all external data via proxy, only accept Bitcoin for payment, and never tell anyone the link to your real-world identity. Granted it takes good opsec to continue this for a long time, which is really hard to pull off, but it may be doable depending on your level of commitment.
(And having the LLC gives you great protection against lawsuits!)
For example, for Google, look at Google Keep – that one leaks API keys directly in the list of accessed URLs, the key has been the same for years, and provides access to Maps and Keep. Same with YouTube (the app packages an API key for the v3 data API) or the WolframAlpha app. Many more apps, from simple "what’s for lunch at my uni’s cafeteria" to Transit apps all leak API keys. Preferably you use the key of an app from the same company which maintains the API, so you can guarantee to always find a recent one.
I spent a few weeks last summer extracting API keys for next to all services out of apps, and breaking some DRM solutions, just to get experience with reversing software (which was something I had a course about at uni at the same time, and the experience helped me with homework).
Obviously, Google and others who have innovated in the space can set the terms of service as onerous or ambiguous as they want to. You can choose whether or not you want to invest in building something around someone else's products.
Don't like the TOS? Develop it yourself or use another product.
See Feist v. Rural Telephone for more on this. The only reason application of Feist is generally limited in cases of online access is because we have a theory that accessing a publicly available database containing phone numbers is akin to accessing someone else's private property, and therefore they can dictate whatever they want under theories like trespass to chattels, whereas consulting a printed telephone book in your home is decidely not accessing the phone company's property.
This is a pernicious, subtle issue now that we're becoming so dependent on online access provided by someone else's servers instead of accessing printed documents that we possess in our homes. Possession is 9/10 of the law, as they say. We need to rethink how "possession" applies to digital resources.
Likewise, there are laws around how much access a private property owner must grant to members of the public, especially if that property owner is running a business that is generally accessible to the public. Private property owners are allowed to declare some people trespassers, but each jurisdiction has different laws surrounding what the public can do on private property and when a trespass is allowable. For example, California's state constitution guarantees the right to hold reasonable protests in private shopping centers that are generally accessible to the public, whether the property owner likes it or not.
No one is saying there is a requirement for another business "to help invest" in any other; there may be requirements not to interfere with someone else's business by attempting to block what is otherwise public and freely available access to non-copyrightable information.
IANAL.
Routebuilder is fortunate that OpenStreetMap has collected much of the same data and that they can just code against a different API and continue to operate.
Mapping data is not "non-copyrightable information".
Open-source projects have a history of being hyper-sensitive to these concerns so that they never have to waste time with lawyers lobbing IP claims. A certain distribution derived from the sources released by a prominent North American enterprise Linux vendor comes to mind, as does WINE's refusal to accept any code from anyone who has any relationship with or connection to Microsoft whatsoever.
OpenStreetMap needs to be useful for everyone, not just people in jurisdictions with more liberal copyright laws.
How could a project like OSM make sure that it didn't happen on a large, clearly violating scale (because many people make copies of small parts, recreating the larger, protected work), especially if it isn't established what an internationally safe standard is.
In practice, you are right, you can copy a single street from google maps to OSM. I bet some mappers in the history of OSM have traced screenshots of google maps or something. But that is only safe because it can't be proven, unless you are unlucky enough to copy a canary.
As far as I know, Google Maps is protected from scripts copying the data points out only by its Terms of Use, which the CFAA basically eval()s into law.
Google Maps won't disappear overnight because they do provide a substantial amount of beneficial proprietary data, like the illustrations and private aerial/satellite imagery (imagery from sources like NASA is public domain), their scripts that allow easy embedding, the ability to connect to one's Google account, and so forth. But there is no legal protection of the raw data points used to build Google Maps as far as I know.
Let me reiterate that I'm not a lawyer and no one should do anything based on my posts.
https://en.wikipedia.org/wiki/Database_Directive
http://ec.europa.eu/internal_market/copyright/prot-databases...
This has been shown viable time and again, with App Store rejections and the like. It is obviously high-risk but sometimes worthwhile.
They aren't, but most businesses are regulated to prevent them from screwing your business.
If were renting a property for my burger stand a fast food giant could not buy the property and evict me without notice.
Common carriers from shippers to telecoms are regulated. Banks and lending are regulated too. Many businesses are regulated. Sure it slows things down, but it also creates stability.
I do not know what fair API use looks like, but some kind of regulation seems likely. Likely the kind of thing in the article will fall into grey areas.
The simple reality is that Google can control in any way shape or form how their API is consumed. Like I said, if you don't like that, don't build your business on the API. You do not have a right to anyone's API, regardless of how important the data is to your pet project or unicorn idea.
This same argument comes up when the Twitter API consumers get all up in arms because the business they built solely on top of Twitter's platform is all the sudden deemed irrelevant because of API access changes or terms of service changes. Tough tootles! And guess what, your API scraping twitter feed re-display iOS app is not innovation!
I personally think that "free APIs" are great, but if you don't have it in your business plan to share a portion of your revenue with external API data providers when they eventually ask, then you are going to get yourself in the position that the OP did.
Why not ? Plenty of financial APIs are regulated (and beyond horrible). The government has decided that anyone with a banking license and a certain amount of money stored at the central bank can use them. And God help you if you try to use the international APIs, they are so incredibly incredibly horrible.
Without this plenty of financial services wouldn't exist, no way would smaller banks be able to operate. Despite how badly designed it all is, without a doubt it is a very good thing that these APIs exist and are regulated.
Maybe regulation of APIs is exactly what we need. Hell, maybe we can even learn from the mistakes in financial APIs first and then regulate these APIs.
> if you don't like that, don't build your business on the API.
Are an impediment to progress when applied unilaterally as you are doing.
HN discussion: https://news.ycombinator.com/item?id=2592399
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.
Because you get a free high quality Maps API to use for a decade? What else would you have used in 2006?
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/ )
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.)
Which anti trust situation?
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.
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
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.
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
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.
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.
As a rule of thumb, try to use something standardized, with more than one implementations.
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.
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/...
- Open source it (with or without the wrapper to Google Maps).
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.
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.
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.
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.
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.
> 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.
more here: https://mapzen.com/projects/valhalla docs: https://mapzen.com/documentation/turn-by-turn/ API: https://mapzen.com/developers/
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.
We at Mapzen are explicitly designing our projects to outlast us (if necessary).
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.
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?
maps.google.com works great though. I wish I wasn't supporting Google's massive operations but it is convenient to use.
AFAIK they don't have path/street data, just a massive location dataset, so you can't use it for directions by itself.
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.
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.
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
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.
(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.
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).
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/...
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?
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.
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.
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.
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.
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
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?
Just install UMap instead.
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."
― Isaac Newton
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?
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.
When did that change?
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!
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...