Housekeeping #2862

Clarify the copyright status of PKGBUILDs

GNUtoo - over 3 years ago - . Updated about 3 years ago.

freedom issue
% Done:




Updated by GNUtoo over 3 years ago

The abslibre repository have no license, nor files that clarify the copyright status.

As it's up to the projects and contributors to choose a license.

However it would also be possible to decide that the PKGBUILDs from Arch Linux and its various derivatives like Parabola are not copyrightable by having the project state it.

Statements on licensing from projects have legal consequences at least in the European Union1, so I assume that if a project states that the work they produce is not copyrightable, it would also be legally valid, and that in case of legal issues, a court of law would recognize the project decision.

In February 2020 I started a thread on the dev mailing list on this topic but I got no replies.

Since then I've got more information on the topic so I opened this bugreport to collect and centralize them.

Licenses for package definitions in other projects

So far I've found several projects that use licenses for package definitions. We need to document if there are also projects that consider package definitions as not copyrightable.

Project Package definition license
Gentoo GPLv2
Guix GPLV3+
OpenWRT GPLv2 or GPLv2+?
Yocto MIT for the packages definitions and GPLv2 only for some other files

Position on PKGBUILDs licensing of various contributors

The 19 December 2019, I was told in #archlinux that the package definitions were considered as copyrightable by some Archlinux developers, but that nobody cared enough to fix the issue by choosing a license. However I've also found inconsistencies with that position since then as Eli Schwartz told on #parabola that Eli's PKGBUILDs are not copyrightable2.

I was also told that there might be a thread on the topic in one of the Arch Linux mailing list, but I've not found a way yet to search them as mailman didn't provide a search functionality on them.

Contributor Default license Policy
Eli Schwartz Unlicense Eli's PKGBUILDs are not copyrightable, and if they are the Unlicense can be used instead2
GNUtoo GPLv3+ Seeks consensus and is willing to resilience to any free software license, or agree that the PKGBUILDs are not copyrightable to follow consensus


2 From #parabola on Freenode the 09 August 2020:

04:11 < eschwartz> > All PKGBUILD files in this repository are licensed under the Unlicense. IMHO they aren't unique enough 
                   to qualify for copyright, therefore I have made this explicit.


I'll try to keep that bugreport post updated, so I'll describe the various additions here.


Updated by bill-auger over 3 years ago

i can only presume that the person who made that claim in #archlinux was not actually on the team - if the arch package maintainers believed that the build recipes were copyrighted, then it seems to me that all mirrors and arch-derived distros would be illegitimate; and it would be a copyright violation to download any PKGBUILD from arch or AUR, or any mirror - i find it very difficult to believe that any responsible and experienced software developer would sincerely claim that their work is copyrighted, and then publish it for un-fettered re-distribution, without any license, disclaimers, terms of use, or even an: "all rights reserved" notice - regardless of the intention, that would be an irresponsible trap to set for unwitting users, a "rookie mistake" at best, indicative of inexperienced or sloppy project management, which i do not believe is the case regarding archlinux - this was discussed on IRC some time ago; and eli (one of the arch trusted users) believes that the consensus among the arch team, has always been that build recipes are not copyrightable; and that this explains why the concern has had no priority, in all of the ~20 years since the arch project began

probably more than 90% of abslibre, was adapted from the prior work of someone outside the parabola project - without the co-operation of arch, arch32, and archarm, the only thing we could do, is to refrain from publishing abslibre - surely, re-writing it all is not a viable option, right?

that leads to the heart of the matter, of course - the usual method of re-licensing, in cases where some contributor disagrees with the proposal, is to purge their contributions, and re-implement the functionality under the new license - however, there is generally little to no "wiggle-room" for creativity in build recipes - the range of possible re-implementations, would be as tightly constrained, as the original was, and necessarily identical, in the most common cases - that is why such contributions should be considered as trivial, and not copyrightable - that extremely narrow range of "design-space", is well below the "threshold of creativity" in all normal cases; and so attribution was probably not required - the Maintainer(s) and Contributor(s) are strictly information, for the sake of bug reporting and acknowledgment, and not as a copyright statement

the strict constraints placed upon packagers, in order to execute the build successfully, are primarily and fundamentally attributable to the upstream developers and the developers of the build tools, but not the packager - the packager is not creating anything novel - unless there is significant source-level patching, she is merely (re-)configuring and performing a routine procedure, which someone else has designed and pre-determined all useful variations - the most salient example of course, is that one could not re-implement `./configure && make && make install`, without also modifying the program under build or its build system - even `./configure --without-foo`, if it is meaningful at all, is an option prescribed by, and attributable to the upstream and/or tool-chain developers

directly to the ticket subject: an explicit statement would be the proper formality; but it does not add significant weight to the general argument, really; because permission is already present, if only implicitly, and presumed by the conventional default, as a matter of "hacker culture" - it would be very difficult to find an arch or AUR maintainer, or user, who believes that general public permission is not granted for any arch or AUR PKGBUILD

of course, the "hacker culture" argument is fairly weak on its own, as is the users' general belief; but the mere fact that the arch project documentation instructs mirrors on how to re-distribute their software, and does not require any special formal permission to do so, demonstrates the general intention of permission -one could argue that it is an explicit statement of permission

i believe that it would be easy to argue, that everyone who has ever contributed to arch packaging, understood fully, that their works would be freely available, modifiable, and widely re-distributed - if that work were done without that intention in mind, there would be no sincere reason to publish it to a public arch server in the first place

even if those contributions were offered with the nefarious intention of planting a copyright bomb, one could still argue that they were given willingly, with the full knowledge that there would be re-distribution; and that all parties would be under the presumption, that this "promiscuous re-distribution" was endorsed (indeed encouraged) by the project - IMHO, that implication alone should diffuse the bomb

i would hope, that in order to claim a copyright violation, one would be required to demonstrate, that the copyright holder did not intend for the accused to acquire a copy, or to re-distribute copies - i believe that claim would be fallacious for anything in the archlinux repositories, and that this is the key factor in this discussion

if anyone on the archlinux team disagrees that all PKGBUILDs hosted on arch public servers are intended for unfettered re-distribution, then archlinux has a very big problem to address - perhaps, you are wise to raise the issue; but the problem (if there is one), is not in parabola - only the archlinux management could resolve this dangling ambiguity - regardless of how much gets documented here, if the arch team is unwilling to discuss it, than i dont see the proposal having any legs


Updated by bill-auger over 3 years ago

  • Status changed from confirmed to open
  • Tracker changed from Bug to Housekeeping

Updated by GNUtoo about 3 years ago

I didn't see that update, sorry about that.

I've discussed with Emulatorman on #hyperbola about that issue too.

They are willing to relicense their PKGBUILDs to CC0, so I decided to also release mine under CC0.

I herby Denis 'GNUtoo' Carikli (re-)release all the PKGBUILDs I did so far under the CC0 license.


Updated by bill-auger about 3 years ago

my previous comment was just a counter-argument for the sake of balance, and to orient the discussion toward a practical, pragmatic direction

one practical concern i could add, is that all of the "source files" links on the parabola packages website and broken - it has probably been that way forever; and this is probably the reason why - it would be nice to "fix" that

i dont think we need any parabola mainatiners to agree so explicitly, to liberal licensing of all parabola software - i doubt that any would argue against a proposal to make it general parabola policy - for all intents and purposes, the FSDG already presumes it - however, my main point was that there is little utility to begin with parabola - the great majority of parabola software and build recipes were not, and never will be, authored entirely by parabola team members - for only a small number of package maintainers to make such statements, especially if it is only those representing the AUR or derivative distros, is the metaphorical "tail" trying to wag the dog

convincing past contributors to make an explicit statement, or agree to some blanket license, is the first stage; but it would need to be a matter of distro policy into the future, and most pivotally, a policy of the archlinux distro - anything we do, without the full co-operation of arch, at the management level, would fall far short any pragmatic goal

Also available in: Atom PDF