[Dev] Update on the PKGBUILDs license
Denis 'GNUtoo' Carikli
GNUtoo at cyberdimension.org
Mon May 2 14:58:00 GMT 2022
On Fri, 29 Apr 2022 00:26:49 -0400
bill-auger <bill-auger at peers.community> wrote:
> when i tried this, i noticed that my editor recognized it
> and gives it a special color - that suggest to me that
> these headers are widely known/acceptable these days
> there is a lot of buzz in the libre community about REUSE,
> which favors SPDX - i think we should encourage it
The FSF and GNU tend to favor copyright headers, and Bradley Kuhn
mentioned that SPDX was too limited.
So I tried to look a bit into it and found out that there are certain
things you can't do like adding exceptions to licenses for instance
(like releasing code under GPLv3+ with an additional permission to link
against GPLv2 libraries). Text written by human enable to do these
Though for our use case (PKGBUILDs in Parabola), SPDX looks fine for me
as long as we also keep the README file we have to explain the situation
in more details (because we have CC0 on top of likely not-copyrightable
As for having the authors like that, the example you chose is not the
best one. Ideally it should be:
> # Copyright (C) 2019,2020 Andreas Grapentin <andreasXgrapentin.org>
> # Copyright (C) 2019,2020,2021 bill-auger <bill-augerXprogrammer.net>
And then only 1 line with Maintainer, like that:
> # Maintainer: Parabola hackers <this mailing list>
Or like that:
> # Maintainer: A specific parabola hacker <Mail>
For the later I would prefer to have Parabola hackers / Parabola
project or something similar as maintainer and to unify that across
all PKGBUILDs we have.
Though I am also hesitant to change that without asking the people
listed in Maintainer, as some might have compelling reasons to add them
as Maintainer instead of the Parabola project.
We could even remove the Maintainer: line and move it in a README
In addition, if necessary, below, we can also add a policy/howto
detailing how to do changes the package the case we have special needs
for specific packages. For instance:
- When updating this package you need to do these tests to make sure it
- Look at foo branch to see if there are any pending invasive changes
and please sync with the person who worked on them before making
invasive changes. For smaller changes (version bump, adding boards),
you can do it directly.
- Do not do these changes otherwise it'll break in this way.
This way the information is in the file and not necessarily in a
maintainer's brain which might not always be available. And it enables
anybody (including people that are not (yet) Parabola hackers) to
understand how to modify the package instead of having to go through a
Guix has something like that with the Guix package for instance:
> ;; If you are updating this package because it fails to build, you
> ;; need to actually update it *twice*, as the installer is pointing
> ;; to the N-1 guix package revision.
[guix package definition]
It doesn't say "don't touch, only <maintainer> can modify it".
Similarly they have rules for core packages (in their official
documentation) as in Guix modifying them has way more impact than other
distributions (like Parabola, Trisquel, etc) as in Guix modifying them
require to rebuild almost everything due to the way Guix works.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Dev