Google vs. Facebook in API scrum: Why can't we all just be reciprocal?

Google tweaked its terms of service for its contacts application programming interface and raised a bit of a ruckus. Turns out Google will only enable contact data to be exported if the party on the other end is reciprocal. In its terms of service, Google notes:

5.8. Google supports data portability. By accessing Content through the Contacts Data API or Portable Contacts API for use in your service or application, you are agreeing to enable your users to export their contacts data to other services or applications of their choice in a way that’s substantially as fast and easy as exporting such data from Google Contacts, subject to applicable laws.

That tweak is a dig at Facebook, which isn't reciprocal to Google. In a statement to TechCrunch, Google said that Facebook is a data dead end. So Google changed its rules. Google won't allow Web sites to automatically import contact data unless the other site allows a similar export. The key word is "automatically." You can still download contact data to a file that in theory could be added to Facebook.

Google is going to take some heat, but the move does send a message. Facebook argues that exporting data is difficult when it comes to the social graph. In the end, the API battle is really over control. The social graph goes through Facebook and Google wants better access to it---so it can use its search to craft a social networking hook.

Add it up and users are in a contact data mix-up between Google and Facebook. In reality, the API battle may just be symbolic. You can still import contact data from Hotmail and Yahoo Mail, two massive email services that happen to be partners (Yahoo) or investors in Facebook (Microsoft). But rest assured data portability and being reciprocal appears to be an issue that's emerging.

The trick going forward will be interpreting what's a real issue of being reciprocal and what's corporate positioning.