432

Forgejo is now copyleft, just like Git (forgejo.org)

submitted 3 months ago by pnutzh4x0r@lemmy.ndlug.org to c/opensource@lemmy.ml

95 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[-] exu@feditown.com 20 points 3 months ago

I wonder why they didn't go with AGPL, which is made for server-based software like Forgejo.

From my understanding GPL does nothing to force hosting services to open their code as long as they don't distribute builds.

[-] thatsnothowyoudoit@lemmy.ca 15 points 3 months ago

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.

[-] ulterno@lemmy.kde.social 1 points 3 months ago

simply zip up their code and send it to the AGPL’ed software owner

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.

[-] thatsnothowyoudoit@lemmy.ca 4 points 3 months ago* (last edited 3 months ago)

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.

[-] ulterno@lemmy.kde.social -1 points 3 months ago

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.

Packaging the whole .git directory would make it significantly larger
This method is bankruptcy-safe, as compared to hosting on the internet.
- Ideally, I would like there to be both, a zip (in case I don't have an internet atm) and a link to the vcs
Yes, the companies mostly don't care enough and people doing it won't think of it as being hostile, just as putting the least effort.

[-] LemoineFairclough@sh.itjust.works 6 points 3 months ago

It seems there was a pre-existing agreement to use the GNU GPL with Forgejo, and it seems to me that the GNU AGPL is not compatible with the GNU GPL.

There is more discussion about that around https://codeberg.org/forgejo/discussions/issues/201

I'm assuming that there has been some resistance to using the GNU AGPL with Forgejo (it seems the discussions about licenses has been contentious), and the GNU GPL seems to have been discussed much more than the GNU AGPL. It was probably overwhelmingly likely that we would get Forgejo with the GNU GPL rather than the GNU AGPL. I would have preferred that the GNU AGPL was used instead, but I'm not going to worry about it much since I probably can't change this situation for the better.

[-] exu@feditown.com 4 points 3 months ago

You're right, seems like GPLv2 is incompatible with AGPL. GPLv3 includes extra clauses to allow it.

From the GNU Licensing page

Please note that the GNU AGPL is not compatible with GPLv2. It is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa. However, you are allowed to combine separate modules or source files released under both of those licenses in a single project, which will provide many programmers with all the permission they need to make the programs they want. See section 13 of both licenses for details.