On Fri, 29 Apr 2022 00:26:49 -0400 bill-auger <[email protected]> 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 things easily. 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 packages). 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> [license] 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 somehow. 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 doesn't break. - 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 single maintainer. 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. Denis.
pgpxOSxpEqqCK.pgp
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
