Re: [libreplanet-discuss] opinions please: expanding the definition of "software freedom"

[J.B. Nicholson-Owens]

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.