This is a guide to License Zero, its primary documentation. If you’re interested in using License Zero to fund your work, read this guide. If you spot ways to improve it, open a pull request or send an e-mail.
Software licenses are key to how License Zero works, and this guide will describe a few. But this guide is _not_a guarantee that any particular license will work for you. The License Zero terms of service say so, and they apply to this guide, too. Think for yourself!
License Zero is a toolkit, a platform, and a plan for funding open software developers. Using License Zero, developers can make new kinds of deals with users. Either:
You can use my work to build other open software for free. But if you want to make closed software instead, buy a license online to support me.
You can use my software for personal, educational, and other noncommercial purposes for free. But if you want to use my software for business, buy a license online to support me.
Sound familiar? It’s the model of leading developer services like GitHub. It’s the crux of more recent “open core” companies, like MongoDB and Elastic, that charge for features businesses want. It’s the model of a much older generation of companies like MySQL, Qt, and Artifex. Outside of software, it’s the model of countless independent stock photographers, B-roll videographers, production music producers, and beat makers.
Now it’s a model for independent library, framework, developer tool, and app makers, too. Finally.
In the past, developers usually had to form companies and either hire outside help or essentially stop programming to sell more than a handful of closed or commercial-use licenses. Doing more meant investing substantial personal savings, raising venture capital, or taking on debt. License Zero standardizes and automates the back-office operations of terms management, payment processing, and recordkeeping, so developers can scale up while staying focused on building and promoting great software. Selling through License Zero costs nothing but a little time up front, and scales to a practically unlimited number of sales per day, at pricing of your choice.
License Zero is not a donation platform. Users pay for licenses through License Zero because they need them, just like they pay for Amazon Web Services, Microsoft Office, or the toner in the printer. If software helps do a job, the cost of a license for it should be expensable. When tax time comes, it might also be deductible. After all, it’s not a gift, a favor, an act of charity, or a pat on the head. It’s just business.
This guide begins with a step-by-step guide to offering licenses through licensezero.com.
From there, it takes a deeper dive into the business model. The implementation details take the form of three kinds of forms: License Zero’s free license choices, Parity and Prosperity, the private licenses that customers buy, and freebies, or free private licenses.
The next section gives an overview of licensezero.com, followed by an introduction to Artless Devices, the company that runs License Zero.
The final section addresses frequently asked questions about how to use or accept code from others in projects being sold through License Zero.
Start selling through licensezero.com in ten easy steps:
Download the command-line interface by running this script in a terminal:
curl -sL https://licensezero.com/install.sh | sh
The script will install a single
licensezero executable on your search path.
Give the command-line interface some information about yourself:
licensezero identify \ --name "Jane Developer" \ --jurisdiction "US-CA" \ --email "firstname.lastname@example.org"
The jurisdiction argument is an ISO 3166-2 standard code for where you live. See jurisdictions.licensezero.com for a list of all supported countries and subdivisions.
Use the command-line interface to register with License Zero:
Follow the link sent by e-mail to connect your Stripe account to License Zero. If you don’t have a Stripe account yet, follow the instructions to create one.
Save the licensor ID and access token licensezero.com gives you:
licensezero token --licensor bdf5dbb7-5823-41bb-a7a8-07cb5c9739ea Token: *************
Enter your secret access token at the prompt.
Change the license for your project to Parity 7.0.0, the free for open source license, or Prosperity 3.0.0, the noncommercial license. You can download a plain-text
LICENSE.md copy of Parity 7.0.0 or Prosperity 3.0.0 and replace the variables at the top. The identifiers for
package.json or other package metadata files are
Offer licenses for your contributions to the project for sale:
licensezero offer \ --price 1000 \ --repository "https://github.com/licensezero/example" \ --description "demo project for License Zero"
Specify your price in United States cents.
100 is $1.00.
1000 is $10.00.
Add the offer link that licensezero.com provides for you to your project’s documentation. If your packaging system supports funding messages, as does npm, consider adding your offer URL there, as well.
Tell the world about your project! Nobody buys licenses for projects they’ve never heard of.
E-mail Kyle, who’ll get you plugged into the License Zero user group. We will help you tell the world.
People tend to skip over code listings. Don’t skip this one!
def licensing(user, contribution): # See "Public Licenses" below. if user.meets_conditions_of(contribution.public_license): contribution.public_license.permit(user) else: # See "Private Licenses" below. private_license = user.private_license_for(contribution) if ( private_license is not None and user.meets_conditions_of(private_license) ): private_license.permit(user) # See "licensezero.com" below. else: license_zero.buy_private_license(user, contribution)
As an independent software developer, you control who can use your software and under what terms. License Zero’s licenses, Parity and Prosperity, give everyone broad permission to use and build with your software. However, each license comes with a catch. Parity requires users to share work they build with your software back as open source. Prosperity requires users to limit commercial use of your software to a limited free-trial period.
licensezero.com can help you sell licenses that allow what Parity and Prosperity don’t: use in closed projects and unlimited commercial use. Stripe processes the payments directly to an account in your name. licensezero.com handles taking orders, formatting licenses, and sending receipts.
This public-private licensing model, also know as “dual licensing” or “selling exceptions”, is not new. In fact, it’s one of the oldest business models for open source software. L. Peter Deutsch and MySQL pioneered it decades ago, and important projects like Qt and MongoDB continue it today. License Zero evolves the public-private licensing model by making it work for more kinds of software and by making it practical for independent developers who can’t or don’t want to set up companies, hire sales teams, and write custom legal terms.
License Zero starts where you exercise your power as the owner of intellectual property in your work: in your project’s
LICENSE file. Since license terms in
LICENSE files apply to everyone, we call them “public licenses”. Later on, we’ll distinguish them from the “private licenses” that you sell to individuals.
You might currently use The MIT License, a BSD license, or a similar open source license there now. License Zero offers you two alternatives:
The Parity Public License works a bit like the Creative Commons Share Alike(https://creativecommons.org/licenses/by-sa/4.0/) or the AGPL, but requires users to release more of their own code, in more situations. Parity requires users who change, build on, or use your work to create software to release that software as open source, too.
The Prosperity Public License works a bit like a Creative Commons NonCommercial license, but for software. Prosperity gives everyone broad permission to use your software, but limits commercial use to a short trial period of thirty days. When a commercial user’s trial runs out, they need to buy a private license or stop using your software.
Both options are short and readable. You should read them. Both licenses have improved massively with developer feedback.
Most developers will ask themselves two simple questions:
First: Will people use your software to build other software? If your software is a library, framework, developer tool, or deployment tool, they likely will. Continue to the next question. If your software is a complete application or plugin, and not a software development or deployment tool, they likely won’t. Choose Prosperity.
Second: Do you want to let people use your software in business for free, so long as they release software they build with as open source? If you do, choose Parity. If you don’t, choose Prosperity.
The logic behind these questions is simple: If you give away all the permission people need for the primary use case of your software, you won’t have anything left to sell. Very few people will need any additional license, and fewer still will buy one.
The differences between Parity and Prosperity reflect some political differences that you might want to be aware of.
Prosperity is not an “open source” or “free software” license as most understand those terms. Source code for Prosperity software can still be published and developed online, using many popular services like GitHub and npm. But many developers will not accept it as part of their movements, and perhaps criticize you for referring to it as “open source” or “free software”.
Parity, on the other hand, was written specifically to offer License Zero users an open source license option.
An early version of Parity was proposed to the Open Source Initiative’s license-review mailing list for approval in September of 2017. The idea was to discuss the license in one place, for the benefit of all users, rather than having the same conversation a bunch of times all over GitHub and other social media.
Alas, the debate at OSI dragged out, flamed over, and eventually ground to a halt. Many of the causes were procedural. Neither the standards nor the process for approval were clear going in, and they did not become clear before going out. The public documentation for the process at the time, written by a prior OSI board member, better reflected a plan of overdue reform than reality.
In amongst the meta diversions, personal insults, appeals to authority, and attempts to have the submitter kicked off the list via back channels, substantive criticism came largely from two angles:
First, many participants in discussion loathed the dual licensing business model, understood that the license was written to enable it, and condemned the model by way of the license.
Dual licensing and new, stronger copyleft licenses for dual licensing are nothing new. Attacking them as “not open source” is.
Numerous OSI-approved licenses have been used for dual licensing in the past, from the popular GNU General Public License, Version 2 through to the Open Software License and Affero GPL. OSI approved several licenses written specifically for dual licensing over its history, such as Sleepycat, Q Public License, and Reciprocal Public License versions 1.1 and 1.5. When these licenses came up, some insisted that OSI made mistakes—repeatedly—and should retract approvals. When it came to which licenses, exactly, should be retroactively booted, opinions varied widely.
The Open Source Initiative did not take any decision on the license that became Parity. They did not approve it and they did not reject it. It was unclear how to get a definitive decision either way.
What we learned, through the process, is that we don’t care. The Open Source Initiative does not own the phrase “open source” as its exclusive intellectual property. The bedrock of its claims of authority over use of the term—a rigorous, technical definition, a reflection of broad-based consensus—don’t hold up. Which is why it feels a need to issue press releases and call in favors. It’s politics, not principle, though it clothes itself in principle.
As for “free software”, Parity is probably not a “free software” license as defined by the Free Software Foundation.
FSF’s definition of free software requires granting freedoms to run, copy, distribute, study, change and improve software. It also recognizes that some conditions on those freedoms can enhance “software freedom” overall by ensuring that others receive source code and freedom to work with it. This is exactly the approach Parity takes.
However, FSF’s definition of free software admits only conditions on the freedom to share modified versions with others, along the lines of the GPL licenses that FSF has published, and not conditions on other freedoms. That partially explains why the Open Source Initiative approved RPL‑1.5, a thematic predecessor of Parity, while FSF considers RPL non-free. It does not explain why the FSF’s own Affero GPL license, which requires sharing alike when you run a modified copy of a web service, gets a pass.
In the end, your software is yours to license and market as you choose. There are no United States registered trademarks on “open source” or “free software” to stop you using them for your work. Politics and power plays around those terms may or may not matter to you, and they may or may not matter to your users.
Users who can’t meet the conditions of the public
LICENSE terms can buy a private license that allows them to use the work without meeting those conditions. License Zero publishes a form private license, and sells private licenses to users on developers’ behalf.
Each private license grants the buyer broad permission under copyright and patent law to use contributions to an open software project, in language a bit more like what a company legal department would expect. Otherwise, the legal effect is much like that of a permissive public license, like MIT or BSD, except the private license applies only to the person who bought it, from the date they bought it.
Private licenses give the buyer limited ability to pass their licenses on, or sublicense, others. Generally speaking, buyers can pass their licenses on to others if they build software with significant additional functionality over and above that of the License Zero code they use. They can pass on only the right to use the License Zero as part of the new program they’ve created, and to maintain it. They can’t pass on their license to make changes or build other programs with the software. In other words, buyers can sublicense the “user” parts of their private licenses, but not the “developer” parts of their private licenses. Other developers who want to develop new programs, commercially or as closed source, need to buy their own private licenses.
Private licenses last forever, and cover the set of contributions to an open software project that a developer tags with the same identifier listed in the private license. To use an open software project without following the rules of its public licenses, users need other licenses, like private licenses from licensezero.com, that cover every contribution to the project.
Once a developer publishes contributions to a project tagged with a particular identifier, those contributions become forever linked to that identifier. Developers can’t take those contributions back, so that private licenses sold for for that identifier no longer cover them. That means users can buy the private licenses required for a particular version of a project, and rest assured that they will always have the rights they need for that version.
Apart from this rule against taking contributions back, developers retain total control over what work is covered by a particular identifier. If a developer embarks on a rewrite, or adds significant new functionality in a major release, they can create a new identifier for that new work, and charge for it separately. If the new work builds on the old work, users will need private licenses for both identifiers to use the combined project.
In general, there is only one situation where License Zero ever signs any agreement that requires a developer to do work in the future: When a customer sponsors relicensing of a set of contributions, the developer must implement the change, according to instructions in the relicense agreement. Otherwise, License Zero terms only cover work that has already been done. Developers can choose to make additional contributions tagged with old identifiers. But they can always choose to use a new identifier instead.
Many companies sell proprietary software on subscription. Customers pay a license fee, usually monthly or annually, as long as they use the software. Subscriptions create recurring revenue for sellers. Customers continue to pay, month after month, year after year, even if the seller doesn’t release any changes to the software.
License Zero does not support subscriptions. Customers pay for private licenses just once, and those licenses last forever. That design decision reflects the complexity of subscription licensing, on the one hand, and License Zero’s overarching goal of zero friction, on the other.
Subscription license sellers have to charge their customers repeatedly. Each payment can go wrong. Payment methods expire. Delays and errors abound. Customers go out of business, or decide not to renew. To cope, sellers pay payment processing and invoice companies, hire billing managers, and even sell debts to collection agencies.
From the customer point of view, sellers go out of business, retire products and services, or let contracts expire to renegotiate price. To avoid getting stranded, customers demand source code escrow, transition services, and other protections against getting stuck without critical software. They push for long price commitments, or rules limiting how much prices can go up each year.
All of that complicates subscription license agreements. But even the best subscription license agreement eventually ends. When a subscription ends, for whatever reason, the customer’s license for the software ends with it. Looking at an old proprietary software license, it’s rarely clear if the license is still good. Did one side or the other stop it from renewing? Did the payment for this year’s renewal actually go through?
That uncertainty makes anything like a single form for private license, or a single command to find what licenses are missing, impossible. One-time payments and forever licenses are simpler, both at the time of sale and over the long term.
That doesn’t mean developers can’t use License Zero to get paid for work over time. As mentioned above, developers have complete control over whether to make new contributions under an existing licensing identifier, or create a new one. Developers can create new identifiers for each new major release of a project, or even for each new month. It’s up to developers to communicate those choices to users, if they like, so users know what to expect. As a baseline, License Zero’s licenses and terms only grant licenses for the software developers have already made, in the past. But licenses for past work don’t expire in the future.
Freebies are free private licenses with optional time limits. Developers can use the command line interface to generate signed freebies for specific people that last for a set number of days or forever.
You might like to gives freebies to reward other contributors to your project who make their work available under a permissive license, for parallel licensing, extend the free trial period for projects under Prosperity, or to resolve a question about whether a particular use will trigger the commercial-use time limit. It’s entirely up to you.
licensezero.com is a website and API for selling private licenses, closing relicense deals, and generating freebies.
You can think of licensezero.com as a kind of Internet vending machine. As a contributor, you can make a deal with the operator of the vending machine to stock it with private licenses and relicense deals for sale. The vending machine then handles taking payment and spitting out licenses on your behalf.
You could also think of licensezero.com as a kind of e-commerce platform service-izing the back-office operations of a public-private licensing business: negotiation, communication, payment processing, records management. Rather than start a company and hire people to handle those tasks, or take time away from development to do them yourself, you can use licensezero.com to run your licensing business 24/7. It works just a well for expensive licenses priced in the thousands of dollars and relatively cheap licenses costing just a few bucks.
You can create an account to sell private licenses through License Zero by linking a standard Stripe payment processing account, via Stripe Connect. Stripe Connect enables licensezero.com to connect its Stripe account to yours, then generate access keys to initiate payment processing requests directly on your account. Stripe assesses its fee, and any commission for licensezero.com, on the transaction.
licensezero.com generates unique identifiers for licensors and their licensing offers. The identifiers are version 4 UUIDs like:
Your licensor ID is your identify on licensezero.com. If you name, e-mail address, or other personal details change, your licensor ID will remain the same.
Each time you offer licenses through licensezero.com, the site will generate an offer ID for you. Offers are a bit more immutable. Subject to some exceptions, you can change business details like the price of licenses at any time. But if you need to change some detail about what you’re offering, like its website or description, you will need to retract your old offer and make a new one.
License Zero signs important records like private licenses with a NaCl-style Ed25519 cryptographic signing keypair. Customers can check these signatures against licensezero.com’s public key. licensezero.com also records the date and cryptographic hash of every record that it signs, along with the signature.
licensezero.com serves a page with information and purchase forms for each identifier. For example:
The URL pattern is:
licensezero.com serves SVG graphics with private-license pricing information that you can include in your projects’
README files or other documentation. For example:
The URL pattern is:
The Markdown syntax is:
Artless Devices LLC is a California limited liability company. It serves as the legal counterpart to licensezero.com. As a developer offering private licenses for sale through licensezero.com, you will have three legal relationships with Artless Devices:
To use licensezero.com and its API, you must agree to terms of service with Artless Devices. The terms were written to be read, and you should read them. They set important rules about responsibility and liability, and make very explicit that Artless Devices isn’t going to provide, or be responsible for, any legal advice about whether License Zero is right for you or your work.
To offer private licenses for sale through licensezero.com, you agree to the agency terms with Artless Devices. You should definitely read that agreement, and again, it was written to be read, not to glaze your eyes over. But there are a few especially important aspects, from Artless Devices’ point of view.
First and foremost, you appoint Artless Devices as your agent to sign private licenses on your behalf. That means that Artless Devices can do the deals you authorize through the API, via licensezero.com, with the same effect as if you’d signed them yourself.
Second, Artless Devices earns commission on private license sales. The amount is set out in the agency terms when you offer your work for private licensing.
Third, you guarantee that you have the rights to offer the software you offer to license through License Zero, and to keep your projects’ metadata in line with what the command line interface generates. The guarantee helps protect Artless Devices from those trying to take license fees for others’ work. Your promise about metadata helps ensure that the command line interface works as intended for users buying licenses.
Fourth, the relationship isn’t exclusive, and with the exception of work for which you lock availability, either side can end it at any time. You can sell private licenses through other services, or on your own.
Finally, neither the terms of service nor the agency terms change ownership of any intellectual property in your work. You own your rights, and you keep them. Artless Devices doesn’t receive a license from you. Rather, you license users and agree to relicense your work directly. Artless Devices merely acts as your agent, signing on your behalf, as you’ve directed via the API.
Artless Devices owns and licenses the intellectual property in the command line interface that you will use to register and offer licenses for sale, as well as forms and other software tools published online.
As a independent software maintainer, you can license your work under both a public
LICENSE terms and private licenses at the same time because you own the intellectual property in your work that others needs licenses for. In other words, you can license your work in two ways at once because you own it.
When others contribute to your work, they will own the intellectual property in their contributions, not you. As a result, users of your combined work will need licenses from you and from other contributors. There are two straightforward ways to achieve that.
You can choose to take contributions to your project only from those who license their contributions under permissive open source terms. For example, you might license your contributions to a project under Parity terms, but ask contributors to license their work under Blue Oak, and append the text of that license to your project’s
LICENSE file with a note that others’ contributions come under that license.
Users of the combined project would then receive a license from you on Parity terms, for your contributions, and licenses from other contributors on permissive terms, for their contributions. Would-be users who won’t abide by the open source release conditions of your license can still buy a private license from you, for your contributions. The private license for your work, plus the permissive license for others’ contributions, cover all contributions.
In that kind of situation, you can sell private licenses for your contributions to the project, but others cannot. Perhaps that feels completely fair. If it doesn’t, you may like to offer special credit, payment, or a freebie to contributors, to convince them to license their contributions under permissive terms.
License Zero also supports projects that require multiple private licenses, for contributions from different developers. If you publish contributions under The Parity Public License, and another developer forks, licensing their own work under The Parity Public License, too, they can append
licensezero.json metadata for a separate License Zero identifier. Users who run the command line interface will see that they need a private license from each of you to use the project as a whole. The same could happen with two contributors using The Prosperity Public License, or contributors using a mix of
Note that as a contributor, you control pricing only for your own contributions, not anyone else’s contributions, even if their work builds on yours. Contributors building on top of work you license under The Prosperity Public License will need to purchase private licenses from you to use and build on your work for the purpose of making money through licensezero.com, but otherwise, licensezero.com doesn’t say anything about any relationship between you.
Packages, tools, and projects depend on other packages, tools, and projects in turn. These relationships create webs of dependencies, or dependency graphs, within software projects.
Users need licenses for all intellectual property within their software projects, including its dependencies. And they must follow the rules of each of those licenses. That means each project tree has not just a dependency graph, but a license graph, as well. The License Zero command line interface traverses the license graph automatically, seeking out License Zero packages.
Consider this dependency graph:
Package A depends on Package B and Package C. Package C depends on Package D in turn.
When all contributions to each package in the graph are licensed under the same terms, users must follow the rules of that license for all code in the graph:
In this case, all the packages in the dependency graph are licensed under Parity terms. Parity allows this, as long as source code for all the packages gets released, and each package preserves the license terms and notices of its dependencies.
However, the licenses for packages in a dependency graph need not be the same:
A user of package A needs to follow the rules of both Parity and Prosperity, in order to use package A. That means both limiting commercial use to 32 days and releasing source code for software built with package D, including for software built with package C or Package A.
Note that the authors of package A and package C are free to license work on their own packages under MIT and Blue Oak terms, respectively. The Parity license of package D requires release of source code and licensing on terms at least as permissive as Parity. Both MIT and Blue Oak are more permissive than Parity, with fewer rules about releasing source code.
The author of package A must mind the license rules for the Prosperity license for package B, too. If the author of package A wrote that package primarily as a hobby, or as academic research, they’re free to continue using package B indefinitely. If the author of package A instead wrote package A primarily to make money, they need a private license for contributions to package B, so as not to exceed the 32-day trial period.
The bad news is that license graphs can be even more complex, where packages also used stacked licensing:
This kind of complexity shows up even in existing open software projects that don’t use any License Zero licenses, with mixes of GPL, BSD, MIT, LGPL, and other licenses.