Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp408991rwd; Thu, 8 Jun 2023 02:25:32 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6c+vpkER+tn4FIKD60vul6eJ0B4UqwFV2BYv1gQeeVYcmEJJjM1EsvRGMD0eup2aMhQZys X-Received: by 2002:a17:902:f683:b0:1a1:956d:2281 with SMTP id l3-20020a170902f68300b001a1956d2281mr8584136plg.3.1686216331766; Thu, 08 Jun 2023 02:25:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686216331; cv=none; d=google.com; s=arc-20160816; b=Ynz7beTjBMKL+bsq5lZb7krDiSFhfuXPoMAPRQWX0WIAPRDSqfP0GfK9GVlN2461So B2CSSnrz8ch+NsbqIooCV/PApjlL0NPYPkmyGPFcFMoQn8dbcFHHj6UFS4zKoCE+HfBI w+TBS6hzdVksPvBl3evgMnrTKnSOimPcTc0F5Um98IO+OCV+peSLENb3nEZjanx4cREX b1lXEsgIBapK+wQnBoFFrAqQYVUvz50iyN7XFOzKHnEvltuNE942Mzfwvw82MeVKinH5 MxO/Qnq6nwhG4RKd9V1qiO2HF72yQhJXDPDhlrhKeu1miA4HbvPpCcEV3wkMVoOUppdg ajyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=sThVuzyZ47bYSrGhSylo/lmlkoslKyDOmuTNtwInvtU=; b=nO6AZpOQjqu88MWZUhA9DbX+Ia1Qg0tDw/u8nxTtN1M5H0nQBXDrTNuumeJm0IfZok 8cdJ68y08kcdlUTdwk0BkdJiRottbycQ5kLt3ATsVBIJaRSTkUVVgR+ucf2gRkSr5cfZ Dn+sdFYWRmz8enWb76iwo6zdbs0UBc4ZyGlzBqska9mNLoXD+r0VlbShdJ+Nr42hRjVX eUD0vHKrLqw55bK+4D6T8RZlX7WdGn0xsNujitFgirbnG640hNtsndKuAZ3e1A51x2TJ UDG/cKgt9xVZpe4M7ZOH0+firDC1U28HYCLt062THhDWTX70QS1lhVgJALKL+Hb1wYRf 4hgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=wx+Ytz28; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v2-20020a170903238200b001a97fd670e6si763442plh.208.2023.06.08.02.25.14; Thu, 08 Jun 2023 02:25:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=wx+Ytz28; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235170AbjFHJFn (ORCPT + 99 others); Thu, 8 Jun 2023 05:05:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235746AbjFHJFk (ORCPT ); Thu, 8 Jun 2023 05:05:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A02AEE50; Thu, 8 Jun 2023 02:05:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 392FA64B1C; Thu, 8 Jun 2023 09:05:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27BEAC433EF; Thu, 8 Jun 2023 09:05:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1686215133; bh=b/HhhLn8tA5xrBrydV1Af1DGSHM7acWjZVlMLxM9uro=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wx+Ytz28FmOSrtoOj0sYpKdPCfHo7/V7si2xru3lCENMHSox1yvRNu2+3HF8SW7Om bRGeeMjINHGIaDXuxAVasZ5j4vUmfITRq6dXuCl6wII8GPZKZTP0taIa5G/KbnCc7P R7oZ76z31qQc0r5gniCFz7Dr70yDEgifTkSfWe/A= Date: Thu, 8 Jun 2023 11:05:30 +0200 From: Greg Kroah-Hartman To: Ard Biesheuvel Cc: Richard Fontana , Bagas Sanjaya , Herbert Xu , "David S. Miller" , Franziska Naepelt , Linux SPDX Licenses , Linux Kernel Janitors , Linux Crypto , Linux Kernel Mailing List , David Howells , Jarkko Sakkinen , Dan Carpenter , Alexander Kjeldaas , Herbert Valerio Riedel , Kyle McMartin , "Adam J . Richter" , Dr Brian Gladman , Stephan Mueller Subject: Re: [PATCH 1/8] crypto: Convert dual BSD 3-Clause/GPL 2.0 boilerplate to SPDX identifier Message-ID: <2023060850-shakable-dynamite-c4ff@gregkh> References: <20230607053940.39078-10-bagasdotme@gmail.com> <20230607053940.39078-11-bagasdotme@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Jun 08, 2023 at 10:37:33AM +0200, Ard Biesheuvel wrote: > On Wed, 7 Jun 2023 at 16:38, Richard Fontana wrote: > > > > On Wed, Jun 7, 2023 at 1:42 AM Bagas Sanjaya wrote: > > > > > > Replace license boilerplate for dual BSD-3-Clause/GPL 2.0 (only or > > > later) with corresponding SPDX license identifier. > > > > This is at least the fourth or fifth time (I'm losing track) where you > > have incorrectly assumed a particular non-GPL license text matches a > > particular SPDX identifier without (apparently) checking. > > > > What exactly does 'checking' entail here? There is no guidance in > Documentation/process/license-rules.rst on how to perform this > comparison. > > Also, checkpatch now complains about missing SPDX identifiers, which > is what triggered this effort. Should it stop doing that? > > > Bagas, I urge that you learn more about the nature of SPDX identifiers > > before submitting any further patches at least involving replacement > > of non-GPL notices with SPDX identifiers. For this unprecedented > > license notice replacement initiative to have any legitimacy it must > > attempt to apply SPDX identifiers correctly. > > > > Since we're in language pedantic mode: it must do more than attempt, > it must apply them correctly, period. > > Arguably, this is an 'attempt to apply SPDX identifiers correctly' on > Bagas's part, which apparently falls short (and I may be guilty of the > same for some arch crypto code) > > So what is the ambition here: do we just leave the ambiguous ones as-is? I recommend yes, leave them as-is until the legal people who actually care about having SPDX lines in all of the files take the time to do the work to resolve these issues. Remember, they are the ones asking for it, no need for us to do their work for them :) thanks, greg k-h