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) . 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 , 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.
 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.
 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.