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.

  • @cbarrickEnglish
    16•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
      6•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.

      • @cbarrickEnglish
        3•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
          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.