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=-5.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 9DBD5C74A21 for ; Wed, 10 Jul 2019 13:41:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 484DC20651 for ; Wed, 10 Jul 2019 13:41:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=jilayne.com header.i=@jilayne.com header.b="sQouqgxx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726098AbfGJNlH (ORCPT ); Wed, 10 Jul 2019 09:41:07 -0400 Received: from mx1-c1.supremebox.com ([198.23.53.215]:37943 "EHLO mx1.supremebox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726080AbfGJNlG (ORCPT ); Wed, 10 Jul 2019 09:41:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jilayne.com ; s=default; h=Message-Id:In-Reply-To:To:References:Date:Subject:Mime-Version :Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jYKE97bK5LKWHN6XaTs+TD+SmtYE6/HBy8Kwb5QQnuM=; b=sQouqgxxvHMy2ZZus/jZ1QnN+9 1A+fi42ayxlVamGTDIArWxR8Kp+pNqsWucchx7sDU8/a6QSMi3yh+chIlPMIt3Meaavf/Bxyj1lfj tZ6jZh4UBFd8AknaG3yL2IWdZpxp70I1e7gzCDnCi0JrE/nE1DzUdfeYBJeBPuu+zXO8=; Received: from 184-96-235-43.hlrn.qwest.net ([184.96.235.43] helo=[192.168.0.12]) by mx1.supremebox.com with esmtpa (Exim 4.89) (envelope-from ) id 1hlCqG-0005SU-1P for linux-spdx@vger.kernel.org; Wed, 10 Jul 2019 13:41:04 +0000 From: J Lovejoy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: efficacy of MODULE_LICENSE Date: Wed, 10 Jul 2019 07:41:03 -0600 References: <1B1C3AD5-9222-40A8-A0D2-7BF7CE1181DF@jilayne.com> <20190710093806.GA22916@kroah.com> To: linux-spdx@vger.kernel.org In-Reply-To: <20190710093806.GA22916@kroah.com> Message-Id: <789E72F5-FAF6-4E64-8CA8-471EE00BF865@jilayne.com> X-Mailer: Apple Mail (2.3445.104.11) X-Sender-Ident-agJab5osgicCis: opensource@jilayne.com Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org > On Jul 10, 2019, at 3:38 AM, Greg KH = wrote: >=20 > On Tue, Jul 09, 2019 at 10:28:59PM -0600, J Lovejoy wrote: >> Hi all, >>=20 >> We seem to have gone a bit quiet recently! Hopefully that=E2=80=99s = just a >> symptom of nicer weather and holiday season, but we can still pick up >> some momentum :) >>=20 >> I wanted to get your input on the MODULE_LICENSE tag, which I have >> found to be a bit vexing in some instances. I am finding examples >> where there is a clearly identifiable license in the file, for = example >> ISC, and then the MODULE_LICENSE tag is something like "Dual = BSD/GPL=E2=80=9D. >> There is absolutely no other reference to GPL whatsoever (or any BSD >> variant for that matter). >=20 > MODULE_LICENSE is used by the kernel itself, at runtime, to determine > the "license" of the module that is being loaded into it. >=20 > At that point in time, it is a dual-licensed chunk of code, as it > incorporated gplv2 bits into it in order to create that module image, > right? by dual-licensed, I=E2=80=99m assuming you mean conjunctive (=E2=80=9CAND=E2= =80=9D) by way of the incorporated GPL-2.0 bits into the ISC-licensed = file, then yes, that sounds right. But this file, by itself, is just ISC for the license as the = =E2=80=9Cincorporating=E2=80=9D part only happens at runtime, right? so for purposes of identifying the license of the file (and if someone = wanted to re-use that file elsewhere), ISC would be the operative = license info. >=20 >> Based on my understanding of >> = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/in= clude/linux/module.h#n172 >> = >> - the MODULE_LICENSE info was never meant to be definitive license >> info, but seemingly more of an approximation. I=E2=80=99m wondering = if others >> have a different view? >=20 > It is used at runtime to determine if the module has access to some > types of kernel symbols or not. >=20 > It can also be used at any time to extract the license from the module > image on a disk, you can see this by running the 'modinfo' program on > any kernel module: > $ modinfo visor | grep license > license: GPL v2 =E2=80=9Cextract the license=E2=80=9D is a bit concerning here - as I = take that to mean the extraction part is the MODULE_LICENSE info, which = isn=E2=80=99t really accurate.=20 or is the intent here not necessarily accuracy, but a threshold = determination that it=E2=80=99s open source/compatible (and not = proprietary or something like that)? >=20 >> More specifically - where we have specific license match (like the >> example above) - we can add the appropriate SPDX identifier, but if = we >> leave the MODULE_LICENSE info, I suspect that scanners will pick that >> up and report a mix of licensing info (e.g., ISC, BSD, GPL, as in my >> above example), which kind of brings us to the same place we are now. >> Should we also remove the MODULE_LICENSE tag where it contradicts the >> actual license info in terms of an exact license match (i.e., there = is >> nothing to match to GPL here, other than the MODULE_LICENSE tag, but >> there is an exact match to a different license, ISC, in this case). >=20 > 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. >=20 > MODULE_LICENSE covers the "resulting image" of combining many = different > files that can have different SPDX-identified licenses in them. >=20 > Does this help any? 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? maybe this last question is more of a question for the tooling folks? or maybe the answer is yes, in a strict scanning sense, but because = MODULE_LICENSE is used for a different purpose, so be it=E2=80=A6 = 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)=20 thanks, Jilayne