Discuss: Changing license from AGPL

[bpartridge]

First of all, amazing work - this seems to be a very well designed library!

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.

My understanding of AGPL is that if someone interacts over a network, with a process that links to or otherwise derives from AGPL code, then the ENTIRE source code running in that process must be released. AGPL is primarily used for databases, where modifications to the database process are likely to be useful to other users of the database, and thus large companies can't "fork" the database and add their own, say, high-availability features without contributing them back. This is a decent overview: https://www.quora.com/What-is-the-difference-between-GPL-AGPL-and-LGPL-licenses

And even with the GPL (not AGPL), some argue that the entire application, both backend and frontend code, may be considered "part of the same application" and would need to be open sourced: https://www.sencha.com/legal/open-source-faq/

But to have this requirement for application code is a dealbreaker. It would be relegated to standalone deployments with very little value add; people would not, for instance, be able to use this for a help center or wiki inside a commercial product, without having an entirely separate server infrastructure for it and at most embedding it in iframes (which largely defeats the purpose of it being a React library!) And, per Sencha's arguments, even this is in a gray zone.

In theory, something like the LGPL would seem to most closely match the intention; people could link to the ORY Editor on both frontend and backend, and while they would need to contribute upstream any changes they make to the ORY Editor, they would not need to contribute any of their other business logic that embeds the ORY Editor. However, the act of minifying code may in fact tie things closely enough together that a court would see the application as a derivative work; to my knowledge this hasn't been tested in the courts in any country. People like this individual shy away from any GPL or LGPL Javascript library for related reasons: https://www.nczonline.net/blog/2015/12/why-im-not-using-your-open-source-project/

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.

Subthread on HN for discussion: https://news.ycombinator.com/item?id=14417763

[devrandomguy]

Related old discussion regarding AGPLv3 libraries in closed-source applications: https://softwareengineering.stackexchange.com/questions/107883/agpl-what-you-can-do-and-what-you-cant

Just sharing it for now, I'll start a new comment if/when I have one. FWIW, I like the idea of the AGPL, but I haven't used it yet.

[devrandomguy]

It looks to me like the conflicting interpretations ("Usage is not derivative, even for libraries" / "The whole application is covered, even over the network") would cause people to modify their architecture and design, to avoid having to confirm their interpretation of the AGPLv3. IMO, the FSF needs to make an AGPLv4 and GPLv4 to clarify the boundaries between derivative works and works that use covered works, but are themselves out of scope.

I retract my support for them, at least for client side libraries that are effectively static-linked to the rest of the application bundle.js.

[aeneasr]

Hey, thanks for the write up! We're definitely considering switching the license model as we know that AGPL has had some issues in the past. On the other hand, we want to avoid the situation where large companies take advantage of open source projects like this one without giving back, although this has a lower priority for us than helping as many people and developers as we can. We will discuss this internally next week!

[dustinkeib]

+1 for MIT or BSD 3 clause! Thanks!

[NullPtrEx]

On the other hand, we want to avoid the situation where large companies take advantage of open source projects like this one without giving back

I don't want to sound very pedantic -- and I really appreciate all the work you guys have done here and put up as open source -- but ORY Sites is closed source (and something you make money off) and uses other open source projects. Imagine if those open source projects that you used were also AGPL.

The other thing is that a company that sells products (and does not do OpenCore like business model) would want to use this library, but would not be able to because of licensing, and hence would not be able to contribute to this project.

[aeneasr]

AGPL only requires you to open source the library if you made changes to it and link to it in your app, to my understanding you don't need to open source code that uses AGPL licenses. That's at least how GPL works iirc.

[confiks]

So with which intention did you guys specifically choose the AGPL in the GNU family of licenses? As is mentioned by the OP, the AGPL is intended for server applications, where the source code is not distributed to end users. ORY is a client side library, which makes the specific-to-AGPL clause "your modified version must offer source code to all users interacting with it remotely through a computer network" super hard to interpret. ORY doesn't seem to do any network interaction by itself, so regardless of the intent of choosing the AGPL, it might not even apply.

So say ORY would use the GPLv3, that could work. A minified Javascript bundle with the ORY code is distributed to the end users. The GPLv3 would require that you at least make the modified source code of ORY available, which is "the preferred form of the work for making modifications to it".

But it's pretty unclear, and untested in court, how much of that Javascript bundle you'd have to make open source. The top SE answer that was already linked, makes a very good case that, really, you'd only have to open source the 'ORY part' of the Javascript bundle. Maybe you'd split the bundle in GPL and closed-source files to make the distinction a bit more clear, but you'd be sure that you only have to release "the modified work" which is ORY.

I think this is the most healthy and useful explanation of the GPL for ORY. But the legal uncertainty scares a way a lot of companies. The way in which that legal fear is constructed, might actually be a reason for you to choose for the GPL. In my opinion, the legal fear is probably not warranted, and the enforcement of the license would be in a European court where punitive damages practically do not exist.

Maybe the best question to ask is: would you yourself, as a company, be fearful of using a GPLed Javascript library in your closed source product? (and then of course releasing the source code of the modified GPLed library).

Also, if I may add in on this, I think the bikeshed should be painted red.

[aeneasr]

@confiks the points you raise are very valid, and came up in discussions we had with the FSFE and also reflect my readings on this topic in various blog articles. While I myself don't have a particular problem to pay for OSS when using it as a company, especially because I want make sure that the projects is maintained and my bugs are addressed, I understand that others might not see it that way, and that AGPL might not even help us in court with this if we ever decided to go that route - which is unlikely as I expressed my understanding of AGPL in the previous posts and I'm the founder and CEO of ORY.

Who in this thread would like to use the technology (not just taking a look, really use it) and does not want to do that because of fear of AGPL implications?

[aindlq]

The problem is that many developers from commercial companies will not even look into GPL/AGPL based libraries, because there are zero chances that management will approve it. Typically company gets a list of licenses, that are safe to use, from a lawyer and I've never seen GPL or AGPL in such a list.

[vatterspun]

First, if you're someone is worried about cooperation or use by a business, go with Apache 2.0, which includes language around patents. Anyone who pays any attention to open source knows that patents are in a terrible state and it's wise to address that within your license. Neither MIT nor BSD include anything on this topic.

Second, there are a lot of advantages to releasing your code under a GPL license, even for business:

The problem is that many developers from commercial companies will not even look into GPL/AGPL based libraries, because there are zero chances that management will approve it

The share-and-share-alike attitude means that everyone contributes to a single code base. A rising tide raises all ships, making technology work for everyone. This is the concept behind successful projects like Linux, a project that companies like Cisco and Microsoft (who have been in trouble with the GPL) now contribute to.

Speaking from experience at a Fortune 100 company, they afraid of two things:

1. Tying a developers hands
2. Losing control of a software product when a developer grabs GPL'd code to solve a problem and then that code shows up in an closed-source project.

As a result, a big fuss is made internally against the GPL, but this doesn't reflect in their actions.

[kmmbvnr]

You can just add an AGPL Section 7 "Additional Permission" clause http://www.gnu.org/licenses/agpl-3.0.html#section7 that would explicitly allow projects to import and use the editor without triggering a derivative work under the AGPL.

Here is the sample from the GCC project that allows using its runtime library to compile with projects under different licenses.

https://www.gnu.org/licenses/gcc-exception.html

[aeneasr]

Thank you all for the extensive debate. We came to the conclusion that we will not be moving away from AGPL, but we are discussing the addition of section 7 of AGPL. Before making a final decision, we will pair up with people familiar with legal proceedings in the area of open source, so this might take a while. I will keep you posted on this matter. In the meanwhile, if you have requests concerning your business, please contact us at hi@ory.am as we are in the process of setting up an affordable commercial license that frees you from all AGPL obligations and ensures our ability to maintain this project down the road, even if our other branches of business fail.

Although I'm closing this issue, feel free to discuss further ideas here. I will be monitoring this issue very closely.

[aeneasr]

We are currently investigating LGPL, which allows, to our understanding, linking without corrupting the code with GPL. As noted above, AGPL does not make a lot of sense for javascript, as the code is usually transmitted to the client. This would allow us to demand any changes to the editor to be made public under LGPL and keep moving this forward.

[aeneasr]

We're now LGPL!