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.

  • LemoineFairclough@sh.itjust.worksEnglish
    0·
    25 days ago

    Maybe a more appropriate practice is to only engage with a Contributor License Agreement if the repository one contributes to is already available with the GNU AGPL or one is actually in control of some money the person one contracts with will gain due to one’s changes. For example:

    • Before I contribute to a project, I should make a copy of as many relevant repositories I’m able to and ensure each one is easy to redistribute, and only make changes to my copies. That way, I can continue distributing the improved software if a person I engage in a CLA with does something I don’t like later, but they are still able to apply any change of mine to a repository that gets more attention (thus helping more people). Also, I might get money (as an employee) for doing this, which would prevent that money from being used against the Free Software Movement.
    • If I were a board member, manager, or employee and someone engaged in a CLA with an entity I have influence over, I have a good chance to direct more money to support the Free Software Movement (or block dealing with a person where doing so would be harmful).

    If I have already fixed a software issue, made it clear what license should be used with my change, and made it available to the public, I wouldn’t necessarily be against engaging in a CLA (though I might ask to be paid to do so since I wouldn’t normally go out of my way to manually sign things, and I do value my time).

    FYI I can navigate to https://blog.hansenpartnership.com/why-microsoft-is-a-good-steward-for-github/ from https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html (using https://blog.hansenpartnership.com/gpl-as-the-best-licence-governance-and-philosophy/ for an intermediary step), so I’m a little suspicious about the author’s thoughts on these matters. I also didn’t find any useful information about the GNU Affero General Public License from the same author, and I consider the GNU AGPL to be important based on https://ploum.net/2024-07-01-opensource_sustainability.html and https://lemmy.world/post/16602135

    • Norah - She/They@lemmy.blahaj.zoneEnglish
      0·
      25 days ago

      Would you not consider signing a CLA (without remuneration) if it binds a project to releasing your code under an OSI license? The only way they could have done better I think is by specifying AGPL instead. I’m not trying to argue that all CLAs are good here, but I don’t think that when they achieve the goals of the free software movement, they should be treated with suspicion or derision.

      Honestly, all of the recent light shone on CLAs is a great thing. But there are still valid reasons to maintain a unified copyright for a project. None of these projects would have been able to move to AGPL without having used a CLA for that purpose. It also allows enforcement of that license via things like litigation, because you can have one entity on the docket, instead of a thousand contributors all defending their copyright.

      I think the correct course of action isn’t to avoid signing one, but to force projects to commit to the social contract of open source in writing. I think there’s also a discussion that no one has earnestly talked about. A contributor license agreement is a contract between two parties, and under contract laws both parties must materially benefit. “I will get x, and you will get y”. This is known as consideration, and courts will nullify contracts that only benefit one of the parties. The only consideration I think there is to be found in most of the CLAs that have been brought up lately, is basically “your code will be merged into the project and released under it”. They don’t specify the continuation of open source, but it’s heavily implied by the aforementioned social contract. So when someone like RHEL goes and closes their source, they’ve essentially changed that contract to “you will sign over your copyright to us, and we will exploit your labour for profit”. That is not consideration, and it calls into question the validity of every single CLA signed. I genuinely think there’s grounds for every RHEL contributor that signed one to form a class and sue, and I would love to see FSF or EFF organising and supporting that sort of effort.

      Back to Element for a second though, as far as I can see, their new CLA is a valid contract, because it gives a right to the contributor, that their code will always be released under an OSI license. So if a successful suit was brought against someone like RHEL, or Hashicorp, we could see other projects scramble to repeat Element here. That would be, in my opinion, a very good thing for the free software movement.