People who use GPLv3 want the code to stay open/libre under any circumstances. If this is the goal, why not use the AGPL instead, even for applications which are not served over a network?

This takes away the possibility that people integrate parts of your program into a proprietary network application, even if this seems improbable. There’s nothing to loose with using this license, but potentially some gain.

Only reason I can think of is that AGPL is less known and trusted which may harm adoption.

  • cbarrick@lemmy.world
    link
    fedilink
    English
    arrow-up
    32
    arrow-down
    1
    ·
    1 year ago

    AGPL is a sure-fire way to steer off corporate support.

    GPL is usually fine for corporate use.

    For example, Google and Meta actively contribute to Linux (GPL) but neither would ever touch an AGPL project for fear of infecting their other IP.

    • Tobias Hunger@programming.dev
      link
      fedilink
      arrow-up
      11
      arrow-down
      9
      ·
      1 year ago

      You make it sound as if corporations actually contribute a lot to open source projects they use. That is not the case in 99.9% of all cases where corporations decide to use some open source project.

      If you are lucky as an open source maintainer you get a few patches from devs using their private email addresses to sneak the contribution around the legal department, but even that is rare. What you will see is random requests from company users to provide an SBOM for the entire project right now or bug reports asking to fix something right now.

      So I seriously doubt you loose out when using AGPL or GPL.

      • cbarrick@lemmy.world
        link
        fedilink
        English
        arrow-up
        21
        arrow-down
        4
        ·
        1 year ago

        Linux, coreutils, LLVM, GCC, Chromium, Firefox, V8, Python, Postgres, Java, systemd, kubernetes, Docker, Bazel, Buck, Abseil, Guice, Fedora, Ubuntu, Android, Hadoop, Apache, Nginx, Spark, TensorFlow, PyTorch…

        Yeah, companies never contributed to open source.

        • Tobias Hunger@programming.dev
          link
          fedilink
          arrow-up
          10
          arrow-down
          1
          ·
          1 year ago

          Most of your examples are projects started by a company. The very few remaining are those 0.01% that got lucky.

          My point stands: When you start an open source project, there is no need to worry about what companies might like or not. You will not get money from anyone.

          • cbarrick@lemmy.world
            link
            fedilink
            English
            arrow-up
            5
            arrow-down
            1
            ·
            1 year ago

            To be clear, when I say “corporate support,” I don’t mean the company pays you.

            I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.

            That’s how all of the projects I listed operate.

            If you don’t care about interfacing with the industry like this, that’s totally fine, and the AGPL works. But if your goal is to write a piece of software that is used by the industry, then it can’t be AGPL without a strong and exceptional business model.

            And I’m not trying to make a statement about whether you should write this kind of software. It’s only a statement about what to expect if you write this kind of software.

            • Tobias Hunger@programming.dev
              link
              fedilink
              arrow-up
              1
              arrow-down
              1
              ·
              1 year ago

              I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.

              Oh, most companies will pay someone to maintain an internal fork, but hardly any will contribute back. Sometimes that’s due to lazyness, sometimes it is the idea that nobody will care for the company internal stuff, but most of the time it is outright forbidden to share internal IP even when that comes in the form of patches to open source code.

              In my experience it is safe to just ignore that case and not care about corporate convenience when starting any open source project.