I think it's clear that the SSPL does not meet the Fedora licensing requirements:
| “If you make the functionality of the Program or a modified version | available to third parties as a service, you must make the Service | Source Code available via network download to everyone at no charge, | under the terms of this License. Making the functionality of the | Program or modified version available to third parties as a service | includes, without limitation, enabling third parties to interact with | the functionality of the Program or modified version remotely through | a computer network, offering a service the value of which entirely or | primarily derives from the value of the Program or modified version, | or offering a service that accomplishes for users the primary purpose | of the Software or modified version. | | “Service Source Code” means the Corresponding Source for the Program | or the modified version, and the Corresponding Source for all programs | that you use to make the Program or modified version available as a | service, including, without limitation, management software, user | interfaces, application program interfaces, automation software, | monitoring software, backup software, storage software and hosting | software, all such that a user could run an instance of the service | using the Service Source Code you make available.”
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003603.html
This means that we cannot update certain software (which I will not name here because I find the name offensive) past their Ocotber 15, 2018 versions. Patch backports are also out of the quesiton because the old (AGPLv3) and new licenses are mutually incompatble, and the patches would have to be assumed to be licensed under the new license if taken from a branch that has already been relicensed.
Correct?
Thanks, Florian
On Wed, Oct 17, 2018 at 5:36 PM Florian Weimer fweimer@redhat.com wrote:
I think it's clear that the SSPL does not meet the Fedora licensing requirements:
Can you elaborate why?
| “If you make the functionality of the Program or a modified version | available to third parties as a service, you must make the Service | Source Code available via network download to everyone at no charge, | under the terms of this License. Making the functionality of the | Program or modified version available to third parties as a service | includes, without limitation, enabling third parties to interact with | the functionality of the Program or modified version remotely through | a computer network, offering a service the value of which entirely or | primarily derives from the value of the Program or modified version, | or offering a service that accomplishes for users the primary purpose | of the Software or modified version. | | “Service Source Code” means the Corresponding Source for the Program | or the modified version, and the Corresponding Source for all programs | that you use to make the Program or modified version available as a | service, including, without limitation, management software, user | interfaces, application program interfaces, automation software, | monitoring software, backup software, storage software and hosting | software, all such that a user could run an instance of the service | using the Service Source Code you make available.”
This section, right? This could be interpreted as "you have to give us the source code for the compiler you used to build the software, under the SPPL license". Is that an example of your concern?
josh
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003603.html
This means that we cannot update certain software (which I will not name here because I find the name offensive) past their Ocotber 15, 2018 versions. Patch backports are also out of the quesiton because the old (AGPLv3) and new licenses are mutually incompatble, and the patches would have to be assumed to be licensed under the new license if taken from a branch that has already been relicensed.
Correct?
Thanks, Florian _______________________________________________ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
On Wed, Oct 17, 2018 at 09:01:57PM -0400, Josh Boyer wrote:
| or the modified version, and the Corresponding Source for all programs | that you use to make the Program or modified version available as a | service, including, without limitation, management software, user | interfaces, application program interfaces, automation software, | monitoring software, backup software, storage software and hosting | software, all such that a user could run an instance of the service | using the Service Source Code you make available.”
This section, right? This could be interpreted as "you have to give us the source code for the compiler you used to build the software, under the SPPL license". Is that an example of your concern?
Not to mention the corresponding source code to the local operating system including the kernel and all device drivers; every executable, library, and runtime runtime directly or indirectly executed; the virtualization hypervisor and/or host operating system; system BIOS/UEFI/device firmware; and arguably your entire SAN/network/backup infrastructure and everything you use to manage/monitor *that* too.
Because all of that ("without limitation") is used "to make the program available as a service."
It's one heck of a poison pill that makes the SSPL-licensed software effectively impossible to utilize in order to provide a public-facing service. (At least without obtaining a commercial license..)
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/20...
There is a lot of good discussion here. Here's Florian's take:
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/20...
TL;DR: The [[un]intended] consequences are significant, and because the goals behind the license aren't entirely clear, we don't know if those consequences are bugs or a features.
- Solomon
* Josh Boyer:
On Wed, Oct 17, 2018 at 5:36 PM Florian Weimer fweimer@redhat.com wrote:
I think it's clear that the SSPL does not meet the Fedora licensing requirements:
Can you elaborate why?
| “If you make the functionality of the Program or a modified version | available to third parties as a service, you must make the Service | Source Code available via network download to everyone at no charge, | under the terms of this License. Making the functionality of the | Program or modified version available to third parties as a service | includes, without limitation, enabling third parties to interact with | the functionality of the Program or modified version remotely through | a computer network, offering a service the value of which entirely or | primarily derives from the value of the Program or modified version, | or offering a service that accomplishes for users the primary purpose | of the Software or modified version. | | “Service Source Code” means the Corresponding Source for the Program | or the modified version, and the Corresponding Source for all programs | that you use to make the Program or modified version available as a | service, including, without limitation, management software, user | interfaces, application program interfaces, automation software, | monitoring software, backup software, storage software and hosting | software, all such that a user could run an instance of the service | using the Service Source Code you make available.”
This section, right? This could be interpreted as "you have to give us the source code for the compiler you used to build the software, under the SPPL license". Is that an example of your concern?
Yes, because the System Library exemption for Corresponding Source does not kick in due to the way the new terms are worded. I think. And we cannot relicense the toolchain and kernel under the new license.
It's also the case that a default installation of the software is non-compliant because the software itself does not provide a mechanism to download its sources. This wasn't so much a problem with the AGPL version because the AGPL has generally been interpreted in such a way that in this context, distribution of the Fedora-modified version by Fedora was sufficient to comply with the AGPL requirement.
Thanks, Florian
-
Florian Weimer -
Josh Boyer -
Solomon Peachy