mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: Vitaly Chikunov <vt@altlinux.org>, Jarkko Sakkinen <jarkko@kernel.org>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>,
	keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
	davem@davemloft.net, herbert@gondor.apana.org.au,
	dhowells@redhat.com, zohar@linux.ibm.com,
	linux-kernel@vger.kernel.org, patrick@puiterwijk.org,
	linux-integrity@vger.kernel.org
Subject: Re: [PATCH v10 1/9] crypto: Add support for ECDSA signature verification
Date: Fri, 5 Mar 2021 17:15:37 -0500	[thread overview]
Message-ID: <4abdc777-03a9-bee1-3ae1-93d77e14eea0@linux.ibm.com> (raw)
In-Reply-To: <20210305194640.nnerhdadoczqyta3@altlinux.org>

On 3/5/21 2:46 PM, Vitaly Chikunov wrote:
> Jarkko,
>
> On Fri, Mar 05, 2021 at 07:05:39PM +0200, Jarkko Sakkinen wrote:
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (c) 2021 IBM Corporation
>>> + *
>>> + * Redistribution and use in source and binary forms, with or without
>>> + * modification, are permitted provided that the following conditions are
>>> + * met:
>>> + *  * Redistributions of source code must retain the above copyright
>>> + *   notice, this list of conditions and the following disclaimer.
>>> + *  * Redistributions in binary form must reproduce the above copyright
>>> + *    notice, this list of conditions and the following disclaimer in the
>>> + *    documentation and/or other materials provided with the distribution.
>>> + *
>>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>>> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>>> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>>> + * HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>>> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>>> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>>> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>>> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>>> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>> + */
>> This license platter is redundant, given SPDX.
> I think SPDX identifier supplements license plate and is machine readable
> identifier, but it does not replace or making adding of license plate
> redundant.
>
> - Quoting https://spdx.dev/ids/
>
>    "When a license defines a recommended notice to attach to files under
>    that license (sometimes called a “standard header”), the SPDX project
>    recommends that the standard header be included in the files, in
>    addition to an SPDX ID.
>
>    Additionally, when a file already contains a standard header or other
>    license notice, the SPDX project recommends that those existing
>    notices should not be removed. The SPDX ID is recommended to be used
>    to supplement, not replace, existing notices in files."
>
> - GPL license text have section on "How to Apply These Terms to Your New
>    Programs" which says to add license boilerplate text and it does not
>    say SPDX identifier is enough.
>
> - Also, page https://www.kernel.org/doc/html/latest/process/license-rules.html
>    does not forbid adding license plate text. (Even though it misguidedly
>    says "alternative to boilerplate text" is the use of SPDX.)
>
> - License text is a readable text and not just identifier.
>    I think SPDX tag could be not legally binding in all jurisdictions.
>
> By there reasons I believe you cannot request removing license platter
> from the source and this should be author's decision.
>
> Thanks,
>
Thanks for looking into this. I am fine with the SPDX identifier.

Regards,

    Stefan



  reply	other threads:[~2021-03-05 22:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05  0:51 [PATCH v10 0/9] Add support for x509 certs with NIST P384/256/192 keys Stefan Berger
2021-03-05  0:51 ` [PATCH v10 1/9] crypto: Add support for ECDSA signature verification Stefan Berger
2021-03-05 17:05   ` Jarkko Sakkinen
2021-03-05 17:58     ` Vitaly Chikunov
2021-03-05 19:46     ` Vitaly Chikunov
2021-03-05 22:15       ` Stefan Berger [this message]
2021-03-05  0:51 ` [PATCH v10 2/9] crypto: Add NIST P384 curve parameters Stefan Berger
2021-03-05 17:08   ` Jarkko Sakkinen
2021-03-05  0:51 ` [PATCH v10 3/9] crypto: Add math to support fast NIST P384 Stefan Berger
2021-03-05 17:09   ` Jarkko Sakkinen
2021-03-06 19:25   ` Vitaly Chikunov
2021-03-06 23:29     ` Stefan Berger
2021-03-07  0:03       ` Vitaly Chikunov
2021-03-07  1:21         ` Stefan Berger
2021-03-05  0:51 ` [PATCH v10 4/9] ecdsa: Register NIST P384 and extend test suite Stefan Berger
2021-03-05 17:10   ` Jarkko Sakkinen
2021-03-05 18:27     ` Stefan Berger
2021-03-05  0:51 ` [PATCH v10 5/9] x509: Detect sm2 keys by their parameters OID Stefan Berger
2021-03-05  7:39   ` Tianjia Zhang
2021-03-05 17:16   ` Jarkko Sakkinen
2021-03-05 18:02     ` Stefan Berger
2021-03-05  0:52 ` [PATCH v10 6/9] x509: Add support for parsing x509 certs with ECDSA keys Stefan Berger
2021-03-05 17:07   ` Jarkko Sakkinen
2021-03-05  0:52 ` [PATCH v10 7/9] ima: Support EC keys for signature verification Stefan Berger
2021-03-05  0:52 ` [PATCH v10 8/9] x509: Add OID for NIST P384 and extend parser for it Stefan Berger
2021-03-05 17:10   ` Jarkko Sakkinen
2021-03-05  0:52 ` [PATCH v10 9/9] certs: Add support for using elliptic curve keys for signing modules Stefan Berger
2021-03-05 17:07   ` Jarkko Sakkinen
2021-03-05  0:53 ` [PATCH v10 0/9] Add support for x509 certs with NIST P384/256/192 keys Stefan Berger
2021-03-05 17:10   ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4abdc777-03a9-bee1-3ae1-93d77e14eea0@linux.ibm.com \
    --to=stefanb@linux.ibm.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jarkko@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patrick@puiterwijk.org \
    --cc=stefanb@linux.vnet.ibm.com \
    --cc=vt@altlinux.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®