MIT/BSD is great for small, less important things, and allows for no-question-asked use of such software in basically any setting where software does not need certification. This is something many authors seem to cherish: "my piece is useful and popular!".
The problem is that a small fun hack may eventually grow into an important infrastructural piece, and at best you can try and re-license it under GPL / LGPL if you want more control, and all contributors agree.
OTOH going with AGPL usually means that no corporation will ever touch your software with a ten-foot pole, so corporate contributions to the codebase will be zero (unlike GPL software). This may keep that software more free in one's eyes, but also obscure.
As a practical matter, I think that you're right — but I think that this is in many cases quite short-sighted of the corporations who choose to go this route, in much the same way that for many years they resisted shipping GPLed software to customers. One can make profit on AGPLed server software in exactly the same fashion that one can make profit on GPLed client software.
If Amazon offered an AGPL Redis, they'd still be able to build whatever they want around it, and keep that proprietary. I'd still find value in paying them for their running-Redis-in-AWS. They'd still make money. Their competitors would get a Redis … the same way that they currently get a Redis.
But antirez and the rest of us would get to share in their performance patches &c. Would that alone make him as rich as he deserves? No, probably not. Would it alone even enable him to make a meager living? No, probably not. But it'd be better than a BSD license, which requires very little indeed.
GPL has neither of these qualities. GPL only requires pay-it-forward with reciprocity being incidental. GPL only prevents takeovers that require proprietization to be effective (which is some portion of takeovers, I'd agree)
Separately, the AGPL situation is obnoxious. AGPL does nothing wrong here. Corporations being anti-AGPL is bullshit (but is indeed all-too-widespread).
You actually don't need all contributors to agree, you only need one. The MIT and BSD licenses don't ban you from relicensing into more restrictive licenses (that's why they're popular with businesses, after all).
The fine hair splitting begins at what is the required amount of modifications required to be able to relicense the given chunk of code.
Eg if I were coding a database like Redis, maybe I'd be totally cool with people freely using it in their moonshot VC-funded trike sharing site, but not with cloud providers offering it as a paid service (or, at least not without paying me some royalties).
Maybe because then you need to have CLA's (Contributor License Agreements)? Otherwise, who is "you" that they need to ask? It's not just your code, it is based on work of many other contributers.
Basically, making anyone who contributes aware that the contribution doesn't give them a claim in the copyright of the project. Short and simple.
It's the social issue, not the legal issue, that's annoying about CLAs.
It is as simple - and it is not. You need to take care of special cases, like contributions from company employees in their free time (their company could still own rights to this work), people contributing other people's code (SO answers), patents and whatnot. Fortunately there are existing CLA agreements (Apache for instance).
As for this being the social issue, I don't know yet how big a problem that is. It's never bothered me before, as I recognize that maintainer might want to take the project in another direction in the future and since I don't want to maintain it, I am just happy that they are doing it for me. I will use CLA for my project and if someone doesn't like it, it's fine too - I don't mind forks (if they are well maintained, I'll just switch to them ;), and if someone doesn't want to contribute because of this, I don't want their contribution to be in my code anyway, because it limits my options in the future. There's a new post today on HN [0] that presents options pretty nicely, and it is very aligned with the conclusions I came to.
[0] https://www.influxdata.com/blog/its-time-for-the-open-source...
Because handling “ask me for permission” is expensive, even if you say no, and you can only do it if you sacrificing much of the main benefit to using open licensing, which getting free work from downstream, since people having to give code ownership to you makes them less likely to contribute back anything that you can use with your licensing model, even if they are doing GPL derivatives that the rest of the world can use without the “or ask me” part.
Or do you posit that GPL (or another reciprocal license) prevents adoption of software where a MIT (or another permissive license) would lead to adoption of that same software?
I posit that people businesses share contributions because it brings them business value, and the business itself being able to use the code in proprietary derivatives often significantly enhances the business value from sharing contributions, which is why SQLite (available as public domain or permissive license) and PostgreSQL (permissive license) have significant upstream contributions from downstream proprietary users, and even Linux gets a fair amount from people whose main use motivating modifications is hosted use which does not require contributions (because it's GPL, not AGPL.)
I further posit that, OTOH, people who don't want to control downstream use are more likely to contribute if they can do so with a license that doesn't constrain downstream use.
But most critically I observe that a GPL-or-proprietary offer cannot use GPL-only contributions, it requires acquiring rights from downstream contributors to relicense code under a proprietary license. So even if people are contributing under the GPL, that isn't “giving back” to the vendor of software that is under a GPL-or-proprietary license scheme (where the value proposition is that the proprietary offers at least as much in all dimensions as the GPL version, and more in some), since by adopting that license scheme they have locked themselves out of use of community improvements that are offered only under the reciprocal provisions of the GPL, which can result in the proprietary version being supported by less aggregate development resources than a community, GPL-only fork.
I'm not aware of any Linux mods not being shared upstream (or at least intended to be eventually PRed to master), except maybe grsec? Please don't give them (AWS/Azure/Google) ideas; we might soon see eg. proprietary drivers for datacenter hardware or Docker/k8s-specific kernel mods. That's a case AGPL could've prevented (though again, I don't know of any proprietary kernel mods).
Hm, come to think of it, the possibility of security-piercing the kernel, then to offer the result as a Linux VM or worse, for hosting Docker-like containers, is concerning. One reason more to buy real VMs with a verifiable standard distro installed, rather than "containers" I guess.
That's my point: they usually upstream changes even when they don't legally need to, because they benefit from the changes being upstream and not something they have to maintain in separately.
That's no worse than the GNU project, which obtains copyright assignments from contributors.
That's what GPL ensures. You can use GPL software anywhere but if you're giving it to other people, you have to give them the same rights you were afforded. And sometimes that also means giving them access to your software too.
LGPL exists too. Makes it a bit more simple for drop-in-libraries.
I find the entitlement complex that some software developers have over other peoples' software to be bizarre. "How dare you offer this free software under terms that don't allow me to exploit your labor commercially without the slightest contribution!" is a real thing that real people say every goddamn time you dare release anything not MIT/BSD licensed.
As discussed upthread, avoiding being used in closed source projects is the entire purpose of the GPL.
You can of course compose your system of closed-source and GPL'd parts, as long as GPL'd parts are separate, and remain open.
And I'm not arguing for people to not use GPL. All I'm saying is there are valid reasons to use MIT (or whatever) if ones goal is to make their project as usable as possible.
It takes a very forward-thinking person to understand that they have more to gain from the thousands of eyes and the support of the community, than from a paywall that gates access to their creation. (And that person could reasonably choose to license their software as GPL or any other open license, there are lots of trade-offs.)
But if you're not building the system from scratch, you need to be aware of the licenses you've accepted, and for many businesses the addition of GPL software to the stack will be a non-starter. Do you think we'd have Apple as it is today if it wasn't for BSD Unix and the BSD license?
But indeed, GPL does limit the ways you can distribute software licensed under it. In particular, licensing something like a library, or another early-bound component under GPL forces the users to license their work under GPL, too. This is why LGPL exists.
It's simply wrong to say that nobody pays attention to this. It's a choice you make, and whether you view the consequences as "repercussions" or "features" depends entirely on your view and the actual outcomes of those choices.
Fwiw I understand that Darwin is also available as BSD, so it seems you can get some good actors that are willing to pay it forward without necessarily needing to add a license that goads them into it.
Their subsequent choice to use BSD-licensed components, and to support/create BSD-licensed components where only GPLed components existed, must be seen in the light of this experience.
(If they have a good legal department that understands intellectual property issues at all, and their product team knows they don't actually need to hack on the Linux kernel to make whatever they're building, then they will not likely be restricted against using Linux ... but the decision will necessarily restrict their choices when finding other components to use as part of the system they are building.)
Whether that is a good thing or a bad thing, I certainly feel is debatable and I'll reserve judgement. But it is provably wrong to say that nobody chooses not to use a GPL-licensed piece of software because of the license it is distributed under. Tons of people do.
GPL licensing will not stop me from using your software. It will stop some people. I do not say that I agree with those people and their decisions. I could not have built my career without GPL software, and it does not stop me.
GPL is unpopular, and if you want people to use your software, it is the wrong license to choose.
Should it be? Perhaps not. ...but I don't think the parent comment is nearly as wrong as people seem to think.
It doesn't matter if the GPL technically is a better or worse license; the fact is that (perhaps indeed driven by large corporations) GPL has a very negative image right now, and since we do live in a 'look at my popular github repo with oh so many stars, aren't I popular, oh btw hire me pls' world now, that is actually a big deal.
The question is not, 'should I use GPL?', because the answer is no, if you want to have a successful popular open source project.
The question is; how do we actually change the perception of GPL so the answer becomes yes?
I'm not sure... but I think it's a far more important question.
(I can certainly say that I no longer use the GPL, after using it for many years, largely because it was requested I remove it from projects. What do you do in that situation? Since I really don't care that much why not just put it under something else? I don't have a good answer.)