Someone Forked systemd Over Its New Birth Date Field

Liberated systemd is a fork that reverts systemd’s new optional birthDate support in user records, citing privacy concerns.

A new systemd fork has appeared with a specific purpose: removing systemd’s recently added support for storing a user’s birth date in JSON user records.

The fork, called Liberated systemd, published its first tagged release as v261 shortly after the official systemd 261 release. In other words, the fork follows upstream systemd while reverting the change that added the new optional birthDate field.

Importantly, this is not a new init system, a wider redesign of systemd, or a general-purpose alternative to the upstream project. Its stated purpose is to remain close to upstream systemd while removing what the author describes as “surveillance enablement.”

As you probably know, the upstream systemd change adds an optional birthDate field to user records. According to the related commit, the field stores a user’s date of birth in ISO 8601 format, meaning YYYY-MM-DD. The change also updates homectl, documentation, user-record parsing, output handling, and tests.

The commit notes that systemd user records already support other personal metadata fields, including email address, real name, and location. For the Liberated systemd author, however, adding birth date support crosses a line because of its possible connection to age-verification systems.

The project’s scope is intentionally narrow: it only removes birth date support and otherwise remains aligned with upstream systemd. The README states Liberated systemd will not add new features, bug fixes, security patches, or optimizations. According to the developer, liberated systemd exists only to remove changes the author considers surveillance-related.

So, keep in mind that means this is not a practical replacement for most users. Replacing systemd outside a distribution’s normal package flow is risky. The reason is simple – systemd is the first process started on most Linux systems, so a broken replacement can leave a machine unable to boot. Which is something we definitely wouldn’t want to happen.

The author recommends testing the fork in a virtual machine before using it on real hardware and warns nightly builds are more likely to be unstable than named releases.

For additional details, see Liberated systemd on GitHub.

Bobby Borisov

Bobby Borisov

Bobby, an editor-in-chief at Linuxiac, is a Linux professional with over 20 years of experience. With a strong focus on Linux and open-source software, he has worked as a Senior Linux System Administrator, Software Developer, and DevOps Engineer for small and large multinational companies.

One comment

  1. undercook4948

    Just never provide it the birthdate? Does systemd have plans to require it to function? I figured it would be up to the distro.

Leave a Reply

Your email address will not be published. Required fields are marked *