Change Details

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 [[https://wikitech.wikimedia.org/wiki/Geolocation|**proprietary data**]] (especially CentralNotice for geolocation); - starting in 2015, proprietary and closed-source software services may be **embedded over the network** by [[https://www.mediawiki.org/wiki/Thread:Talk:Content_translation/Specification/Yandex_backend|some of our code]].

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 **[[https://wikitech.wikimedia.org/wiki/Geolocation|proprietary data]]** (especially CentralNotice for geolocation); - starting in 2015, proprietary and closed-source software services may be **embedded over the network** by [[https://www.mediawiki.org/wiki/Thread:Talk:Content_translation/Specification/Yandex_backend|some of our code]].

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 **[[https://wikitech.wikimedia.org/wiki/Geolocation|**proprietary data**]]]]** (especially CentralNotice for geolocation); - starting in 2015, proprietary and closed-source software services may be **embedded over the network** by [[https://www.mediawiki.org/wiki/Thread:Talk:Content_translation/Specification/Yandex_backend|some of our code]].