Good to see IndieCC progressing along.
I am wondering about a license platform which requires commercial users to pay $1/user/month via github sponsors, with a npm install script that checks the machine’s git config’s github username property (fallback to the machine’s git config’s email property) against the organisation’s github sponsors, with those who donate more than $1 month able to specify via a custom interface usernames/emails to shout.
Machines with no github username config property, and no git email config property would be permitted to run freely, as it is most likely CI, and if it is a user trying to do that to circumvent licensing, then that is an inconvenience on their part that they can incur.
Enforcement would just be the installation doing a warning of it being unlicensed.
This would get a lot of backlash no doubt, however it seems effective at having freeloaders pay or incur the cost of maintenance themselves.
I don’t consider lost usage from freeloaders here an issue, as they would then have to compete with the monetary consolidation from the non-freeloaders. Nor does a maintainer gain any benefit from freeloading, as dealing with them detracts maintainers from working on other ROI tasks. And if a company does do a hostile fork, then so be it, the indie dev can cut his losses and focus on something else, letting another entity foot the bill for the maintenance.
Finally, having had software I’ve written used by pretty much every corp size on the planet, without any ROI from them, it is about time that companies paid for the time donated to them through the commons by indie devs, rather than fleecing the indie devs. A few heavyweights behind it, and companies will be forced to at least acknowledge this current fleecing.
For what is commercial usage here, I’m going with — be it closed source or open source, doesn’t matter, if the dev is deriving an income working on whatever it is they are installing of yours, then that counts — which is similar to the IndieCC definition.
An exception would be provided if the licensing costs would cause them financial hardship, such as those in debt or below their local poverty line, or hit by currency ratios.
An exception could also be made when the verifier detects the email/username has had a commit merged in the org.
To deal with the scalability of such a model, instead of every single dev now charging $1/month. I think what would likely happen is devs would consolidate themselves into cohorts, such as what Sindre has done under his name to financial success, or what Bevry has attempted. Then they would pool their resources according to different distribution schemes. As the dog eat dog world of open source is still the case, and the anti-competitive monopolistic forces won’t go away, so best for cohorts to find commune with a loyal fanbase to fend off or cooperate with other cohorts, than each tiny indie dev doing it themselves. I see the same package implemented several times, once in each large cohort, with consumption choice based on which ecosystem the consumer is down with.
Such distribution schemes could be:
- benevolent dictator takes all, manually distributes according to his will among contributors
- automated splits, eg.
- split proportionally amongst commit authors in the past x months
- 90% split evenly to maintainers, 10% split evenly to contributors, split by their proportional package installation count within the org.
- Commercial maintainers/contributors could opt out of the split, to make sure the funds go only towards those participating in the commons.
Posting here to solicit feedback and criticism. If it is an experiment that we want to run:
I can use bevry’s ecosystem as the testbed, starting with bevry’s antiquated orgs (docpad, browserstate, then eventually the bevry main org) however we should get a few other cohorts onboard too to force the hand to a compensated world, rather than just prompt a mass exodus to hostile forks
I would need help with the licensing terms, as I have no idea the considerations to phrase such a thing.
I can do the GitHub sponsors fetching and validation, no worries there