Page MenuHomeDevCentral

Non open-source infrastructure software policy
Open, Needs TriagePublic


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.


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: 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,

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

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