Skip to content

Add FAQ item on why “AGPL + CLA” is a poor “fair source” license #58

@voxpelli

Description

@voxpelli

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions