0013: Guidelines for Proprietary Software

Summary

This proposal outlines the requirements and expectations as to when and how proprietary software is enabled on postmarketOS. Specifically, the focus is on packages that only exist to enable the use of proprietary software (e.g. open source components that integrate with the software, runtime environments, and bootstrap utilities). This guidance only applies to contributors and package maintainers.

Motivation

With the recent release of the arm64 version of the Steam client, there has been a growing interest in supporting Android handheld gaming devices, like the Pocket S2, using postmarketOS to offer a “steamdeck-like” experience, where Steam is downloaded on first boot and launched in steamdeck mode, offering a full user interface. This has culminated in the proposal to add a steamos postmarketOS UI to enable this usecase which has sparked some discussion within the team.

https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8979

By having a common understanding and process in place, the team can alleviate some of the more common ethical and technical discussions, giving us more room to focus on the specific implications of a particular piece of software and how the team can keep our users informed and safe.

This is NOT about packaging or distributing proprietary software. Instead, as mentioned in the summary, it is about software that bootstraps, provides a runtime for, or otherwise enables the use of a specific proprietary software (e.g. Steam). Tools like Wine or Waydroid do enable the use of proprietary software but that isn’t their primary goal or only intended use and, as such, this proposal does not apply to them.

The adoption of this proposal does NOT mean that any/all proprietary software or software that only exists to enable the use of proprietary software is acceptable in postmarketOS. That decision is ultimately up to the assembly and should be taken on a case-by-case basis weighing up the facts and wider context behind a piece of software.

Software that is antithetical to the postmarketOS mission should not be condoned within the project and, as a general rule, proprietary software should be avoided as much as possible. Enabling proprietary software in postmarketOS should be strongly justified and serve a clear purpose that aligns with the postmarketOS mission.

Consequences

With this proposal, we will introduce a new section to the pmaports documentation which describes the requirements for proposals which enable the use of proprietary software, such as the SteamOS UI. The exact requirements will be discussed separately and may evolve but will include at least the following:

  1. The bootstrap/runtime software will not be added to any of the existing image configurations that are already included in postmarketOS, or in other words the software should not be installed implicitly for existing users or added to images without changes to the pmbootstrap config.

  2. The user must be informed about the software (including a link to this documentation) prior to first use.

  3. The bootstrap/runtime software must be maintained by someone who is a well-known figure in the community (ie. a member of the postmarketOS team or other FOSS community, maintainer of other well-known free software, etc).

  4. Reasonable steps must be taken by the implementer/maintainer to limit what access the proprietary software has to the host system (e.g. restrict access to $HOME and dbus) and to disable anti-features like telemetry and auto-updates where possible.

  5. The proprietary software must be documented in the new docs page, including information about it’s local and network access, account requirements, etc.

  6. The bootstrap/runtime software must be maintained by at least 2 people with reasonable confidence that they will actively maintain the software for the foreseeable future.

The postmarketOS assembly will continue to be able to reject packages that enable the use of proprietary software for any moral or technical reasons through a vote. We understand that this is a nuanced topic and that it is unlikely for there to be unanimous agreement on if and when it’s acceptable to streamline the use of proprietary software on postmarketOS.

Implementation Plan

  1. Write a docs.p.o page describing the project stance on the use of proprietary software and the requirements for bootstrap/runtime packages to be accepted. This should reflect the contents of the PMCR.

  2. Vote to find the SteamOS MR acceptable for merging (assuming it meets the new requirements and usual technical requirements) via unanimous consent or via a full vote if unanimous consent can’t be reached.

The proposer

  • Casey Connolly (@kcxt)

I have been involved with @drakulix in implementing the Steam runtime support and packaging the various components.