From: Greg KH <gregkh@linuxfoundation.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Kate Stewart <kstewart@linuxfoundation.org>,
Philippe Ombredanne <pombredanne@nexb.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files
Date: Thu, 2 Nov 2017 18:25:10 +0100 [thread overview]
Message-ID: <20171102172510.GA25121@kroah.com> (raw)
In-Reply-To: <CAK7LNARyMGo1f3PkiCeQcz8_g5+axqhcwiHkQJDfi1S7P_VyUA@mail.gmail.com>
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
next prev parent reply other threads:[~2017-11-02 17:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-02 15:16 [GIT PULL] License cleanup: add SPDX license identifiers to some kernel files Greg KH
2017-11-02 17:09 ` Masahiro Yamada
2017-11-02 17:25 ` Linus Torvalds
2017-11-02 17:32 ` Linus Torvalds
2017-11-02 17:45 ` Greg KH
2017-11-02 17:52 ` Linus Torvalds
2017-11-02 18:02 ` Greg KH
2017-11-02 18:18 ` Linus Torvalds
2017-11-02 18:21 ` Thomas Gleixner
2017-11-02 18:53 ` Linus Torvalds
2017-11-02 17:25 ` Greg KH [this message]
2017-11-08 23:07 ` Rob Herring
2017-11-09 13:40 ` 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=20171102172510.GA25121@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=kstewart@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pombredanne@nexb.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=yamada.masahiro@socionext.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.