Hacker News Reader

Comment by jsmthrowaway | Hacker News Reader

I haven't worked for a company in four years that permits the installation of AGPL software because the ramifications are still unclear and largely untested. MongoDB asserts, for example, that just using MongoDB doesn't require you to do anything, even though the license text is in clear contradiction to the assertion. I do not think MongoDB understands its own license.

Chris DiBona has spoken in public about Google's reasons, but he was kind. I cannot discuss other experience I have publicly, so I'd simply suggest doing some research on the large unknowns in deployment of AGPL software underneath a proprietary Web service somewhere, and then think about all the integrations you'd wire up to something like a Slack derivative.

I am not a lawyer and would strongly suggest consulting one before using AGPL software anywhere in your infrastructure, at all.

View on HN

I don't understand you reasoning at all. What could be the problem with using a chat software that is released under AGPL?

Because almost certainly engineers will want to integrate an on-premises system into their existing system, and that will trigger the AGPL for all the systems that are network-connected to the AGPL system.

Unless you are sure that your engineers will know to not try to integrate the AGPL software with any of your existing systems, I agree that people should just stay away.

No it won't... It will at most trigger the AGPL for the integration off that system... which is it's proprietary no one will ever want... hence no one will ever sue you to release it.

Are Tinfoil hats on sale or something?

No, just folks with a little more legal experience than "potentially and willfully violate the terms and spirit of a license because we assume nobody will ever sue us," which also doesn't scale beyond a team of two. Not enough people take license compliance seriously. (Your comment an example.)

Just to communicate the impact here, getting compliance wrong can result in significant legal liability. You and I are both unqualified to dismiss it or discuss it.

I find it interesting that you're getting consistent downvotes for saying the same thing my startup's legal counsel has repeatedly said about the AGPL: Be extremely careful. Assume nothing and write defensively, because the nature of an "integration" is too vague to risk a company's infrastructure.

I get the impression others here are happily screwing around with AGPL integrations with nothing to lose.

I wonder what the lawyer would say about a startup agreeing to EULA's in gmail or iphone/android. Im sure there is not vague terms in those contracts, and that customer emails is perfectly safe to be stored there with no liability risk to the company.

I only suspect, but I think that vague terms in contracts is less of an issue when there has been no court cases involving companies that followed standard practices regarding compliance.

... Okay if it isn't tinfoil hatery... show me the case law which proves me wrong?

Saying "I know a cautious lawyer" is just tautological BS.

>Because almost certainly engineers will want to integrate an on-premises system into their existing system, and that will trigger the AGPL for all the systems that are network-connected to the AGPL system.

That's the FUD version.

The real version is that unless you are changing the source code (hint: not just writing a plugin using an externally facing API) and deploying it, you don't have to do shit.

I think you're all correct.

The key thing is MongoDB uses an AGPL _variant_ that has AGPL core and Apache 2.0 drivers. So you can run it in proprietary software if you're only calling the Apache 2.0 drivers and not modifying the AGPL part (MySQL is the grand-daddy of this variant model back to the days of GPLv2).

A number of other projects use the same pattern, and so does Mattermost. If you can run MongoDB there shouldn't be a licensing issue with Mattermost.

And you still don't have to do shit even if you are changing the source code, as long as you only deploy it internally, which doesn't count as redistribution.

What do you mean by "trigger the AGPL for all the systems that are network-connected to the AGPL system"?

The AGPL requires that you offer to distribute the source code to derivative works you make of AGPLed code; and it requires that you make that offer to a) people you have distributed binaries to and b) people you permit to access that derivative work over a network.

I guess I can imagine someone arguing that, by integrating Mattermost (for example) with another system, you are thereby giving users of that other system access to your installation of Mattermost, and so you would be required to offer them the source to that installation of Mattermost. Is that what you mean by "trigger the AGPL"?

It'll only trigger the AGPL if you make it available to outside users. Internal use doesn't count as redistribution for any of the *GPL licenses.

Well, the ``license.txt``available at the GitHub repository states that any enhancement made to the server must shared back with the community. So, even if you are using an enhanced version internally, you must redistribute it publicly.

Still its not clear that file can compel someone to even reveal what they do internally. Its an empty promise.

Yeah but if, for any reason, your company gets sued because they violated the AGPL license you're probably fucked.

Reply on news.ycombinator.com