Category Archives: Law

Flappy Bird: A New Model for Software Innovation?

Okay, I know that the title may already have some people scoffing, but bear with me for the moment. This is about more than just Flappy Bird.

Picture this with me, if you will: you have written an app. You have written an app, and its popularity has skyrocketed. The ad revenue has gone through the roof. Suddenly, you are accosted on all sides by people saying things about your app. You had no idea that this was going to happen: as far as you were concerned when you wrote it, it was just another idea you wanted to try out. There was nothing to distinguish it, for you, from any of the other ideas that you had had, none of which had ever made much money.

So, what to do? You are a lone developer. You don’t have a PR department, so you have no way of dealing with the media circus that is suddenly surrounding you. You don’t have a legal department or experience with lawyers, so you also have no way to deal with the legal issues that may be raised – for instance, claims from users about health effects, claims from intellectual property holders about potential violations – not to mention the fact that you may find that you remain personally liable for these things, even after you incorporate or sell the app (which is something that may crop up when dealing with things like the Google Play Developer Agreement).

A naive solution

So what can you do? Well, the obvious things to do are either to build a new company around it, or to sell the app to a company that is already well-placed to handle this sort of concern. However, the fact that the app was released through Google Play might make this somewhat hard.

There are three main problems that I am aware of:

1. You can’t transfer the app to another Google account without also transferring the signing key (which the receiving entity requires in order to distribute software updates).

If you use the same signing key for other apps that you have written, you will probably be very reluctant to transfer it, because doing so will, in principle, give the recipient the ability to issue updates for your other apps, as well as make use of certain Android resources that are shared between your apps – such as custom identity providers (which may be unique to your particular “ecosystem” of apps) – which, in turn, may make it impossible for you to meet your legal obligations to your customers.

It will also, perhaps more importantly, mean that you no longer have control over the key’s security. This will be important to you if you want to continue supporting your old apps (which are also effectively “tied” to their original key), ensure your customers’ security, and release new apps of your own that are tied into the same identity ecosystem.

Releasing the new app under a separate package name does “solve” the problem – but only at the cost of automatically losing all of its existing customers, which may quite probably defeat the purpose.

2. You can’t transfer the Ad Units to another Google account – which the receiving entity needs in order to receive your Ad revenue.

It is true that once you have transferred the app, you can issue an immediate software update changing the Ad Units to ones owned by the receiving entity. However, in general, it is not compulsory for users to accept updates, and I have heard horror stories of app developers’ revenue streams falling off dramatically after they have been required (because of upgrades to Google’s platform) to switch their existing apps to new Ad Units – presumably because many users do not accept the update, and therefore continue to use a version of the app that uses the old Ad Unit.

One reason why users might switch off automatic updates is to save on bandwidth charges. Once a user has done this, each update is effectively “opt-in” and many users will simply not bother.

3. You can’t transfer your liability to another entity, under the Google Play Developer Agreement. (At least, without getting special approval from Google – and good luck with that.)

This is a particularly nasty one. Let us suppose that company “A” wants to buy your app. Company “A” is in the business of managing and supporting apps, and is willing and able to accept full legal responsibility for it from that point forward, as part of the purchase deal.

Now, you also give company “A” the app’s source code as part of the sale, and at some point it will release an update to Google Play. However, suppose that 50% of the existing (active) users choose not to update, and therefore carry on using the app in its prior state. These users received the app before the transfer, and therefore, full legal responsibility for their use of the app rests with you, according to the Google Play Developer Agreement. Moreover, this responsibility is non-transferable, and so it remains with you, even after the transfer of ownership. If someone decides that the app is infringing their IP (for example), they will not only be able to sue company “A” – they will also be able to sue you.

Now, I can see simple technological solutions to points 1 and 2 (requiring action by Google, unfortunately), and I can see that in principle it should be possible for Google to implement a legalistic solution to point 3.

Technological solutions

My solutions to points 1 and 2 are as follow (in reverse order):

2. The existing signed app (apk file) already functions as, effectively, a signed “request” asking the Android OS to use a particular Ad Unit. The cryptographic signature certifies that the request is from the app’s owner. This helps to keep the system secure, preventing a third party from forging a “request” and redirecting the ad revenue to their own account. A new signed request, changing the Ad Unit, is at present created by uploading a new signed apk file (i.e. an app update). The “request” is then honoured on a per-user basis, when (or if) they decide to accept the update.

However, there is no technological reason to require this particular protocol. A better protocol might be to allow the owner to sign a “request” consisting of only the unique package name of the app, the old and new Ad Units, and a special identifying code indicating the type of request being made (e.g. “ReplaceAdUnit”) (plus a timestamp). So the request might look something like this:

1400251570 ReplaceAdUnit com.mycompany.myapp 8f3b24fc 332bce29

After this has been signed using the normal signing key for com.mycompany.myapp, and then uploaded to Google, all requests from this particular app to the Google Ads API requesting Ad Unit “8f3b24fc” can instead be served using Unit “332bce29”, from the request timestamp (represented by 1400251570) onwards until any further such requests are made. Any further requests can change the Ad Unit again by referencing Unit 332bce29 – and requests for 8f3b24fc, as well as 332bce29, will be redirected to the new Unit (and this can be repeated indefinitely – the Ad Units will form a chain that can be followed iteratively, always picking the newest record and checking for monotonically increasing timestamps).

1. The solution to problem 1 should now be obvious. Another type of signed request can be created. Instead of replacing the Ad Unit, this time the request is to replace the signing key – perhaps call it ReplaceSigningKey. The request then consists of this operation identifier, plus the unique package identifier of the app, and the fingerprint of the new key (plus a timestamp). From that moment onwards, all updates to the app, as well as (naturally) all further signed requests, must be made with the new key – the old one will no longer work (this is important because the entity you are transferring it to may not want you to retain the ability to release signed versions of their app). No connection is established between the new and the old key – the new versions of the app will be within a new “domain” as far as Android is concerned, just as usually happens when a different signing key is used. Again, this helps with transfer-of-ownership scenarios.

This also, incidentally, helps ensure key security by allowing you to expire your old keys (in case they have been compromised).

Unfortunately, this change probably requires changes to the Android OS on each individual device. I am not sure how feasible this would be. It may be possible to implement it through an update to the Google Play app.


In the case of point 3, it is clear that Google is placing legal restrictions that are artificially restricting the rights of individuals and businesses through Google’s monopoly-position on the provision of this particular type of publishing contract. Google Play is currently one of the world’s largest markets for computer software, and individuals and businesses cannot simply decide not to publish through Google Play: it is a practical necessity for certain types of business activity in today’s changing world. Therefore, by failing to include provisions for reassignment of liability in their standard publishing contract, it could be argued that Google Play is here abusing its monopoly position.

What may not be so clear is that the same argument could be applied to points 1 and 2. In both cases, Google is failing to provide the necessary flexibility for its users to carry out their business activities with the freedom to isolate, buy, and sell, business units as appropriate, making their cloud data usage securely separate as and when it is found to be appropriate. It is therefore, effectively (whether intended or not), forcing its customers into a certain pattern of internal organization, as a condition of performing certain activities that are necessary to their normal functioning as businesses – which could also be seen as an abuse of its monopoly position.

Leave a comment

Filed under Law, Software industry

How eBooks should work

All eBook distribution systems should be subject to the same regulations (mandated by law).

Regulations should be:

  • Transfer of ownership – always allowed, but with a minimum period of ownership to prevent abuse (say, 1 month).
  • Transfer between devices owned by the same person (even across different services owned by different companies, provided that both companies provide the same material, excepting only major differences in content*) – always allowed, unlimited with no restrictions, and never otherwise prejudicing the nature or quality of the service (or the relationship between the company and its licensee) in any way, should take only moments (no more than, say, 30 seconds).

* “Major differences in content”

In all cases where content is licensed sometimes as a whole, and sometimes in part (and perhaps to different companies), OR where it is sometimes licensed alone and sometimes with additional material, the content should be addressable by part (where each part constitutes a component that is always either present in total or not present) and each addressable component should be individually transferrable between devices (and between owners) as above. This is to prevent the situation where additional content is added in order to prevent transfer to a rival company’s devices where part of the content is provided but the additional content is not.

The software should in addition be set up to make it easy to transfer exactly the intersection of the components of a given work sold as a unit provided by the sending service with the components provided by the receiving service, and also to transfer the components back to the sending service if and when needed and reconstitute them into the original work, even after they have undergone arbitrary transfers to and from other services, and even if they are transferred back from a third service, whether they come back in part or in whole. In addition, components transferred in this way must always be just as easily accessible to the user on the receiving service as they are on the sending service, and they will be considered to constitute a single “work” while residing on the second service, and while involved in (and after) any transfers onward from, or back to, the second service. In addition, when only some of the components are present, these components must be just as easily accessible as when all components are present, such that the user experience is the same except for the omission of the missing components.

Copyright notices and other legal requirements should not be considered components for the purposes of this “law”, and must be present in all instantiations of any set of components, regardless of completeness. Determining the set of legal notices required for a given set of components shall be the responsibility of the company on whose systems the components in question currently reside.

Other content-distribution systems may benefit from the same framework, perhaps with further modifications to prevent the spirit of the law from being abused by the content licensing and/or distribution companies.

I’m still not sure I’ve got it all pinned down yet, but it’s a start at least.

The biggest problem I can see with this so far is the requirement for authors to release content in indivisible, unalterable “components” that must be invariant across different contracts. In particular, what if an author wants to publish several editions of a work… And what about the specifics, like what happens if one version contains a few corrections not present in another version… I think the latter would come under “minor differences” and therefore not matter. Editions should usually be regarded as separate works, except that it is true that they may share large parts of the work in common. I think it is probably most desirable that these constitute the same component wherever possible (where there are only minor differences), for maximum transferability. So the result will be that, in effect, all subsequent editions of a work will be considered to comprise the original work, plus a set of new whole components unique to the new edition… except where major changes have been made to the old components.

I think there will have to be something to require the companies to stock all editions of a work, rather than just the newest one, so that people’s old purchases don’t become unusable over time (perhaps as old content services go out of fashion – or indeed out of business).

That raises the other issue I have been thinking about, namely that of a company’s demise. To my mind there should be a government guarantee of the right to your content, even in the event of the providing company’s collapse. I don’t know what kind of guarantee, if any, is currently provided. But it certainly doesn’t seem right that you should pay for some content in the manner of a book purchase (which I think most people agree should provide you the content forever, provided you look after it), and then simply lose it because of market forces. Of course, the device transfer features should make this less of an issue, but there is still a risk here.

Leave a comment

Filed under Law