linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Rob Herring <rob.herring@linaro.org>
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, 9 Nov 2017 14:40:49 +0100	[thread overview]
Message-ID: <20171109134049.GB6545@kroah.com> (raw)
In-Reply-To: <CABGGiswvTExoeQHro_ctpTEhdxf6_VQXdZJDbDvBhG6QndG04A@mail.gmail.com>

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

      reply	other threads:[~2017-11-09 13:40 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
2017-11-08 23:07 ` Rob Herring
2017-11-09 13:40   ` Greg KH [this message]

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=20171109134049.GB6545@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=rob.herring@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).