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

New DFA/LALR compiler stuff in Ruby

Just put the following into the README for my new GitHub project, which is basically the DFA/LALR core of compiler framework. I think it just about sums up everything you need to know. 🙂

This is one of those bugs that bites me from time to time. I find myself wanting to design my own parser/compiler for something. Then I decide I don’t like any of the available parser/compiler frameworks, and I want to design one of my own. For some reason, I decide recursive descent is too wimpish. (even though it’s used by GCC now…)

Well, that’s not the point. If you’re going to do it yourself, you might as well bite the bullet and do it the hardest way possible.


And yes, I know Ruby has things like String#scan, but that’s NFA, dammit! Non-deterministic Finite Automata. If people have gone to all sorts of lengths to make DFAs optimal and Deterministic, there must be something in it! (maybe 50-odd years ago, I know…)

And yes, it’s true, I haven’t checked to see whether there already is something like this out there for Ruby. Except that I know there is at least one NFA/recursive-descent based framework already (TreeTop). Which is probably perfectly fine for any conceivable purpose. I’m just insane.

Seriously, this isn’t really finished. It needs a good facade or two built around it, and then a couple of command-line tools perhaps…


Leave a comment

Filed under Compilers

New open-source dictionary for FBReader on Android

I’ve just finished work on a new dictionary for FBReader on Android (FBReaderJ). The code is on my github account (a fork from geometer’s official version, which is available from the official website or the official github account). It doesn’t look like much at the moment, and frankly the code’s a little bit of a mess, but it reads the dictionary files! And it puts words on the screen! Seriously, what more could you ask for??!

Anyway, the main reason I wanted to do this was that as far as I could see there didn’t seem to be a suitable open-source Android dictionary app to go alongside FBReaderJ. At the moment the only option is to install a closed-source App, which FBReader uses as an external service. This meant that there was nothing to work on to make the customisations I wanted to make. So I thought I’d remedy the situation!

What customisations, you might ask? Well, it may sound silly, but one major thing was that I wanted to be able to move from one entry to another without having to press the screen twice. The existing support requires you to press the screen to make an entry disappear, before pressing it again to bring up another one. Small, but can have a high impact on usability, particularly for a language learner.

Of course, I’ve since realised that my efforts were probably largely unnecessary. I probably didn’t have to reimplement StarDict dictionary support for Java – that was already available as part of the (mostly extinct) babiloo project, it seems. Also, I possibly could have figured out how to use the Android APIs to do a textual query to some service provided by (closed-source) ColorDict or something (not sure about this; what I’m really thinking of is the Android Quick Search Box functionality, and as far as I can see [from this page], it brings up its own dialog on screen). Also it’s just occurred to me that I might have been able to get the ColorDict Activity to behave in a similar way by giving it some kind of rendering hints in the Intent or something. I don’t know.

On the other hand, there are other customisations that I want to make, but more on those another time… 🙂

Well anyway, here’s a free screenshot in case you don’t believe me. 🙂 As you can see, it’s not displaying the whole entry (but this should be comparatively simple to fix). The text is from WordNet, I believe.

Right, now I’m off to bed ’cause it’s one o’clock in the morning. Either that or to stay up all night coding on my next crazy idea. Not quite sure yet.

Leave a comment

Filed under EBooks

Turning ePub chapter end-notes into “popups”

Lately, as part of my efforts to learn French, I’ve been trying to read Rivarol’s French translation of Dante’s Inferno on my Android mobile phone. I’ve mostly been using Kindle, but I have also tried FBReader. I’m not sure what format Kindle uses, but with FBReader(J) I’ve been using the ePub version from gutenberg.org.

One problem I’ve been finding is that all of the end-notes are at the end of the chapter (as you might expect), and it is hard to flip back and forth between the end-note and its reference. To remedy this, I decided to find a way to make the end-notes appear as “popup” boxes over the main text. Unfortunately, this was not directly possible with the fairly limited ePub format (or, at least, not with FBReaderJ). A simple solution was to (1) put all of the end-notes at the end of the document, rather than the end of the chapter (so that you wouldn’t have to skip over them), (2) create hyperlinks allowing you to jump back and forth between each reference and its corresponding end-note, and (3) put a page break after each end-note entry so that you only see one at a time. To achieve (3), one way in FBReaderJ is to simply put a new level-2 heading at the start of each entry, which causes it to be put on a new page.

Luckily, the ePub format is very simple, consisting of just a few XML files contained in a ZIP archive, with the actual content being stored in XHTML format. My usual approach to this kind of problem would be to hack something up in Perl using regexps. However, this time, I decided to do something in Java, partly because I had some kind of idea that I might try to integrate it into FBReaderJ at some stage. This has probably led to it taking twice as long and ending up twice as complex, but on the other hand it has improved my knowledge of Java’s XML libraries.

Here is an example of the result, looking at a paragraph from Dante’s “l’Enfer” chapter 18 (the text is public-domain). Notice the blue link reading “[end-note 1]”. Before processing, this was simply “[1]” (and not a link). I added “end-note” to make it a bigger target.

And here is what you get if you click it:

…And there’s a link back to the reference’s location in the main text. As you can see, the link text I have added is in English. In retrospect, perhaps it should be in French :).

It took surprisingly long to write the code for this, considering how simple it seems now. But I did have to update the OPF descriptor file, and the toc file as well, and create tables of all the relevant ids to create the links, and then separate the end-notes out into a separate document so they could all go at the end without risking hitting some obscure ePub file size limitation, all while wrestling with the w3c DOM in Java… you get the picture :). I think my program should work with all of the rest of the ePubs in the same series (Rivarol’s French Dante – so far I’ve only tried it with l’Enfer [Inferno]), and it should be fairly easy to adapt it to work with slightly differently formatted documents.

I am continuing to work on trying to make FBReader a better platform for language learning. I have a funny feeling my next stop is going to be to do something with ColorDict…

Leave a comment

Filed under EBooks

Chinese font with magic embedded Pinyin!

I’ve just about finished working on a new Chinese font (actually, an extension of WenQuanYi Micro Hei) that includes something I like to think of as “Pinyin characters”.

UPDATE: you can now download the font, and code, from my github repository. Just click the button that says “ZIP”.

Basically, each Pinyin syllable in the chinese text is converted into a character-sized block containing the Pinyin. The tone mark is also moved and enlarged to make it more visible. At the moment, the Pinyin must be entered using numbers for tones, and colons for umlauts, with a space after each syllable, as in “nu:3 ren2 ” (if you’re wondering, the space forms part of the “ligature”). The conversion happens automatically if your browser or application is set up with proper ligature support, and with the font correctly installed. I have currently managed to get this to work in both gEdit (a text editor) and Google Chrome on Linux. With a little work, it should be possible to get it to work in recent versions of IE and Firefox too (and probably on Windows/Mac as well as Linux).

The characters are generated automatically by a Python script, which needs to be imported into the FontForge user interface. The whole set is generated (on my PC) in under 10 minutes, and takes up slightly less than the whole “Private Use” area of Unicode (and also just slightly less than the maximum allowed number of ligatures in “liga”, I think).

First, here is a sample of some Chinese text with embedded Pinyin, using the standard “WenQuanYi Micro Hei” font, displayed in Google Chrome:


And here is the same text in my modified font, still in Google Chrome:

Note that the only difference here is that a different font is selected! The text is identical. Same characters, same number of characters; just some of them are grouped into ligatures. There is no need to re-encode the Pinyin; and saving to a file from gEdit (for instance) causes the original Latin characters to be saved, not the ligatures.

Why would I want to do this? Well, as with most of the things I do, it just seemed like a good idea at the time, I suppose. But the principal motivation really was that I have read online that one of the main reasons for the Chinese not using Pinyin more is that it doesn’t look right alongside Chinese characters. So I thought, what if I could change that? If Pinyin was made to fit in better with ordinary Chinese characters, would the Chinese start using Pinyin more? Would they find it useful? Or does it miss the point? I think it would be interesting to find out.

Leave a comment

Filed under Chinese