• FizzyOrange@programming.devEnglish
    51·
    22 days ago

    How did they get permission from all previous contributors to do this? It doesn’t have a CLA. Seems sketchy.

    • TheOneCurly@lemm.eeEnglish
      16·
      22 days ago

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

      • FizzyOrange@programming.devEnglish
        11·
        21 days ago

        Yes but it doesn’t let you remove the MIT license:

        The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

        Doesn’t look like they are complying with those terms to me.

        • TheOneCurly@lemm.eeEnglish
          2·
          21 days ago

          All source files have individual comment headers with the original authors and license identifier. It’s not the full license text but I do believe that style is compliant.

          • FizzyOrange@programming.devEnglish
            12·
            21 days ago

            Yeah… But that’s even more confusing since they didn’t change it to “MIT AND GPL3”. So now the whole project is GPL3 but individual files are MIT?

            I think they should speak to someone who understands copyright law.

            • sus@programming.devEnglish
              31·
              21 days ago

              the MIT copyright notice is still present with all copies of MIT licensed code, I don’t see the problem?

              • FizzyOrange@programming.devEnglish
                2·
                21 days ago

                The problem is that there’s ambiguity if you add new code to those files because the file header says it is MIT licensed but the project licence says it is GPL3. It’s contradictory.

                I believe they could have resolved the issue by deleting the file headers and including a copy of the MIT license in LICENSE with a note saying something like “Code at this commit is fully licensed under the MIT license which is reproduced here; subsequent code is licensed only under the GPL3. Both licenses must be respected.”

                But they haven’t done that, and it doesn’t seem like they’ve even thought about it.

                • sus@programming.devEnglish
                  1·
                  21 days ago

                  I’d opine that the MIT license has no requirements about avoiding ambiguity. That’s kind of its thing, it’s as unobtrusive as possible and minimizes the amount of having to think about license compliance minefields.

                  And incidentally they have done quite a bit to avoid ambiguity, in readme.md:

                  License

                  Forgejo is distributed under the terms of the GPL version 3.0 or any later version.

                  The agreement for this license was documented in June 2023 and implemented during the development of Forgejo v9.0. All Forgejo versions before v9.0 are distributed under the MIT license.

                  though they also distribute binary-only copies… the main website even recommends downloading the binary. not even a tarball, just the plain binary. which even in old versions don’t contain an MIT license at all. Even a hexdump of the binary does not contain any representation of the MIT text. I think that’s actually an MIT license violation?

  • refalo@programming.devEnglish
    35·
    21 days 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
      6·
      21 days 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.

      • v9CYKjLeia10dZpz88iU@programming.devEnglish
        21·
        21 days ago

        Either way, even if they just stated that they just like the GPL, and want it to apply to their contributions towards federation and other improvements, I think that’s a reasonable decision as long as their primary contributors agree with it too. I don’t think a fork seems necessary unless the contributors want it to remain permissively licensed.

      • refalo@programming.devEnglish
        11·
        21 days 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”.

  • v9CYKjLeia10dZpz88iU@programming.devEnglish
    25·
    22 days ago

    Isn’t GitTea still under the MIT? I just don’t see the purpose for switching licenses, I didn’t think it was significantly different. It really doesn’t matter to me though, I didn’t plan on creating a custom version anyway.

    • TheOneCurly@lemm.eeEnglish
      61·
      21 days ago

      If you had read the very short blog post you would have learned that they wanted to merge in some GPL licensed code contributions. This sort of behavior is exactly what the GPL copyleft language is intended to encourage.

      • v9CYKjLeia10dZpz88iU@programming.devEnglish
        1·
        21 days ago

        I had read the discussion in the past and saw they already had GPL related dependencies they had pulled into the repository. I don’t know the full history or the contributors project goals. I usually don’t find GPL code hard to avoid in normal MIT projects already separated from the GPL, but I can’t state an opinion because I haven’t tried to understand the background. This is to say, I don’t find it completely convincing, and view it partially related to the contributors just liking the GPL.

        I wouldn’t personally make this choice because the project competes with an MIT licensed version. As an example, one of their goals is federation which might bring companies which realize they don’t need GitHub to promote their projects or collaborate. If their competition does the same, those companies might be more likely to choose the permissively licensed version instead. Though, this is a hypothetical example, and I think I’m just negatively biased against the GPL.