He actually does like it:
He is very rigorous in many of his other beliefs (GNU/Linux, this "open vs "free" debate).
If he does not agree with BSD/MIT licenses because they inevitably allow companies to limit the "freedom" of their customers, how is selling an exception any different except that the open source project is now making money? I mean an argument could be made at that point that you are selling off your principles to the highest bidder. I don't necessarily believe that, but still...
Compare this to our current situation, where everyone's so used to clicking "I Agree" on an EULA screen before they can use a program that many Free Software programs (most famously Firefox) started including such screens, even though there is no requirement to agree to any terms before using them! Of course, there are usually terms related to redistribution and re-use of the code, but that can be done without ever seeing such a screen.
Stallman doesn't disagree with BSD/MIT licenses; he only advocates the GPL as a short-term measure to get to the goal quicker. BSD/MIT code is (usually) a valued contribution, as it lifts everyone up equally; Free Software is lifted, but so is proprietary software since it is trivial for anyone to repackage it as proprietary. That's fine if your goal is to advance the state-of-the-art, give unimpeded access to better security, get your ideas out there, etc. but it doesn't do very much for (or against) the goal of having mostly Free Software.
The only way to go the other way and turn proprietary software into Free Software is by a dedicated effort on the part of the copyright holder (who may be dead!). Hence the playing field is heavily biased in proprietary software's favour, which endangers the mostly-Free goal. The GPL tries to rebalance things by going the other way.
In a mostly-Free world, this bias would (hopefully) be counteracted by the inertia of Free Software, so the GPL would be unnecessary and the more permissive licenses would be a better choice.
Notice that Open Source didn't feature in the paragraphs above, since it's unrelated. That's Stallman's argument: it misses the point. He doesn't say it's intrinsically bad, although it may cause indirect harm to Free Software through distraction and confusion. Of course it also does indirect good, by leading people to Free Software who would never have been exposed to a purely Free Software message.
This is in part due to the fact that for a long time it was difficult to forgo the EULA screen on the Nullsoft Scriptable Install System, which a lot of free software projects were using for their Windows ports.
For me the question is about corporate control, rather than end-user access to the code. For this reason I see the following things as harmful:
1. Dual licensing
2. Requiring copyright assignment for contributions.
These things place organizations in control of the software, and they are things less important to more permissive licenses.
Hence my view is that the BSD license is more radically anti-corporate than the GPL.
There's the video of Brian Aker trying to antagonise rms at FOSS 2009[1], wherein rms lays out some additional rationale, if you're interested.
"Selling exceptions means that the copyright holder of the code releases it to the public under a free software license, then lets customers pay for permission to use the same code under different terms, for instance allowing its inclusion in proprietary applications."
Users still have access to the same exact code. There is no loss. He goes to on further detail what you might find confusing:
"We must distinguish the practice of selling exceptions from something crucially different: proprietary extensions or proprietary versions of a free program. These two activities, even if practiced simultaneously by one company, are different issues. In selling exceptions, the same code that the exception applies to is available to the general public as free software. An extension or a modified version that is only available under a proprietary license is proprietary software, pure and simple, and no better than any other proprietary software. This article is concerned with cases that involve strictly and only the sale of exceptions."
Sure, there's loss of what the other party builds on top of the code. While I don't think this is a real loss, the argument that it is is exactly the argument that Stallman uses against the desirability of non-copyleft licenses, so Stallman's positions on these issues seem incoherent viewed together, even if each might be viewed as reasonable enough on its own.
Ah, but the beauty of it is that the principles haven't been sold. It's still Free Software, which is all that matters. Except now, it is Free Software funded by proprietary software companies.
You can't effectively dual license software unless the public license has restrictions that don't serve your target market. The more restrictive the license, the more it favors dual licensing. This is actually my biggest concern with the GPL.
> And in practice, it seems the most common alternative to the AGPL in this setting is to just keep your code fully proprietary, so competitors can't build on it.
Efficito (of which I am a co-founder) offers hosting for a web-app based on open source software. We have few specific enhancements that don't make it upstream but those are really specific to our hosting offers (i.e. they don't provide customer-facing functionality, but provide functionality to us as hosting provider). Almost all of our work gets contributed back. The software is licensed under the GPL v2+, and the community is (I think rightly) hostile towards upgrading to the GPL v3.
I don't like the AGPL. I think that once you start encumbering services, then you have added a series of restrictions which really are even unheard of in the proprietary software world. Yes, it is pragmatic, but this is the way real freedom is lost, by insisting that practice serve some notion of freedom rather than the other way around.
In practice, the restrictions in the proprietary software world are insane compared to the AGPL, imo. There are restrictions on, to make a non-exhaustive list:
1. Commercial vs. non-commercial use. Just yesterday there was a JS chart library that got positive comments here on HN, whose terms for the free version are that you cannot make any money from sites using the charts, even indirectly (a single affiliate link on your website and it's a license violation!).
2. Number of developers. Your three-man team asked a fourth person to make some edits to the code? Now you need to upgrade your license to cover a 4-seat setup!
3. Number of deployed servers or sockets or CPUs. You're load-balancing across more than 32 cores? Now you need to negotiate an Enterprise license!
4. Number of users. You got linked on HN and got 10,000 hits today? You've exceeded the size of site that's eligible for the free license!
I actually read the AGPL as driven by mostly pragmatic factors. It didn't even come from the FSF initially, but from a developer (Affero) who believed it fit their business strategy better than the existing licenses.
One of the traditional business strategies built on the GPL, which RMS does not greatly like, but is quite possible to do, is the dual-licensed GPL/proprietary approach. People who are willing to GPL their own software may incorporate your code under the GPL's terms. Other people who prefer more traditional commercial terms can, alternately, purchase a commercial license.
In the webapp setting this approach no longer works, because the GPL only covers "distribution", and a webapp backend is never distributed. Therefore nobody will buy a commercial license. The AGPL more or less restores the traditional GPL terms in the webapp setting, where you have to GPL your product if you ship an app containing the GPL'd code: only now, deploying a public webapp is a form of "shipping" (which is how most software devs actually do see the situation... deploying a live webapp is a modern-day form of shipping software).
And in practice, it seems the most common alternative to the AGPL in this setting is to just keep your code fully proprietary, so competitors can't build on it. I think in that sense AGPL is helpful if it encourages more releases, e.g. if it encourages more companies to take the Launchpad approach with their code (AGPL) rather than the GitHub approach to it (proprietary). The other common alternative is to release the source but under a non-OSI license like "free for noncommercial use only, commercial users must buy a license". The AGPL seems at least more generous than that.