Hacker News Reader

Hacker News

Comment by throwawayk8s | Hacker News Reader

Parent Full thread

throwawayk8s

Is there any OSS implementation that is not AGPL?

View on HN

Seaweed. Apache license.

https://github.com/seaweedfs/seaweedfs

I don’t think development is very active at all now that Basho is dead, but Riak CS is Apache licensed.

https://github.com/basho/riak_cs

Ceph Object Gateway is LGPLv2.1

Why would that matter? Apps using its api don't need to be AGPL

First of all, it isn't clear this is the case.

But this entire comment thread on the AGPL misses the mark. It doesn't matter that the AGPL hasn't been tested in court or what fine grained distinctions you apply to the license or what the AGPL intends. No company in their right mind would risk using software licensed under the AGPL because the result of being wrong would be catastrophic. The legal advice to be skeptical of the AGPL is absolutely right. There is no conceivable reason to ever use AGPL software when you could simply license it under a commerical license or use a non-AGPL alternative.

Generally when someone licenses something under the AGPL they totally understand this and that is their intention.

> The legal advice to be skeptical of the AGPL is absolutely right.

The legal risk involved by using AGPL software for a company is exactly zero.

AGPL is an open source license which, by the very definition of open source, means that you can freely use the software. Full stop.

The only arguable risk is when modifying the software and on top of that using it in conjunction with other in-house software. But if you are ready to use a proprietary license, you already refrained from modifying the software.

So just use it and end of story. AGPL is a perfectly fine, open source license.

Or, you could use AGPL software and license it under AGPL as well. Considering most money today is made in the hosting and servicing and not selling license, I don't see why you would bother caring about old fashioned ways.

You're right, Google should drop their policy and open source the whole thing, since it's their data and GCP services that are the crown jewels, right? https://opensource.google/documentation/reference/using/agpl...

They are talking about integrating it with rest of their apps in monorepo tho. Not running a completely separate service that you only talk via API

It's kinda easy to miss that detail when you focus on bitching about license instead of the point.

You're right, Google is a sane and healthy model of business to follow and surveillance capitalism, based explicitly on capturing data on users and selling it to third-parties for ads is something that benefits society as a whole. There are absolutely no models other than the one Google is running.

We would like to self host and our legal team forbids us from using AGPL stuff.

Sounds like a problem created entirely by your legal team, not software or licenses.

Working with legal is advisable instead of ignoring it.

The solution to "colleague got it wrong" is not "silently ignore them" and I never suggested that. In fact my suggestion is precisely that you "work with them" and have them review this specific case.

"Don't use AGPL" is a good baseline rule if you don't have a legal team but does not apply in this case as I'm sure they'd advise if they reviewed it.

You should consider a replacement of your legal team.

This doesn’t seem accurate. Isn’t AGPL viral across RPC boundaries requiring open sourcing not just the service but all supporting code for that service?

No it's not. From a practical standpoint, I'm not even sure how that could work. You would have to require all browsers to be open source AGPL in order to load a web page served by it. By way of analogy it seems the equivalent of requiring the mouse and keyboard firmware to be licensed the same as the operating system.

A real life example is Instructure, which makes Canvas (which is agpl) but has other proprietary services that interact heavily with it. It's never been a problem

1: https://github.com/instructure/canvas-lms

> require all browsers to be open source AGPL in order to load a web page served by it

Don't be silly: a web server is not distributing a web browser, and thus when you visit news.ycombinator.com, they don't have influence over whether you do that via netcat, curl, or Awesome AGPL Browser 1.0

If, however, they used https://git.deuxfleurs.fr/Deuxfleurs/tricot to serve the http request, then AIUI the AGPL entitles you, as a "13. Remote Network Interaction; Use with the GNU General Public License. (https://opensource.org/licenses/AGPL-3.0)", to ask for the source code of tricot and potentially any systems that it subsequently interacts with

I'm certain I'm going to regret posting this, given how hot-button the AGPL is in every one of these threads

Instructure doesn't need to comply with AGPL obligations because it owns the product. It isn't licensing it to itself under the AGPL.

As far as I know, this isn't true. Some AGPL users claim that it is a requirement of the AGPL, but I am also unaware of any litigation that substantiates that reading of the license.

Can you cite cases that have established this as fact?

I would suspect no one wants to invest the legal team or time to be the "trailblazer" court case to find out whether your theory or the common interpretation is correct. The "just ban AGPL" stance is by far the safer route since it's not like there are no sane replacements for AGPL stuff

IANAL, and thus far my life is worse for any interaction with the legal system

It totally is safer, and I tend to agree with it in a business context. But the license itself doesn't seem to indicate that any kind of "RPC" is thus encumbered.

When MongoDB was under the AGPL, your application wasn't under the AGPL if you connected to it and asked it to do queries.

For some places, the in-house legal department makes it very difficult to use anything AGPL even if you assure them you're only using the api.

Triton Manta is MPL

https://github.com/TritonDataCenter/manta

Are you sure this offers the same S3 compatible API? It sure does look like it rolled its own API[1], which I guess is fine so long as you're entirely in the Triton ecosystem, but makes reusing existing software harder than necessary without that compatibility layer. And that's not even getting into this absolutely mess: https://github.com/TritonDataCenter/manta#repositories it reminds me of the "Microservices" video come to life

1: https://github.com/TritonDataCenter/manta/blob/master/docs/u...

Reply on news.ycombinator.com