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.
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.
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.
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.
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.
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.
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.
Some time ago a client of me was looking for a solution to add watermarks to PDF files from their local on premise ERP system. The ERP system itself is a standard software. Obviously, they have a license to use that ERP but they definitely do not own the source code of it. Thus, they cannot change the license to AGPL or integrate it somehow.
I thought about writing a little plugin with Java in iFile to do that which is published unser AGPL. Using something under AGPL would mean that we have to make the entire solution available under that license.
Question 1: What is the entire solution in that scenario?
- Is it the part of the plugin that deals with watermarks?
- Is it the entire PDF handling plugin?
- Is it the entire process in the ERP system?
- Is it the entire ERP system that calls the plugin?
- Would it include sattelite systems that are connected to that ERP system that indirectly use the PDFs and thus potentially ‘infest’ the entire IT landscape?
- If the PDFs are send automatically to business partners of my client and they process it internally in their systems, are their systems now part of the solution?
Question 2: AGPL says users must have access to the source code of the solution no matter if they use it locally, over network etc. But Who is the user in such a scenario?
- The IT department of my client?
- The end users of the ERP system of my client who are only interested in the PDF but definitely not in the source code?
- Everyone at my client?
- Including business partners who might have access to the PDFs?
- Everyone?
Question 3: My client is not a software company, so they never published ANY source code or software. Where would you publish the code?
- The plugin for PDF creation would be called only in the background. The frontend is only standard ERP so I couldn’t easily put a link to the source code in the GUI.
- My client’s intranet?
- My client’s homepage?
- GitHub or a similar platform?
There is a lot of uncertainty when using AGPL software in a business context which will - in many cases - lead to the decision not to use the software at all.
This is a lot to read. How about a tldr for the lazy?
@[email protected] made a well structured comment using bullet points. It can be read pretty quickly but I guess the tldr is the last line:
There is a lot of uncertainty when using AGPL software in a business context which will - in many cases - lead to the decision not to use the software at all.
if you want to know why you have to spend 20 seconds reading the preceding text.
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.
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.
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.
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.
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.
Some of my old projects were GPL because I didn’t know AGPL existed. It’s not one of the default options on GitHub, i.e. the place where 90% of open source developers debut their journey
You can always ask that question. Why not anticipate a potential use on the web and use the AGPL? Why not anticipate people wanting to incorporate parts of your code into their products and use the LGPL? Maybe it could be used within Android or in BSD and you should use Apache/MIT/BSD to avoid license incompatibility? (If your main concern is to give something to the world and not copyleft.) I mean you’re actively prohibiting combining code if you use a strong copyleft license, even if the BSD people have good intentions.
It’s an individual choice on a case by case basis. Obviously people will choose popular licenses more often, despite something being the correct choice. But every license has pros and cons. There is no single answer to licensing.
I may or may not care whether the code gets integrated into a proprietary network project, depending on the particular FOSS project. If it’s some general purpose command line widget, for instance, I would probably prefer not to restrict its usage in that context. If it were a long-running back-end online service project like MongoDB, though, that would be a different story, because that’s the kind of thing AGPL was created for.
GNU licenses aren’t about denying people from making money, they’re about ensuring that they share their code changes with everyone. AGPL was created to solve a new edge case concerning SaaS companies like AWS, Azure, Google, Alibaba, etc.
