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!
- Apply the Parity License to your project.
- Apply the Apache 2.0 License to your project's third-party contributions.
- Set up a patronage/crowdfunding platform, and make sure it has a tier that grants licenses to sponsors.
- Apply the Patron License to your project.
- (Optional) Handle additional licensing with other License Zero licenses.
- Read about why do this whole thing in the first place.
- 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?
- Make sure everyone in the free software community is able to use our software freely, so long as they are also sharing their software.
- Open the doors to licensing arrangements so people and corporations looking to write proprietary software have to give back in some way.
- 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:
- Agree to license their own changes under a permissive license (like MIT or Apache 2.0).
- Agree to grant you the ability to grant private licenses to third parties, while retaining their own copyright.
- 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.
Top comments (25)
Long-term, do you plan on paying out to small-time contributors, with something like feature/bug bounties? Or the same as with npm, just a strong recommendation to not spend too much time if you're not paid by a third party.
This is a great question, and I really should've written more about it (maybe I'll add it in as an update).
In summary, I think this is a great reason to use OpenCollective, because it makes it easy to do these payouts. I think I'm fairly comfortable taking in small individual contributions that are freely given, but if someone's putting a big patch together, I think the expectation should be that some of the sponsorship money should go to them.
Does that make sense?
I think that's fair. I'm just feeling that there's a lot happening at the maintainers discretion -- but I guess A) you can't avoid that and B) ideally, most of the income is profits, so there are no expectations on how it should be managed (as opposed to with donations).
A fundamental flaw in the thinking of trying to get an open source project funded/monetized is assuming the people who use it can make the decision to give money (in a subscription model).
Patreon and the likes do not work for companies.
They people who decide to use a certain open source project at work do not have the decision power to make monetairy donations.
I do not really have the solution for this problem.
Maybe the concept of Tidelift is a good one.
Gone are the times where businessed could simply donate resources like servers, as there are plenty of companies offering this for free for open source projects.
I've expensed plenty of software and subscriptions at work before! Things like Dash and irccloud have been critical to my work, and I've found that going through expense processes is definitely possible.
But I know it's not possible for everyone, and that's why I wrote the section on additional licensing, so that more corporate-friendly licensing models can be used as necessary. The patronage model is meant to be a baseline, not a complete story.
I thought that was kinda the point made in this post. That you should offer a commercial license so that it matches the way businesses already expense things.
My employer already pays for various software licenses (including libraries like GSAP), so this kind of license would fit the current model. Meanwhile there's no way I could expense Patreon.
Correct me if I'm wrong. Scenario: A business discovers their proprietary licensed product uses your Parity licensed product by 2 levels of indirection. (They use an MIT lib that uses an Apache lib that uses your Parity lib). So far as I know, their choices are to either pay you for a commercial license or to replace your lib in their product within 30 days, which could be intractable.
An otherwise permissibly-licensed (e.g. MIT or Apache) project would be bringing a lot of hidden risk/liability to their users by creating a dependency on a Parity-licensed lib. It seems like the only way to make that risk transparent is for the project to change their license to Parity. If projects don't do this, then it will start requiring extra risk assessment to use "permissible" license libs. I remember in the early days of open source that businesses were afraid to use anything with the "open source" label due to risk/liability. I even had to get special lawyer approval for an MIT lib once. I'd hate to go back there.
Another thing that always bothered me about the business model of using AGPL (and I guess Parity) is that the project still isn't really an open source community project. Ownership rights are exercised to do a private commercial release. But if you disappear without sharing or transferring those rights, no one else can ever do a commercial release and those customers are stuck (depending on their commercial license terms). Others can fork it, but they can't choose to release it under a different license. Whereas something like MIT doesn't have this problem since it doesn't cut off any practical usage rights if the author goes off the grid. (Although MIT doesn't solve the "free labor" problem that popular open source projects can have.) Anyway, it's a contingency to think about.
Same disclaimer: I am not a lawyer.
Scenario A (surprise library): this is partly why I explicitly said I'm only recommending this model for devtools, not libraries.
Scenario B (developer going away): shrug. I don't see this as a big issue. Products disappear all the time, people adapt. Look at Google shutting down major projects apparently on a whim.
Dev tools are often packaged up or depended on by other dev tools. Not to mention things like starter templates. Or maybe my definition of dev tools is too broad. Were you thinking like endpoint apps like VS Code or vim? (Although VS Code has been adapted for other uses too.)
I suppose it’s true that products disappear. We’ve had that happen to us or seen it happen to others with some vendors. Because they weren’t making enough money. Anyway, I guess in my mental model, if I decided I was tired of an OSS project I can just stop and someone else can keep it going if it’s important to them. But this is different. It is really a business model, not a community project.
I think if you're concerned about that first scenario, it's important to understand where your tool stands in the ecosystem. I also think it's perfectly acceptable that all those users will, in fact, need to pay for proprietary use. And we can build tools to make that easier.
Very true. I was thinking about that in a twitter thread too twitter.com/tunnckoCore/status/123....
And... now thinking again. This whole problem can be solved with registering a non-profit which will hold the copyright instead of you personally? Of course you still need to have (initially, later the co-maintainers?) few people in that body - family or peers and friends. That way, there would have "official" protocol & rules what and how to happen.
Hm. I may try that way. Thoughts?
In the US anyway, my understanding is that non-profits have ongoing requirements (requires a board, annual meetings, some financial reporting) and are not controlled by a single person -- the board could out-vote you on an issue. So it has non-trivial overhead and some risk as just a vehicle for ownership rights.
I could be wrong on some of the details, but I believe the gist of what I'm saying is true. I have been an observer in formation of one non-profit as well as working for another. Definitely investigate it for yourself.
Ааh, yea, probably. Good to know, I'm looking at UK ones currently.
That's okay. In governance of bigger open source projects it's almost the same thing. There's no problem for smaller ones to be similar too.
My case is that I'm concentrating everything in a single monorepo of independent libraries & devtools and pieces - some connected to each others, others completely not related to other packages.
Anyway, thanks. :)
This is fine if you're starting your own business or freelancing full time... but seems like overkill for an ordinary open source project.
I also feel like maybe you've forgotten what it's like getting started. How Step 7 (quit your day job) sounds laughably impossible, and "getting swept away by the thrill of popularity, the excitement of other people willingly using our code to achieve great things" seems like the best thing to hope for!
Part of the motivation for writing this is precisely because I'm getting started with a new project that can potentially become a major one and I find the current situation unacceptable.
I don't believe it should be, and my intention is to propose a new system that makes this a standard expectation from maintainers of successful projects.
Thanks for taking a stab at it, Kat!
I wrote extensive gulp pipelines and workflows for my organization that have more than 1,100 node modules installed across combinations of packages and their versions. There are many different authors at play. I am not opposed to work towards compensating someone for their efforts if their product provides value at its price, of course, but I am trying to determine how compensation models would work out practically for tools this large, given the amount of authors that would be involved. I suspect that my organization would arrive at having our teams rewrite much from scratch to be proprietary (at a huge cost), pay for turnkey solutions that may not fully deliver, or drastically reduce features to build our applications.
It's quite a conundrum really, and we have seen what happens when altruistic maintainers burn out or move on (recall the event-stream incident). Nobody owes us anything, and we have accepted the fragility that comes with the systems we've adopted.
Based on what I wrote, wouldn't only
gulpitself be Parity, in which case they just pay for a singlegulplicense? Maybe there's a few more packages in there.I think a really interesting bit here is that licensezero itself has tools that automate the process of buying these licenses, and I think that tooling could improve even further if the need arose.
At least gulp but also all its gulp plugins that can be used. I originally thought that I would still need to have awareness of license types for all dependent packages, too, but rereading your post makes it clearer to me that that should be abstracted enough. I wonder where the ultimate responsibility lies if a package has a dependency but does not honor its license or payment model correctly. Is only the package at fault or also my organization for including (and possibly paying) this package while satisfying its but perhaps not its dependent's licenses? That's what made me worry about my large amount of dependencies originally.
As a believer in markets typically finding and providing good solutions, I wholeheartedly agree with you that tooling will improve to satisfy both provider and consumer of these products.
From an ease-of-use perspective, I suspect that one avenue would simply be a subscription model through a registry. You could have registries such as npm compete with other registries similarly to how music and video subscriptions are done. Reducing barriers of entry for consumers is key to choosing services. If an organization was charged X per month or year to have unlimited downloads of packages, that would be a much easier pill to swallow than dealing with individual licensing requirements on a per package or per author basis. With that would come the expectation that service providers a) pay out their package authors / contributors appropriately, and b) some assurances that packages are safe, curated, inspected, etc.
Have you posted about your thoughts and experience with this model since this post? I'm wrestling with sustainability and licensing issues myself for a project that I'm working on and I'm curious where you've ended up.
Edit: Thank you for writing this post in the first place. It was really interesting to read.
Googling got me to this Twitter thread from the author which seems to be dated a year after this post. It seems to have been a frustrating experience which I can completely understand. I still hope to try the Parity license for a project I'm writing but I will go tentatively and will measured expectations.
Thx for putting this together!!!
Regarding the APACHE license in the CONTRIBUTOR.md do you have an example how it should be worded?
A GitHub starter template or example project with everything set up could be great.
Having a template sounds like a great idea! I think I'll work on this soon.
What do you think about NPOSL-3.0 license?
I don't mind people making money using my software, I just don't think they should make that money without giving back in some significant way :)