• refalo@programming.devEnglish
    0·
    3 months ago

    Guess it’s time for yet another fork…

    Also the post seems to contradict itself:

    Both Forgejo and Git must be used together

    Forgejo codebase includes basic support for go-git, a Go package distributed under a permissive license that can be used in place of Git

    And the fact that it only needs an external binary that understands git commands tells me that it’s not technically tied to “Git proper” as much as they want us to believe.

    • Jade@programming.devEnglish
      1·
      3 months ago

      You missed out this fairly important bit re go-git:

      it is not supported or packaged because it is not fully compatible and could corrupt Git repositories.

      As far as being tied to git proper, that’s because there is no drop-in alternative implementation that implements all the functionality that you need to run a Git server. Right now, Git proper is your only option. That might change as gitoxide matures, but that could take years.

      • refalo@programming.devEnglish
        01·
        3 months ago

        You missed

        I did see that, I just didn’t feel that it was relevant to my point

        there is no drop-in alternative

        My point was that there could be (and the GPL even wants there to be). Also “Both Forgejo and Git must be used together” could be construed as Git itself requiring Forgejo, which isn’t true either.

        The fact that forgejo only calls an external git binary is what makes such tools compatible with non-GPL software as well… you just have to be able to substitute the binary for something else, it doesn’t matter if that “something else” exists yet or not.

        Maybe we just differ on our definitions of “requiring Git”.

    • TheOneCurly@lemm.eeEnglish
      1·
      3 months ago

      Existing code is MIT licensed, that’s their permission. Sublicensing without restriction is one of the parts of MIT.