The Delayed Public License

Say you’re an open source developer and you want to write a mobile app (in my case, for the Ubuntu phone).

You put some effort into it, and you think it would be nice if you could get a little revenue back for your efforts. Mobile stores make it very easy to do this, either from upfront payments, in-app payments (IAP), or ads.

The problem is that if you open source your app, anyone can fork it, strip the payments or ads (or re-code the app to pay themselves instead), and re-upload the stripped app to the store. Which, while it may not seem fair, is something that you explicitly allowed by choosing an open source license.

I don’t like the forced choice between either receiving no renumeration for your time or closing your source code. If I die or lose interest, I’d still like the world at large to be able to build upon my code.

Open source developers have been used to receiving no renumeration for their time for quite a while. 🙂 But it’d be nice to change that, or at least allow those that are interested in doing so to try to earn some revenue by traditional means.

This isn’t an issue that was invented by mobile stores. You always could have had IAP or ads in your open source project and have had to worry about Debian maintainers stripping them out or being forked. It’s just that using IAP or ads before mobile platforms existed was very difficult.

The Delayed Public License

Some Ubuntu app developers were talking about this issue recently, and we came up with the Delayed Public License (DPL) [1]. It’s basically a meta license, that toggles between all-rights-reserved and a FOSS license after a set amount of time. In plain terms, something like:

All rights reserved. Every code commit can be licensed as GPL-3 one year after its publication.

  • You can still host your code in a public repository. Even though the code is public, it wouldn’t be legal for anyone to use it until that year is up. People are still welcome to fork your code, but they have to fork it one year back in the commit history.
  • You would release your app to the store as a closed source app. You can do that despite the DPL, because you own the copyright to the whole project. But people could still get the code from your repository.
  • Unlike a closed source project, you can still accept patches. Though you’d need a CLA of some sort.
  • The FOSS trigger is automatic. So you can’t forget or change your mind. And it’s easy to do; you don’t need some code escrow service.
  • When using the DPL, you obviously aren’t stuck with GPL-3 or a delay of one year. You can choose a different FOSS license and time period to suit your own needs.

While this meta license wouldn’t be be OSI approved [2], it still feels open source.

I’d love to hear more legally-binding ways of phrasing the license. Tying each VCS commit to its own publication timer might not be trivial to express legally.


[1] The idea came from a discussion between Michael Zanetti, Stuart Langridge, Sturm Flut, Ted Gould, and me. Credit for the name goes to Sturm Flut.
[2] Which means you have to be careful about picking a hosting provider. Launchpad for example will only host you for free if you use a FOSS license. GitLab would allow a DPL project. I’m not sure about GitHub: you have to pay for private repositories, but I don’t know about a public, non-open-source repository.

7 thoughts on “The Delayed Public License”

  1. Hmm… This sounds very much like the model used by ID Software for their older game engines (Quake for instance). It’s a good compromise model for software that has to be financed through sales, like games and other one-off software.

    Software development usually is funded through other means though. Most often it’s funded by companies paying developers to create software they specificly require. Not software to be sold, but to be used. Only a tiny percentage of this is sold.

    This is also reflected in the App economy – The chances of actually getting paid for the time invested in an App is like one in 100. If we exclude the gaming industry it’s even less. Therefore, depending on App income is like depending on winning the lottery. A few will of course win big, most won’t. But that’s an entirerly different discussion. 🙂

  2. Couple of thoughts…
    * If it’s “all rights reserved”, how can you accept patches? The readers of the code wouldn’t be allowed to modify it, strictly speaking…
    * What’s to prevent legally unscrupulous people from using the code to provide their own versions of your project? There are enough shady goings-on in app stores to make me think that earning a living there selling apps whose code is available (even if not legally usable) is probably well-nigh impossible.

    You might find interesting, it discusses the requirements (or not) for a license such as the DPL.

  3. Here’s a hypothetical, but not too unlikely scenario.

    You release version 1.0 of your project under the DPL. A year later, it becomes free software and can be integrated in distros, for example in Debian.

    And here comes a big security issue in your project, which you quickly fix, and release a 1.1 version.

    At that point, the 1.0 version in Debian has a known security issue, which they just can’t fix because the needed patch has not yet passed the 1 year after which it becomes free software.

    How do you propose resolving such a case?

  4. Given how having a CLA did work for Canonical to get a external community around projects (for example, Upstart), this sound like a bad idea.

    Also, if the goal is that you start to get money, how much would someone sending a patch get ? For example, someone sending a complete software translation to china, thus unlocking a complete new market for you.

  5. @Stephen Kitt, people can’t *distribute* all rights reserved code, but they still own the copyright to their own patches.

    There’s nothing stopping someone illegally taking the code. But same for GPL violations today. Villains will be villains. I think the main goal is stop well intentioned people. And you have some recourse/evidence when trying to get a forked app removed from the store.

    Thanks for that stackexchange link! Basically the exact same issue/solution as my post.

    @bochecha, well you (the app developer) aren’t necessarily the maintainer of the Debian “fork”. If you *want* to assume responsibility for it, you can simply additionally release security patches as GPL-3 immediately. Or just let the maintainer that forked your repository make their own patch for the issue.

    @Michael, sure. Using a DPL and/or CLA would probably reduce incoming patches. But maybe a developer will think it’s worth it.

  6. I like this idea. I was hoping for it to become a lot more mainstream as Kickstarter and other crowd-funding platforms took off. It seems perfect for games: if the crowd funds us at this level, we will legally bind ourselves to open source the end-result eventually.

Leave a Reply

Your email address will not be published.