This is from last month, but I haven’t seen any discussion of it. Seems like Forgejo is now a hard fork of Gitea, instead of being a soft fork like it was over the previous year.

The main reason I’m posting it now is this: “As such, if you were considering upgrading to Forgejo, we encourage you to do that sooner rather than later, because as the projects naturally diverge further, doing so will become ever harder. It will not happen overnight, it may not even happen soon, but eventually, Forgejo will stop being a drop-in replacement.”

  • mholiv@lemmy.worldEnglish
    0·
    3 months ago

    Because gitea is fully the victim of corporate capture. Any PRs that make gitea better in a way that would reduce the main corporate “sponsor” profit are rejected.

    The company has a conflict of interest with the community and it shows. Forgejo is sponsored by a non profit open source cooperative.

      • mholiv@lemmy.worldEnglish
        0·
        3 months ago

        Right now Forgejo is a drop in replacement. This article is them announcing that Forgejo will eventually not be one.

      • mholiv@lemmy.worldEnglish
        0·
        3 months ago

        https://codeberg.org/forgejo/discussions/issues/67

        The biggest issue is they require your to give them your rights as they pertain to copyrights.

        That means even if you submit MIT or GPL licensed code they can just instantly say “we relicense this code as proprietary” and there is nothing anyone can do.

        They rejected a bunch of valid PRs. Including the one linked here because the author refused to assigned their copyrights to the Gitea corporation.

        • matcha_addict@lemy.lolEnglish
          0·
          3 months ago

          Thanks for the link. But is this really unseen in FOSS? My understanding is some FOSS projects do this so that it is easy to make major decisions without having to bring every person that has ever contributed to the project, kinda like how ZFS is stuck with license issues because they can’t bring all contributors together to approve a license change.

          • MigratingtoLemmy@lemmy.worldEnglish
            0·
            3 months ago

            I’m not one to fight for software taken over by a corporate that is against FOSS. If you like Gitea, stick with it till you have a problem

            • AbidanYre@lemmy.worldEnglish
              0·
              3 months ago

              My concern is that this hard fork means “till you have a problem” might be too late for a smooth switch.

                • AbidanYre@lemmy.worldEnglish
                  0·
                  3 months ago

                  I’m not trying to start an argument, just looking for that balance between “gitea hasn’t done anything wrong yet” and “what if forgejo runs out of steam and the project stalls”

          • catloaf@lemm.eeEnglish
            0·
            3 months ago

            No, it can happen when the organization that owns the product decides to change the license, to include making a product closed-source. Redis just changed from BSD to dual-license SSPL and a custom license, for example.

            Because Gitea is MIT-licensed, Gitea Ltd. is well within their rights to change the license on Gitea to any license they please, including the “fuck you all rights reserved” license. However, unless specified in the license, you cannot revoke a previous license. So even if it’s closed going forward, you can still continue to use the last MIT version under that license.

            You cannot do this with GPL code, however, because the GPL states that any work derived from something under the GPL must also be licensed under the GPL (“copyleft”). The person you are replying to seems to not know that the MIT license has no such requirement.

            • imsodin@infosec.pubEnglish
              0·
              3 months ago

              Well yeah, that’s how licenses and copyright work - licenses can change. And sure on an adversary take-over (or corporate overloads taking control), that’s problematic. However the beauty is, it’s still MIT code: It can be forked (see what’s happening with redis). However a project copyright (and DCO) is not in place to enable just that, it’s in place to enable any license change by the project. Say a license is updated and there are good reasons for the project to move to the updated license - I think it’s pretty reasonable that the project would like to be able to do that and therefore retain copyright. Of course you are also free not to contribute such a project. However claiming it’s a license violation or unheard of is pretty disingenuous (formerly ingenious, thanks :) ).

              This has nothing to do with GPL or MIT: If you own copyright of a GPL licensed code-base, you can change that license at any time. Of course that only applies to new code. And that’s the same for GPL or MIT or any other license.

              • catloaf@lemm.eeEnglish
                0·
                3 months ago

                That last bit isn’t quite true. When contributions themselves are MIT-licensed, they can be relicensed. When the contributions are GPL-licensed, they can’t be relicensed by the product owner, because that right was not granted to them by the contributor. That’s where contributor agreements and copyright assignments come in.

                (Also I’m pretty sure you wanted “disingenuous”, not “ingenuous”.)