If they accepted contributions without a CLA, then no they can't make closed-source modifications (without some major surgery to get rid of the code not owned by them). If they wrote all the code in the first place, then that's hardly an "unfair advantage".
The only way to accept contributions and then make closed-source modifications is with a CLA; in which case it's the CLA, not the AGPL that you're really complaining about.
ETA: OK, so what if a company start out being AGPL, never accepts any contributions, and then when they become established, stop publishing new code as AGPL and takes everything proprietary? Isn't that just "open-washing", taking advantage of all the community good-will and hype around open source?
I don't think so; consider four possible scenarios:
1. They keep everything proprietary from the beginning.
1a. They become established, making decent money, serving some customer needs. Everything is still proprietary
1b. They fail. Good luck talking their VCs at that point into open-sourcing their code (or even getting it into any kind of shape that anyone could use). All their customers are stuck without any options but to stop using the software.
2. They start by making things AGPL.
2a. They become established, making decent money; eventually they take the product closed-source, doing one final release. Their customers continue to be served, but everything is now proprietary.
2b. They fail. The code is already AGPL, so nothing any of their owners or creditors can do to claw it back.
Large companies that have come to depend on their software can take their code and continue to use it and develop it on their own if they want. If there's enough of the right kind of people, a community can form around the releases and the project can live on in a pure open-source form.
2a is better than 1a, because at least there was a time when things were AGPL; the AGPL code can still be forked off and maintained if there's a big enough community.
2b is way better than 1b. In fact, 2b can hopefully make 2a more likely, since it's lower risk for people to build their infrastructure on a start-up.
Yeah, I think you're spot on with the whole CLA thing. This is why I added the badly-emphasized caveat "in business", which ime typically use CLAs. Outside of startup-land, AGPL is a fine license. I just don't think it's used honestly in startup-land, that's all. We all know the real reason OSS startups use the AGPL: to push competitors and enterprises to purchase a MAY-issue commercial license through FUD; yet we still praise them for being Open Source. Yay. But imo, in startup-land, it feels like a non-compete masquerading as Open Source, even though I know it isn't.
I'd rather OSS startups be more honest and use something like Fair Source. Bonus is that everything would eventually be OSS, unlike the typical Open Core model.
Fair source is worse than the AGPL though, sure it's "eventually open source" but what good is 2 year old code for anyone? How do you add improvements/security fixes to the codebase without the developer saying you didn't clean room the implementation?
I think you're coming at this from the wrong angle, but the 2-year delay is really only applicable to users that want to compete, or in cases where the startup goes under or in a bad direction. For most users, the freedoms under Fair Source align pretty closely to Open Source, e.g. read, fork, modify, redistribute, etc. with the non-compete caveat. Users can absolutely use the latest version -- unless they're competing, but most users aren't competing and don't plan on competing.
The difference is that all users also eventually get the proprietary features, unlike an Open Core project under AGPL + commercial terms. I do think Fair Source is a better model than Open Core, at least in most cases, because of this alone. So I guess, would you rather: 1) never have the proprietary features, or 2) have 2-year old proprietary features? I know what I'd prefer, and from a simple continuity perspective, I know which is preferred by users.
Like I said, I'm not saying AGPL is bad. I just don't like how it's used in startup-land and I think there are better, more honest, options now.
The 2-year delay applies to all of the codebase in my experience, not just the proprietary features. Users potentially have to delay security fixes for 2 years to avoid copying non-OSS code.
Fair source is a poison pill masquerading as OSS-friendly, just like BSL and friends. It's not useful in practice, and I don't think there are any examples of folks successfully using/forking BSL/fair-source code that is now OSS. That's by design.
I think you're missing my main point: the only users who should need the OSS version would be those competing, because FSS offers the same freedoms as OSS to users who aren't competing. I don't see how this is a poison-pill, or how it's masquerading as anything malicious. I think it's pretty honest i.r.t. intent.
Re: forking FSS. Check out what Oxide is doing with CockroachDB -- there's your BUSL example.
The only way to accept contributions and then make closed-source modifications is with a CLA; in which case it's the CLA, not the AGPL that you're really complaining about.
ETA: OK, so what if a company start out being AGPL, never accepts any contributions, and then when they become established, stop publishing new code as AGPL and takes everything proprietary? Isn't that just "open-washing", taking advantage of all the community good-will and hype around open source?
I don't think so; consider four possible scenarios:
1. They keep everything proprietary from the beginning.
1a. They become established, making decent money, serving some customer needs. Everything is still proprietary
1b. They fail. Good luck talking their VCs at that point into open-sourcing their code (or even getting it into any kind of shape that anyone could use). All their customers are stuck without any options but to stop using the software.
2. They start by making things AGPL.
2a. They become established, making decent money; eventually they take the product closed-source, doing one final release. Their customers continue to be served, but everything is now proprietary.
2b. They fail. The code is already AGPL, so nothing any of their owners or creditors can do to claw it back. Large companies that have come to depend on their software can take their code and continue to use it and develop it on their own if they want. If there's enough of the right kind of people, a community can form around the releases and the project can live on in a pure open-source form.
2a is better than 1a, because at least there was a time when things were AGPL; the AGPL code can still be forked off and maintained if there's a big enough community.
2b is way better than 1b. In fact, 2b can hopefully make 2a more likely, since it's lower risk for people to build their infrastructure on a start-up.