Secretly behind the backs of the official community council and not many months later started to turn Gitea into an open-core product.
And they also demand a CLA from contributors now, which is directly against the idea of FOSS.
I was a bit sceptical about the justification of this fork in the beginning as well, but time has proven the Forgejo team to be sadly completely right.
I’m not addressing anything Gitea has specifically done here (I’m not informed enough on the topic to have an educated opinion yet), but just this specific part of your comment:
And they also demand a CLA from contributors now, which is directly against the idea of FOSS.
In contrast, I think it is acceptable to … release under the GPL, but sell alternative licenses permitting proprietary extensions to their code. My understanding is that all the code they release is available as free software, which means they do not develop any proprietary softwre; that’s why their practice is acceptable. The FSF will never do that–we believe our terms should be the same for everyone, and we want to use the GPL to give others an incentive to develop additional free software. But what they do is much better than developing proprietary software.
If contributors allow an entity to relicense their contributions, that enables the entity to write proprietary software that includes those contributions. One way to ensure they have that freedom is to require contributors to sign a CLA that allows relicensing, so clearly CLAs can enable behavior antithetical to FOSS… but they can also enable FOSS development by generating another revenue stream. And many CLAs don’t allow relicensing (e.g., Apache’s).
Many FOSS companies require contributors to sign CLAs. For example, the FSF has required them since 2005 at least, and its CLA allows relicensing. They explain why, but that explanation doesn’t touch on why license reassignment is necessary.
Even if a repo requires contributors sign a CLA, nobody’s four freedoms are violated, and nobody who modifies such software is forced to sign a CLA when they share their changes with the community - they can share their changes on their own repo, or submit them to a fork that doesn’t require a CLA, or only share the code with users who purchase the software from them. All they have to do is adhere to the license that the project was under.
The big issue with CLAs is that they’re asymmetrical (as opposed to DCOs, which serve a similar purpose). That’s understandably controversial, but it’s not inherently a FOSS issue.
Some of the same arguments against the SSPL (which is not considered FOSS because it is so copyleft that it’s impractical) being considered FOSS could be similarly made in favor of CLAs. Not in favor of signing them as a developer, mind you, but in favor of considering projects that use them to be aligned FOSS principles.
Well, I don’t disagree with your specific points, but you are missing that the founding idea of FOSS was a copyright hack to ensure that software remains modifyable/fixable by its users. A mandatory CLA that allows relicensing partially circumvents that not only for the users but even the contributors.
Sure you can argue that technically the already released code can not be relisensed, but that’s really missing the point that FOSS software intends to be open now and in the future.
CLAs can be abusive, but not necessarily. Apache Foundation contributors need to sign CLAs, which essentially codify in contract form the terms of the Apache 2.0 license. It’s a precaution, in case some jurisdiction doesn’t uphold the passive licensing scheme used otherwise. There’s also a relicensing clause, but that’s restricted to keeping in spirit, they can’t close the source.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
Forgejo is a reactionary fork of Gitea, started because the creator of Gitea founded a company to maintain it.
Thanks for the info!
Secretly behind the backs of the official community council and not many months later started to turn Gitea into an open-core product.
And they also demand a CLA from contributors now, which is directly against the idea of FOSS.
I was a bit sceptical about the justification of this fork in the beginning as well, but time has proven the Forgejo team to be sadly completely right.
And they started sending advertisement emails to people who registered on gitea.com.
I’m not addressing anything Gitea has specifically done here (I’m not informed enough on the topic to have an educated opinion yet), but just this specific part of your comment:
Proprietary software is antithetical to FOSS, but CLAs themselves are not, and were endorsed by RMS as far back as 2002:
If contributors allow an entity to relicense their contributions, that enables the entity to write proprietary software that includes those contributions. One way to ensure they have that freedom is to require contributors to sign a CLA that allows relicensing, so clearly CLAs can enable behavior antithetical to FOSS… but they can also enable FOSS development by generating another revenue stream. And many CLAs don’t allow relicensing (e.g., Apache’s).
Many FOSS companies require contributors to sign CLAs. For example, the FSF has required them since 2005 at least, and its CLA allows relicensing. They explain why, but that explanation doesn’t touch on why license reassignment is necessary.
Even if a repo requires contributors sign a CLA, nobody’s four freedoms are violated, and nobody who modifies such software is forced to sign a CLA when they share their changes with the community - they can share their changes on their own repo, or submit them to a fork that doesn’t require a CLA, or only share the code with users who purchase the software from them. All they have to do is adhere to the license that the project was under.
The big issue with CLAs is that they’re asymmetrical (as opposed to DCOs, which serve a similar purpose). That’s understandably controversial, but it’s not inherently a FOSS issue.
Some of the same arguments against the SSPL (which is not considered FOSS because it is so copyleft that it’s impractical) being considered FOSS could be similarly made in favor of CLAs. Not in favor of signing them as a developer, mind you, but in favor of considering projects that use them to be aligned FOSS principles.
Well, I don’t disagree with your specific points, but you are missing that the founding idea of FOSS was a copyright hack to ensure that software remains modifyable/fixable by its users. A mandatory CLA that allows relicensing partially circumvents that not only for the users but even the contributors.
Sure you can argue that technically the already released code can not be relisensed, but that’s really missing the point that FOSS software intends to be open now and in the future.
Anyways, a good related read is: https://opensource.net/why-single-vendor-is-the-new-proprietary/
Am I out of touch?
No, it’s the Free Software Foundation that is wrong about Free software licensing practices!
I guess we can all agree on the FSF being out of touch lately 😅
CLAs can be abusive, but not necessarily. Apache Foundation contributors need to sign CLAs, which essentially codify in contract form the terms of the Apache 2.0 license. It’s a precaution, in case some jurisdiction doesn’t uphold the passive licensing scheme used otherwise. There’s also a relicensing clause, but that’s restricted to keeping in spirit, they can’t close the source.