Disclaimers: This system is still a work in process. I look forward to reading (and incorporating!) your (constructive!) feedback and I hope to evolve this into a fully usable model that anyone can Just Adopt™. I am also not a lawyer. And even if I were, I am not your lawyer. Don't take any of this as legal advice or in any way legally sound. If you want to make sure this is legally sound for you, get your lawyer to look at it. Finally, I'm in no way affiliated with License Zero. I am writing this because I think it's created some great tools to achieve what we're trying to do here.

Before you read anything else, note this: This whole thing focuses on developer tools -- it's not intended to be used as-is for things like libraries, databases, or operating systems. It does cover compilers, linters, package managers, bundlers, and all sorts of other such tooling. My hope is that by being more focused on a specific class of software, we can have a better chance of succeeding.

This isn't to say this model can't apply to other use cases. It's just that I won't cover here the implications for those other cases, and there might be some surprising complexities in implementation for those.

The Entire System, Summarized

Since this post is meant to be used as a reference post, here's the entire model in one place. Click through the various links for a detailed explanation of the how and why of each step!

1. Apply the Parity License to your project.
2. Apply the Apache 2.0 License to your project's third-party contributions.
3. Set up a patronage/crowdfunding platform, and make sure it has a tier that grants licenses to sponsors.
4. Apply the Patron License to your project.
5. (Optional) Handle additional licensing with other License Zero licenses.
6. Read about why do this whole thing in the first place.
7. Quit your day job when the above makes enough money for you. Congratulations, you have a working free software business now!

The Model, in Detail

The model I'm proposing involves moving our communities back towards a Free Software model -- by which I mean, using so-called Copyleft licensing -- and using that to direct funding towards maintainers in order to compensate them for their labor. This proposed workflow is not fundamentally different from the licensing model used by companies like Red Hat or MongoDB, but it is more specific and adapted to smaller projects maintained by only one or only a couple of devs, and it's also designed to be possible for "devtools" maintainers, a usage gap not covered by most licenses used by those larger open source companies. I'll summarize the entire model in the end, but first, some background on the motivations behind all this.

The Parity License

Apply the Parity License to your project.

The first step in this model is using a strong copyleft license -- something like the AGPL, but in this case, I prefer the Parity License, due to its closing of the "devtools loophole" -- that is, it imposes the share-alike requirement on anyone using your developer tooling (linters, compilers/transpilers, editors, etc.), not just people "linking" or in the case of the Affero GPL, "using your service".

To apply the license, simply copy the license text into a LICENSE-PARITY file in the root of your tool. If you're using a package manager that recognized SPDX license expressions (like NPM and Cargo), the ID you're looking for is Parity-6.0.0.

Considering how many small-team open source projects out there are actually developer tools, I believe this is a critical gap that needs bridging. The Parity License also comes with the benefit of being way more readable to humans, and even includes clear forgiveness for those who weren't aware of the particulars of the license, so long as they start complying with the terms after finding out. Another favorite part about this license for me is that it allows others to license their own software in a more permissive license than Parity itself, so it's not the same kind of "viral" as other copyleft licenses.

What are we trying to get out of this licensing decision?

1. Make sure everyone in the free software community is able to use our software freely, so long as they are also sharing their software.
2. Open the doors to licensing arrangements so people and corporations looking to write proprietary software have to give back in some way.
3. Close any usage loopholes that would allow proprietary users to bypass these expectations.

Third Party Contributions

Apply the Apache 2.0 License to your project's third-party contributions.

Of course, once we start dealing with copyleft with the intention of granting proprietary licenses, we come up to probably the trickiest part of this entire model: making sure that people can still contribute to your project.

This is the part where I can only give vague advice, as a non-lawyer, but this is my own personal understanding is that every single contributor to your project must agree to one of several alternatives, if you're to be able to pull off this workflow:

1. Agree to license their own changes under a permissive license (like MIT or Apache 2.0).
2. Agree to grant you the ability to grant private licenses to third parties, while retaining their own copyright.
3. Assign their copyrights to you.

Which one you pick is ultimately up to you, but you must make sure that this is made clear and explicit, for example, through note on your CONTRIBUTING.md, or a Contributor License Agreement.

For the purposes of this blog post, we'll go with the first alternative: having third-party contributions licensed under Apache 2.0. Apache 2.0 is a VERY permissive license, much like the MIT and BSD0 license, except it also has language granting patent permissions, which is considered pretty important nowadays.

So go ahead and copy the text of the license and put it in a file called LICENSE-APACHE in your project's root folder. If you're using a package manager with a license field, the new SPDX expression for it would be Parity-6.0.0 AND Apache-2.0, so add that in as well.

If you want to go the other routes, or you still want to use a CLA even for the Apache licensing, you can go over to Project Harmony for some templates, and even an Agreement Selector. You can also set up a CLA bot for your GitHub repository to automate the process of signing these.

But wait, you ask, this whole exercise is about sustainability and software freedom. Why do contributors have to give up so much for no reward? My answer to that is that you shouldn't accept nontrivial patches from contributors without some kind of compensation. Once you're making money from this whole setup, I believe it is the ethical thing to do to offer some part of that to contributors that submit nontrivial changes to your project. Going further, regular contributors should be made full collaborators on the project and you should split the proceeds from your sponsorships and license agreements more fairly with them. The specifics are up to you -- and them.

Crowdfunding Platforms

Set up a patronage/crowdfunding platform, and make sure it has a tier that grants licenses to sponsors.

You have a few choices here, depending on your team:

• If you're the only core dev on your project, I recommend signing up for GitHub Sponsors or Patreon if that's not available (as of this writing, Sponsors is still in beta and sponsors accounts are being granted in a trickle as GH figures out the kinks).
• If you're on a team, I recommend using something like OpenCollective or similar.

You should set up some basic tiers with rewards you're willing to give your sponsors. This can be things like provide X number of hours of support, adding them to a "thank you" list in your README, or even have their logo emblazoned on your project site. Be creative!

The most important thing here, though, is to decide which of the tiers will grant people a license to use your software in closed source scenarios. Since this essentially will amount to a subscription, I recommend you aim at a reasonable number here, taking that into account.

The Patron License

Apply the Patron License to your project.

Go ahead and download the Patron License and fill it out, then stick it into PATRONAGE.md in your project root.

This bit of legalese is what will grant individual subscription licenses to anyone who wants to use your software for proprietary purposes. It's important to note that these will be single developer licenses, and will only last so long as their sponsorship does.

But what if you want to grant bulk licenses to someone, or an entity? Or let a friend or friendly project have a one-off blanket waiver to the terms of your license? That's where additional licensing comes in.

Handling Additional Licensing

Handle additional licensing with other License Zero licenses.

Now, there's a couple of important licensing scenarios here I haven't covered yet. What do you do if you just want to grant a one-off waiver to a friend or collaborator? What about selling single-purchase licenses? Or bulk enterprise licenses to enterprises? Yes, in that case, you'll need more specialized licensing.

Some of these use-cases are already covered by the License Zero tools so I recommend you head on over and install their tool and use it to grant waivers and private licenses to your heart's content!

Again, just to restate it: I am in no way affiliated with License Zero and all of this is purely because I think their tooling and licensing is the best means to the ends I'm trying to achieve here. I'm more than happy to give them a boost because of that!

Anyway that's that! You're done! Go forth and create awesome things! Happy hacking!

Some Background

The rise of Free and Open Source software, the Cult of GitHub, the ecosystems spawned by language-centered package managers, and corporate acceptance and participation in Open Source have created an incredibly unsustainable situation where freely sharing one's source code and work has become the norm, rather than the exception, for vast communities of developers, be it professionals, hobbyists, or students. So much so, that we've come to expect availability of source code in a multitude of cases where closed source was previously normalized. The dream of Open Source (as defined by the Open Source Initiative), is practically achieved.

But where does that leave us?

In getting swept away by the thrill of popularity, the excitement of other people willingly using our code to achieve great things, I believe we have gotten a bit ahead of ourselves and forgotten to care about what's most important: our own selves and our well-being.

Free Software, as defined by the FSF and other Free Software advocates, had the answer to some of this: by creating a world of free software, where certain rights were reciprocally guaranteed, we would be able to ensure the long-term sustainability of our communities and be able to push away corporate exploitation. This was achieved through software licensing that was in many ways hostile to corporate interests, but friendly to the communities developing the software: "I'll scratch your back, so long as you scratch mine."

Alas, the OSI and its efforts annihilated much of the then-rising popularity of this model, and I believe this was to the immense detriment of our communities.

You see, while many developers (and the corporations that employ them) are happily using software freely available through GitHub, NPM, Ruby Gems, and various other distribution methods, maintainers are hitting their breaking point in what's become a bit of an open source sustainability crisis: maintainers are burning out, overwhelmed by the demands of an increasingly large community on a project they are usually only allowed to work on in their "spare" time, while simultaneously being punished for any attempts at implementing more sustainable models, such as the recent advertisement-based funding controversy.

For some reason, maintainers are expected to work on what is essentially a full time job, for free, or to rely on basic charity that ultimately only benefits those who are popular enough, such as crowdfunding and sponsorship platforms. Remember that work is work, even when you're doing open source, and that pressuring people into doing work for free for you is ultimately unethical.

After some time thinking and examining various possibilities, I believe I've come up with one way to change this for the better: A way for maintainers to be able to justify spending their time on their projects while continuing to ensure the free availability of source code, and without relying on the charity of strangers to do so. That is, going from charity into a fair deal.

CHANGELOG

• Updated the former CLA section to instead recommend that third-party contributions be licensed under Apache-2.0 or a similar permissive license to make the whole process easier. CLA documentation stayed in place for those interested in going that route.