 |
| “We don't allow AGPL.” (comment) | ||
| recommended by 1 user | 2015 | DannyBee on: Why I am pro-GPL | open source | original thread | | ||
| DannyBee on Jul 27, 2015 | on: Why I am pro-GPL | view on HN | ||
| One user recommended this comment. What they said: |
|
jkaplowitz Jul 27, 2020 | on: The terms of the AGPL are pretty easy to comply with | context
Thanks for having publiished these policies publicly! You gave a pretty clear summary of Google's motivations for banning AGPL on HN five and three years ago two of the previous times this came up, and having worked at Google 2011-2015 (including some interactions there with you), your public explanations of why from back then are extremely credible and rational given the logistics of what's easy and hard inside Google. https://news.ycombinator.com/item?id=9956542 https://news.ycombinator.com/item?id=13979443 Not that I'm surprised, as you've always been pretty forthright and honest. Thanks for continuing to be that way. |
| Also recommended by people who recommended this: | ||
| 1. | “It's because we have tons of temps, vendors, and contractors, and don't want to have to owe them” (comment) | |
| recommended by 1 user | 2017 | DannyBee on: A new home for Google Open Source | original thread | | ||
We don't allow AGPL.
AGPL is very easy to control for the external facing stuff, but not the internal stuff.
For example, based on how it defines remote network interaction, it doesn't differentiate internal or external users. So if we used AGPL in internal systems that Temps, vendors, and contractors had access to, we'd end up owing all the temps, vendors, and contractors source code to the internal system, regardless of what other NDA's or anything else were in place (it's well settled that you can't contract around or NDA folks into giving up GPL/AGPL rights)
We aren't willing to take this risk (and i'd bet most companies that are doing it don't realize this is an issue :P)