We're actually not confident with AGPLv3. We might change it to a more permissive license if it prevents people from adopting the technology. Feel free to create an issue on GitHub and we'll discuss it!
> I am not a lawyer, and this is not legal advice, but the choice of AGPL makes this utterly unusable as part of a commercial web application.
> Not only would it require all frontend code to be open sourced, but if it's used in-process in the application server as recommended for server-side rendering (for accessibility or SEO), all backend code for that application process would need to be open sourced as well.
...
> If you want the largest usage (and, by extension, upstream contributions), I'd encourage a license like Apache, BSD, or MIT. React itself is licensed under the BSD 3-clause license to sidestep many of these issues! The ecosystem nowadays is such that the default is to fork on Github anyways and send pull requests upstream, so that the application can benefit from continuous upstream bugfixes and just use the mainline NPM version without needing to maintain a fork. There are so many incentives to contribute that I think many open source projects lose more than they gain by trying to formalize contractual obligations.
Here is the culprit: When no other people invest in enhancements, there is also nothing that can go back upstream.
I like free software very much, but I also don't want to be forced to give things free, that I make. Problem is not the small enhancements I make to an OSS product, but when I link or use some OSS part in a bigger software that I made -- should I always be forced to give everything for free?
Particularly for companies, that is a difficult thing.
To be clear: Of course I would give away my contributions to an OSS product, but I also want to be free, to use OSS in commercial products without need to fear that I loose my own rights.
GPL here is just difficult and when lawyers have to decide about software, anything can happen (as in the patent-wars).
A great example of such competitive environment is game development where you can't let religious fear of licenses get in the way. If a license is compatible with the business model then use it, and if not then try to get the developer to give you an exception. Development time is precious in getting the product released in the right time window and in a stable state. Studios can't afford skipping GPL development tools (which would not be part of the end product) or LGPL libraries (unless constrained by aspects shared by the competition), as the risk to the company from delayed release is significant higher than the cost of having a lawyer go through a license and confirm if it will impact the model for releasing the game. As a result many AAA games are released with a huge list of free and open source libraries.
But if you are an incumbent holder in a market with very little competition, then you can have policy against licenses and do well. What would an extra month of development for iphone cost Apple as a company?
That's a feature, not a bug. If I release free software and you are unable or unwilling to play fair, I don't __want__ you to use my software.
If ORY was a full stack content editing service, rather than just a client with a demo server, then you could still run it unmodified, making it easy to share the source (just link to the official repo). Your other services could either operate on the data being saved by ORY-service, or communicate with it via an HTTP API (whose implementation would be an open component of the ORY-service). But once again, your own software would not fall under the AGPL, because they do not extend, or trivially wrap, ORY.
The only way an AGPL license would force a user of ORY to share their own code, would be if they forked ORY and extended its own codebase, or wrapped it in a trivial adaptor for some framework or platform, e.g. a Wordpress plugin.
IANAL, and the AGPL is a long read, but I do feel like I understood it, and could use this alongside closed-source services.