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". _______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
