| Even granting your point which I think is a bit of a stretch for "open", I think there are some unreasonable requirements at place here. >"you can interoperate with me as long as follow my terms and conditions", with those terms being considered reasonable. I wonder if the HTML5 requirement can considered reasonable. Why does the server's web service API care if the client is HTML5 or not? Microsoft says this in their post: >There was one sticking point in the collaboration. Google asked us to transition our app to a new coding language – HTML5. This was an odd request since neither YouTube’s iPhone app nor its Android app are built on HTML5. Nevertheless, we dedicated significant engineering resources to examine the possibility. At the end of the day, experts from both companies recognized that building a YouTube app based on HTML5 would be technically difficult and time consuming, which is why we assume YouTube has not yet made the conversion for its iPhone and Android apps. Google's statement is totally mum on the matter except for "it violates terms of use". If they want to call themselves open, they should atleast let us know what the HTML5 requirement is about, as it is certainly strange for a web service API. And in my opinion this makes it a 'unreasonable' condition for an open API and Google's silence does not help it. I do think Google is within their rights(absent monopoly concerns) though. |
Yes, it is very reasonable.
The server doesn't, but google does. The HTML5 requirement means that google can change everything about their service (e.g. they can switch the ads from being h264 videos today, to javascript games tomorrow, to 3d interactive items the next day when 3d screens become the norm on phones). If they had to expose an "ad inventory API", they couldn't change these things without breaking older clients.
An analogy: Microsoft relies on the TCP packets coming from YouTube being always 100 bytes or less (because they are). Google says "no, you must use a general TCP stack, because one day we might want to make our packets longer". Microsoft dedicates significant engineering resources to examine the possibility, and at the end of the day recognizes that even though they have a general purpose TCP stack, switching to it will result in some inconvenience to users. So they release an app that has a TCP stack that expects 100 bytes or less -- and google refuses to serve it.
This is exactly the same, except at a higher abstraction level. Google doesn't care to spell it out, because anyone who is capable of understanding that issue already does.