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=-7.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 1420EC73C7C for ; Wed, 10 Jul 2019 09:38:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DB5C22084B for ; Wed, 10 Jul 2019 09:38:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562751490; bh=TweQwngFTushi7uejUx9bNsztf3LPlL2LxB8vUGLdJY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=JXNdChrG3Ux4BFKfNSPzcO++yqKrsfp+rNBwXfJHs1N2IOgG/gTBN4wVsJnYAK6st eZFBwqkhPipwYr5xz5VPUo0Ex81mj1tJIy9FfT5iYTI2pnu6oS2IRqKgog35LVdOof J2+SmxCcRzxD+wzuspJWiWgJFAZe27MRmxW/P46I= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727030AbfGJJiK (ORCPT ); Wed, 10 Jul 2019 05:38:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:38410 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726097AbfGJJiK (ORCPT ); Wed, 10 Jul 2019 05:38:10 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D07392064B; Wed, 10 Jul 2019 09:38:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562751489; bh=TweQwngFTushi7uejUx9bNsztf3LPlL2LxB8vUGLdJY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HI7fEYrtkiA8e2ypPYP6743abCufw8dmmmuT19VVVsy9mRCmJkWEvAeLDiBmeeZYZ xTjDM6mA/2/DH4Q07HH0DrD/V9gE41IJE2L+N1hRujMBb+DkUBSMyDIphLN/F8Qwdp n2mLJB/BeOyt7RHGoTe6y6NwWuyCyA7IfGJ3HeI4= Date: Wed, 10 Jul 2019 11:38:06 +0200 From: Greg KH To: J Lovejoy Cc: linux-spdx@vger.kernel.org Subject: Re: efficacy of MODULE_LICENSE Message-ID: <20190710093806.GA22916@kroah.com> References: <1B1C3AD5-9222-40A8-A0D2-7BF7CE1181DF@jilayne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1B1C3AD5-9222-40A8-A0D2-7BF7CE1181DF@jilayne.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org On Tue, Jul 09, 2019 at 10:28:59PM -0600, J Lovejoy wrote: > Hi all, > > We seem to have gone a bit quiet recently! Hopefully that’s just a > symptom of nicer weather and holiday season, but we can still pick up > some momentum :) > > 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”. > There is absolutely no other reference to GPL whatsoever (or any BSD > variant for that matter). MODULE_LICENSE is used by the kernel itself, at runtime, to determine the "license" of the module that is being loaded into it. 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? > Based on my understanding of > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h#n172 > > - 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? It is used at runtime to determine if the module has access to some types of kernel symbols or not. 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 > 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). 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. MODULE_LICENSE covers the "resulting image" of combining many different files that can have different SPDX-identified licenses in them. Does this help any? thanks, greg k-h