Message-ID: <YOcSwXkpzAFGucXM@ebb.org>
Date:   Thu, 8 Jul 2021 07:59:13 -0700
From:   "Bradley M. Kuhn" <bkuhn@....org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Luis Chamberlain <mcgrof@...nel.org>, tglx@...utronix.de,
        akpm@...ux-foundation.org, shuah@...nel.org, rafael@...nel.org,
        rgoldwyn@...e.com, kuno@...b.nl, fontana@...rpeleven.org,
        Ciaran.Farrell@...e.com, Christopher.DeNicolo@...e.com, hch@....de,
        corbet@....net, linux@...mhuis.info, ast@...nel.org,
        andriin@...com, daniel@...earbox.net, atenart@...nel.org,
        alobakin@...me, weiwan@...gle.com, ap420073@...il.com,
        tj@...nel.org, jeyu@...nel.org, ngupta@...are.org,
        sergey.senozhatsky.work@...il.com, minchan@...nel.org,
        axboe@...nel.dk, mbenes@...e.com, jpoimboe@...hat.com,
        keescook@...omium.org, jikos@...nel.org, rostedt@...dmis.org,
        peterz@...radead.org, linux-block@...r.kernel.org,
        linux-spdx@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org, copyleft-next@...ts.fedorahosted.org
Subject: Re: [PATCH 0/2] LICENSES: add and use copyleft-next-0.3.1


[ Full Disclosure: I've written parts of copyleft-next, have been involved
  with the initiative basically since its inception, and obviously I like the
  license a lot.  Take my comments with the recommend dose NaCl granules
  those facts require. ]

Greg KH wrote:
> Any chance you wish to just change the license of these files, given that
> you are the only one that has tried to use it for kernel code?

There is a lot of dual-licensed (GPLv2-only|{2,3}-Clause-BSD) code already in
Linux.  Many corporate copyright holders have well documented strong reasons
for wanting that.  (Those policy goals and the analysis behind them, I find
problematic and sometimes outright wrong, but nonetheless it's their right to
license their copyrights that way, and the license *is* GPLv2-only
compatible, as is Luis'!).

I assume that you're not asking those companies to relicense to pure
GPLv2-only.  While those companies perhaps faced early resistance when they
began their dual-licensing-in-upstream endeavor, it was ultimately accepted
and that opens the door, IMO, to accepting any form of GPL-compatible
dual-licensing upstream.  There is no cogent argument that I can see that
says “(GPLv2-only|{2,3}-Clause-BSD) is so special that it should be
grandfathered in over other forms of dual licensing”.

(Ironically, IIRC, (then acting on behalf of Qualcomm/Atheros, Luis — the
person proposing the (GPLv2-only|copyleft-next) dual-licensing *now* was a
champion of upstreaming (GPLv2-only|{2,3}-Clause-BSD) code years ago before
it was a wide and common practice.)

> As a follow-up to this, I do not want to see your "test_sysfs.c" module as
> a dual-licensed file, as that makes no sense whatsoever.  It is directly
> testing GPL-v2-only code, so the attempt to dual license it makes no sense
> to me.  How could anyone take that code and do anything with it under the
> copyleft-next license only?  And where would that happen?

But, it's a valid compatible license, so there is no harm.  And, see below,
regarding policy reasons …

> I understand the appeal of copyleft-next in that it resolves many of the
> "grey" areas around gplv2, but given that no one is rushing to advise us to
> relicense all of the kernel with this thing,

Consider me to be the first to advise that!  I realize it's a tough thing to
do, but every great adventure to solve a big problem starts with a first
step!  I further realize it's a non-starter, but please don't say again no
one has advised you such!

BTW, the only reason I didn't advise it because I know a top-level license
change away from straight, no-exceptions/no-additional-permissions GPLv2-only
is a non-starter for the Linux community.  (Great, BTW, that you've stuck so
firmly to your steadfast plan on this!)

Greg continued:
> there is no need to encourage the spread of it given the added complexity
> and confusion that adding another license to our mix can only cause.
Relatedly, Christoph asked (footnote mine):
>> Why do we need a random weirdo [0] license in the kernel tree?  Is there
>> any benefit?

To be frank, we in the copyleft-next community were very excited to learn
that such dual-licensed code had been added to upstream Linux, back when it
was many years ago.  It's a vote of confidence from a well-known developer
who really is excited about our policy goals.  FOSS licensing isn't just
about simplicity and cleanliness.  Like budgets, which seem dry topics on
surface, they are actual moral documents that make a statement about the
philosophy and aspirations for software freedom by the licensor.  Of course,
we all know it's completely symbolic to dual license
(GPLv2-only|copyleft-next), just like it's purely symbolic to dual license
(GPLv2-only|2-Clause-BSD) upstream [1].  But it makes a statement that I
think is a good one.

Finally, while GPLv2-only compatibility has been a mainstay so far in
copyleft-next drafting, it's not clear to me that we can keep that
compatibility forever and reach copyleft-next's policy goals.  There's been
no discussion of this yet, but it's certainly in the realm of possibility.
If GPLv2-incompatibility ultimately happens in future copyleft-next versions,
having dual-licensed code out there will be a huge help as it will assure
that code can forever be used both on GPLv2-only and copyleft-next sides of
future single-license-project equations.

Thanks for listening; of course it's the sole prerogative for the copyright
holder to decide whether to change the license of their code or not, and I
hope that they don't bow to pressure, just as Qualcomm wouldn't bow to
pressure if you started asking them to stop dual licensing all their upstream
Linux code under BSD licenses.

[0] BTW, Christoph, I remember when I started in FOSS in the early 1990s,
    everyone called the GPL a “random weirdo license”.  The incumbent always
    seems not as random and weirdo as the challenger.

[1] There is the argument that 2-Clause-BSD has fewer requirements than
    GPLv2-only; however, that's not an argument to release the code
    *upstream* that way, it's an argument to release a separate version under
    2-Clause-BSD.

--
Bradley M. Kuhn - he/him

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/

Powered by blists - more mailing lists