Show HN: Common Sense License (CSL) – civic license for a techno-feudal world(github.com)
github.com
Show HN: Common Sense License (CSL) – civic license for a techno-feudal world
https://github.com/shmaplex/csl
The CSL is an attempt to rethink software licensing in a way that balances freedom, sustainability, and fairness. It’s inspired by the idea that our digital infrastructure increasingly mirrors feudal systems: concentrated power, obligations flowing upward, and everyday users left vulnerable. The license is designed to give creators a practical alternative to proprietary or exploitative models, while encouraging transparency, collaboration, and equitable distribution. I’d love to hear thoughts from developers, legal experts, and anyone experimenting with bootstrapped projects.
6 comments
The readme says "5%" but the license says "13.37%".
Assuming 5%, Google can us only up to 20 CSL protects, assuming they have 100% profit.
> “Attributable Revenue” means revenue directly or indirectly generated through the use of the Software, including but not limited to product sales, SaaS fees, subscriptions, licensing, consulting, advertising, automation value, or labor displacement.
It's hard to know what is not included. Layers and accountant will run away.
Let's suppose I sell icecream and cakes[1], and use a program to manage the icecream stock, do I have to include the croissant revenue? What if I sell sometimes a piece of cake with a ball of icecream on top?
[1] It's common here. In summer they sell icecram and in winter cake+coffe, but you actually can order any of them all year long.
Assuming 5%, Google can us only up to 20 CSL protects, assuming they have 100% profit.
> “Attributable Revenue” means revenue directly or indirectly generated through the use of the Software, including but not limited to product sales, SaaS fees, subscriptions, licensing, consulting, advertising, automation value, or labor displacement.
It's hard to know what is not included. Layers and accountant will run away.
Let's suppose I sell icecream and cakes[1], and use a program to manage the icecream stock, do I have to include the croissant revenue? What if I sell sometimes a piece of cake with a ball of icecream on top?
[1] It's common here. In summer they sell icecram and in winter cake+coffe, but you actually can order any of them all year long.
This is interesting, but I wonder about how the threshold will be interpreted.
First, the revenue is a fixed number, this is usually a bad idea in contracts that will last a long time. There should be some adjustable indexing going on.
Second, the revenue number is in USD, this is probably less of an issue, but still creates ambiguity. What if revenue is reported in a different currency? Do we use an exchange rate? Which one? At what point in time do we choose the exchange rate? At the time revenue is reported? At the time the license comes into effect? Unclear.
Third, there are probably ways of skirting thresholds by artificially manipulating your corporate structure through subsidiaries etc., changing both revenue and headcount. How would that be solved?
Fourth, how is labor measured? By average salary? By specific salary? What counts as labor on the project? Who approves the labor? This also adds management and accounting overhead to the open source project, which isn't great.
I applaud the efforts, but I see some challenges in using the license. I hope these issues can be answered!
First, the revenue is a fixed number, this is usually a bad idea in contracts that will last a long time. There should be some adjustable indexing going on.
Second, the revenue number is in USD, this is probably less of an issue, but still creates ambiguity. What if revenue is reported in a different currency? Do we use an exchange rate? Which one? At what point in time do we choose the exchange rate? At the time revenue is reported? At the time the license comes into effect? Unclear.
Third, there are probably ways of skirting thresholds by artificially manipulating your corporate structure through subsidiaries etc., changing both revenue and headcount. How would that be solved?
Fourth, how is labor measured? By average salary? By specific salary? What counts as labor on the project? Who approves the labor? This also adds management and accounting overhead to the open source project, which isn't great.
I applaud the efforts, but I see some challenges in using the license. I hope these issues can be answered!
Yeah, these are all valid concerns. Thanks for the feedback.
1. Revenue should not be a fixed number. Consider adjustable indexing as a solution as you mentioned. 2. The revenue in USD was for modelling only. Anyone can change this based on their locale and pick their own currency as their laws permit. 3. Good point and these need to be considered, maybe there is a clause or something that can be added to cover this. Will look into it. 4. You as the repo or project owner make those decisions. That’s not for the license to decide I believe. “This also adds management and accounting overhead to the open source project, which isn't great.” there are plenty of software that handles this. Probably even some open source ones that could solve these hurdles.
1. Revenue should not be a fixed number. Consider adjustable indexing as a solution as you mentioned. 2. The revenue in USD was for modelling only. Anyone can change this based on their locale and pick their own currency as their laws permit. 3. Good point and these need to be considered, maybe there is a clause or something that can be added to cover this. Will look into it. 4. You as the repo or project owner make those decisions. That’s not for the license to decide I believe. “This also adds management and accounting overhead to the open source project, which isn't great.” there are plenty of software that handles this. Probably even some open source ones that could solve these hurdles.
I've converted license to plain text instead of markdown and have added: anti-evasion clause, affiliate aggregation rules, audit rights, gross attributable revenue, closed some loopholes, democratic governance process (with public comment), procurement alignment language and incentive-fit structures. Would be great to get anymore feedback.