Group: Software/FSDG distributions

From LibrePlanet
< Group:Software
Revision as of 19:21, 17 September 2024 by GNUtoo (talk | contribs) (→‎Policies on what can be packaged: Add infos about LibreCMC.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduction

This page can track some differences between FSDG compliant distributions.

This could help see if FSDG distributions can collaborate more on some topics.

Documentation

Since some of the issues that FSDG distributions have to deal with are the same, it sometimes make sense to have common documentation. So it makes sense to track the license and software used for documentation and wikis in order to see how to improve collaboration and common resources.

Distribution Documentation Wiki
Link License Link License Software
N/A Libreplanet GFDL 1.3+ and copyright assignment Mediawiki
Dragora GFDL 1.3 (+?) No Wiki found
Dynebolics No Wiki found
Guix GFDL 1.3 (+?) libreplanet.org/wiki/Group:Guix GFDL 1.3+ and copyright assignment Mediawiki
Hyperbola wiki.hyperbola.info CC BY-SA 4.0 Dokuwiki10
LibreCMC librecmc.org/fossil CC BY-SA 4.0 Fossil
Parabola wiki.parabola.nu CC BY-SA 4.0 Mediawiki
ProteanOS Ikiwiki
PureOS
Replicant CC BY-SA 3.0 Redmine, migration to Mediawiki planned.
Trisquel
Ututo

General policies

While FSDG compliant distributions need to follow the Free System Distribution Guidelines, they can also have additional policies that are more strict on other aspects.

Knowing that not only enables to choose the most adapted FSDG distribution to one's needs, but it is also important to keep in mind when trying to build cross-distribution collaboration.

For instance non-functional data licensed under the CC-BY-ND licenses is not allowed in Parabola but it might be allowed in other FSDG compliant distributions, so what might be a bug in Parabola is not necessarily a bug in other distributions.

Distribution Free culture[1] Licensing strictness Require package to be built from source Reuse packages or binaries Computer support
Dragora
Dynebolics
Guix No[2] Seems to be strict[3]. Yes Only to build some compilers. No restrictions
Hyperbola Yes[4]
LibreCMC
Parabola Yes
  • Requires all the licenses of a package to be known.
  • Doesn't require to have a mapping between files or files content and licenses.
 Yes[5] Reuse some packages from various distributions:
  • Arch Linux
  • Arch Linux ARM
  • Arch Linux 32
 Restrictions exist only for official support for ARM computers:
  • Requires a free software bootloader
  • Requires documentation in the wiki
  • Requires a package to ship the bootloader
ProteanOS
PureOS
Replicant Unknown (no decision) Weak[6]. No[7] To support a device, Replicant requires:
  • an isolated modem
  • a replaceable battery
  • to be able to install Replicant without nonfree software
Trisquel
Ututo

Bugs and bug reports handling

Note that the FSDG has a "Commitment to Correct Mistakes" section: 

Most distribution development teams don't have the resources to exhaustively check that their distribution meet all these criteria.
Neither do we. So we expect distros to occasionally contain mistakes: nonfree software that slipped through, etc. 
We don't reject a distribution over mistakes.
Our requirement is for the distribution developers to have a firm commitment to promptly correct any mistakes that are reported to them.

And here we have FSDG compliant distributions that work differently. For instance:

  • Dragora, Guix and ProteanOS are distributions made from scratch.
  • Dynebolics, Hyperbola, LibreCMC, Parabola, PureOS, Replicant, Trisquel and Ututo S are derived from other distributions.

The consequence is that the bugs happen in different ways. In distribution made from scratch, bugs will happen when introducing new packages or updating them, whereas in the other distributions the bugs will often happen because the distribution they are based on have problematic packages, and that no one though (yet) about fixing them.

In some distributions (like Replicant 6.0), fixing bugs can take a long time (due to the lack of contributors) so freedom bugs often also take a long time to fix.

In any case helping the distributions fix the bugs by submitting patches and/or packages definition that are fixed could help a lot getting things fixed more rapidly.

Distribution could also have different requirements for fixing bugs. For instance in Parabola, we can simply blacklist a package by adding it to a blacklist file, but doing so might break people's packages, so not every Parabola hacker agree on how to deal with the big amount of packages to fix and the lack of contributors (some want to remove packages and add them back when fixed, while other want to get a proper fix, and that probably depends on the situation as well), though the proper fix is to get more contributors help fixing all that.

We could also benefit from help from less technical users that run multiple FSDG compliant distribution as some of the bugs reported in one distribution sometimes also affect other FSDG compliant distributions as well.

Some distributions might also allow some individuals to push fixes directly, so it could also be useful to document how that works too, as in some cases doing things like that can save a lot of time and also lower the amount of work of existing contributors in reviewing code. Other distributions always require some form of patch reviews to increase the quality of the distribution.

Reusability and compatibility with different legal jurisdictions

If for some reasons we want to reuse an FSDG distribution and also make sure that a given FSDG distribution is legally redistributable, we at least need to:

  • Look if the distribution we reuse has a DRM circumvention and software patents related policies compatible with the place where we want to redistribute it, or to avoid redistributing packages incompatible with the local legislation.
  • Make sure that there are no compiled software that contain combined work from license like the GPLv2 and the CDDL, that may be compatible at the source level, but result in a non-redistributable binaries.
  • Also look if our use matches the trademarks policies of the distribution.
  • Find how to ship the corresponding source code.

This can be useful in various situations:

  • For instance when people deploy or redistribute (part of) FSDG distributions in organization that want to avoid legal risk/
  • Or in context where people or organization are already targeted by some repression, to avoid extra legal risk.

In other cases some people resist unjust laws by not obeying them or by not collaborating to make it easy to respect them.

Also note that for software patents, there is no way to avoid them all, and knowing about specific patents increase the penalty in case of software patent infringement. Here the best way to fix that is to get various legislation modified to completely ban software patents, and use community defense[8] in the meantime to lower the risks.

DRM circumvention and software patents related policies

This table tries to document if there is a policy with regard to DRM circumvention and software patents, and also looks in practice what packages are available. Note that some distributions might not have decided on a policy and many distributions also inherit packages from a parent distributions, so that also affect the available packages in practice.

Distributions
Dragora Dynebolics Guix Hyperbola LibreCMC Parabola ProteanOS PureOS Replicant Trisquel Ututo S
Libdvdcss Yes Yes Yes No, but has instructions to install it[9].
Official policy No restrictions[10].

License combination and compiled software

Distribution Packages to avoid
Dragora
Dynebolics
Guix Guix has 2 packages that needs to be avoided when redistributing various software or images made with Guix[11]:

Note that Guix takes care of making sure that these packages are not pulled as dependencies by other packages, so it's very easy to avoid them (just not install them).

Hyperbola
LibreCMC
Parabola
ProteanOS
PureOS
Replicant
Trisquel
Ututo

Policies on what can be packaged

Many FSDG compliant distributions are based on upstream distributions. This table tries to document if the distribution insist in having new package added upstream, and what type of software can or can't be packaged.

Distributions
Dragora Dynebolics Guix Hyperbola LibreCMC Parabola ProteanOS PureOS Replicant Trisquel Ututo S
Based on upstream distros? No No Yes:
  • OpenWRT
 Yes:
  • Arch Linux ARM
  • Arch Linux 32
  • Arch Linux
  • Aur
 No Yes:
  • Debian
 Yes:
  • Replicant 6.0: LineageOS
  • Replicant 11: AOSP
 Yes:
  • Ubuntu
  • Also has very small number of Debian packages and packages made from scratch. It tries to keep that to a minimum for maintenance reasons[12].
Accepts new packages Yes[13] Yes[13] Yes[14] Yes[15] Yes[13] Need to be upstreamed first.[16] Yes[17] Yes, but also tries to minimize maintenance costs.[18][12]

Package system

Distributions
Dragora Dynebolics Guix Hyperbola LibreCMC Parabola ProteanOS PureOS Replicant Trisquel Ututo S
Package format Dragora tarball apt[19] Nar archives Pacman tarballs opk Pacman tarballs opk[20] deb
  • apk for applications
  • None for the system
 deb Gentoo tarballs[21]
System package manager qi guix pacman opkg pacman apt apt emerge[21]
Package system package definitions code generating packages package definitions package definitions
  • package definitions
  • blacklist of packages to replace
 package definitions[22] Replicant doesn't have a real package system but software can be added by adding a git repository with an Android.mk or Android.bp file.
  • Scripts that modify Ubuntu packages
  • package definitions for Trisquel specific packages
 package definitions[21]
Package definition format Lisp code PKGBUILD Makefile PKGBUILD Deb package definitions Replicant doesn't have real package definitions. Though software can be build with either:
  • Android.bp
  • Android.mk
 Deb package definitions Ebuilds + eclass[21]

Mirrors

Distributions
Dragora Dynebolics Guix Hyperbola LibreCMC Parabola ProteanOS PureOS Replicant Trisquel Ututo S
Package mirror list Doesn't have mirrors, has build farms instead list list list N/A[23] list
Documentation Doesn't have mirrors, has build farms instead. You can also run your own build farm. instructions instructions N/A[23] instructions

References

  1. ↑ The FSDG has a section on non-functional data: "Data that isn't functional, that doesn't do a practical job, is more of an adornment to the system's software than a part of it. Thus, we don't insist on the free license criteria for non-functional data. It can be included in a free system distribution as long as its license gives you permission to copy and redistribute, both for commercial and non-commercial purposes. For example, some game engines released under the GNU GPL have accompanying game information—a fictional world map, game graphics, and so on—released under such a verbatim-distribution license. This kind of data can be part of a free system distribution, even though its license does not qualify as free, because it is non-functional.".
    So Free culture means that the distribution has a policy to go beyond what the FSDG requires and requires all works to be licensed under a free license, even if they are non-functional data.
  2. ↑ According to an conversation on #guix on Liberachat the 05 January 2023, Guix sticks to the FSDG:
    18:46 < GNUtoo> hi, I've a quick question: Does Guix require free licenses for non-functional works (like game data) or not? The FSDG allows licenses like cc-by-nd for that (but not the -nc ones).
    18:46 < GNUtoo> The only thing I found on that is the following: https://guix.gnu.org/en/manual/devel/en/guix.html#Software-Freedom
    18:46 < GNUtoo> but it's unclear if the question was considered or not
    18:47 < nckx> We don't deliberately stray from the FSDG, in either direction, when it comes to licencing.
    18:47 < nckx> (We might reject packages for other reasons out of its scope.)
    18:48 < GNUtoo> ok, so I assume that cc-by-nd is ok for non-funcional data then, thanks a lot
  3. ↑ According to bug bug #51352, in the case of bundled dependencies, Guix seems to require a list of dependencies<->license. The ungoogled-chromium package definition seems to have such a list. Though long time ago, some people (bill-auger and Neox) told me that the license list was incomplete. So it probably needs someone independent to look into it to see if it's still the case today or not, as things also improved over time. Also note that packaging a cleaned up Chromium takes time, and Chromium also gives Google control of the web standards, so there might also be unrelated reasons why various distributions do not package chromium or code based on Chromium.
  4. ↑ https://wiki.hyperbola.info/doku.php?id=en:philosophy:chromium_flaws mentions that we (hyperbola) "require all software to be built from source"
  5. ↑ The documentation on Parabola blacklist format mention that blacklisting Arch Linux packages not built from source (by Arch Linux) need to be removed or replaced as the packages "must be compiled from source, as we are stricter about that than Arch is". Packages not build from source are package whose package definition download binaries and package the binaries.
  6. ↑ The license list is generated and available in the settings, but there are no package definitions, so it's not easy to check the licenses. People need to look in each git repository to see the precise license. Some repositories have licensing data in the form of empty files with license names. These are probably picked by the code that generates the license list.
  7. ↑ Even if binary packages are allowed, Replicant still needs to ship the complete and corresponding source code of binary packages as well, otherwise this would make the package nonfree and/or create license compliance issues for Replicant.
  8. ↑ Basically use crowdfunding for funding a legal defense when attacked, ask help from people for information on how to invalidate the patents, etc.
  9. ↑ https://trisquel.info/en/wiki/enable-dvd-playback
  10. ↑ Replicant didn't take any decision related to patents or DRM circumvention.
  11. ↑ There was a discussion on the Guix mailing list about including support for the ZFS linux module and/or depending on it for Gnome in the guix-devel mailing list. The conclusion of this discussion was that there was strong proof that compiled modules were not redistributable, and so Guix chose to avoid redistributing them. Guix also made sure that the ZFS linux module cound't be pulled on accidentally, for instance by installing gnome. However at the time people discussing weren't able to find strong enough proof of the fact that the source code itself was not redistributable, or any information that this source code was redistributable at all. The Software concervancy legal analysis that is pretty well detailed was enough to show that binary distribution was not permitted but it didn't analyze precisely the case of a source-only distribution. The FSF also has published some analysis of the situation that seems to imply that source-only distribution also violates the GPL: But there wasn't the level of details required to really convince Guix maintainers. A precise analysis of what parts of the GPL and CDDL conflicted (with the citations) and how they apply to source only distribution would probably have been sufficient but no one took the time to do this research and report on it.
  12. ↑ 12.012.1 I personally worked with ark74 to fix a bug in the 'guix' Trisquel package. Ubuntu didn't deem the bug important enough to fix it. So instead of using the Debian package we reused the guix patches that fixed the issue. We did that for maintenance reasons as when the guix packages will be updated, at some point the patches can simply be removed without much extra work. This shows a focus on lowering the maintenance costs. This can make the acceptation of new packages harder but it also means that the distribution takes security seriously and maintains better the packages it has than a distribution that would accept anything without any concern over maintenance.
  13. ↑ 13.013.113.2 This distribution is not based on an upstream
  14. ↑ Around 2020, the LibreCMC maintainer was OK with adding new packages, assuming that the package are not too big. This can be seen in the discussion about adding dnscrypt-proxy2.
  15. ↑ look at the Parabola repositories wiki page for more details.
  16. ↑ https://tracker.pureos.net/w/development/pureosdebianteam/
  17. ↑ Replicant has been adding software like wipe, evtest etc to the images that weren't in the original distribution it was based on. Though the image needs to remain small.
  18. ↑ From #trisquel on liberachat, the 14 February 2023:
    17:28 < GNUtoo> quidam: btw, what is it possible to add extra software in Trisquel (like h-client, pacstrap + parabola installation keyring, pureos-keyring, etc) or are we supposed to somehow work with upstream to add these packages?
    17:29 < GNUtoo> (or to make our own ppa)
    17:30 < quidam> oh, we for sure can add anything :)
  19. ↑ It's most likely apt: "The dyne:III consists in a Debian-Live system running free packages from various Apt based distributions" from dynebolic's README.txt
  20. ↑ http://files.proteanos.com/pub/proteanos/pool/a/acpi/
  21. ↑ 21.021.121.221.3 "Ututo XS is compiled using Gentoo Linux ebuilds and emerge software." from Ututo Wikipedia page
  22. ↑ http://proteanos.com/doc/pkg/basic-expat/
  23. ↑ 23.023.1 Replicant doesn't have packages repositories.
Retrieved from "https://libreplanet.org/wiki?title=Group:Software/FSDG_distributions&oldid=70423"