[ojosilva]

Looks and works great, but there are 2 limitations I think would prevent it from using it in our stack:

1) It cannot be easily embedded, ie. as a field in a form. Apparently it's meant (UI-wise at least) as a full-screen editor and has lots of dependencies of its own, including React.

2) AGPLv3 license is a killer. Means that any work that links to the library should be opensourced. Despite some people interpreting it differently, it would be risky for a consumer product to ship making use of this library.

[arekkas]

We are working on (1), and make it possible to include it in non-react environments. However, there are still some dependencies required (such as react). So yes, this is not perfect at the moment.

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!

[btown]

I did create an issue about the AGPL: https://github.com/ory/editor/issues/392 Quoting some of my thoughts from that thread here:

> 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.

[ralmidani]

Actually, I would be more confident working with a GPL- or AGPL-licensed product, because enhancements are more likely to go back upstream.

[PythonicAlpha]

That is right. I just know, that many companies flee from GPL licenses (and more so AGPL). They omit any product involving GPL just to be sure not to get any juristic hassles (if rational or not).

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).

[belorn]

Any company that arbitrary limit themselves will be at an disadvantage to their competitors. LAMP for example include GPL products and avoiding it can be more costly and time consuming than the alternative (hosting solutions with LAMP for example).

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?

[ralmidani]

> many companies flee from GPL licenses

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.

[devrandomguy]

+1 for keeping the [A]GPL. As I understand it, the CRUD service that backs this would be separate software, which only communicates with this editor through an API, so it would not be affected by ORY's license.

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.

[btown]

Some of your assumptions may not hold in this case: see my thoughts at https://github.com/ory/editor/issues/392