In a recent conversation on the ops list, @LuisVilla cautioned against using AGPL-licensed software:
Short version is that I'm not certain we comply with the requirements of AGPL out of the box—what we do with source availability is great, but arguably not sufficient. But I have been talking with Rob, and will soon talk with ops/ @mark., to get us all on the same page about this.
@RobLa added:
Yup, what he said ^ No problem in spirit with AGPL, but the requirements of the license are such that compliance is not as simple as it is with just about every other license we have. I don't remember what it was that Nik was looking at the last time AGPL came up, but I believe it was a relatively small and unimportant feature and so it was easier for him to just avoid it rather than forcing a conversation about AGPL compliance. This is large and important, so if we need to force a discussion about AGPL, that's fine. We need to have that conversation sooner or later, and this would be a perfectly reasonable trigger.
It would be great if we could clarify what the issues are, given that basically all our code is available from our git repositories / source debs. I'm especially interested in these scenarios:
- private security patches that are only released to the public on the next release
- use of AGPL modules -- any issues beyond 'program needs to be AGPL too'?
- shelling out to AGPL-licensed executables
- mixing of GPL and AGPL network services, which communicate exclusively over the network
Not relevant:
- hyperlinking a webservice based on AGPL software
Premises:
- All our code is published and under some sort of OSI-approved license, but:
- since 2009, our code embeds proprietary data (especially CentralNotice for geolocation);
- starting in 2015, proprietary and closed-source software services may be embedded over the network by some of our code.