With 'virgin' developers, Microsoft could fork Android

A similar proprietary software scenario fueled Microsoft's growth when it was a young company supplying PC operating systems.

image alt text

Windows Phone is not an option for Microsoft’s mobile renaissance. It’s just too little and too late.

To catch up, Microsoft could invest in an Android fork that would impress consumers with responsive on-device performance, integration with Microsoft’s mobile ecosystem, and compatibility with the more than 1 million apps available through the Google Play and other app stores.

Every discussion about forking Android leads to discussions of “how open is Android?” and “will the proprietary Android components prevent a competitor from building a great smartphone based on the Android Open Source Project?”

A similar proprietary software scenario fueled Microsoft’s growth when it was a young company supplying PC operating systems. Microsoft DOS was designed per IBM’s specification to run exclusively on IBM’s PC hardware platforms. Phoenix Technologies employed software developers it nicknamed “virgins,” who hadn’t been exposed to IBM’s systems to create a software layer between Microsoft’s DOS system and PCs built by IBM’s competitors. This prevented IBM's competitors from infringing on IBM’s patents or copyrights, and subsequently helped fuel the explosive growth of PC clones. Microsoft could use the same approach to “clone” the proprietary Android components in its own Android fork.

Two recent stories written from opposing points of view published by Ars Technica and CNET cover in detail the pros and cons of forking Android using the Android Open Source Project (AOSP) source tree. In a nutshell, Google publishes Android source code under free and open source licenses. A “fork” is simply an independently compiled version of Android. Download the free Android source, recompile and distribute the forked version. That’s all it takes - the device manufacturer is in business.

But some would argue that Google’s control of the proprietary part of Android, the Google Mobile Services (GMS) platform, is a tactic to monopolize Android. GMS refers to the interfaces between apps that run on a mobile device and Google’s proprietary cloud services that create its ecosystem. Google’s proprietary apps and many independently developed apps rely on GMS. Distributing a version of Android with Google’s proprietary apps and access to its cloud services requires a license from Google, as well as Google’s verification that the version of Android complies with its standards. That’s fair enough - the verified smartphone manufacturers get Android and Google’s entire ecosystem for free, including its proprietary Google apps and all the apps in the Play Store.

Unless the Android fork is verified by Google, a smartphone manufacturer can’t ship Google’s proprietary apps. However, Google’s verification is not needed for an individual consumer to download and install a Google-signed version of the Google Play app store and then download the full inventory of Google proprietary apps to an unverified Android version. Microsoft would not want Google’s proprietary apps and cloud services, but would want to leverage the million-plus independently developed Android apps and large developer community. Bypassing GMS means some independently developed apps that rely on the GMS platform and Google’s cloud services will break.

Microsoft’s experience cloning PCs can be applied to cloning GMS

Microsoft can fix this problem easily. A good team of developers could “clone” GMS functionality so independently developed Android apps could operate without modification and replace Google’s ecosystem of cloud services with a competitive ecosystem. This would involve reverse-engineering GMS so that a programmatic request made by an app to the GMS clone will return the expected results in the exact expected format.

A good example would be replacing the Android location services with Microsoft’s Bing maps. The new Android location application programing interface (API) released last year simplifies the coding of apps that use geographic location and is included in Google’s proprietary Play Store. This new location API is built using lower-level location manager APIs that are part of the Android Open Source Project. Microsoft would need to build a functional carbon copy of the new location API using the lower-level location manager APIs that would operate identically when an app called for location services.

The clean room, or sometimes called the Chinese wall, technique is a design method for reverse engineering a platform and recreating binary-level app compatibility that was proven legally defensible a long time ago. In the early 1980s, Phoenix Technologies was one of the first companies to employ this technique in creating the first compatible PC bios that allowed Microsoft DOS to run on PCs that weren’t manufactured by IBM.

When the PC was first introduced, Microsoft’s DOS operating system, was designed to interface with IBM’s PC hardware platform using the basic input/output system (bios) that IBM had specified. Phoenix Technologies cloned IBM’s bios and licensed it to IBM’s competitors that wanted to build DOS-compatible PCs and sell them into a PC market that was as dynamic and growing at the time as the smartphone market is today.

In the past, 'virgin' developers helped prevent copyright infringement

Phoenix Technologies’ “virgin” developers were verified to have never been exposed to IBM’s proprietary bios source code or hardware design. The virgins wrote compatible bios using specifications written by developers who had read IBM’s bios source code and design documentation.

A clone of Google’s GMS platform could be built in the same way. One group of developers who are familiar with GMS and all its related functions and APIs that app developers use to build apps could write a specification for recreating the GMS APIs, while the virgin developers would precisely reproduce the function and operation of the API.

PCs and Google’s cloud services are similar. They are both platforms. Coding a bios routine that writes a block of data to a disk exactly like IBM’s bios is similar in concept to writing a location service that operates identically to Android’s location API.

It would be nearly impossible for Google to sue Microsoft for API copyright infringement because Google opposed such copyrights in its defense against Oracle’s patent and copyright lawsuit. In this case, Judge Allsop stated in his ruling (PDF):

“So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API.”

Android app compatibility and Nokia hardware would be a big win for Microsoft

Every consumer has fond memories of his or her Nokia phones. Nokia hardware with full Android app compatibility could attract a lot of consumers. Cloning GMS wouldn’t be easy, but Microsoft has the technical resources, experience and money to succeed. Estimating the size of the project to clone GMS isn’t a simple task, but one case in point of a project of equal strategic importance is Intel. Intel has more than 1,000 engineers working to ensure Android compatibility with its Atom mobile processor. Microsoft’s cloning of GMS would be an order of magnitude less expensive than the Nokia purchase, and could drive many more consumers into Microsoft’s ecosystem more quickly than Windows Phone has been growing in painfully small increments.

Join the discussion
Be the first to comment on this article. Our Commenting Policies