You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Coming from a long discussion over at Hacker News about whether AGPL is a good or a bad choice for a project my take essentially boiled down to:
It’s bad when used as a “fair source” license
It’s extreme when used as an “open source” license
And my impression is that most companies that use AGPL doesn’t do it because they want to be the most extreme of the extreme OSS projects (except eg sourcehut) but rather uses a combination of AGPL and CLA:s to (in similar way as #47) make themselves play by different rules to the rest of the community and hoping to get the same effect as eg FSL would give them, but with two major differences:
They get to use an OSI-approved license, so they can claim to be “open source” rather than “fair source”, which is good but unclear/dishonest marketing
The license is perpetual – it will unlike FSL never resolve to something more permissive – making the company play by other rules forever, and when the company is gone, no one can ever pick the project up and continue it in the same spirit, because they would all have to do it the SourceHut way then
I think it would be good to write something about why one shouldn’t pick the AGPL + CLA route for ones “fair source” project even though it enables one to market it as an “open source” project.
And I would love to have an FAQ-entry to link to the next time I have to explain to someone why I consider AGPL to 99% of the time be a bad choice.
The text was updated successfully, but these errors were encountered:
Personally, I completely agree with the OP — and I've actually written about this "dishonesty" i.r.t. AGPL in startup-land many times. But I'm not convinced something like this belongs on the Fair Source website.
We're trying to stay away from Fair Source vs Open Source right now, because that battle carries a lot of vitrol; rather, we've been focusing on Fair Source vs Closed Source.
Thinking out loud about this in the perspective of DOSP:
The Business Source License requires the DOSP to be to a GPL-compatible license
If that would have been the general definition of the Fair Source Definition, then AGPL would not have qualified to be a Fair Source license as AGPL code can not be included in GPL projects (GPL code can through a special exception be included in AGPL projects though)
The general DOSP requirement is not limited to any specific subset of licenses as it stands now though, right?
Coming from a long discussion over at Hacker News about whether AGPL is a good or a bad choice for a project my take essentially boiled down to:
And my impression is that most companies that use AGPL doesn’t do it because they want to be the most extreme of the extreme OSS projects (except eg sourcehut) but rather uses a combination of AGPL and CLA:s to (in similar way as #47) make themselves play by different rules to the rest of the community and hoping to get the same effect as eg FSL would give them, but with two major differences:
I think it would be good to write something about why one shouldn’t pick the AGPL + CLA route for ones “fair source” project even though it enables one to market it as an “open source” project.
And I would love to have an FAQ-entry to link to the next time I have to explain to someone why I consider AGPL to 99% of the time be a bad choice.
The text was updated successfully, but these errors were encountered: