Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model

The AGPL is also unusable for most real use cases. Suppose OpenSSL or GnuTLS switches to the AGPL. How are you going to offer me source when I connect to your server with a TLS client? Would it even suffice to write an RFC to add a special extension to the ServerHello to offer a link to source code, if you know that no other software implements that RFC? I don't think you have any argument that the AGPL wouldn't require you to offer source in this case:

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

I'm a user. I'm interacting with it remotely through a computer network. Your software definitely supports such interaction. The fact that I'm connecting with openssl s_client instead of a web browser is your legal problem, not mine.

Suppose the Linux kernel switches to the AGPL. How are you going to offer me source when I connect to your server with a TCP client? Suppose 389 Directory Server switches to the AGPL, or Kubernetes does. Suppose your IRC client does and I send you something with /me, which is internally implemented with the "client-to-client protocol." Suppose curl switches to the AGPL, and you curl my web server - am I a "user" that you have to offer source to? Probably! (Maybe I've signed up for pingbacks or some other type of web hook from you. That would definitely make me a user.)

The AGPL "works" for a very small subset of software, namely network applications that render their own interface with download capabilities to a remote human user (so, in practice, web applications, though a BBS could do it with zmodem or something), and it prevents the code in that software from being reused in other types of software. If your web-based forum software has a nice function for email address validation, the Git developers can't use it even though Git is GPL'd and could otherwise move to the AGPL, because sometimes people use git daemon or git http-backend and their users interact with it over the Git CLI.

That last bit, I think, means there is an ethical obligation not to use the AGPL; it introduces a new problem in the field of free software licensing. If you've got some MIT-licensed software and you want to use some GPL'd subroutine I wrote, you can switch to the GPL. If you want to use some AGPL'd subroutine I wrote, you might not be able to. (Or you might be incentivized to turn your software into a webapp!) Historically free software has been a commons, at least in theory, and license incompatibilities have been seen as a bug. The AGPL draws a fairly artificial line between software where the AGPL provisions can be reasonably implemented and where it can't and essentially turns license proliferation into a feature.