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.

  • designatedhacker@lemm.ee
    link
    fedilink
    arrow-up
    16
    ·
    11 months ago

    They might hope to make money at any point in the future. AGPL is too viral to integrate with. Working at a large corporation they’ve banned a standalone desktop tool we could have used because it was AGPL. We wanted to pay for it, but we couldn’t. It’s a dead end product for corporate users. So personal use , hobbyists, and those companies that think the AGPL won’t infect their IP or don’t care. You limit your TAM severely if you use AGPL.

    So if you aren’t in it to ever make money in the future, go for it.

    • detalferous@lemm.ee
      link
      fedilink
      arrow-up
      13
      ·
      edit-2
      11 months ago

      This is simply wrong.

      Is you release software that YOU OWN as AGPL, there is nothing stopping you from also licensing it as non AGPL, for a fee, in the future. I’m fact this is more possible with AGPL, since it disallows Tivoization.

      If there’s a chance you want to make money off of it, AGPL is 1000x better than MIT. Once you release under MIT, a corporation can take it and do anything. If it’s AGPL a company can take it and do anything once they negotiate a license for it, and pay you for the privilege.

      • designatedhacker@lemm.ee
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        11 months ago

        Unless it’s open source and you have any contributions without a rug pull contributor agreement. Also you don’t have any AGPL dependencies.

        We had that relicense convo with the desktop tool maker and they were hogtied by both. Corporate policy dudes had to be harassed into even looking into it. Then maybe 3 months of back and forth championed by motivated tool users later they said to hell with it and banned it.

        So if you plan for the AGPL rug pull for your contributors or you have no contributors and none of your dependencies are AGPL in a viral way, go ahead.

        • detalferous@lemm.ee
          link
          fedilink
          arrow-up
          2
          ·
          11 months ago

          Totally agree

          Your contributors must attribute copyright or agree to any reason license if you choose this. (This seems so obvious to me that I didn’t mention it)

          But it’s still strictly superior to MIT licensing, which has the same requirement (since that’s part of copyright law, not party is the license itself), while still preventing commercial adoption under a different license.

          • designatedhacker@lemm.ee
            link
            fedilink
            arrow-up
            2
            ·
            11 months ago

            I think we’re in violent agreement. The problem is you need someone in licensing/legal to take a risk at this point to even use AGPL on a corp machine. Figure out the law and the license, then make judgement calls on some slightly fuzzy parts. They’re just not going to do it. Maybe in a few years if someone tests “the right” model, whatever that is in court and prevails. Meaning the dev gets paid and the user retains intellectual property that is either tangential to the product or provides enough value to be it’s own product that’s still sellable in the same way as before the suit.