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  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:   Wed, 22 Nov 2017 11:35:28 -0200
From:   Mauro Carvalho Chehab <>
To:     Christoph Hellwig <>
Cc:     Thomas Gleixner <>,
        LKML <>,
        Linus Torvalds <>,
        Andrew Morton <>,
        Jonathan Corbet <>,
        Kate Stewart <>,
        Philippe Ombredanne <>,
        Greg Kroah-Hartman <>,
        Russell King <>,
        Rob Herring <>,
        Jonas Oberg <>, Joe Perches <>,,
        Charlemagne Lasse <>,
        Carmen Bianca Bakker <>
Subject: Re: [patch V4 01/11] Documentation: Add license-rules.rst to
 describe how to properly identify file licenses

Em Wed, 22 Nov 2017 14:23:29 +0100
Christoph Hellwig <> escreveu:

> On Wed, Nov 22, 2017 at 09:51:17AM -0200, Mauro Carvalho Chehab wrote:
> > Also, one may forget that headers use /**/ and end by doing the wrong
> > thing, as a common practice is to just cut-and-paste the same copyright
> > header on both C and H files at development time.  
> Yes.
> > Make headers_install could replace such macros by SPDX comments when
> > installing on userspace.  
> Agreed.  Or for that matter we could simply stick to the comment version
> for UAPI headers only, and have a macro for everything else.
> > >    - Breaks in assembly, boot and other special source files. There was no
> > >      easy solution to that and the result would have been to have macros in
> > >      some files and not in others.  
> > 
> > At the end, we have different markups, depending on the file type.
> > I guess the main problem of using a macro is that a module composed
> > by multiple C files will end by defining it multiple times. Not sure
> > if gcc would do the right thing on grouping everything altogether
> > and producing the right equivalent to MODULE_LICENSE().  
> We'd basically need to add a new entry to a section, similar to how
> say __setup works in the core kernel.  But I think the important bit
> is to start with a macro now, even if it has zero functionality to
> start with - at least that enables us to fill the functionality once
> needed.
> > Also, at least on media, I found cases where the same module
> > has multiple licenses, e. g. some files that are grouped together on
> > a module are GPL v2 only, while others are GPL v2+.  
> A module always has the least permissive license of all files.

Yes, but I'm not sure how a macro would work. I mean, if a driver
foo has, let's say:

	foo-core.h: FILE_LICENSE_SPDX("SPDX-License-Identifier: GPL-2.0");
	foo-core.c: FILE_LICENSE_SPDX("SPDX-License-Identifier: GPL-2.0");
	foo-driver.c: FILE_LICENSE_SPDX("SPDX-License-Identifier: GPL-2.0+");

I can't see how to write such macro in a way that it would be
discovering the license interception.


Powered by blists - more mailing lists