0040 License Package Sources

License Package Sources

Summary

Our package sources currently do not have explicit licenses. This RFC proposes to license all Arch Linux package sources under the terms of the Zero-Clause BSD license.

Motivation

NOTE: This RFC was not written by lawyers so any statements about legal things are merely the result of research.

Arch Linux package sources (PKGBUILD and strictly related files such as e.g. .install, .desktop or systemd files) currently lack a license. This is potentially problematic as it leaves the licensing of package sources open to interpretation. Some users have expressed concerns about this (ML1, Parabola Licensing Issue).

Some people consider package sources to be non-copyrightable (NoC1, NoC2, NoC3, Parabola Discussion). However, most other distributions have assigned (or want to assign) a license. See Approaches taken by other Linux distributions.

Package sources may or may not be copyrightable. Whether they are may even vary from one jurisdiction to another. For instance, Tuchman Law argues that Hello World programs are not copyrightable since they leave no room for creativity. The same could be said about trivial PKGBUILDs. In contrast, a complex 500-line PKGBUILD is more likely to count as a creative work. Most of our package sources will be somewhere in the middle of the those two extremes.

Thus, if package sources are copyrightable at least in some cases, we should assign a license to all of them to be on the safe side. If they are not copyrightable, the license would not matter much. As such, we only stand to gain by assigning a license.

There is no clarity as to what conditions apply to a software without an explicit license.

In some jurisdictions, the default license assigned to the software is quite restrictive.

See GitHub's interpretation and this Open Source Stack Exchange discussion, and this article by Choose a License. It can be understood that not having a license is akin to undefined behavior.

By resolving this legal uncertainty for ourselves, we also implicitly aid downstream projects, benefiting other distributions and projects, as well as companies who consume or want to modify our packaging sources.

This RFC proposes the Zero-Clause BSD license for all package sources as it seems to be the best way to convey how PKGBUILDs are supposed to be used. It is a widely accepted and easily understood license and quite liberal. While it's uncommon for a distribution to use a 0-clause license, we believe it would provide the least amount of friction as users that use bits and pieces of our package sources don't need to be worried about violating a license.

Prior Discussions

Approaches taken by other Linux distributions

Major linux distributions all have a license for their package specifications or are working towards providing one. MIT or 2-Clause BSD licenses are most common; some re-use upstream licenses for package specifications.

Void Linux uses the 2-Clause BSD License for their void-packages repository.

FreeBSD uses the 2-Clause BSD License for their ports repository.

Gentoo uses the GPL v2 for their package repository.

Nixpkgs uses the MIT license for all packages.

OpenSUSE uses a standard header declaring the source to use the same license as the package itself, unless the package is proprietary, in which case the source uses MIT.

Debian uses a standardized machine-readable file which assigns licenses to every file in the package source. See here for an example. It seems that many packages re-use the upstream license for the build instructions, though that is not always the case.

Fedora package specifications are under the MIT license by default, as stated by the Fedora Project Contributor Agreement. Contributors are free to choose other licenses.

Alpine doesn't currently provide licenses for their package specifications, but is working towards providing one.

Parabola GNU (an Arch Linux derivative) is looking for a way to solve this upstream.

Specification

Official repositories

  1. Create a script to scan all packages and gather all authors according to their git contributors and # Maintainer and # Contributor tags.
  2. Create a GitLab project (called archlinux/relicensing-discussions) with service desk functionality to allow people to report their stance via email.
  3. Send an email to every author containing a list of all their package contributions and inform them about the new license. Ask for them to either do nothing and thereby consent to license all their contributions under 0BSD or to object within four months. The email should have reply-to set to the aforementioned GitLab project's service desk.
  4. After four months, drop a LICENSE file into each package repository in which all the authors have consented to the license.
  5. Periodically check the GitLab project and address/discuss any concerns or objections. We'll address objections on a case-by-case basis. In such a case, we'll have to consider whether the contribution needs to be removed and/or rewritten.

See also Eric S. Raymond's licensing guide. For reference how other open source projects have handled their relicensing, also see: MPV relicensing, MPV relicensing result, Dolphin relicensing, Mozilla relicensing.

A discussion from the Parabola distribution (See Parabola Discussion) indicates that there are good reasons to ask for objections rather than asking for consent:

It would be very difficult for anyone to claim: "I did not know or did not intend, that these would be shared freely, for use and modification by anyone in the world". It is generally assumed by Arch users, that every contributor to every recipe in Arch and AUR knows fully, that the work will be published freely for the public use, and that anyone with a copy, is most likely to have taken it, specifically with intent to modify it, and that no special permission is required to do so.

The license does not contain individual attribution for each contributor, which would be error-prone to write manually and hard to generate automatically. Instead, the license uses the generic phrase "Arch Linux Contributors". This is in line with typical approaches in other projects. If individual attribution is needed, it can be obtained using version control history.

The email text shall be as follows:

Title: Licensing your Arch Linux contribution as 0BSD

Hello Arch Linux Contributor,

You have contributed to the following packages in the past: <list of packages>

We're contacting you to inform you about our plans to license our package sources as 0BSD. This follows the text and discussion outlined in RFC 40 [1].

The short version is: Arch Linux package sources didn't have an explicit license before. In order to steer away from this uncertainty, we'd like to license all package sources such as PKGBUILDs and auxiliary files as 0BSD.

IF YOU CONSENT TO THIS, you don't have to do anything.

IF YOU OBJECT TO THIS, please reply to this email WITHIN FOUR MONTHS. It will automatically create an issue in our tracking system where we can discuss further steps.

[1] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40

We'll enforce the existence of LICENSE files using a standard software solution such as Reuse or by integrating it into our Arch-specific tooling. This RFC doesn't specify a specific solution to enforce those.

AUR

The AUR currently specifies that all packages in it could be elevated to official repositories. This implies that their licenses need to allow for this eventuality. As such, we should explicitly require their package sources to share the same license as the official packages before they become eligible for promotion.

This RFC does not specify that all AUR packages will be required to have the expected license. If they do not have them, however, they are not eligible for promotion.

  1. The AUR has a .SRCINFO check in a pre-receive hook. In the same place, we need to add a check for a LICENSE file with the appropriate license text. In case no appropriate LICENSE file with the expected text is found, we'll warn the users in git's pre-receive hook that packages without a 0BSD license are not eligible for promotion to official repositories.
  2. Update AUR submission guidelines in the Arch Wiki to include the creation of a LICENSE file.

License Text

Binary files, as well as any files describing changes ("patches") to the software that is being built are excluded from this license. They are provided under the license terms of the software they describe changes for.

Any files containing a license notice are excluded from this license. They are provided under the license terms defined in their respective notices.

Copyright 2024 Arch Linux Contributors

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted.

THE SOFTWARE IS PROVIDED “AS IS” AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Drawbacks

We're getting consent via lack of objection. This may or may not be less legally bulletproof compared to asking every past contributor for explicit consent. An earlier version of this RFC proposed asking every contributor for consent directly. However, this was deemed infeasible.

We may have to rewrite some PKGBUILDs in case of objections.

This is some work and may annoy people.

Unresolved Questions

We'll never know whether we have the complete list of contributors. This has two reasons:

  1. We don't have the complete history of all of our package sources. Many packages have existed in pre-SVN times.
  2. Some AUR packages might have had their contributor tags removed.

Alternatives Considered

  1. Keeping the status quo. This would continue with us being in a licensing gray zone.
  2. Alternative licenses. We did consider suggesting other licenses but ultimately settled on 0BSD for its simplicity and lack of attribution requirements. MIT or MIT-0 might be good alternatives. With MIT, the need to keep the license file might be cumbersome for some use cases. MIT-0 is nearly equivalent to 0BSD, but newer and less widely known. Parabola makes a case for CC0: Parabola Discussion.
Calendar August 7, 2024