Hacker News Reader

Comment by rad_gruchalski | Hacker News Reader

You only have a problem if you modify anything in the source code of minio that you host.

> You only have a problem if you modify anything in the source code of minio that you host.

And even in that case, you only need to share your modifications of minio, not anything about the rest of your system. Doesn't seem too much of a problem, to begin with.

That’s right.

Or put a proxy in front of it.

Indeed. I predict that year 2022 will be the year of a sidecar protocol proxy service.

A lot of companies I've worked for had a blanket ban on AGPL. This is not a problem with the license, it's a problem with those companies. But it's still going to be a pain for the people who work there.

Or for people who work at companies that have those companies as close clients.

If more high-value projects adopt the AGPL, legal departments may be motivated to revisit those bans.

Yes, this is the main reason to welcome these recent adoptions of AGPL.

Blanket bans of licenses are bad for free software. More pressure to revisit them is a good thing.

I drove a revisiting like this in more than one organization.

Fitting decisions like this around the status quo makes no sense. It's exactly actions like this which change the status quo. I'm happy to say there are dozens of organizations without AGPL bans thanks to one useful piece of code I wrote. Most are small, but one is in the tens of billions of dollars in valuation.

Most companies who publish AGPL software also offer a paid commercial license, so it is accept AGPL (and contribute in kind) or pay (and contribute in money).

I don't think this is bad forcing companies to choose between these two (or abandon the software), and they are fully responsible to making lives of people who work there easier.

> This is not a problem with the license, it's a problem with those companies. But it's still going to be a pain for the people who work there.

This sounds like a general problem, unrelated to licensing. If you work in companies with shitty policies, you are in for a world of pain.

These are big companies you would recognize. Shitty policies seem to go with the territory in large companies.

I don't agree it is a problem with the companies. The issue most companies (and their lawyers) have is that this has not (afaik) really been tested in court. So, sure _you_ may state that we should be fine if are are not modifying the code or directly linking, etc, etc, but the interpretation of the license is still _very_ open. Until legal precedent is set, most companies are not willing to take the risk. And why should they?

Many companies (our included) consider AGPL to be a poison pill. and until someone gets sued and the courts set precedent...

Based on [1] it sounds like even if you "link" to AGPL licensed code over a network, unmodified or not, it would require you to also license your own code as AGPL? That sounds pretty far reaching, if I'm reading it correctly.

[1] https://softwareengineering.stackexchange.com/a/107931/28221

I didn’t downvote you. No, that’s not the case. Here’s a better explanation: https://writing.kemitchell.com/2021/01/24/Reading-AGPL.html

Basically, if you ever need to use agpl stuff, do not embed or add your proprietary ip to a modified version. Use a sidecar. Only embed features you don’t care about.

I don't think that essay supports what you said. (It's incredibly well written by the way, thanks for linking it.) Near the end it asks:

> If you build a larger web service by combining network services that call each other over HTTP, rather than libraries or snippets of code linked or pasted together, does “Corresponding Source” include the source for those other services? What if each service is containerized, encapsulated in its own operating system? Do those operating systems count as “System Libraries” or “generally available programs” shield the application code they run?

Note that the author is asking a question here. It's not entirely clear (AFAIK, IANAL, etc) what precisely constitutes "linking" when it comes to the (A)GPL.

A thought experiment. Evil Corp takes a GPL licensed program and modifies it to communicate via file descriptors instead of linking with it at compile time and directly calling its functions. They proceed to distribute a separate proprietary product that makes use of the GPL program for many of its core functions. They claim that this isn't a violation of the GPL because they haven't "linked" with any GPL'd code. This is clearly a violation of the spirit of the GPL, but is it a violation of the letter?

To comply with the license, the Evil Corp would be required to share their modifications giving anybody who sees this as their market advantage the ability to do exactly the same thus diminishing the advantage. The Evil Corp would not be required to share the code which talks to the modified GPL'd library.

That's the spirit of this license and everything is working as intended.

But it's a good line of thought. Here's another thought experiment. When compiling say golang or Rust program, all dependencies end up being compiled into a single standalone binary. If a dependency of a dependency pulls in an unmodified GPL module, what impact does it have on our resulting binary? The common understanding is: if we're asked to share the code of the GPL dependency, we can share the original unmodified dependency and we're not required to share our code using the dependency.

Until we're proven otherwise, we should stick to that common understanding.

Reply on news.ycombinator.com