Home
DevCentral
Search
Configure Global Search
Log In
Transactions
T1938
Change Details
Change Details
Old
New
Diff
All the code written by Nasqueron is open source. Same for all the software we used in the past. But now, with Sentry then Vault switch to a closed source license, situation has evolved. There is no policy inside the Operations SIG about the kind of software we can install on our infrastructure. Do we want to restrict it to only open source? If so, what we use to replace Sentry and Vault? What about VMWare ESXi used as hypervisor? **Chapter I. The not-open-source-anymore software** Sentry and Vault are currently installed on our infrastructure. **No more open source** Both products were open source at first: - Vault uses BSL with 4-years-lag translation to MPL. - Sentry used BSL, now switched to FSL, with 2-years-lag translation to Apache 2.0. The FSL has been imagined as a response to BSL critics to only restrict the use by competitors. Those new licenses are NOT open source, only make their source code available. **Forks** As software widely used in infrastructures, both have been forked from the last open source code: Vault has been forked by IBM / OpenFoundation as OpenBAO, but primarily to be used as part of the Open Horizon stack: https://github.com/openbao/openbao/tree/development starting back from Vault 1.14.1 source code. No release currently. Some Wikimedia teams (but not for MediaWiki errors itself) use a reimplementation of Sentry called GlitchTip, https://glitchtip.com/ Finally, we already use OpenSearch, the Elastic fork for that reason. **Chapter II. Hypervisor** VMs have always been hosted on VMWare ESXi hypervisors. With few machines, a full OpenStack deployment is //illusoire//. Yet, this hypervisor is NOT open source neither. **Chapter III. The open source you can't distribute (RHEL)** RHEL downstream is used for production Docker engine, while the upstream CentOS Stream is used for development Docker engine. Red Hat absorbed then killed CentOS, has been bought by IBM and now forbid to redistribute their packages sources to fight the RHEL downstreams. GPL requires to provide source code with the binaries, the Red Hat position is it's legal to forbid further redistribution. Do we accept that? If not, our options are: - keep our Docker engines to CentOS Stream / Rocky - move to another OS, Debian or a containers-optimized OS If so, as an open source project, we can have RHEL licenses for our infrastructure, so there is no reason not to directly use it. See https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-open-source-organizations. **Out of scope questions** This discussion is about our servers infrastructure, as managed by the Operations SIG. Some questions could be of merit but are out of scope in this discussion: - The licenses of the content hosted on the services hosted on the servers - The development server and shellserver user content, which are in several cases a mix of open source and personal stuff
All the code written by Nasqueron is open source. Same for all the software we used in the past. But now, with Sentry then Vault switch to a closed source license, situation has evolved. There is no policy inside the Operations SIG about the kind of software we can install on our infrastructure. Do we want to restrict it to only open source? If so, what we use to replace Sentry and Vault? What about VMWare ESXi used as hypervisor? **Chapter I. The not-open-source-anymore software** Redis, Sentry and Vault are currently installed on our infrastructure. **No more open source** Those products were open source at first: - Vault uses BSL with 4-years-lag translation to MPL. - Sentry used BSL, now switched to FSL, with 2-years-lag translation to Apache 2.0. The FSL has been imagined as a response to BSL critics to only restrict the use by competitors. - Redis is released under SSPL, a derivative of GPLv3 with provisions to publish source code for SaaS providers, without any translation to an open-source license. Those new licenses are NOT open source, only make their source code available. **Forks** As software widely used in infrastructures, both have been forked from the last open source code: Vault has been forked by IBM / OpenFoundation as OpenBAO, but primarily to be used as part of the Open Horizon stack: https://github.com/openbao/openbao/tree/development starting back from Vault 1.14.1 source code. No release currently. Some Wikimedia teams (but not for MediaWiki errors itself) use a reimplementation of Sentry called GlitchTip, https://glitchtip.com/ ValKey is a fork of Redis, maintained by one of the main Redis developer. Finally, we already use OpenSearch, the Elastic fork for that reason. **Chapter II. Hypervisor** VMs have always been hosted on VMWare ESXi hypervisors. With few machines, a full OpenStack deployment is //illusoire//. Yet, this hypervisor is NOT open source neither. **Chapter III. The open source you can't distribute (RHEL)** RHEL downstream is used for production Docker engine, while the upstream CentOS Stream is used for development Docker engine. Red Hat absorbed then killed CentOS, has been bought by IBM and now forbid to redistribute their packages sources to fight the RHEL downstreams. GPL requires to provide source code with the binaries, the Red Hat position is it's legal to forbid further redistribution. Do we accept that? If not, our options are: - keep our Docker engines to CentOS Stream / Rocky - move to another OS, Debian or a containers-optimized OS If so, as an open source project, we can have RHEL licenses for our infrastructure, so there is no reason not to directly use it. See https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-open-source-organizations. **Out of scope questions** This discussion is about our servers infrastructure, as managed by the Operations SIG. Some questions could be of merit but are out of scope in this discussion: - The licenses of the content hosted on the services hosted on the servers - The development server and shellserver user content, which are in several cases a mix of open source and personal stuff
All the code written by Nasqueron is open source. Same for all the software we used in the past. But now, with Sentry then Vault switch to a closed source license, situation has evolved. There is no policy inside the Operations SIG about the kind of software we can install on our infrastructure. Do we want to restrict it to only open source? If so, what we use to replace Sentry and Vault? What about VMWare ESXi used as hypervisor? **Chapter I. The not-open-source-anymore software**
Redis,
Sentry and Vault are currently installed on our infrastructure. **No more open source**
Both
Those
products were open source at first: - Vault uses BSL with 4-years-lag translation to MPL. - Sentry used BSL, now switched to FSL, with 2-years-lag translation to Apache 2.0. The FSL has been imagined as a response to BSL critics to only restrict the use by competitors.
- Redis is released under SSPL, a derivative of GPLv3 with provisions to publish source code for SaaS providers, without any translation to an open-source license.
Those new licenses are NOT open source, only make their source code available. **Forks** As software widely used in infrastructures, both have been forked from the last open source code: Vault has been forked by IBM / OpenFoundation as OpenBAO, but primarily to be used as part of the Open Horizon stack: https://github.com/openbao/openbao/tree/development starting back from Vault 1.14.1 source code. No release currently. Some Wikimedia teams (but not for MediaWiki errors itself) use a reimplementation of Sentry called GlitchTip, https://glitchtip.com/
ValKey is a fork of Redis, maintained by one of the main Redis developer.
Finally, we already use OpenSearch, the Elastic fork for that reason. **Chapter II. Hypervisor** VMs have always been hosted on VMWare ESXi hypervisors. With few machines, a full OpenStack deployment is //illusoire//. Yet, this hypervisor is NOT open source neither. **Chapter III. The open source you can't distribute (RHEL)** RHEL downstream is used for production Docker engine, while the upstream CentOS Stream is used for development Docker engine. Red Hat absorbed then killed CentOS, has been bought by IBM and now forbid to redistribute their packages sources to fight the RHEL downstreams. GPL requires to provide source code with the binaries, the Red Hat position is it's legal to forbid further redistribution. Do we accept that? If not, our options are: - keep our Docker engines to CentOS Stream / Rocky - move to another OS, Debian or a containers-optimized OS If so, as an open source project, we can have RHEL licenses for our infrastructure, so there is no reason not to directly use it. See https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-open-source-organizations. **Out of scope questions** This discussion is about our servers infrastructure, as managed by the Operations SIG. Some questions could be of merit but are out of scope in this discussion: - The licenses of the content hosted on the services hosted on the servers - The development server and shellserver user content, which are in several cases a mix of open source and personal stuff
Continue