4 ms·
Just from IP/legal point of view AGPL and AGPL adjacent licensing that imposes control over how you use the code is a non-starter for many companies especially
by localfirst 2y ago
Just from IP/legal point of view AGPL and AGPL adjacent licensing that imposes control over how you use the code is a non-starter for many companies especially ones that are "backed by YC" proudly displayed on their website because that signals money will be exchanged in the future by design.
MIT/BSD license that imposes no control over the how the code is used is the only FOSS we are allowed to use and we do donate regularly to maintainers working selflessly.
What makes me angry is that somebody then uses that MIT/BSD license code, makes some modifications and releases it as AGPL with clear intent to make a buck from it without paying that original maintainer any money.
- ncruces 2y agoI actually have no beef with either “money will change hands in the future” or “AGPL because we want to advance FOSS.” The problem is that AGPL is a total no starter at “day job,” and even at “side gig,” I'm obviously not going to release the source code of the entire service because of a message queue dependency. I mean, if I was trying to switch clouds for whatever reason, I might want this, and could even be persuaded to pay to self host it. But at this point there's no pay option. Just source I couldn't possibly use, not even for a month, not even as a trial, company policy or no company policy. It makes no sense.
- localfirst 2y agomy issue with money being mixed up with FOSS via AGPL is because it inevitably leads to a fork where the paid version has features and performance superior to the open source "community" version. i much rather ppl just release closed source proprietary software that i can pay for and the value proposition is clear not be lead to surprises down the road where the community version is neglected