Precedence: list
MIME-Version: 1.0
In-Reply-To: <CA+T2pCGAS+ehDKb60JQR8J6ixASGfjfOzQQe4A-UCgHFg=1K2A@mail.gmail.com>
References: <1614404acdb.edd44d4135179.3833405768989653606@zoho.com> <CA+T2pCGAS+ehDKb60JQR8J6ixASGfjfOzQQe4A-UCgHFg=1K2A@mail.gmail.com>
From: William Pitcock <nenolod@dereferenced.org>
Date: Wed, 31 Jan 2018 13:35:28 -0600
Message-ID: <CA+T2pCFFNCc+tk-tsjHnRzsEB3X_CNbRRysA2qf5PtvU0MGp=g@mail.gmail.com>
Subject: Re: [alpine-devel] RFC: Fixing license field in APKBUILDs (or a bit more)
To: =?UTF-8?Q?Przemys=C5=82aw_Pawe=C5=82czyk?= <przemoc@zoho.com>
Cc: alpine-devel <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

On Wed, Jan 31, 2018 at 12:26 PM, William Pitcock
<nenolod@dereferenced.org> wrote:
> Hello,
>
> On Mon, Jan 29, 2018 at 4:23 PM, Przemys=C5=82aw Pawe=C5=82czyk <przemoc@=
zoho.com> 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.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---