Mail archive

Re: [alpine-devel] RFC: Fixing license field in APKBUILDs (or a bit more)

From: William Pitcock <>
Date: Wed, 31 Jan 2018 13:35:28 -0600


On Wed, Jan 31, 2018 at 12:26 PM, William Pitcock
<> wrote:
> Hello,
> On Mon, Jan 29, 2018 at 4:23 PM, Przemysław Pawełczyk <> wrote:
>> Preface
>> -------
>> It is kind of a follow up to the the previous thread started month ago:
>> License naming in APKBUILD - SPDX License List
>> Please check it if you haven't already.
>> Intro
>> -----
>> Conversion from simplistic and imprecise license naming that was used
>> before in Alpine Linux (e.g. GPL, GPL2, BSD, etc.) to slightly more
>> verbose but also more precise and standardized license naming will
>> undoubtedly make quality of Alpine Linux packages higher.
>> SPDX license identifiers are already getting adoption in many
>> open-source circles. I believe that Alpine Linux did a good thing by
>> deciding to use SPDX over half year ago. Unluckily, or maybe luckily,
>> conversion didn't truly followed on back then. There were some changes
>> here and there, but nothing of greater scale to really nail all existing
>> packages. I wrote "luckily", because at the end of 2017 SPDX License
>> List got new version 3, which has some changes compared to version 2.x.
>> I believe, as I already wrote in previous thread, that we should stick
>> to this new version, and most likely to its updates too, when they will
>> be ready, as I doubt they will be disruptive.
>> One unfortunate thing about sticking with version 3 of the list is that
>> one of distros reusing Alpine Linux as its base, Adelie Linux, is
>> apparently fixed on older version of SPDX License List, so already done
>> and upcoming changes may be not truly welcomed by them to some extent,
>> but I hope we'll be able to resolve all problems eventually and Alpine
>> Linux and Adelie Linux relationship will remain good and healthy.
> Adelie strongly prefers to use SPDX 2.
> We have already done some amount of license audit (e.g. for the subset
> of Alpine packages we ship), which has been using SPDX 2 identifiers.
> If we switch to SPDX 3 identifiers, we will have to start over, as
> they will need to be reverified.
> In addition, all packages that we are planning to upstream (KDE)
> presently use the SPDX 2 identifiers.
> We also have already done a lot of work to incorporate SPDX 2 into our
> standard packaging procedures, a few contributors complained that SPDX
> 3 identifiers are "annoying" and "mental bandwidth wasting."
> A possible compromise would be to allow either SPDX 2 or SPDX 3
> identifiers, based on the maintainer's preference: SPDX 3 deprecates
> but does not remove the SPDX 2 identifiers; in other words SPDX 3 is a
> superset of SPDX 2. Put differently, any tool which works with SPDX 3
> identifiers has to work with SPDX 2 identifiers as well.

After discussing with jirutka, we came to the conclusion that SPDX 2
shorthand identifiers are fine as long as they are not vague. For
example "GPL-2.0+" is equally valid to "GPL-2.0-or-later". This
resolves the main gripe that Adelie has with SPDX 3.


Received on Wed Jan 31 2018 - 13:35:28 UTC