[Dev] Update on the PKGBUILDs license

[bill-auger]

as i mentioned to gnutoo on IRC, in order to do this properly,
we will need some cooperation from arch - i did some research
and have prepared an email to send to arch - anyone who is
interested, please read it over and offer critique or corrections

------------------------------------------------------------
re: the license of the ABS tree

There is a conventional concept called: "inbound<->outbound"
licensing, for software contributions. Github for example,
recognizes it and makes it explicit in their TOS. Roughly
speaking, if the project has no explicit policy regarding the
license of contributions, then all contributions are implicitly
considered to be offered under the main license of the project.
I intend to make the case that Arch could use this common
understanding, and Arch's own existing policies, as
justification to freely license the ABS tree and all of the AUR,
with minimal effort or arguments from contributors.

It is my understanding from discussing this with one Arch TU,
that the consensus among the Arch team, is a subtle twist to
that "inbound<->outbound" convention. Namely, that build recipes
are considered to not copyrightable, based on the "threshold of
originality" rule-of-thumb of copyright. Therefore, if that is
and was the consensus, then all contributions were accepted into
Arch under that presumption (ie: the main license of the project
is implicitly: "This is not copyrightable. Please do not claim
otherwise").

That may not be or may not be valid implicitly, but i think that
Arch has grounds to make it explicit, and to license all ABS and
AUR build recipes, retroactively (we believe that CC0 is the
ideal option in this case). If some contributions were offered
without that presumption; then frankly, Arch has "shot itself in
the foot", by failing to make the terms of contribution and
derivation explicit from the beginning. This issue should not be
ignored forever. It only gets more difficult to fix over time.

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.

If contributors did not know that. They were either foolish, or
they were planting a hidden copyright bomb on the project.
Whether ignorantly or maliciously, i think that could be
considered to be "entrapment" by legal experts. Such
contributions should be identified, and if the contributor does
not agree to a CC0 license, the contribution should be deleted
and re-written. If the re-written code happens to be identical
to the original, that only underlines the original presumption
that it was not copyrightable in the first place.

Likewise, every package maintainer assumes that all
contributions are offered freely. If any contributor were to
state in advance, that other people should not be allowed to
modify the recipe, we would all hope that the contribution would
be rejected on the face of it. Arch should protect it's users by
making that an explicit policy. Arch would also be protecting
itself in that way; because then, anything adopted from AUR into
Arch, would be unambiguously acceptable.

I could find little which could be construed as policy on the
matter; but i found a few points of reference, which demonstrate
that the intent of unfettered re-distribution and modifications,
always existed, at least implicitly.

------------------------------------------------------------

Copying:
* Arch allows anyone to clone the ABS repo,
  without special permission.
* The wiki gives instructions on how to do so.

------------------------------------------------------------

Modifying:
* The "Trademark Policy" explicitly encourages modifications
  and derivatives.
* The "Arch Build System" wiki article lists this as an
  intended use-case.

from
https://wiki.archlinux.org/title/Arch_Build_System#Use_cases:
> Its use cases are:
> * Customize existing packages to fit your needs (e.g. enabling or disabling options, patching).
> * Easily compile and install a newer, older, beta, or development version of an Arch package by editing the version number in the PKGBUILD.

------------------------------------------------------------

Sharing:
* The issue of "sharing" was not as easy to find evidence for.
  Although Arch clearly allows anyone to clone the ABS repo, and
  instructs how to do so, i could find nothing that states what
  down-streams are permitted to do with it, other than modifying
  for personal use. However, the "Code of Conduct" and "Trademark
  Policy" recognize that complete system derivatives exist and
  are not problematic for Arch, if the trademark policy is
  honored and Arch is not burdened with user support.

from
https://terms.Archlinux.org/docs/code-of-conduct/#Arch-linux-distribution-support-only:
> These distributions often use different packages, package versions, repositories,
> or make custom system configurations silently.

from
https://wiki.Archlinux.org/title/DeveloperWiki:TrademarkPolicy:
> ... we encourage customisation and derivation of Arch Linux, ...

------------------------------------------------------------

Contributions:
* The DeveloperWiki makes it clear that all AUR submissions
  are contributions to Arch proper.

from
https://wiki.archlinux.org/title/DeveloperWiki:Package_Submittal_Rules:
> Once a contributor uploads a package to the AUR they are considered the contributor.
> The act of uploading the package can be considered a donation or patch submittal.
> Everyone acknowledges that the package was created by the contributor,
> but it is now the property Arch Linux.

------------------------------------------------------------

Conclusions:
* Granted that PKGBUILDs are essential to any pacman-based
  distro, for Arch to encourage derivatives, implies that
  derivatives have permission to modify and re-distribute the
  packaging recipes.
* All of this evidence points to the conclusion, that Arch build
  recipes are intended to be freely re-distributable and
  modifiable; and that this is commonly understood by all users
  and contributors to the recipes. We are only trying to make
  these implications explicit, in order to clarify the legal
  ambiguity.

------------------------------------------------------------

We have started doing so within Parabola; but we can only apply
it to contributions offered to Parabola specifically. PKGBUILDs
are fairly ubiquitous though. What i will call "the pacman
ecosystem", is truly shared across many distros. That is,
PKGBUILDs from Arch and AUR tend to flow down to derivatives and
cross-pollinate between them. I think it is safe to say that
most PKGBUILDs in most pacman-based distros were taken, in full
or in part, from Arch or other projects.

In order for Parabola to achieve the ultimate goal of clear
licensing of all recipes, will require the cooperation of Arch,
or at least a clear statement of intent. If Arch adopted this
goal for itself, all other pacman-based distros could inherit the
benefit.

An example policy or statement of intent could be as simple as
this:

  We believe that software build recipes are not copyrightable.
  However, our recipes are all offered under the terms of the
  CC0 1.0 Universal license preemptively, despite that we
  believe the license to be inapplicable. Note that some build
  recipes include patches taken from their respective upstream
  projects. Those are assumed to be under the upstream license.

  If you have contributed to ArchLinux or the Arch User
  Repository in the past, and you disagree with this policy,
  please contact us immediately, and your contributions will be
  deleted.

I am not legal expert; but i think that would make a strong case
against anyone who contests it. It is essentially a DMCA
"take-down" policy. Furthermore, anyone who contests it, must
first demonstrate that the contribution meets the "threshold of
originality", which would be as difficult to argue for, as the
claim: "I did not know that my work would be shared and
modified".

I believe that the evidence thus far, has been sufficient to
suggest, that Arch could do this immediately, with minimal
effort or arguments from contributors. On the other hand, I did
find one reference which could be sufficient on it's own.

Section "5.2. Contribution Licenses" of the Arch TOS, touches
upon licensing:

from https://terms.Archlinux.org/docs/terms-of-service/:
> In the case of a contribution of software to an Arch Linux Project
> via GitLab or otherwise, you agree to license the contribution
> under the Project’s license. If the Project does not state a license,
> you agree to license it under the terms of the GNU General Public License version 3.

That is fairly unambiguous, except for the following subtleties:
* Is the ABS tree an "Arch Linux Project"?
* What is that project’s license?

The "DeveloperWiki:Projects" wiki article does not list ABS; but
I found that at least some team members, consider ABS to be an
"Arch Linux Project". The protected "Arch IRC channels" wiki
article gives the topic of the #archlinux-projects IRC channel
as:
> Projects development and discussion (mkinitcpio, abs, dbscripts, devtools…)

That alone, if true, could resolve the ambiguity, trivially.
Contribution to the ABS tree are licensed GPLv3, implicitly, per
the existing TOS. Of course, the GPL is somewhat overkill for
shell scripts. The CC0 is more appropriate and probably most
agreeable to all; so that is our recommendation, if the ABS tree
is not already considered to be an "Arch Linux Project".