Group: Software/research/DistributingSoftware

Introduction

Some activities or strategies either requires wide adoption to work, or require to have ways for users to use specific free software applications regardless of the operating systems or platforms they use.

For instance if lot of people produce documents in formats that are either undocumented and/or legally risky to use and/or not already implemented (well) in free software, then free software is at a disadvantage. To fix that we'd need wide addoption of standard formats like OpenDocument. But for that adoption to happen, users also need to be able to run software like Libreoffice on their computer without necessarily switching to GNU/Linux.

This article is meant to summarize the status of porting and distributing software on other platforms, from the point of view of users of FSF certified distributions.

Platforms

Android

One of the big issues with Android is that a lot of applications depend on the nonfree Google SDK.

However it is still possible to build pure Java applications for Android 6.0 or later with PureOS. Replicant also has an SDK for Android 4.2 or later that can also build native applications (like emacs that are written in C). It is also possible to build applications within Replicant (Replicant has to do that to ship the default builtin applications like the desktop environment/launcher, the SMS application, etc).

Users can then install applications through various way:

• with the 'adb install path/to/application.apk' command
• By downloading an apk package with a browser and running it

However this has downsides as gpg signatures are not verified, and it's more work to keep applications installed in this way up to date.

It is also possible to get your application packaged by F-Droid but the F-Droid repositories are not compliant with the free system distribution guidelines (FSDG). In addition most of the applications in the F-Droid repositories depend on the nonfree Google SDKs.

A way to help here would be to build and distributions 100% free software SDKs and to make an FSDG compliant F-Droid repository (and ship a modified F-Droid with only that repository available).

More details is available on the SDK page of the Replicant wiki.

Browser addons and/or extensions

It is possible to work on browsers addons with only FSDG compliant distributions as some addons are packaged in FSDG distributions. The BrowserAddons has details about FSDG compliant repositories that also have addons.

There are also various repositories like addons.mozilla.org that are not FSDG compliant.

BSD

We currently don't have any BSD FSDG compliant distribution, though Hyperbola is working on something like that. So we might be able to test our software on BSD distributions in the future.

Though FreeBSD and NetBSD have a layer of compatibility that can run some GNU/Linux applications. So just releasing software for GNU/Linux sometimes work. OpenBSD lacks such compatibility layer though.

Docker

There are various ways to distribute applications through docker.

The DistroExecutionEnvironments and DockerRegistries wiki pages have more details about how to run various FSDG compliant distributions inside docker and how to distribute the images.

It is also possible to package applications directly in docker images. Guix has support for that through commands like that:

guix pack -f docker -S /bin=bin guile guile-readline

More details about packaging applications directly are available in the guix pack section of the Guix manual.

At the time of writing, FSDG distribution have docker packages that are configured to use the nonfree docker.io repository, so it might be useful to warn people about that. The ExternalRepositories page has more information about the status of this bug in various FSDG compliant distributions.

Even after fixing this bug, it might still be a good idea to warn people not using FSDG compliant distributions in general and to explain to people running FSDG distributions that running 'docker pull <registry>/<organization>/<image>' is the equivalent of downloading some software from Internet and running it: if the registry is not configured in the FSDG distribution, it might contain nonfree software or at least it might not have been reviewed by anybody for FSDG compliance / compatibility.

At the time of writing FSDG distrbutions also have lot of work to do with the removal of third party repositories that are not FSDG compliant, so it's better to be cautious with third party repositories in general. The ExternalRepositories wiki page has more information about the progress of fixing packages in various FSDG compliant distributions.

GNU/Hurd

At the time of writing, GNU/Hurd has very limited hardware support, so it is unsure if they are people using GNU/Hurd as their main operating system on their computers. So it's probably not worth trying to package software on the non-FSDG compliant GNU/Hurd distributions.

However GNU Guix is FSDG compliant and while not all package build fine for GNU/Hurd, the GNU/Hurd support is very well integrated in Guix: it is possible to create Hurd virtual machines (for instance with 'guix system image --target=i586-pc-gnu ./system.scm'), and the Guix configuration system also supports creating such virtual machines easily (that feature is called 'childhurd' in the Guix manual).

So a way to go here could be to package software for Guix under GNU/Linux and then making sure it cross compiles well for GNU/HURD.

This way the software packaged in Guix also benefits GNU/Linux, and making sure that software works fine on GNU/Hurd can also pave the way to support other posix-like operating systems with like BSD.

The big advantage here is that testing is relatively easy to do compared to BSD (see the BSD section for more details).

GNU/Linux

There are various ways to distribute your software for GNU/Linux. The best way is probably to write it in a way that is easy to package in GNU/Linux distributions, for instance by not having too much dependencies and by using dependencies already packaged by most GNU/Linux distributions. This also makes sure that the software is distributed securely, mirrored, etc.

For distributing software in FSDG distributions specifically, the FSDG_distributions article can be useful to understand distribution policies and see how to get a new package inside. Some distributions require to work with their upstream to add new packages for instance.

It is also possible to make repositories that work on several distributions:

• For instance there is a repository for linux-libre for Debian based distributions (like PureOS, Trisquel, Ubuntu, etc). Here the fact that PureOS and Trisquel (which are FSDG compliant) are based on respectively Debian and Ubuntu probably facilitates testing as what works on PureOS and Trisquel has a relatively big chance of also working on Debian and Ubuntu.
• For other distributions it is unclear if it is possible to run a repository without having to run the target distribution. Guix can at least generate deb and rpm packages but that might not be sufficient for running a repository and this also has big disadvantages (See below).

As Guix packages can also runs on top of most GNU/Linux distributions, it is also an option for distributing software, but it is often less convenient for users of other distributions than Guix because if they install software through Guix they end up with duplicated dependencies that takes space, and a need to also keep their Guix installation and packages up to date. In addition they might need to install Guix manually if Guix is not packaged in the distribution they use. Though the Guix installation script is pretty easy to use but it's not signed (unless someone install it from a Parabola package).

Guix can also produce tarballs, singularity/apptainer or docker containers, deb or rpm packages or even appimages, but they also take space as they bring in all their dependencies, and someone also needs to produce updates for these packages and distribute them to users, whereas users running Guix directly would be able to update the packages themselves (so less work from maintainers is needed) and they won't have to manually go check if there are new versions of the tarball/singularity/apptainer/docker/rmp/deb/appimage they installed.

Packaging software in Guix is also useful for Guix users.

iOS

There is no free compiler for iOS that runs on GNU/Linux. Long time ago it was possible to use gcc to do cross builds, but that setup required nonfree software to be extracted from the iphone to be able to produce working applications. Nowadays there may still be free software compilers that run on (jailbroken) iOS, and they may be used as a basis for making a free compiler that works on GNU/Linux. A way to help here would be to make a free compiler for iOS.

Another issue here is that Apple's Appstore terms and conditions are incompatible with free software. So the only option compatible with free software here is to ask users to jailbreak their phone and publish the application package. VLC also is also published in this way for instance.

MacOS

Most free software applications that run on MacOS depend on a nonfree compiler named Xcode..

However the Zig programming language (that is packaged in distributions like Parabola and Guix) can generate binaries for MacOS without the need of Xcode, so it should be possible to build cross toolchains for MacOS that are fully free and run on GNU/Linux.

There is also a project like Wine for MacOS called Darling, but someone needs to review the source code to understand if it's fully free or not. Darling also depends on the nonfree Xcode compiler.

A way to help here would be to build more common 100% free software compilers like GCC that run on GNU/Linux directly and that can produce binaries for MacOS, or to produce a 100% free compiler that run on Darling and remove the Darling dependency on Xcode.

MacOS also has some package managers that run both on GNU/Linux and MacOS (like homebrew) but they are most likely not FSDG compliant.

MacOS also started making it hard for users to run unsigned applications, and users probably still need an Internet connection to run applications on recent MacOS (MacOS ask the permission of Apple before running each applications).

Ren'Py

Ren'Py is included in several FSDG compliant distributions (like guix). It contains a tutorial that also runs inside Renpy so it should be relatively easy to write programs that run with RenPy.

Ren'Py runs on many operating systems or platforms(Android 5.0+, HTML5/Web Assembly (currently in Beta), GNU/Linux, Windows, Mac OS, iOS) but we didn't look if it was possible to target other operating systems from FSDG compliant distributions without installing any nonfree software. Also the HTML5/Web Assembly platform raises SASS concern when users are not the operators of the server.

Games can be redistributed in the "Ren'py Games List" on their website but it allows nonfree games ("The games on this site are copyrighted by their owner, unless otherwise specified."). It might be possible somehow to mention the game free software license and to somehow include the source code of the game though this has not been researched. Including the source code might also not be trivial as the package format ([2]) is non-standard and specific tools are required to unpack its content.

It is also possible to redistribute Ren'py games by packaging them in distributions. This avoid the issues mentioned above.

ScummVM

ScummVM is a virtual machine originally meant to play some games.

It is packaged in several FSDG compliant distributions so it is likely to be fully free itself, though it never hurts to check its source code in case someone missed something. Checking if its source code has nonfree tests would be a good idea for instance.

The ScummVM virtual machine runs on many operating systems (Android, GNU/Linux, Mac OS, Windows, etc) and other platforms (some gaming consoles) but we don't know if it requires nonfree dependencies to be built for other operating systems than GNU/Linux. This might not be a big issue as it at least enables you to run and/or develop fully free games on FSDG compliant distributions.

This makes it interesting as with that you can probably manage to redistribute applications for a wide variety of operating systems and only test them on FSDG compliant distributions. It could be well suited for educational applications for instance.

Note that ScummVM has lists of checksums inside its source code but this doesn't prevent users from running modified games or people packaging games in distributions from bypassing that (more on that below).

There are already several free games that are known to work with it:

• The Guix

openquest package is a demo / very short game that uses ScummVM as a dependency. It is well integrated so users don't even see ScummVM apart from its logo for a very short time. Since it's free software and even packaged in Guix the game can relatively easily be modified to make longer games and/or applications. The information on how that integration is done (and the checksum bypassed) is available in the Guix package definition.

• There are some free software z-machine games that also work in ScummVM. See this mail for more details about that. This mail also explains how to easily run your own modified version of games by bypassing the checksum warning.

If you plan to make applications for ScummVM and distribute them widely it might also be possible to build your application (ideally in a reproducible way) and send patches in ScummVM to make it easier for users that don't run distributions where your application is packaged to run it.

Apart from that there are various approaches that didn't yield anything usable in freedom yet:

• There are other games that are sometime redistributed by some GNU/Linux distributions but they either lack proper corresponding source (like Beneath a Steel Sky) code or don't compile (like draci-historie: some code is availalbe under the GPLv2 and there are build instructions but so far nobody managed to compile / package it for FSDG distributions).

• There is an SDK (AGI studio or one of its fork) that can in theory be used to make games for ScummVM but nobody knows if it can still be compiled and run on FSDG compliant distributions (it depends on QT4 which is not included anymore in many distributions). In addition to work, this SDK probably need a template, but the templates are under a license similar to SIL Open Font License 1.1 and here too it is unclear if a license like that is free for code.

Uzebox

It is possible to build software for the Uzebox with avr-libc, avr-gcc (which are available in most GNU/Linux and FSDG compliant distributions) and Packrom.

And is also possible to use Uzem to run and/or test the software made in this way.

Note that while the emulators and tools for building software were reviewed and even tried on an FSDG distribution (and it worked fine), but the hardware itself (the Uzebox) needs a bootloader that wasn't reviewed yet at the time of writing. Help is needed for that.

Web

Distributing software as web applications has many issues. One of the main issues is to avoid SASS.

It can still work and respect users freedom if users self-host the software, or if they are part of a collective that hosts the software, and that users only do work for the collective with that hosted software. For instance a collective could host a Nextcloud instance and run Libreoffice through that, and users would collaborate on documents together for the collective.

To make sure users can easily self-host, and that it can be deployed easily, securely, with minimal maintenance, it is a good idea to make sure that the software can be packaged in GNU/Linux distributions, and that the software is relatively easy to configure and deploy.

When JavaScript is used, it's also a good idea to make sure that licenses are mentioned by using the standard promoted by LibreJS for that.

It is also possible to make users download html files with builtin JavaScript and then teach them how to run that local file inside their browsers. In that case it is also a good idea to use the standard promoted by LibreJS to make sure that the code is free software. If the source code is included as-is in the page (if the javascript isn't compressed/minified) then the users can also relatively easily modify that code.

Windows

There are free software toolchain like mingw64 that enable to build software for Windows from GNU/Linux. That software can then be tested with Wine.

Guix has a mingw64 toolchain and it was used by bitcoin-core to build bitcoin for Windows. For that they only used the basic toolchain as-is and did the compilation manually. This is probably because most Guix packages don't cross compile for Windows: at the time of writing, the GNU hello guix package cross compile fine but not many more Guix packages.

The limitations here is that with recent Windows versions, some functionalities are not available anymore without drivers signed by Microsoft. Some applications like Wireshark need functionalities provided by drivers. I have no idea if users are able to run modified versions of drivers or not. But if they can't that would make all signed drivers nonfree.

When collaborating with people that don't use FSDG compliant distributions, it might be useful to warn them about non-free fonts being installed in some distributions. The Free Software Directory has the following warning about Wine:

Warning: some GNU/Linux distributions recommend installing the non-free Microsoft fonts when installing Wine through a package manager. To fix this, you can install it with the apt-get install --no-install-recommends wine command.