Change Details

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.

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.

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.