Open comments: On software freedom and styx.

· by styx

I'm not making a hard decision yet on this front, but I do want to request comments to inform our decision-making process regarding the rules defining "software freedom" - associating only Free Software with the styx "systems" and "software" maintainership and repositories, where possible, and whether to prohibit "nonfree" software in styx and its core repositories1; to what scope, if so; and what impact that will have on the maintainability and usability of a styx system, moving forward.

Personally, I see an insurance of software freedom as a goal of styx, but my ideas on what entails "freedom" derive from a basis of consent and autonomy, at the systematic level, more so than "freedom" in a contrived libertarian stance, and more so than "source code", in a reductively technical sense.

styx is an opinionated and inherently political movement in and of itself, I cannot deny that - and decisions need to be made to align with the values of styx, however, said values are also a moving target that we aim to decide, with the decisions we make. This cyclical affair is called "development", and at the end of it, we want to enable development to be an informed and open process with as many diverse minds as possible, which means that restrictions to software freedom - which restrict the scope of development - may be deleterious to that goal set.

(This post corresponds to RFC 26 in the styx standards track.)

Footnotes

  1. This mainly applies to software we develop and maintain, in the "systems" and "software" repositories, either as our own software, as adopted projects, or as forks and patches for other software, that are considered core and integral to styx itself - things like the kernel, the init system, the package manager, the desktop environment, and drivers with first-tier support (e.g., excluding some GPU drivers which insist on proprietary or non-distributable software.) Things outside of that, which would live in the "community" repository, will clearly and strongly indicate the nature of their license, or that they communicate with proprietary or commercial services, but in a non-condescending and non-alarmist way. ↩

published
2 comments · join the discussion on cohost
novemberorwhatever
novemberorwhatever @novemberorwhatever

In my personal opinion, the most consent-respecting option would be something that doesn't add additional barriers to those who want to use non-free software, but that allows those who want to use just free software to easily filter out the non-free options. IMO, the GNU approach of trying to make it as hard as possible to install non-free software is not really consent-respecting

sirocyl
sirocyl @sirocyl

Yeah, this sounds like a very reasonable option. The way I see it, is that styx itself is free software, by its nature. The two core repositories, "systems" and "software" should reflect that, and largely comprise of free software, whereas "community" hosts any mix of free or proprietary; however there is good reason (e.g., drivers) for the systems repo to need nonfree software.

License tags (as SPDX info) for software, libraries and assets; and source ontology and SBOM information (sometimes full sources and build automation, as well) are a key part of a styx software package, so it may be beneficial to filter and query by license or license class (proprietary, permissive, copyleft/viral) so as to enable a simple checkbox like that on the first install.

view on cohost · powered by cohost-blogger

styx logo styx copyright 2020 sirocyl / ellie (kymkdd) / ncommander / styx contributors

Use of other names and brands is not intended to reflect a claim of, or right to, use the name or brand. styx is an operating system using the Linux kernel and components, and "styx Linux" as a phrase does not reflect the inclusion of the Linux brand or trademark in the styx project. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.