The Freedom to (re)build software

2023-06-20 @rrobin

Open Source Linux distros have enjoyed a freedom that is now at risk - the freedom to patch software and build their own binaries. Historically this practice was well accepted by the upstream developers because it enabled others to:

• patch bugs or security issues in a given version, such as CVE fixes or feature backporting from a newer version
• add/remove features according to the policy of the distribution, e.g. removing telemetry for privacy concerns, or adding a backend for distro specific behaviour

However this clashes with requirements from software developers, that do not want users/packagers to exercise this freedom. Some of these are well intentioned e.g. developers do not want to get issue reports for changes which were introduced by a packager; or they want to reduce the dependencies/versions the software is compiled against to facilitate trouble shooting.

One way to enable this which I find particularly insidious is now baked into newer build systems. They 1) assume online connectivity by default and 2) make use of version locking to further restrict dependency versions to the ones the upstream developer used at release time.

Furthermore it is now common practice for developers to quickly introduce a dependency on the latest compiler/tools features, even when the release window for these tools is short (e.g. 6 weeks). This leaves all those that cannot update their tools stuck with an older version or in need of backporting.

None of this is too surprising, since a lot of new programming languages have been created in the past decade, with significant corporate backing. Their requirements, and priorities, are not aligned with the software freedoms we grew up with.

So this is where we are, what can we do about this?

• step away from software that is hostile to these freedoms
• call out fascination with the latest version/feature that prevents long term support, increases complexity and prevents user builds
• build software that supports offline, reproducible builds, with a clear definition of dependencies

Next time you feel like complaining that old build systems are dated or weird, remember they are only good if we keep working on them and they have these Freedoms baked in, so ... fix them.