26 Nov 2016

A Commercial Reuse License Can Be the Best of Both Worlds

There's a lot of duplication in the software world. When you build an app, it's almost always similar to an existing app, a new take on an existing idea, rather than doing something that no other app did before. Most apps are variants of other apps, conceptually [1].

So, logically, you'd expect to take an existing app and modify it, rather than starting from scratch. All email apps, for example, have to retrieve mails and attachments from a server, cache them locally, sync offline changes back to the server, handle flaky connections by not blocking the UI for the network, search, send new mails, handle multiple accounts, and so on. In terms of UI, they all display mails, threads, an inbox, sent, drafts, labels / folders, search and search results, perhaps a two-pane UI, a way to see mails for a particular account or all accounts together, and so on. So, if you're building an email app, it would be best to start with the source code of the app that's closest to what you have in mind, and implement only what makes your take unique.

But that's rarely possible — you end up coding everything from scratch. Not just the code, but also technical design, investigating and selecting third-party libraries, debugging, optimisation, and UX design.

Having every app reimplement the same stuff is wasteful, in time, money and energy. It adds no value to the world, just as you'd be unlikely to add value if you decided to manufacture staplers rather than using one that already exists.

Open-source does away with this waste [2]. You start with an existing codebase, and implement only what makes your app different. You implement only the diffs. But open-source makes it hard to sell your app for a price, because someone else can always distribute it free or cheaper. This rules open-source out for independent developers and small companies. Everyone but giant companies that have some other revenue stream so huge that funding an open-source project pays for itself by increasing profits from the main revenue stream.

As an independent app developer, I can't, and don't plan to, open-source my apps. But that prevents others from adding value on top of my work, say by adding a feature, or building a better variant of my app.

We need a middle ground where I can permit others to add value on top of my work, without cannibalising my income.

Here's how such a license would work: Suppose I have an app I sell for $10. I release the code under a "commercial reuse" license. This license says that others can download the code, modify it, and distribute their version, provided the licensee pays me $10 for each user they have.

The licensee can charge more, and keep the rest. So, if they sell it for $15, probably because they've added value to command a higher price, they keep $5, and I get $10. Licensees can also charge less, like $6, and pay the difference of $4 out of their pocket, while I still get $10. Or give it away free and pay me the entire $10 out of their pocket.

With such a license, I no longer have to worry about the licensee undercutting me, say by selling it for $6, since it doesn't decrease my own income. Since I never lose money, and only potentially gain money, I have little downside in licensing my code this way.

This, at one stroke, solves the problem with open-source, that it's not as good at generating money. And solves the problem with closed-source, that others can't add value on top of your work.

Ensuring I get paid what I normally get paid also eliminates the conundrum of whether the licensee is adding more or less value and me, and how much much more (or less). These are impossible questions to answer in a way both sides would agree with, so asking them will prevent the deal from getting done. The commercial reuse license sidesteps those judgements. I no longer have to estimate the value the licensee added. I can leave that to the market.

If I increase the price of my app to $20 after someone signs a license agreement to give me $10, the change doesn't affect them. They still owe me only $10 per copy. That prevents me from pulling the rug out from under them. Which in turn frees the licensee to invest. The license price would be the price as on the date of signing the agreement [3], and future increases or decreases don't affect the licensee.

The licensee will be able to sell their version using a one-time fee or subscription, independent of which of the two I've chosen. That gives both sides flexibility to run their business as they see fit [4].

The license includes a patent grant, so that I can't release the code for, say, a file sync tool and then sue the licensee for syncing files.

The license doesn't include a trademark grant, so people can't use my name, logo, icon or tagline. They can't claim their modified version is the original, confusing users. In the worst case, by creating a version with malware to sully my brand.

Licensees don't have to distribute the source code for their modified version. In that sense, this license is like Apache or BSD, not like GPL. That preserves maximum flexibility for the licensee. If they do distribute the code, they should do so under the same license, so that downstream licensees pay me the $10 I'm due for each copy. [5].

There would also be a maximum limit on the money any single licensee owes me, like $10 million. Which is enough money for me to retire. This lets someone convert a paid app to a free app, if they can see more value by doing so. If I make a Gmail native app for the Mac, and Google decides it’s useful for their users, they could decide to pay me $10 million and make it available to all their users, rather than having to pay me $10 per user, which may work out to much more. Unlimited liability would prevent potential licensees from reusing my code, defeating the purpose of the license.

The license could also have an exclusivity clause. This says that if a licensee reaches the maximum limit, $10 million in the above example, they will have exclusive rights. Which means that they can tell me to stop distributing my version of the app, to delete the code [6], and to never license it to anyone else in the future [7].

This is like an acquisition [8], but one with terms that are transparent and documented publicly, as opposed to having to be negotiated in private, which is painstaking and may prevent a deal from happening even if both sides would benefit from it, simply because it's a big overhead in time and opportunity cost for both sides. Paul Graham recommends not talking to acquirers unless you're sure you want to sell, because it's such a distraction. This license lets the deal be done automatically. People who want an exclusive license can just pay you, and the deal is done.

Having looked at the financial aspects, what kind does this license enable? If some were to license my app this way, what kinds of changes can they make?

They can add a feature. Or a remove one that's unrelated to the main functionality of the app, or is confusing to use, and takes away rather than adds to the app. Or rework the UX.

Licensees can port the app to a different platform, like mobile vs PC. Or iOS to Android. Or sell the app using a different distribution channel, like the Amazon app store, which I have no interest in.

A licensee might sell my app along with theirs, as a bundle. Or they may have no app of their own, and merely identify a collection of existing apps that works together especially well, and sell them as a bundle. Perhaps after modifying the apps to work together as a group, like Word and Excel in Microsoft Office.

Licensees may go after different users, like the enterprise market, and sell via a sales force, which I have little interest in, as I focus on the consumer market. Or they may customise the app to a niche.

Licensees may sell support along with the app, perhaps with a 24x7 helpline, which I can't offer. With access to the source code, to almost everything I have access to, they'll be able to do a good job of support, assuming they have competent engineers.

A licensee may choose to sell a white-label version of my app to third parties to sell as their own app.

All these possibilities open up for others to add value by doing I didn't do, or wasn't interested in doing, or couldn't do. They can make money, and so do I. In the worst case, I don't lose money. There's no reason for me not to license apps I build for others to build upon.

[1] With rare exceptions like Uber which, when it came out, did something nobody else did before. But most apps are remixes, not completely new inventions.

[2] Except for license incompatibility, like not being able to use a GPL library in your Apache project. Or even a GPL3 library in a GPL2 project, which is stupid.

[3] Ignoring temporary discounts.

[4] To convert between the two, the license will state a reasonable subscription duration, like 2 years. That is, if I'm selling a subscription for $1 per month, then the licensee can sell a subscription for $1 a month or a one-time $24. And vice-versa. Or choose other subscription periods like $2 bimonthly, $3 a quarter, $6 half-yearly or $12 yearly.

[5] Otherwise, there's a glaring loophole that renders the entire license useless: someone can build a variant, and license it to their spouse to distribute, keeping all the money themselves.

[6] And all other confidential information about the app, like mocks, sketches, business plans, and so on.

[7] Pre-existing licenses would remain valid, of course, but the money from them would go to the acquirer, no longer to me.

[8] Though they don't get the users, or the existing brand name — that will require traditional face-to-face negotiation.

No comments:

Post a Comment