- cross-posted to:
- opensource@programming.dev
- foss@beehaw.org
- cross-posted to:
- opensource@programming.dev
- foss@beehaw.org
Forgejo is changing its license to a Copyleft license. This blog post will try to bring clarity about the impact to you, explain the motivation behind this change and answer some questions you might have.
…
Developers who choose to publish their work under a copyleft license are excluded from participating in software that is published under a permissive license. That is at the opposite of the core values of the Forgejo project and in June 2023 it was decided to also accept copylefted contributions. A year later, in August 2024, the first pull request to take advantage of this opportunity was proposed and merged.
…
Forgejo versions starting from v9.0 are now released under the GPL v3+ and earlier Forgejo versions, including v8.0 and v7.0 patch releases remain under the MIT license.
As someone who worked at a business that transitioned to AGPL from a more permissive license, this is exactly right. Our software was almost always used in a SaaS setting, and so GPL provided little to no protection.
To take it further, even under the AGPL, businesses can simply zip up their code and send it to the AGPL’ed software owner, so companies are free to be as hostile as possible (and some are) while staying within the legal framework of the license.
That seems good enough to me. No?
Sure, it would be nice to have the whole versioning system history, but even having the current version of the code makes it possible to do a code review. And modification too.
Self-Building and deployment might turn out to be harder, but that would just be about which side is having to put the effort of making something comprehensive.
Good enough? I mean it’s allowed. But it’s only good enough if a licensee decides your their goal is to make using the code they changed or added as hard as possible.
Usually, the code was obtained through a VCS like GitHub or Gitlab and could easily be re-contributed with comments and documentation in an easy-to-process manner (like a merge or pull request). I’d argue not completing the loop the same way the code was obtained is hostile. A code equivalent of taking the time (or not) to put their shopping carts in the designated spots.
Imagine the owner (original source code) making the source code available only via zip file, with no code comments or READMEs or developer documentation. When the tables are turned - very few would actually use the product or software.
It’s a spirit vs. letter of the law thing. Unfortunately we don’t exist in a social construct that rewards good faith actors over bad ones at the moment.
Or it could just be laziness.
In case you don’t want to put the effort into making a system into your organisation, to update code in a public-facing versioning system hosted setup, just tell someone to zip whatever you compiled and package it along with the rest of the stuff.