Linux-SPDX Archive on lore.kernel.org
 help / color / Atom feed
* efficacy of MODULE_LICENSE
@ 2019-07-10  4:28 J Lovejoy
  2019-07-10  9:38 ` Greg KH
  0 siblings, 1 reply; 7+ messages in thread
From: J Lovejoy @ 2019-07-10  4:28 UTC (permalink / raw)
  To: linux-spdx

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

Based on my understanding of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h#n172 <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?

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


Thanks,
Jilayne

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: efficacy of MODULE_LICENSE
  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
  0 siblings, 1 reply; 7+ messages in thread
From: Greg KH @ 2019-07-10  9:38 UTC (permalink / raw)
  To: J Lovejoy; +Cc: linux-spdx

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: efficacy of MODULE_LICENSE
  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
                       ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: J Lovejoy @ 2019-07-10 13:41 UTC (permalink / raw)
  To: linux-spdx



> 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:
>> 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
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h#n172
>> <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

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

thanks,
Jilayne


^ permalink raw reply	[flat|nested] 7+ messages in thread

* efficacy of MODULE_LICENSE
  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 16:06     ` Greg KH
  2 siblings, 0 replies; 7+ messages in thread
From: Armijn Hemel - Tjaldur Software Governance Solutions @ 2019-07-10 14:09 UTC (permalink / raw)
  To: J Lovejoy, linux-spdx

[resending, as vger.kernel.org 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:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/romfs/super.c

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/jffs2/super.c

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

-- 
Armijn Hemel, MSc
Tjaldur Software Governance Solutions


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: efficacy of MODULE_LICENSE
  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
  2019-07-10 16:06     ` Greg KH
  2 siblings, 1 reply; 7+ messages in thread
From: Zavras, Alexios @ 2019-07-10 14:12 UTC (permalink / raw)
  To: J Lovejoy, linux-spdx

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?


-- zvr
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: efficacy of MODULE_LICENSE
  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 16:06     ` Greg KH
  2 siblings, 0 replies; 7+ messages in thread
From: Greg KH @ 2019-07-10 16:06 UTC (permalink / raw)
  To: J Lovejoy; +Cc: linux-spdx

On Wed, Jul 10, 2019 at 07:41:03AM -0600, 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:
> >> 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
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h#n172
> >> <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
> 
> “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. 

It seems pretty accurate for the aggregated work that is the object file
that is loaded into the kernel, right?  How is it not "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)?

That is what we use it for, yes.

It really is a yes/no test that we use to allow access to specific
internal kernel symbols or not.

But, it's also useful for when companies "lie" with that string.
Lawyers generally frown when technical people at a company try to do
"tricks" and fool the kernel by messing with that string.  I know at
least 2 VERY major and huge companies[1] that have turned their
treatment around for this very reason when they realized what they were
"caught" doing, and now are big contributors to our kernel community.

So it is a nice tool to be able to use at times :)

> >> 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?

It shouldn't, which is why we clarified a number of these strings
recently with the documentation.  What else needs to be adjusted to make
this more accurate for what you want to use when scanning a binary
image?

Remember, that's what this is used for, the binary image, not for the
individual files.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: efficacy of MODULE_LICENSE
  2019-07-10 14:12     ` Zavras, Alexios
@ 2019-07-10 18:55       ` Thomas Gleixner
  0 siblings, 0 replies; 7+ messages in thread
From: Thomas Gleixner @ 2019-07-10 18:55 UTC (permalink / raw)
  To: Zavras, Alexios; +Cc: J Lovejoy, linux-spdx

[-- 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2019-07-10 16:06     ` Greg KH

Linux-SPDX Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-spdx/0 linux-spdx/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-spdx linux-spdx/ https://lore.kernel.org/linux-spdx \
		linux-spdx@vger.kernel.org linux-spdx@archiver.kernel.org
	public-inbox-index linux-spdx


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-spdx


AGPL code for this site: git clone https://public-inbox.org/ public-inbox