Hacker News Reader

Comment by swsieber | Hacker News Reader

Well, AGPL was the answer to that issue, but it hasn't really done much. I think part of the impact was things like GitHub recommending the MIT license.

View on HN

My understanding is that the AGPL is an answer to an older problem and didn't see the cloud coming. It addressed those running web-hosted GPL licensed applications who were side-stepping the viral aspect of the GPL by claiming that they were not "technically" distributing a binary by making the application available on the internet as an executing web app.

The AGPL requires those who create web applications derived from the AGPL (whether they're distributed as binaries or not) to make the code for their web applications available.

The AGPL does not address the cloud-hosting conundrum at all. This conundrum is where a cloud hosting company (e.g. Amazon AWS) can replicate the original author's service offering using the unmodified open source tool (wrapping it and interacting via API at most), and undercut the original author's business model. I.e., you can imagine a power user of some AGPL software competitively putting the software author's company out of business.

This is the reason for the recent licensing restrictions around ElasticSearch and MongoDB. The originating companies have had their hosted service revenue models undercut by Amazon AWS offerings that simply repackaged the software as part of their cloud offering.

Making the AGPL even stronger by adding in a viral API clause would pigeon hole AGPL software to only the most fringe ideological use-cases as everyone would be afraid to run AGPL software in a business context.

The AGPL covers the cloud use case insofar as, if a cloud provider takes the AGPL-licensed code, adds additional features, and offers it as a service it would have to add those additional features. (And, potentially, other code that interacts with the AGPL-licensed code; the boundaries are a bit unclear.)

Of course, the desire is to keep AWS from offering even just a fully-compatible competing service. But that would 1.) require APIs to be copyrightable and 2.) would, as you suggest, make that software pretty much unusable for most cases.

You're right that the AGPL largely pre-dated the cloud providers although the direction things were going in was reasonably clear.

I don't think the AGPL actually cares about being able to undercut the original author's business model, as long as you're not just taking open source software, adding minimal value-add, then keeping that as a closed service.

The AGPL was really driven by the increasing prevalence of software being delivered in the form of a service. I don't recall much discussion of business models at the time but there was at least a school of thought that the GPL's protections of software freedom were being eroded because of service providers exploiting this "ASP loophole."

People tend to spread a lot of FUD about AGPL. We have recently released a server product under GNU AGPLv3, and very next moment someone says: "Agpl makes it basically worthless except as a toy" :-\

Source: https://twitter.com/binarytemple/status/1172884198912331776

Also you can ask 20 honest developers what they think AGPL means and get 3 or more wildly different explanations, at least if you include "I've no idea except it also works lver the network".

The meaning seems pretty clear. It's like the GPL but distribution now also encompasses offering the software over the network in the form of a service.

What's less clear is what defines the boundaries between AGPL-licensed software and the rest of your stuff making up whatever you're offering. This isn't always 100% clear with the GPL either but the GPL meaning of distribution is pretty tightly tied to traditional Unix methods of combining code which are mostly unambiguous.

> The meaning seems pretty clear. It's like the GPL but distribution now also encompasses offering the software over the network in the form of a service.

Agree.

> What's less clear is what defines the boundaries between AGPL-licensed software and the rest of your stuff making up whatever you're offering. This isn't always 100% clear with the GPL either but the GPL meaning of distribution is pretty tightly tied to traditional Unix methods of combining code which are mostly unambiguous.

Agree again.

See my point? I don't say AGPL is bad only that it has a tendency to confuse developers in all directions.

Or you can stop spreading the FUD and point people to: https://www.gnu.org/licenses/why-affero-gpl.html

It might very well be that this is more of an education and explanation problem.

My point still stands: I don't personally know a single person who is able to explain AGPL.

Is it not "if you take AGPL code and run it on your server and make it available to other people, you need to give them the code to whatever you're running"?

It's the "whatever you're running" that gets complicated if you're using the AGPL code in conjunction with a bunch of other code to deliver some service to customers. What are the rules around how that other code is allowed to interact with the AGPL code before it has to be made available as well?

Ok, two slightly different already, in addition to a number of people who have no idea at all.

I think this proved what I said.

(That said there was a thread on the n8n project where a couple of persons had serious problems understanding the basics of open source, its relation to free software, why commons clause isn't open source etc etc so guess we will have to explain what is and isn't "open source" for the foreseeable future :-/

Reply on news.ycombinator.com