archive mirror
 help / color / mirror / Atom feed
From: Armijn Hemel - Tjaldur Software Governance Solutions  <>
To: J Lovejoy <>,
Subject: efficacy of MODULE_LICENSE
Date: Wed, 10 Jul 2019 16:09:39 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[resending, as doesn't always like what my mail client
is sending]

On 7/10/19 3:41 PM, J Lovejoy wrote:
>>> 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) 

I know that FOSSology will also report what is in MODULE_LICENSE, but
there are files in the Linux kernel where the authors have acknowledged
it does not necessarily reflect the actual license:

I might go too far saying that the scope of this tag would be the
derivative work (the Linux kernel binary), but that is usually how I
interpret it.


Armijn Hemel, MSc
Tjaldur Software Governance Solutions

  reply	other threads:[~2019-07-10 14:09 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
2019-07-10 14:09     ` Armijn Hemel - Tjaldur Software Governance Solutions [this message]
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).