linux-kernel - Re: [copyleft-next] Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

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]

Date:   Fri, 19 May 2017 01:04:42 +0200
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Theodore Ts'o <tytso@....edu>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Alan Cox <alan@...ux.intel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        AKASHI Takahiro <takahiro.akashi@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Rusty Russell <rusty@...tcorp.com.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ciaran.farrell@...e.com, christopher.denicolo@...e.com,
        fontana@...rpeleven.org, copyleft-next@...ts.fedorahosted.org,
        One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
        Paul Bolle <pebolle@...cali.nl>, Peter Anvin <hpa@...or.com>,
        Joe Perches <joe@...ches.com>
Subject: Re: [copyleft-next] Re: Kernel modules under new copyleft licence :
 (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

On Thu, May 18, 2017 at 06:12:05PM -0400, Theodore Ts'o wrote:
> Sorry, I guess I wasn't clear enough.  So there are two major cases,
> with three sub-cases for each.
> 
> 1)  The driver is dual-licensed GPLv2 and copyleft-next
> 
>    1A) The developer only wants to use the driver, without making
>        any changes to it.
> 
>    1B) The developer wants to make changes to the driver, and 
>        distribute source and binaries
> 
>    1C) The developer wants to make changes to the driver, and 
>        contribute the changes back to upstream.
> 
> 2)  The driver is solely licensed under copyleft-next
> 
>    2A) The developer only wants to use the driver, without making
>        any changes to it.
> 
>    2B) The developer wants to make changes to the driver, and 
>        distribute source and binaries
> 
>    2C) The developer wants to make changes to the driver, and 
>        contribute the changes back to upstream.
>
> In cases 1A and 1B, I claim that no additional lawyer ink is required,

I really cannot see how you might have an attorney who wants ink on 2A but not 1A.
I really cannot see how you might have an attorney who wants ink on 2B but not 1B.

> because the code can just be distriuted under the terms of the rest of
> the kernel --- namely, the GPLv2.
>
> Even in the case where the
> developer has made changes to the driver, the change can be released
> only under the GPLv2, with the next result that in modified driver,
> only the terms of the GPLv2 are controlling.
>
> In the case of 1C, since the developer is contributing changes back to
> upstream, and upstream presumably wants to keep the dual-license
> nature of the source file, the developer will need to get permission
> from their corporate counsel that it's OK for that company to release
> code under the copyleft-next license.  And if the counsel is not
> familiar with that license, they may need to research what
> implications it might have towards the company's patents, etc.  So
> there is extra ink in the case of 1C --- but fortunately, that's a
> relatively small set in practice for most drivers.
>
> In the single-license copyleft next case, in all of the cases
> corporate counsel will need to be engaged if this is a new license and
> they haven't analyzed the license yet.  So my claim is that 2A, 2B,
> and 2C will require different amounts of extra, additional lawyer ink.
> 
> Does my reasoning make more sense now?

I see what you are saying now however it seems we disagree on what any
careful attorney might do. I have no knowledge of a single attorney who
have ever had a position to green light 1A or 1B just because of the
magical "or" clause is used.

> > b) Less boiler plate header, that's all. Pegging a dual thing would kind of
> > defeat the purpose of the whole effort to make it as crystal clear as possible
> > copyleft-next is GPLv2 compatible and its efforts to reduce license legalese.
> > If its possible to avoid why not ask, which is what I've done.
> 
> I'll note, wrly, that lawyers can't agree on whether or not any boiler plate on
> individual source files is needed at all.  Some might argue that:
> 
> MODULE_LICENSE("GPL");
> 
> is all that's needed, which is pretty simple.  :-)

Sure, but one of the gains of single licensed files is what you can import
from an outside project, or what you can take out and use in another licensed
project. Since Linux *has* that macro though -- I think it is also also
sufficiently clear that the license that applies when copyleft-next is
used on Linux is GPLv2.

So I am arguing that the MODULE_LICENSE() macro says *much* more than that
silly or clause does given that the license is explicit about license
compatibility when such licensed code is used on larger GPLv2 projects.

  Luis