标签：#agpl

When we open sourced Neural Inverse Cloud, the easiest choice would have been MIT. Most developers like MIT. It's short, permissive, and widely adopted. If you've released an open-source project before, MIT is probably the first license you considered. We didn't choose it. We chose AGPL. Not because we dislike permissive open source. Not because we want to restrict users. We chose it because infrastructure software plays by different rules. The Infrastructure Problem MIT works incredibly well for libraries. You publish code, developers use it, and occasionally improvements flow back into the project. Nobody is forced to contribute, but community norms often make it happen anyway. Infrastructure software is different. Cloud IDEs, databases, developer platforms, deployment systems, and backend services can be monetized without ever distributing the source code. A company can: Fork your project Add proprietary features Launch a hosted version Build a competitive advantage on top of community work Never contribute anything back The original project does all the R&D. The fork captures the value. We've seen this pattern repeatedly across open-source infrastructure over the last decade. Why AGPL Exists AGPL closes a loophole that traditional open-source licenses leave open. With GPL, if you distribute modified software, you must publish your changes. But what if you never distribute the software? What if you simply run it as a hosted service? That's where AGPL comes in. If you modify AGPL software and provide it to users over a network, you must also provide the source code for those modifications. That applies to everyone. Including us. If we improve Neural Inverse Cloud, those improvements stay open. If someone else builds a SaaS business on top of it, their modifications stay open too. Why This Matters for Users We wanted users to have guarantees. With AGPL: You can self-host the latest version Community improvements remain accessible No company can create a permanently