From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1517602684; cv=none; d=google.com; s=arc-20160816; b=lMmfke+6YHJzojNxKLJ4e8D9ICOfC5oq+4kSv28D7tp82D9vl/Is1Pw89xDvZSmdDs G9DUlD7+q432PxgdsefpNf1wZE7kMdn6xokiIjmbWs/xubvDrc5L4BYDNzvXlt0DNmaS AhvoP0Icr/Gz80oQIdIG/QmOQlvPM6/HiRB8OCXofoqUwhZmmpqj5eTSQ9y4EFLsmWkB oUxzNQBE/Pr0vS/LY2FxNEr4MChM1+KfPEC07Lj4Yp2lITR7rSBWMe98QKHmcBqx7at6 5IjQosqsYkKRflx2DZkHXn0SICHWsHMy2eOwf6z4q37CWosDBnrg4DTXg7r9Uzw/j3AB xkvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; bh=stGfY5aQhoeR0ykzTSOiRdB10AaJmQBzpRwth2NE+Jc=; b=pFH3pvJrA+wkhMXy7HbcyXBnb0qi3pJ6RpvVIXW2js8wCyJPibEWFdSX7H95Ip13el 3zF05l5dKW7nXIchMVLtrhhzlNy2h6rZrQ4BvzQcR9F6u4bZOIsR3ygtn5jBPegR3kTS diYhWN0NKZOcGaYj0SR2LyESaCiHO4QEHoouedbZ/NeBIKl7pY7rY+KZpz48MD6e/Lrb walN09BiD+Rr9L31/mN8lJSHJzzRd2OJ2Lq06b2N/ylnhOAugv8l1pbrjNK3XRjOxzxe hCI+5SlJel5NM6uyldrlKfP3KcimDY9PphsoiaY8KQDBNp4psDNAIiLnjdGOale4tOFo 8PJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=google header.b=SdI1jUtb; spf=pass (google.com: domain of kstewart@linuxfoundation.org designates 209.85.220.41 as permitted sender) smtp.mailfrom=kstewart@linuxfoundation.org Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=google header.b=SdI1jUtb; spf=pass (google.com: domain of kstewart@linuxfoundation.org designates 209.85.220.41 as permitted sender) smtp.mailfrom=kstewart@linuxfoundation.org X-Google-Smtp-Source: AH8x226URpDWH/thbXaD/pHoHqlexbQmOqyr4KcprTvY6GlfWplTMV4o781pk82jmyxTxsSwdq5wYevHLkr4yz9DSk0= MIME-Version: 1.0 In-Reply-To: <1517598363.7489.126.camel@perches.com> References: <20180202154026.15298-1-robh@kernel.org> <1517598363.7489.126.camel@perches.com> From: Kate Stewart Date: Fri, 2 Feb 2018 14:18:02 -0600 Message-ID: Subject: Re: [PATCH v6] checkpatch.pl: Add SPDX license tag check To: Joe Perches Cc: Rob Herring , Igor Stoppa , Andrew Morton , "linux-kernel@vger.kernel.org" , Andy Whitcroft , Greg Kroah-Hartman , Thomas Gleixner , Philippe Ombredanne , Jonathan Corbet Content-Type: multipart/alternative; boundary="001a114110c8ec9601056440683b" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1591304287671259020?= X-GMAIL-MSGID: =?utf-8?q?1591321753373195233?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: --001a114110c8ec9601056440683b Content-Type: text/plain; charset="UTF-8" On Fri, Feb 2, 2018 at 1:06 PM, Joe Perches wrote: > On Fri, 2018-02-02 at 12:27 -0600, Rob Herring wrote: > > On Fri, Feb 2, 2018 at 9:49 AM, Igor Stoppa > wrote: > > > On 02/02/18 17:40, Rob Herring wrote: > > > > Add SPDX license tag check based on the rules defined in > > > > > > Shouldn't it also check that the license is compatible? > > > > > > > Perhaps we shouldn't try to script legal advice. > > True. > > I believe what was meant was that the > entry was a valid SPDX License entry > that already exists as a specific file > in the LICENSES/ path. > > So that entry must be some combination of: > > $ git ls-files LICENSES/ | cut -f3- -d'/' | sort > BSD-2-Clause > BSD-3-Clause > BSD-3-Clause-Clear > GPL-1.0 > GPL-2.0 > LGPL-2.0 > LGPL-2.1 > Linux-syscall-note > MIT > MPL-1.1 > > From my perspective, it'd be better if the > various + uses had their own individual > license files in the LICENSES/ path. > At the end of december, the SPDX license list[1] was rev'd to Version: 3.0 28 December 2017. At the request of FSF, the GNU license family would not use the "+" notation, and would bias towards using "-only" and "-or-later", explicitly. So adding both variants to the LICENSES/ path aligns with this forward direction. > Right now, there are many missing licenses > that are already used by various existing > SPDX-License-Identifier: entries. > > > APACHE-2.0 > BSD > CDDL > CDDL-1.0 > ISC > GPL-1.0+ > GPL-2.0+ > LGPL-2.1+ > OpenSSL > > There are odd entries like: > > GPL-2.0-only > This is the new way to represent GPLv2 only, as described above. While the GPL-2.0 and GPL-2.0+ notation is still valid, it is deprecated in the latest version, so transitioning existing over time will probably be needed. So I think the list of licenses to be added to LICENSES/ path is: APACHE-2.0 BSD CDDL CDDL-1.0 ISC GPL-1.0-only GPL-1.0-or-later (note: actually same contents as one GPL-1.0-only) GPL-2.0-only GPL-2.0-or-later (same contents as GPL-2.0-only) LGPL-2.0-only LGPL-2.0-or-later (same contents as LGPL-2.0-only) LGPL-2.1-only LGPL-2.1-or-later (same contents as LGPL-2.1-only) OpenSSL Having files with the same contents, but different names is irritating, but I can't see a another way of complying with REUSE guidelines. Any better suggestions? > Parentheses around AND/OR aren't consistent. > The SPDX specification has an appendix that calls for "(",")" around every license expresssion. After discussion with some developers it was decided to be ok to relax that, and only add them when they were essential to clarify the logic. The next rev of the SPDX specification will have this clarified as well. I think we caught most of the changes in the kernel documentation patches for describing this, but if you have specific cases to be reviewed, happy to have a look. Thanks, Kate [1] https://spdx.org/licenses/ --001a114110c8ec9601056440683b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Fri, Feb 2, 2018 at 1:06 PM, Joe Perches <joe@perches.com> wrote:
On Fri, 2018-= 02-02 at 12:27 -0600, Rob Herring wrote:
> On Fri, Feb 2, 2018 at 9:49 AM, Igor Stoppa <igor.stoppa@huawei.com> wrote:
> > On 02/02/18 17:40, Rob Herring wrote:
> > > Add SPDX license tag check based on the rules defined in
> >
> > Shouldn't it also check that the license is compatible?
> >
>
> Perhaps we shouldn't try to script legal advice.

True.

I believe what was meant was that the
entry was a valid SPDX License entry
that already exists as a specific file
in the LICENSES/ path.

So that entry must be some combination of:

$ git ls-files LICENSES/ | cut -f3- -d'/' | sort
BSD-2-Clause
BSD-3-Clause
BSD-3-Clause-Clear
GPL-1.0
GPL-2.0
LGPL-2.0
LGPL-2.1
Linux-syscall-note
MIT
MPL-1.1

>>From my perspective, it'd be better if the
various + uses had their own individual
license files in the LICENSES/ path.

At= the end of december, the SPDX license list[1] was rev'd to
Versio= n: 3.0 28 December 2017.=C2=A0 =C2=A0At the request of=C2=A0
FSF, the GNU license family would not use the "+&quo= t; notation,
and would bias towards using &= quot;-only" and "-or-later", explicitly.
So adding both variants to the LICENSES/ path aligns with=C2= =A0
this forward direction.


Right now, there are many missing licenses
that are already used by various existing
SPDX-License-Identifier: entries.


APACHE-2.0
BSD
CDDL
CDDL-1.0
ISC
GPL-1.0+
GPL-2.0+
LGPL-2.1+
OpenSSL

There are odd entries like:

GPL-2.0-only

This is the new way to rep= resent GPLv2 only, as described above.=C2=A0
While the GPL-2.0 an= d GPL-2.0+ notation is still valid,=C2=A0 it is deprecated
in the= latest version, so transitioning existing over time will probably=C2=A0
be needed.=C2=A0 =C2=A0So I think the list of licenses to be added = to=C2=A0
LICENSES/ path is:
=C2=A0
APACHE-2.0=
BSD
CDDL
CDDL-1.0
ISC
GPL-1.0-only
GPL-1.0-or-lat= er (note: actually same contents as one GPL-1.0-only)
GPL-2.0-only
=
GPL-2.0-or-later (same contents as GPL-2.0-only)
LGPL-2= .0-only
LGPL-2.0-or-later (same contents as LGPL-2.0-only)
L= GPL-2.1-only
LGPL-2.1-or-later (same contents as LGPL-2.1-only)OpenSSL

Having files with the same contents,= but different names is=C2=A0
irritating, but I can't see a a= nother way of complying with REUSE
guidelines.=C2=A0 =C2=A0Any be= tter suggestions?
=C2=A0
Parentheses around AND/OR aren't consistent.

<= /div>
The SPDX specification has an appendix that calls for "(&quo= t;,")"
around every license expresssion.=C2=A0 =C2=A0Af= ter discussion with some=C2=A0
developers it was decided to be ok= to relax that, and only add them=C2=A0
when they were essential = to clarify the logic.=C2=A0 =C2=A0The next rev of the=C2=A0
SPDX = specification will have this clarified as well.=C2=A0 =C2=A0I think we caug= ht
most of the changes in the kernel documentation patches for de= scribing
this,=C2=A0 but if you have specific cases to be reviewe= d,=C2=A0 happy to have
a look.=C2=A0

Tha= nks, Kate



=
--001a114110c8ec9601056440683b--