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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871qwhz2aa.ffs@tglx>
Date:   Thu, 26 May 2022 00:16:13 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Bird, Tim" <Tim.Bird@...y.com>,
        Luis Chamberlain <mcgrof@...nel.org>
Cc:     Richard Fontana <fontana@...rpeleven.org>,
        "tj@...nel.org" <tj@...nel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "jeyu@...nel.org" <jeyu@...nel.org>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "bvanassche@....org" <bvanassche@....org>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "joe@...ches.com" <joe@...ches.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "minchan@...nel.org" <minchan@...nel.org>,
        "linux-spdx@...r.kernel.org" <linux-spdx@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Goldwyn Rodrigues <rgoldwyn@...e.com>,
        Kuno Woudt <kuno@...b.nl>,
        "copyleft-next@...ts.fedorahosted.org" 
        <copyleft-next@...ts.fedorahosted.org>,
        Ciaran Farrell <Ciaran.Farrell@...e.com>,
        Christopher De Nicolo <Christopher.DeNicolo@...e.com>,
        Christoph Hellwig <hch@....de>,
        Jonathan Corbet <corbet@....net>,
        Thorsten Leemhuis <linux@...mhuis.info>
Subject: RE: [PATCH v9 1/6] LICENSES: Add the copyleft-next-0.3.1 license

Tim!

On Wed, May 25 2022 at 19:05, Bird, Tim wrote:
>> From: Luis Chamberlain <mcgrof@...radead.org> On Behalf Of Luis Chamberlain
>> I agree that we want to keep the number of licenses as small as
>> possible but we cannot really dictate which dual licensing options a
>> submitter selects unless the license is GPL-2.0-only incompatible,
>> which copyleft-next is not.
>
> Um, yes we can dictate that.

No!

> There were good reasons that the original BSD dual-licenses were
> allowed.  Those same reasons don't apply here.

That's just wrong. The reason why dual licensing is allowed is to share
code across licesce preferences. The very same reason applies here.

> Each license added to the kernel (even when added as an OR), requires
> additional legal analysis.  Corporate lawyers don't usually rely on
> the interpretation of novel licenses from external sources.  They do
> it themselves.  This means that hundreds of lawyers may find
> themselves reading and trying to interpret the copyleft-next license.

It's none of our problems that corporate lawyers are obviously unable to
act, cooperate and to agree on something.

     The license in question is around since 2016 and the kernel carries
     code under that license since 2017.

  So what the hell are you complaining 5 years after the fact? The whole
  point here is to convert this to SPDX identifiers.

Aside of that I'm impressed by your chutzpah to make up an argument on
corporate lawyer costs.

  Do you realize how much costs the very same crowd of corporate lawyers
  created by ill advising their employees to put corporate defined
  boiler plate into every other kernel source code file or by not
  advising them at all and let them add random crap?

  Do you realize that the costs to cleanup this mess have been mostly
  covered by community members with the help from a _very_ small subset
  of corporate lawyers?

  Do you realize that it's hilarious that your so costly corporate
  lawyers only need to react now that we are trying to convert licensing
  information to SPDX 5 years after the fact?

  Do you realize that the SPDX cleanup effort is reducing the costs for
  everyone including _all_ of the corporate lawyers you are so concerned
  of?

Sure, complaining about your individual corporate costs is way simpler
than:

   - contributing to community efforts to reduce those costs

   - acknowledging that the community efforts even without contribution
     or your particular organization are reducing those costs

Try again.

> And here's the thing.
> The copyleft-next license has a number of legal issues that make it problematic.
> Not the least of which are that some of its terms are dependent on external
> situations that can change over time, in a matter that is uncontrolled by either
> the licensor or the licensee.  In order to determine what terms are effective, you
> have to know when the license was granted, and what the FSF and OSI approved
> licenses were at various points in time.  You literally have to use the Internet
> Archive wayback machine, and do a bunch of research, to interpret the license terms.
> It is not, as currently constructed, a good license, due to this lack of legal clarity.

And here is the thing:

    Whether you consider it to be a good license or not, does not matter
    in this context.

    The license _IS_ GPLv2 compatible which is even understandable for
    mere mortals, i.e. non lawyers. That's the only relevant point for
    including code under this license into the kernel.

    Your way-back machine argument is beyond hilarious. Guess what the
    folks who try to cleanup the corporate lawyers induced mess in the
    kernel rely on? But that's absolutely not applicable to this
    problem. Why?

        The kernel has very strict rules for licensing today. Any valid
        SPDX tag in a source file has to be accompanied with a
        corresponding machine readable license file.

        This license file is version controlled and if there is a
        dependency on any other license in the context then the
        dependency is also available in the git history.

        So no, you do not need Internet archive for this at all simply
        because if the kernel git history vanishes from the planet
        then this particular licensing problem is the least of your
        worries.

Maybe it's about time to move your corporate lawyers, who are
caught in their own past sins, to the reality of today.

Thanks,

        Thomas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ