archive mirror
 help / color / mirror / Atom feed
From: J Lovejoy <>
Subject: Re: efficacy of MODULE_LICENSE
Date: Wed, 10 Jul 2019 07:41:03 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> On Jul 10, 2019, at 3:38 AM, Greg KH <> wrote:
> 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?

by dual-licensed, I’m assuming you mean conjunctive (“AND”) 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 “incorporating” 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.
>> Based on my understanding of
>> <>
>> - 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

“extract the license” is a bit concerning here - as I take that to mean the extraction part is the MODULE_LICENSE info, which isn’t really accurate. 
or is the intent here not necessarily accuracy, but a threshold determination that it’s open source/compatible (and not proprietary or something like that)?
>> 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?

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… 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) 


  reply	other threads:[~2019-07-10 13:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10  4:28 efficacy of MODULE_LICENSE J Lovejoy
2019-07-10  9:38 ` Greg KH
2019-07-10 13:41   ` J Lovejoy [this message]
2019-07-10 14:09     ` Armijn Hemel - Tjaldur Software Governance Solutions
2019-07-10 14:12     ` Zavras, Alexios
2019-07-10 18:55       ` Thomas Gleixner
2019-07-10 16:06     ` Greg KH

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:

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

  git send-email \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).