licensing

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.

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.

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.