Software and content produced or maintained by me is typically dual-licensed under the License Zero Prosperity Public License, the License Zero Patron License. The Prosperity License limits commercial use to a 32 day trial period, after which license fees must be paid to obtain a Patron License.

A License Zero Waiver may also be granted waiving the non-commercial clause of the Prosperity License without requiring a Patron License. These are granted on a case-by-case basis to friends, family, repeat contributors, folks who do good things in their community and usually when the person requesting one makes a compelling case about why the non-commercial clause shouldn't apply to them.

Obtaining a Patron License

A Patron License can be obtained by making regular payments through GitHub, in amounts qualifying for a tier of rewards that includes “patron licenses”. A Patron License grants qualifying patrons permission to ignore any noncommercial or copyleft rules in all of my License Zero Prosperity licensed software.

By becoming a Patron, you'll be helping to ensure I can spend the time not just fixing bugs, adding features, releasing new versions, but also keeping projects afloat and growing. Think of investing in me not just for the output of my code but my continued role in the open-source ecosystem. If open software producers and maintainers like me aren't supported then communities won't grow and there may not be a fresh package when you need a bug fixed.

What does the Patron License cover

A Patron License grants qualifying patrons permission to ignore any noncommercial or copyleft rules in all of my License Zero Prosperity licensed software.

There are no other additional rights or privileges granted under the Patron License. Specifically, it does not guarantee enhanced (or even any) support or priority issue resolution.

A Patron License does not entitle you to support. My software is still a notionally open software and a small licensing fee does not cover an increased support burden. That said, I do my best to eventually respond to every support request (if not resolve them right away) under a AS-IS basis.

If your company derives a lot of value from my work and you need prompt answers from an expert via email or a private support desk backed by a commercial agreement with response guarantees then please contact me.

If I purchase a license, do other users of the application I build with your software also require one

No. In general the Patron License includes provisions for sublicensing to your users as long as they don't then use the tools to create their own software.

But this isn't actually open source

You're correct, at least for the "official" definition of open source. Both the Free Software Foundation and the Open Source Initiative explicitly exclude software that contains limits on use from the definition of "open source". For this reason, the Prosperity License this project uses is not, and likely never will be, an OSI-approved license.

All that said, I think this definition of open source is in need of some reality checks. Without getting into too much detail in this FAQ, the open source community has a sustainability problem. As projects grow in size many maintainers burn-out or find themselves unable to satisfy increasing support and maintenance demands. Finding reliable, well-defined funding sources is extremely challenging (donations simply don't work for the vast majority of projects) and while funding isn't the only or exclusive way to address open source sustainability, it's certainly one component of an overall approach. As a community if we're going to try and improve the sustainability of the projects we rely on, and the health of their maintainers, then we have to expand the umbrella of open source to allow that maybe, just maybe, compensating maintainers for the large amount of time they dedicate to creating those projects, and placing restrictions on the use of those projects as an enforcement mechanism, isn't such a bad idea.

I understand that "free software" and "open source" generate a lot of feelings. If you prefer to call this project proprietary because of the way it's licensed, so be it. This is "a proprietary project with freely available source code that can be used without restriction for non-commercial purposes that engages with its community of users and accepts and encourages their contributions to source code, documentation, and support when they feel it's in their best interest to do so". Call that model whatever you want.

Why not use a copyleft license instead?

A copyleft license places restrictions on consumers that enforce the "openness" of the software. This is great if your goal is to further the reach of the openness but does nothing to address the sustainability problem. It also places these restrictions indiscriminately - it doesn't matter if you're using the project for commercial or non-commercial uses. When tied to a dual-licensing model in which a less restrictive private license can be purchased, the incentive for doing so is connected to an assumption that licensees have an interest in using the software in a less open environment such as closed-source.

Rather than tie funding to whether or not the consumer wants to also make their code open, it makes more sense to me to tie paying money to getting money. In other words, if you're generating revenue in part because of the work done on this project, then you should share some of that with the person who did the work you're using to generate the revenue.

There's also a practical matter in that copyleft licenses only work well with libraries because the license deals with what happens to code that consumes or uses the copyleft-licensed software. Applications are not generally used by or integrated with other code, making the provisions of a copyleft license not applicable.

I want to contribute, why do you make me sign a CLA?

When an open source project uses a non-permissive license the question of how to deal with contributions comes up. A contributor license agreement (CLA) clarifies what will happen to the contributed code and requires the contributor to agree to it, waiving some of their own copyrights in the process. It's unfortunate and does add a burden to the contribution process but it's necessary to ensure the entire project stays properly licensed and contributions can be licensed under the terms of the Prosperity License and Private License. Geoffrey Huntley's Contributor Agreement is designed to be as simple as possible while granting the broadest rights to the project under a non-exlusive agreement (it was developed using Contributor Agreements and then slightly modified).

I hope that you understand why a CLA is needed and that it doesn't keep you from contributing. That said, you need to decide if you derive enough value from submitting a contribution (such as adding support for a feature you need) to agree to the terms of the CLA. If not then I would caution you not to undertake performing work on the project.