linux-kernel - Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1806122111400.1592@nanos.tec.linutronix.de>
Date:   Tue, 12 Jun 2018 21:27:57 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Yang Li <pku.leo@...il.com>
cc:     LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        Andrew Morton <akpm@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@....de>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Rob Herring <rob.herring@...aro.org>,
        Jonas Oberg <jonas@...e.org>, Joe Perches <joe@...ches.com>,
        linux-xfs@...r.kernel.org,
        Charlemagne Lasse <charlemagnelasse@...il.com>,
        Carmen Bianca Bakker <carmenbianca@...e.org>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe
 how to properly identify file licenses

Yang,

On Tue, 12 Jun 2018, Yang Li wrote:
> On Thu, Dec 28, 2017 at 4:17 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > On Thu, 28 Dec 2017, Thomas Gleixner wrote:
> >
> > Sorry for the spam. I somehow missed to refresh the patch before generating
> > the mbox. Find below the correct version of that one which has ALL braces
> > removed which we don't need.

> I'm not sure how we reached the conclusion that we should remove ALL
> braces?  I cannot find related discussion in the archive except for
> the "WITH" case.

https://lkml.kernel.org/r/CAOFm3uEpM_tBErkOvqghcy+wbw0i4mSnafPBRC3HYZVQjsSyMw@mail.gmail.com

> This is conflicting with the current SPDX spec at
> https://spdx.org/spdx-specification-21-web-version quoted below and
> also the explenation in your own file.
> 
> Quote from SPDX spec 2.1: More expressive composite license
> expressions can be constructed using "OR", "AND", and "WITH" operators
> similar to constructing mathematical expressions using arithmetic
> operators. For the Tag:value format, any license expression that
> consists of more than one license identifier and/or LicenseRef, should
> be encapsulated by parentheses: "( )".

This is not relevant here:

   For the Tag:value format, .....

The kernel does not generate SPDX files in Tag:value format. The kernel
uses SPDX license identifiers to reflect the actual license of a file.

> > +   A <SPDX License Expression> is either an SPDX short form license
> > +   identifier found on the SPDX License List, or the combination of two
> > +   SPDX short form license identifiers separated by "WITH" when a license
> > +   exception applies. When multiple licenses apply, an expression consists
> > +   of keywords "AND", "OR" separating sub-expressions and surrounded by
> > +   "(", ")" .
> 
> Conflicting with the example

No, The keyword is 'separating sub-expressions'. It does not say license
identifiers.

So these examples are completely compliant with the documentation:

> > +      // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
> > +      // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
> > +      // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause

Two license (exception) identifiers plus a operator. That's perfectly well
defined.

> > +      // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT

This is actually a case where you need parentheses and they separate the
sub-expression 'ID with EXC'.

Adding extra parentheses around any simple 'ID operator [ID|EXC]'
expression is really overkill and does not make stuff more
readable. Likewise in programming languages. Why would anyone write:

C et al.:	a = (b || c);
Pyhton:		a = (b and c)

Thanks,

	tglx