[GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Greg KH]

[resend without the full diffstat as lkml and some email systems didn't
 like to see emails with 12k lines...]

Hi,

As discussed at the Maintainers Summit last week, here is a pull request
that adds some SPDX license identifiers to three different classes of
files:
	- files with no license identifiers at all, but not uapi files
	- uapi files with no license identifiers at all
	- uapi files with existing license identifiers

This "only" touched 1/6 of the files in the tree.  The remaining files
will be dealt with on a subsystem-by-subsystem basis over the next few
kernel releases.

The full methodology of how these files were determined, and how the
work was done is down below in the signed tag, and in the first commit
of the series.

These patches have a "new" timestamp, a few hours old, only because we
have revised and rewritten the changelog text many times based on lots
of people's inputs (lawyers included.)  The patches themselves are not
"new" at all and were auto-generated as described below and are based on
4.14-rc6.

Note, we had to use /* */ as the comment marker for the .h files, as
there are just too many .h files being included into .S files to be able
to try to identify which is which, so we could not use //, unlike the .c
files.

These have been through 0-day testing with no reported problems, as well
as my build system and Thomas's build system.

thanks,

greg k-h

The following changes since commit bb176f67090ca54869fc1262c913aa69d2ede070:

  Linux 4.14-rc6 (2017-10-23 06:49:47 -0400)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ tags/spdx_identifiers-4.14-rc8

for you to fetch changes up to e2be04c7f9958dde770eeb8b30e829ca969b37bb:

  License cleanup: add SPDX license identifier to uapi header files with a license (2017-11-02 11:20:11 +0100)

----------------------------------------------------------------
License cleanup: add SPDX license identifiers to some files

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

----------------------------------------------------------------
Greg Kroah-Hartman (3):
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license
      License cleanup: add SPDX license identifier to uapi header files with no license
      License cleanup: add SPDX license identifier to uapi header files with a license

 Kbuild                                                                   | 1 +
 Kconfig                                                                  | 1 +
 Makefile                                                                 | 1 +

[12585 files having 1 line added snipped to make vger happy.  If anyone
 wants the full the full diffstat, I can send it off-list.]

 virt/kvm/coalesced_mmio.c                                                | 1 +
 virt/kvm/coalesced_mmio.h                                                | 1 +
 virt/kvm/vfio.h                                                          | 1 +
 12591 files changed, 12591 insertions(+)

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Masahiro Yamada]

Hi.


2017-11-03 0:16 GMT+09:00 Greg KH <gregkh@linuxfoundation.org>:
> [resend without the full diffstat as lkml and some email systems didn't
>  like to see emails with 12k lines...]
>
> Hi,
>
> As discussed at the Maintainers Summit last week, here is a pull request
> that adds some SPDX license identifiers to three different classes of
> files:
>         - files with no license identifiers at all, but not uapi files
>         - uapi files with no license identifiers at all
>         - uapi files with existing license identifiers
>
> This "only" touched 1/6 of the files in the tree.  The remaining files
> will be dealt with on a subsystem-by-subsystem basis over the next few
> kernel releases.
>
> The full methodology of how these files were determined, and how the
> work was done is down below in the signed tag, and in the first commit
> of the series.
>
> These patches have a "new" timestamp, a few hours old, only because we
> have revised and rewritten the changelog text many times based on lots
> of people's inputs (lawyers included.)  The patches themselves are not
> "new" at all and were auto-generated as described below and are based on
> 4.14-rc6.
>
> Note, we had to use /* */ as the comment marker for the .h files, as
> there are just too many .h files being included into .S files to be able
> to try to identify which is which, so we could not use //, unlike the .c
> files.

Please let me ask some questions.

Sorry, I am completely missing the discussion other people have had.

I dug the ML, and I was able to find some parts of
the process of the discussion.


[1]
First, I wondered why *.c files differentiated by //.

According to the following, it is what Linus suggested to make it stand out.
https://patchwork.kernel.org/patch/10016201/


[2]
In the first patch for USB file conversion,
https://patchwork.kernel.org/patch/10016189/
it embedded the SPDX tag in the comment block.

In later version of the tool,
the tag line was moved to the top of each file.
So, probably this is the preferred style... Correct?



I am happy to follow the preferred style if any
for my future patches.  I just want to be sure.


Several DT files use SPDX.  For example,
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/mt7622.dtsi

If SPDX tag at the top line is preferred, should existing files be fixed?


Some projects already adopted SPDX, and the tag in the copyright block
looks nice (at least to me)...
https://github.com/u-boot/u-boot/blob/master/common/board_f.c
https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/bl31_main.c




-- 
Best Regards
Masahiro Yamada

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Linus Torvalds]

On Thu, Nov 2, 2017 at 10:09 AM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> I am happy to follow the preferred style if any
> for my future patches.  I just want to be sure.

So in general, the _hope_ is that we can just end up replacing
existing boilerplate comments with that single line SPDX comment
(using "//" in *.[ch] files, but obviously some other kinds of files
end up having a different comment character, typically '#').

In scripts, the single-line comment may need to be the second line,
simply due to file format requirements (ie the whole "#!" thing needs
to be the first line).

And it's important to notice that while adding a SPDX line should not
really be controversial (as long as you get the license right, of
course - Greg&co have the CSV files for everything, in case you want
to check things you maintain), before removing the boiler-plate you
really need to feel like you "own" the file.

So while I'd personally love to just get rid of existing (usually
nasty and bad) copyright templates in favor of just the one-liner SPDX
notice, that can generally not be automated without maintainer
permission.

And while this is likely really obvious, I'd like to note that at no
point would we remove the individual and company _names_ from
copyright notices. But the silly repeated boiler-plate that just
states the license itself is certainly redundant when SPDX lines are
added. So that's the part that I would love to see people at least
consider removing.

And yes, feel free to replace block comments with // while at it.

> Several DT files use SPDX.  For example,
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/mt7622.dtsi
>
> If SPDX tag at the top line is preferred, should existing files be fixed?

I don't think it's a huge deal, and wouldn't touch existing files
unless you have some other independent reason to do so.

The real reason _I_ personally would like to see at least all the new
SPDX lines to go at the very top of the file is that every time when
we have some kind of ambiguity about placement, we end up with
multiple cases, and then people don't notice when merging, and you end
up having two - or you just end up having unnecessary merge conflicts
because two different people picked two different choices).

So to me, the "just put it as the first syntactically possible line,
and just always use the same comment format" is simply to avoid
unnecessary arguments/conflicts about which of any number of ways you
*could* do it.

We already have something like 700 different versions of the same
silly copyright license boiler-plate due to typos, whitespace
differences, comment style choices, yadda yadda. Let's avoid that mess
by just picking _one_ single format and placement for the SPDX line.

              Linus

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Greg KH]

On Fri, Nov 03, 2017 at 02:09:02AM +0900, Masahiro Yamada wrote:
> Hi.
> 
> 
> 2017-11-03 0:16 GMT+09:00 Greg KH <gregkh@linuxfoundation.org>:
> > [resend without the full diffstat as lkml and some email systems didn't
> >  like to see emails with 12k lines...]
> >
> > Hi,
> >
> > As discussed at the Maintainers Summit last week, here is a pull request
> > that adds some SPDX license identifiers to three different classes of
> > files:
> >         - files with no license identifiers at all, but not uapi files
> >         - uapi files with no license identifiers at all
> >         - uapi files with existing license identifiers
> >
> > This "only" touched 1/6 of the files in the tree.  The remaining files
> > will be dealt with on a subsystem-by-subsystem basis over the next few
> > kernel releases.
> >
> > The full methodology of how these files were determined, and how the
> > work was done is down below in the signed tag, and in the first commit
> > of the series.
> >
> > These patches have a "new" timestamp, a few hours old, only because we
> > have revised and rewritten the changelog text many times based on lots
> > of people's inputs (lawyers included.)  The patches themselves are not
> > "new" at all and were auto-generated as described below and are based on
> > 4.14-rc6.
> >
> > Note, we had to use /* */ as the comment marker for the .h files, as
> > there are just too many .h files being included into .S files to be able
> > to try to identify which is which, so we could not use //, unlike the .c
> > files.
> 
> Please let me ask some questions.
> 
> Sorry, I am completely missing the discussion other people have had.
> 
> I dug the ML, and I was able to find some parts of
> the process of the discussion.
> 
> 
> [1]
> First, I wondered why *.c files differentiated by //.
> 
> According to the following, it is what Linus suggested to make it stand out.
> https://patchwork.kernel.org/patch/10016201/

Yes, that is why.

> [2]
> In the first patch for USB file conversion,
> https://patchwork.kernel.org/patch/10016189/
> it embedded the SPDX tag in the comment block.
> 
> In later version of the tool,
> the tag line was moved to the top of each file.
> So, probably this is the preferred style... Correct?

Right now, it doesn't really matter, the scanning tools can handle it
anywhere.  I just tried to make it more "nicer looking" for the USB
files.

For the automatic-conversion scripts, putting it at the top of the file
was the easiest thing to do.  We do have scripts to put it at the end of
the original comment block, but that can happen later for those files
that do have licenses already.  For those that don't (like this patchset
addresses), putting it at the top is the easiest.

> I am happy to follow the preferred style if any
> for my future patches.  I just want to be sure.
> 
> 
> Several DT files use SPDX.  For example,
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/mt7622.dtsi
> 
> If SPDX tag at the top line is preferred, should existing files be fixed?

It doesn't really matter.

> Some projects already adopted SPDX, and the tag in the copyright block
> looks nice (at least to me)...
> https://github.com/u-boot/u-boot/blob/master/common/board_f.c
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl31/bl31_main.c

Yes, it looks "nicer" there as well, feel free to put it anywhere in
files that you maintain, and I'll be happy :)

thanks,

greg k-h

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Linus Torvalds]

On Thu, Nov 2, 2017 at 10:25 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So to me, the "just put it as the first syntactically possible line,
> and just always use the same comment format" is simply to avoid
> unnecessary arguments/conflicts about which of any number of ways you
> *could* do it.

Side note: I'm not going to enforce it, it's just a personal wish to
hopefully make my life easier.

This pull request from Greg already has different comment formats for
different files. I pulled it despite that.

                  Linus

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Greg KH]

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

On Thu, Nov 02, 2017 at 10:32:17AM -0700, Linus Torvalds wrote:
> On Thu, Nov 2, 2017 at 10:25 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So to me, the "just put it as the first syntactically possible line,
> > and just always use the same comment format" is simply to avoid
> > unnecessary arguments/conflicts about which of any number of ways you
> > *could* do it.
> 
> Side note: I'm not going to enforce it, it's just a personal wish to
> hopefully make my life easier.
> 
> This pull request from Greg already has different comment formats for
> different files. I pulled it despite that.

It should have been consistent, everything except the script files went
as the first line of the file.

For .h files, we had to use /* */
For .c files, we used //
For scripts, and asm, we used the comment "marker" that was used in the
file already.

Attached is the script written by Thomas and tweaked by me to do all of
the tag insertion based on a csv file, it picks the format based on the
name and content of the file.

thanks,

greg k-h

[-- Attachment #2: spdxtags2.py --]
[-- Type: text/x-python, Size: 3311 bytes --]

#!/usr/bin/env python
#
import sys
import os

def insert_at(srclines, pos, tag, style):
    if style == '/*':
        srclines.insert(pos, '/* SPDX-License-Identifier: %s */\n' %tag)
    else:
        srclines.insert(pos, '%s SPDX-License-Identifier: %s\n' %(style, tag))
    return True

def handle_c(srclines, tag):
    return insert_at(srclines, 0, tag, '//')

def is_script(srclines):
    for line in srclines:
        line.lstrip();
        if line.startswith('#!'):
            return True;
    return False;

def handle_asm(srclines, tag):
    # Stupid search for a proper style to comment the SPDX tag
    pos = 0
    style = None
    for line in srclines:
        pos += 1
        line.lstrip();
        if line.startswith(';;;'):
            style = ';;;'
        elif line.startswith(';;'):
            style = ';;'
        elif line.startswith(';'):
            style = ';'
        elif line.startswith('|'):
            style = '|'
        elif line.startswith('!'):
            style = '!'
        elif line.startswith('//'):
            style = '//'
        elif line.find("/*") >= 0:
            style = '/*'
        else:
            # default to /* if we have no clue
            style = '/*'
        return insert_at(srclines, 0, tag, style)
    return False

def handle_sh(srclines, tag):
    return insert_at(srclines, 1, tag, '#')

tf = open(sys.argv[1])

for entry in tf.readlines():

    if len(entry.strip()) == 0:
        continue

    nr, fname, tag = entry.strip().split(',')
    # FIXME: Use a proper encoder
    fname = fname.replace('%2C',',')
    fname = fname.replace('%2B','+')
    if tag == 'NOTAG':
        print("Skipping %s" %fname)
        continue

    if not os.path.isfile(fname):
        print("FAIL: File %s does not exist anymore" %fname)
        continue

    bname = os.path.basename(fname)
    
    srclines = open(fname).readlines()

    done = False
    for line in srclines:
        if line.find('SPDX-License-Identifier') >= 0:
            done = True
            break

    if done:
        print("SPDX id exists already in %s" %fname)
        continue

    ok = False
    if fname.endswith('.h') or fname.endswith('.lds'):
        ok = insert_at(srclines, 0, tag, '/*')

    elif fname.endswith('.cpp'):
        ok = insert_at(srclines, 0, tag, '//')

    elif fname.endswith('.c') or fname.endswith('.uc'):
        ok = handle_c(srclines, tag)

    elif fname.endswith('.S'):
        ok = handle_asm(srclines, tag)

    elif fname.endswith('.cocci'):
        ok = insert_at(srclines, 0, tag, '//')
        
    elif fname.endswith('.dts') or fname.endswith('.dtsi'):
        ok = insert_at(srclines, 0, tag, '//')

    elif fname.endswith('.py') or fname.endswith('.tc') or fname.endswith('.sh') or fname.endswith('.pl'):
        ok = insert_at(srclines, 1, tag, '#')

    elif bname.startswith('Makefile') or bname.startswith('Kconfig') or bname.startswith('Kbuild'):
        ok = insert_at(srclines, 0, tag, '#')

    elif is_script(srclines):
        ok = insert_at(srclines, 1, tag, "#")

    else:
        print("Unhandled or ignored file %s" %fname)
        continue

    if ok:
        open(fname, 'w').writelines(srclines)
        print("Inserted %s into %s" %(tag, fname))
    else:
        print("FAIL: No place for insertion found %s" %fname)

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Linus Torvalds]

On Thu, Nov 2, 2017 at 10:45 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> For .h files, we had to use /* */

That should only be true for the uapi files (because they may
encounter old compilers), not for *.h files in general, I feel.

          Linus

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Greg KH]

On Thu, Nov 02, 2017 at 10:52:23AM -0700, Linus Torvalds wrote:
> On Thu, Nov 2, 2017 at 10:45 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > For .h files, we had to use /* */
> 
> That should only be true for the uapi files (because they may
> encounter old compilers), not for *.h files in general, I feel.

Oh I wish that were the case :(

Thomas and I fought with the vdso build logic[1], and some other
arch-specific stuff for a good day trying to track down all of the
individual .h files that were getting pulled in by gcc to spit out a .S
file.  We eventually just gave up trying to fix them all up one by one,
the combinations were just too large.  By using /* */ for all .h files,
all build combinations worked just fine automatically, no special-casing
needed.

That was _just_ with the first patch in the series applied, no UAPI file
modifications at all.  Our build system is crazy...

thanks,

greg k-h

[1] I found a bug where if any vdso.S files fail to build, the build
    system keeps on going just fine.  Still can't figure out how to fix
    that, obviously it's not something that ever usually happens.  I now
    know why anyone who ever touches those files are driven to drink...

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Linus Torvalds]

On Thu, Nov 2, 2017 at 11:02 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> Oh I wish that were the case :(
>
> Thomas and I fought with the vdso build logic[1], and some other
> arch-specific stuff for a good day trying to track down all of the
> individual .h files that were getting pulled in by gcc to spit out a .S
> file.

Hmm. I thought we fixed those things long ago..

Commit fe58fc8f4025 ("x86: wipe out traditional opt from x86_64
Makefile") removed our use of -traditional back in 2008.

But I do note that the PPC build still seems to have it.

But yeah, maybe there is something else odd about *.S files still.

               Linus

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Thomas Gleixner]

On Thu, 2 Nov 2017, Linus Torvalds wrote:

> On Thu, Nov 2, 2017 at 11:02 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > Oh I wish that were the case :(
> >
> > Thomas and I fought with the vdso build logic[1], and some other
> > arch-specific stuff for a good day trying to track down all of the
> > individual .h files that were getting pulled in by gcc to spit out a .S
> > file.
> 
> Hmm. I thought we fixed those things long ago..
> 
> Commit fe58fc8f4025 ("x86: wipe out traditional opt from x86_64
> Makefile") removed our use of -traditional back in 2008.
> 
> But I do note that the PPC build still seems to have it.
> 
> But yeah, maybe there is something else odd about *.S files still.

The wreckage is with the *.lds.S ones which are used to generate .lds with
some gcc preprocessor magic. And then ld falls flat on its nose with the //
comment.

Thanks,

	tglx

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Linus Torvalds]

On Thu, Nov 2, 2017 at 11:21 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> The wreckage is with the *.lds.S ones which are used to generate .lds with
> some gcc preprocessor magic. And then ld falls flat on its nose with the //
> comment.

The cpp phase should just get rid of them.

But we actually explicitly use "cpp -C" for the lds file to keep
comments around. Which makes no sense to me, but there it is.

That is *completely* crazy.  I wonder why we do that brain-damage.

Literally just removing that -C fixes the problem:

  -      cmd_cpp_lds_S = $(CPP) $(cpp_flags) -P -C -U$(ARCH) \
  +      cmd_cpp_lds_S = $(CPP) $(cpp_flags) -P -U$(ARCH) \

and there is no reason to keep them that I can possibly see.

Seriously, we should fix that regardless, but if it actually keeps us
from having C++ style comments in header files that might be included
in lds.S files, we should _definitely_ fix it.

It seems to be a historical oddity. The "-C" was added in 51b563fc93c8
("arm, cris, mips, sparc, powerpc, um, xtensa: fix build with bash
4.0"), but it came from our old

  export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)

which predates the git history.

Hmm.. Digging down, long long ago we used to do

  arch/$(ARCH)/vmlinux.lds.s: arch/$(ARCH)/vmlinux.lds.S
         $(CPP) $(CPPFLAGS) $(CPPFLAGS_$@) -P -C -U$(ARCH) $< -o $@

and that's where the -C comes from. And *that* came from MIPS, ia64
and sh doing so back in 2002.

But they used to use "-traditional" too.

So I'm pretty sure that the whole stupid "-C" is just a bogus result
of history that should have been gotten rid of long long long ago.

                Linus

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Rob Herring]

On Thu, Nov 2, 2017 at 10:16 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> [resend without the full diffstat as lkml and some email systems didn't
>  like to see emails with 12k lines...]
>
> Hi,
>
> As discussed at the Maintainers Summit last week, here is a pull request
> that adds some SPDX license identifiers to three different classes of
> files:
>         - files with no license identifiers at all, but not uapi files
>         - uapi files with no license identifiers at all
>         - uapi files with existing license identifiers
>
> This "only" touched 1/6 of the files in the tree.  The remaining files
> will be dealt with on a subsystem-by-subsystem basis over the next few
> kernel releases.
>
> The full methodology of how these files were determined, and how the
> work was done is down below in the signed tag, and in the first commit
> of the series.
>
> These patches have a "new" timestamp, a few hours old, only because we
> have revised and rewritten the changelog text many times based on lots
> of people's inputs (lawyers included.)  The patches themselves are not
> "new" at all and were auto-generated as described below and are based on
> 4.14-rc6.
>
> Note, we had to use /* */ as the comment marker for the .h files, as
> there are just too many .h files being included into .S files to be able
> to try to identify which is which, so we could not use //, unlike the .c
> files.
>
> These have been through 0-day testing with no reported problems, as well
> as my build system and Thomas's build system.

I have some concerns about adding the SPDX tag on the dts/dtsi files.
These files are generally either GPL2 or dual GPL/MIT. The license
should normally be decided per platform and generally we don't have
cross-platform includes. So I'd think there could be some cases where
the intent was to match the rest of the platform's dts files, but the
license was omitted by mistake.

In any case, the platform maintainers should have a chance to comment
on their platforms and it seems this was rushed.

Rob

Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files

[Greg KH]

On Wed, Nov 08, 2017 at 05:07:46PM -0600, Rob Herring wrote:
> On Thu, Nov 2, 2017 at 10:16 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > [resend without the full diffstat as lkml and some email systems didn't
> >  like to see emails with 12k lines...]
> >
> > Hi,
> >
> > As discussed at the Maintainers Summit last week, here is a pull request
> > that adds some SPDX license identifiers to three different classes of
> > files:
> >         - files with no license identifiers at all, but not uapi files
> >         - uapi files with no license identifiers at all
> >         - uapi files with existing license identifiers
> >
> > This "only" touched 1/6 of the files in the tree.  The remaining files
> > will be dealt with on a subsystem-by-subsystem basis over the next few
> > kernel releases.
> >
> > The full methodology of how these files were determined, and how the
> > work was done is down below in the signed tag, and in the first commit
> > of the series.
> >
> > These patches have a "new" timestamp, a few hours old, only because we
> > have revised and rewritten the changelog text many times based on lots
> > of people's inputs (lawyers included.)  The patches themselves are not
> > "new" at all and were auto-generated as described below and are based on
> > 4.14-rc6.
> >
> > Note, we had to use /* */ as the comment marker for the .h files, as
> > there are just too many .h files being included into .S files to be able
> > to try to identify which is which, so we could not use //, unlike the .c
> > files.
> >
> > These have been through 0-day testing with no reported problems, as well
> > as my build system and Thomas's build system.
> 
> I have some concerns about adding the SPDX tag on the dts/dtsi files.
> These files are generally either GPL2 or dual GPL/MIT. The license
> should normally be decided per platform and generally we don't have
> cross-platform includes. So I'd think there could be some cases where
> the intent was to match the rest of the platform's dts files, but the
> license was omitted by mistake.

If you feel we got a license incorrect, please fix it up.  But as it
was, there was 11000 files with no explicit license, so the license for
them was implicitly GPLv2, which we preserved with this SPDX mark.

So we didn't change anything here, except draw attention to where some
files were licensed under a different license than the original author
expected it to be :)

thanks,

greg k-h