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.
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.
>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.
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.
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.
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"?
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.
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.
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.
There seems to be two factors at play here that are creating almost nonsensical results.
1. The results, when filtered through the replicability guidelines rendered a clear verdict - 61 to 39 against.
2. The question of "how closely did the findings resemble the original study?" flips the findings. Moderately similar findings are the majority - 58 to 42 in the other direction.
How can you have a study that has "virtually identical" findings that doesn't replicate the original?
Original results that were exactly on the borderline of statistical significance, with new results that were barely on the "fail" side of that line, but both sets of results are within the margin of error of each other?
(I am not a frequentist, so my bias may be showing through)
