linux-kernel - Re: [patch V4 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Nov 2017 19:11:41 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Mauro Carvalho Chehab <mchehab@...pensource.com>
cc:     LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        Andrew Morton <akpm@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@....de>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Rob Herring <rob.herring@...aro.org>,
        Jonas Oberg <jonas@...e.org>, Joe Perches <joe@...ches.com>,
        linux-xfs@...r.kernel.org,
        Charlemagne Lasse <charlemagnelasse@...il.com>,
        Carmen Bianca Bakker <carmenbianca@...e.org>
Subject: Re: [patch V4 01/11] Documentation: Add license-rules.rst to describe
 how to properly identify file licenses

Mauro,

On Fri, 17 Nov 2017, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Nov 2017 11:00:33 +0100 (CET)
> Thomas Gleixner <tglx@...utronix.de> escreveu:
> 
> > Subject: Documentation: Add license-rules.rst to describe how to properly identify file licenses
> > From: Thomas Gleixner <tglx@...utronix.de>
> > Date: Fri, 10 Nov 2017 09:30:00 +0100
> > 
> > Add a file to the Documentation directory to describe how file licenses
> > should be described in all kernel files, using the SPDX identifier, as well
> > as where all licenses should be in the kernel source tree for people to
> > refer to (LICENSES/).
> > 
> > Thanks to Kate, Greg and Jonathan for review and editing and Jonas for the
> > suggestions concerning the meta tags in the licenses files.
> > 
> > Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> 
> The document itself looks good, but I think it should also mention
> what would be the expected values for the MODULE_LICENSE() macro and
> how each license would be mapped into it.
> 
> Right now, include/linux/module.h says:
> 
> /*
>  * The following license idents are currently accepted as indicating free
>  * software modules
>  *
>  *	"GPL"				[GNU Public License v2 or later]
>  *	"GPL v2"			[GNU Public License v2]
>  *	"GPL and additional rights"	[GNU Public License v2 rights and more]
>  *	"Dual BSD/GPL"			[GNU Public License v2
>  *					 or BSD license choice]
>  *	"Dual MIT/GPL"			[GNU Public License v2
>  *					 or MIT license choice]
>  *	"Dual MPL/GPL"			[GNU Public License v2
>  *					 or Mozilla license choice]
>  *
>  * The following other idents are available
>  *
>  *	"Proprietary"			[Non free products]
>  *
>  * There are dual licensed components, but when running with Linux it is the
>  * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
>  * is a GPL combined work.
>  *
>  * This exists for several reasons
>  * 1.	So modinfo can show license info for users wanting to vet their setup
>  *	is free
>  * 2.	So the community can ignore bug reports including proprietary modules
>  * 3.	So vendors can do likewise based on their own policies
>  */
> #define MODULE_LICENSE(_license) MODULE_INFO(license, _license)
> 
> In thesis, for every SPDX property at C or assembler files, we should have
> a mapping into one of those MODULE_LICENSE().

I know. This is on the list of things which need to be addressed. The
module license tags are a mess on their own and I have yet to come up with
something smart to make this consistent.

Whatever I came up with so far requires postprocessing.

For files which have MODULE_LICENSE("...."):

   1) Grab the SPDX identifier from the source file

   2) Check whether the module license string is matching the SPDX license
      id. This is limited because the module license strings are pretty
      restricted.

   2) Store the SPDX license id string in a separate module info variable

Introcude a MODULE_LICENSE_SPDX macro which flags the module info storage
as 'SPDXIFY' and let the postprocessor do:

   1) Grab the SPDX identifier from the source file

   2) Map it to the "known" module license string and store both in module
      info.

That way tools can get access to the SPDX identifier and start to support it.

I refrained from documenting anything in that area yet, because we really
need to sit down and figure out a solution first.

It's on that huge thingy which is append only, aka. todo list.

Thanks,

	tglx