Miles Fidelman wrote:
I've begun to wonder if there is a conflict between software freedom
and
key pieces of software that create massive dependency webs. Or put
another way, "vendor lock-in."
I see no such conflict because the freedoms of free software don't
guarantee software you'll like (clearly you don't like systemd), don't
guarantee software you must use (you could assemble your own GNU/Linux
system and not include systemd), and don't guarantee support for
software (I'm not aware of any obligation to provide you with
support).
"Vendor lock-in" doesn't make sense to me here because systemd doesn't
have a vendor and doesn't lock its users in. Even if Red Hat employees
do the majority of systemd development, users can get free software
(such as systemd) from distributors other than Red Hat and they can
get systemd non-commercially. Systemd users are free to use and
develop GNU/Linux systems that don't include systemd or they can
replace systemd with something compatible they'd prefer to use
instead.
But I figure what you really want is for someone to maintain a
GNU/Linux distribution without systemd you can use so you don't have
to do that work yourself.
I begin to wonder if programs that create massive dependencies - such
as
systemd - directly conflict with freedom 0.
They don't because software freedom says nothing about how much work
is required to separate the rest of the software from the common
dependency. Software freedom only says that if you put the work into
it, you can separate yourself from that dependency. How you'd
implement this separation is a detail.
One might also argue that systemd, in particular, conflicts with
freedom
1 - in terms of feature creep, poorly documented code, changing APIs,
etc., etc.
There is a lot of free software out there. Too much free software for
anyone to know of the details of all of every free program.
Furthermore, the free software movement is not a development
methodology. Therefore I'm sure you could find people who would use
the same descriptions ("feature creep", offering "poorly documented
code", and "changing APIs") for other free software. We don't seek to
amend the free software definition for those programs and we don't
look for ways to exclude them from being called "free" because of
their suboptimal development.
Trying to get systemd seen as non-free based for software development
reasons strikes me as ironically shortsighted because of what you'd
get in the end: the more you lean on the development methodology
argument (a value of the open source movement, not the older free
software movement), the more you're speaking to the wrong movement.
Open source advocates apparently have no problem including non-free
software in free software OS distributions (hence the need for
https://gnu.org/distros/free-distros.html). So there's no reason to
believe open source advocates would put the work into maintaining a
systemd-less GNU/Linux distribution so long as systemd is convenient
to include.