From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09247C74A36 for ; Wed, 10 Jul 2019 18:56:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D8BC920838 for ; Wed, 10 Jul 2019 18:56:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727315AbfGJS4I (ORCPT ); Wed, 10 Jul 2019 14:56:08 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:48417 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727287AbfGJS4I (ORCPT ); Wed, 10 Jul 2019 14:56:08 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hlHl1-0000e8-C5; Wed, 10 Jul 2019 20:55:59 +0200 Date: Wed, 10 Jul 2019 20:55:58 +0200 (CEST) From: Thomas Gleixner To: "Zavras, Alexios" cc: J Lovejoy , "linux-spdx@vger.kernel.org" Subject: RE: efficacy of MODULE_LICENSE In-Reply-To: <27E3B830FA35C7429A77DAEEDEB7344782A9DDD3@IRSMSX103.ger.corp.intel.com> Message-ID: References: <1B1C3AD5-9222-40A8-A0D2-7BF7CE1181DF@jilayne.com> <20190710093806.GA22916@kroah.com> <789E72F5-FAF6-4E64-8CA8-471EE00BF865@jilayne.com> <27E3B830FA35C7429A77DAEEDEB7344782A9DDD3@IRSMSX103.ger.corp.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1821756490-1562784959=:1758" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1821756490-1562784959=:1758 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Wed, 10 Jul 2019, Zavras, Alexios wrote: > J Lovejoy wrote: > >> On Jul 10, 2019, at 3:38 AM, Greg KH wrote: > >> On Tue, Jul 09, 2019 at 10:28:59PM -0600, J Lovejoy wrote: > >>> - the MODULE_LICENSE info was never meant to be definitive license > >>> info, but seemingly more of an approximation. I’m wondering if > >>> others have a different view? > [...] > >> MODULE_LICENSE predated SPDX by a decade or so, and was designed to > >> solve a totally different use case. I would not try to mix the two, > >> or infer one from the other. > [...] > > yes. And I can understand the different use case, I guess my concern/question > > is does the existence of MODULE_LICENSE info that sort of contradicts > > the actual license info for the file (when looking just at that file, > > not the combined/resulting image) frustrate the goal of having clean licensing > > info for when people run scans over the kernel? > > > > or maybe the answer is yes, in a strict scanning sense, but because > > MODULE_LICENSE is used for a different purpose, so be it… scanners > > are going to pick it up and people will just have to understand the above? > > > > mostly, I want to confirm that the SPDX identifier for a file in this case > > can simply be: ISC (not BSD, or GPL) > > I think we should all agree that MODULE_LICENSE was never intended > to actually record the exact license -- only to give some information > on the "GPL-ness" of a module. The naming is unfortunate, but that's > historical decisions for you and we have to live with it. > > Scanning tools should not rely on it (and its limited set of possible values) > to determine actual licenses of modules not integrated in the kernel -- > and an SPDX line with "ISC" (or whatever) should always be the determining input. > > Do we need to document this anywhere to be absolutely clear? The kernel Documentation of license rules, which also defines the usage of SPDX identifiers has a section about Module License: https://www.kernel.org/doc/html/latest/process/license-rules.html#id1 Is that clear enough? Thanks, tglx --8323329-1821756490-1562784959=:1758--