Here's the play: Open source with AGPL, then offer an enterprise license. You get two wins. The OSS community applauds your adoption of an agressive OSS license. Enterprise customers can't use software under AGPL because it risks infecting their IP, so they're forced to buy an enterprise license.
> Enterprise customers can't use software under AGPL because it risks infecting their IP
This is factually untrue. If you want to link an AGPL blob into your app and ship it to customers, sure. In the vastly more common case where you're using a permissive client library[0] to connect to an AGPL server, there's no risk whatsoever.
At most, you might need to make your local changes to that server available to clients if they connect to it directly, as opposed to hosting a cloud SaaS setup where everything is internal to you. However, that's not the worst thing in the world. "Oh no, we improved a Free server our company depends on, and we have to share those improvements so that the person who gave us the server for free can also benefit from them" is pretty hard for me to sympathize with.
This is vastly more business-friendly than the non-FOSS SSPL.
The goal of free software (noting that "open source" is a watered down version of "free software") is for everyone to share their sohrce code. To that end, licenses that require sharing of source code are used. LGPL says, roughly, you must share the source code of this software to anyone you shared the binary to. GPL is more extensive: anyone you shared the binary or the binary of something built on this software to. AGPL is even more aggressive: anyone you shared it to or gave access to it over a network. And SSPL is currently the most aggressive: you have to share the whole thing you built, not just what's linked with this software.
The more aggressive a license you pick, the more likely a corporation won't want to use it. But that's by design. They're allowed to use it, even commercially - they just have to give the source code back. If the software is useful enough, they will. We should make software useful enough for corporations to consider the be benefits of using it to outweigh the cost of having to share their source code. (Also the more source you make them share, the less likely this is. The Linux kernel succeeded at this.
SSPL is controversial and untested (and goes against the business interests of the OSI so will never be box-tick certified compliant) and likely counterproductive if it means you have to share things like Windows. AGPL is the normal "aggressively free" license. GPL is mostly for those who haven't discovered AGPL yet and MIT is for those who don't agree in the goal of source code freedom to begin with.
only because OSI says so. I don't agree with the idea of OSI defining my philosophical positions and technical terms for me, just like I don't agree with the BSD people excluding GPL from the definition of open source.
I'm sympathetic to the OSI not being the only authority. So, have the DFSG, FSF, any BSD, or literally anyone credible endorsed it as Free and/or Open Source?
None of them have bothered to evaluate it or have explicitly decided it's not worth evaluating for now. They haven't endorsed it as Proprietary and/or Closed Source either.
And notice the OSI's objection actually makes no sense and could apply to any copyleft license! By the same reasoning, AGPL isn't open source. Yet they say it is.
> None of them have bothered to evaluate it or have explicitly decided it's not worth evaluating for now. They haven't endorsed it as Proprietary and/or Closed Source either.
However, the SSPL is clearly not in the sprit of the DFSG, yet alone
complimentary to the Debian's goals of promoting software or user
freedom.
In light of this, the Project does not consider that software licensed
under the SSPL to be suitable for inclusion in the Debian archive.
It matters a lot.
A company could potentially make choice that saves them a lot of money, so they better base their decisions on accurate information rather than rumours.
(Note also that big tech have different incentives)
> Enterprise customers can't use software under AGPL because it risks infecting their IP
Yeah, this is BS.
If you simply use AGPL software, it doesn't "infect" anything. If you *change* the AGPL software, you have to release the changes. It forces the big clouds to open source their Redis improvements.
For the type of software that Redis is intended for, integration over network is a must. Hence "just using it" isn't a viable option. AGPL isn't LGPL, it infects anything that uses it over a network. If Redis was AGPL when it was released, nobody would touch it.
Most of the readers of HN make their living from closed source software. You know well enough that non-hostile open source is just a market entry strategy and the type of copyright-driven maximally selfish capitalist markets just force open source to be not viable for a single company to thrive. Projects like Linux kernel are exceptional infrastructure projects that external companies support not build businesses just to ship.
> Hence "just using it" isn't a viable option. AGPL isn't LGPL, it infects anything that uses it over a network.
This is completely, factually, unequivocally, incorrect.
You can connect to Redis using their first-party, MIT-licensed client library. You can write proprietary software using that library with no requirement whatsoever to release your software under any particular license (although of course you still have to comply with the MIT license's attribution requirements).
If all software connecting to the AGPL'd service runs internally, you're not obligated to share your local changes to that service. This covers the vast majority of use cases. Using WordPress with a Redis cache? This doesn't affect you.
If you host an AGPL'd version of a Redis server and your customers connect to it from their own networks, then the only obligation you have over the tried-and-true GPL is that you have to share changes you've made to your Redis server with users. If you use Redis packages as-is like almost everyone does, this doesn't affect you.
So literally the only people who have to care about Redis being under the AGPL now are those who don't want to pay Redis for a commercial license, who expose their Redis server to customers, and who've made local changes to their Redis server. Everyone else gets to keep using it like they always had.
It’s amazing how much FUD there is over GPL/AGPL. I’ve seen at least 10 posts on this thread saying you have to open source your commercial software if you use the new Redis. I don’t know how there could be such a fundamental misunderstanding of one of the most common software licenses out there.
I know, right? Corpos have done a great job convincing devs of the “dangers” of copyleft licenses, in favor of permissive licenses that purely coincidentally just happen to benefit those commercial users.
> AGPL isn't LGPL, it infects anything that uses it over a network.
Stop lying. This is FUD. It must be disregarded with extreme prejudice. The AGPL must remain free, and anyone interacting with it over the network must receive the opportunity to obtain the original or modified versions of the AGPL'd software and that's it. Nobody said anything about opening up the entire network stack. That is SSPL territory.
> Enterprise customers can't use software under AGPL because it risks infecting their IP, so they're forced to buy an enterprise license.
This is a lie. It's FUD. And it should be disregarded with extreme prejudice. Stop it.
First and foremost, AGPL'd software must remain free. They could use it in their stack. The rule is they must point to the sources of the AGPL'd software. If they make a change to the AGPL'd software and users interact with that (even over a network) then they must disclose the changes to the AGPL'd software. That's it. They don't have to open their whole stack. That's SSPL, so stop spreading this FUD.
Second, it's not their IP. They didn't write the AGPL'd software. They must abide by its terms.
Third, even if they chose (emphasize on "chose" and not "forced") to use AGPL'd software, they could simply disclose the changes they made to it. There is little to no excuse not to. The fact is that if the software meets their needs, they have little reason not to. The AGPL exists to protect Software Freedom so if they find that objectionable it can only be concluded that they intend to harm Free Software.
I think you're thinking of the LGPL. The AGPL is basically GPL plus some additional requirements. I could see a company being OK with ~AGPL~ GPL but not ~GPL~ AGPL. I can't imagine the opposite.
I think you have a typo mixing up AGPL and GPL. I agree that it would be hard to imagine a company being okay with the AGPL but not the GPL. On the off-chance that it isn't a typo, could you explain why a company might be okay with AGPL but not GPL?
