linux-kernel - Re: [PATCH v2 01/27] staging: ccree: SPDXify driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOFm3uEfLqvLtvLdj3Fq___EDhQnZn_d-W69Uv3GOKQu8AA51Q@mail.gmail.com>
Date:   Sun, 7 Jan 2018 17:16:21 +0100
From:   Philippe Ombredanne <pombredanne@...b.com>
To:     Gilad Ben-Yossef <gilad@...yossef.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ofir Drang <ofir.drang@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        driverdev-devel@...uxdriverproject.org, devel@...verdev.osuosl.org,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 01/27] staging: ccree: SPDXify driver

Gilad,

On Sun, Jan 7, 2018 at 11:13 AM, Gilad Ben-Yossef <gilad@...yossef.com> wrote:
> On Wed, Jan 3, 2018 at 5:01 PM, Philippe Ombredanne
> <pombredanne@...b.com> wrote:
>> Gilad,
>>
>> On Wed, Jan 3, 2018 at 2:35 PM, Gilad Ben-Yossef <gilad@...yossef.com> wrote:
>>> Replace verbatim GPL v2 copy with SPDX tag.
>>>
>>> Signed-off-by: Gilad Ben-Yossef <gilad@...yossef.com>
>>
>> <snip>
>>
>>> --- a/drivers/staging/ccree/cc_crypto_ctx.h
>>> +++ b/drivers/staging/ccree/cc_crypto_ctx.h
>>> @@ -1,18 +1,5 @@
>>> -/*
>>> - * Copyright (C) 2012-2017 ARM Limited or its affiliates.
>>> - *
>>> - * This program is free software; you can redistribute it and/or modify
>>> - * it under the terms of the GNU General Public License version 2 as
>>> - * published by the Free Software Foundation.
>>> - *
>>> - * This program is distributed in the hope that it will be useful,
>>> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> - * GNU General Public License for more details.
>>> - *
>>> - * You should have received a copy of the GNU General Public License
>>> - * along with this program; if not, see <http://www.gnu.org/licenses/>.
>>> - */
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
>>
>> Thank you for using the SPDX tags!
>>
>> Now, while I appreciate your attempt to use the latest and greatest
>> SPDX license id definitions (published by SPDX a few days agao), THIS
>> IS NOT a welcomed initiative. Please stick instead to use ONLY the
>> SPDX license ids that are defined in Thomas doc patches [1]: e.g. use
>> instead:  SPDX-License-Identifier: GPL-2.0 and please DO NOT USE
>> GPL-2.0-only for now.
>
> Oh dear. It seems I have been over enthusiastic with this.
> I shall post a revised  patch set. Sorry for the noise.
>
>>
>> The rationale is simple: from a kernel standpoint we cannot depend on
>> the latest changes of an external spec such as SPDX (and I am involved
>> with SPDX alright but I am wearing a kernel hat here). This is why
>> things have been carefully documented for the kernel proper by Thomas.
>> It is perfectly fine at some times in the future to adopt the newest
>> license ids, but this will have to happen in an orderly fashion with a
>> proper doc update and the eventual tree-wide changes to update every
>> occurrence. This cannot happen any other way or this would defeat the
>> whole purpose to have clear licensing kernel-wide: using the latest
>> and greatest introduces variations and creates a mess that we want to
>> avoid in the first place.
>>
>> CC: Thomas Gleixner <tglx@...utronix.de>
>>
>> [1] https://lkml.org/lkml/2017/12/28/323
>>
>
> Just a thought - it might be useful to have an SPDX revision as part of the tag,
> e.g.
>
> SPDX-3.0-License-Identifier: GPL-2.0-only
>
> It seems it will make transitions such as this easier, me thinks.
>
> Maybe something to consider for SPDX 3.1 :-)

That would make things a tad more complicated on the contributor side
IMHO. Instead and since the reference is the kernel doc and nothing
else (and not the latest and greatest SPDX updates of last week),
there is no need to version things at all, we just need to rev up the
doc and tools when and if we update things with newer SPDX versions.

Consider this analogy:
When you use zlib in the kernel you can only use exactly the subset of
the zlib API that is vendored in the kernel. You cannot use a new zlib
function in the latest and greatest release of zlib without updating
the vendored version first.
Here Thomas's doc is exactly this: a subset of the SPDX and license
ids as used exactly in the kernel as of now and "vendored" in the
kernel through this doc. You cannot use anything outside of this short
of updating the doc, tools like checkpatch and _every_ place that
could be impacted by this doc update.

-- 
Cordially
Philippe Ombredanne