All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Zavras, Alexios" <alexios.zavras@intel.com>
Cc: J Lovejoy <opensource@jilayne.com>,
	"linux-spdx@vger.kernel.org" <linux-spdx@vger.kernel.org>
Subject: RE: efficacy of MODULE_LICENSE
Date: Wed, 10 Jul 2019 20:55:58 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1907102054400.1758@nanos.tec.linutronix.de> (raw)
In-Reply-To: <27E3B830FA35C7429A77DAEEDEB7344782A9DDD3@IRSMSX103.ger.corp.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]

On Wed, 10 Jul 2019, Zavras, Alexios wrote:
> J Lovejoy wrote:
> >> On Jul 10, 2019, at 3:38 AM, Greg KH <gregkh@linuxfoundation.org> 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

  reply	other threads:[~2019-07-10 18:56 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
2019-07-10 14:12     ` Zavras, Alexios
2019-07-10 18:55       ` Thomas Gleixner [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=alpine.DEB.2.21.1907102054400.1758@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=alexios.zavras@intel.com \
    --cc=linux-spdx@vger.kernel.org \
    --cc=opensource@jilayne.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.