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]

Message-ID: <20170517174128.GQ17314@wotan.suse.de>
Date:   Wed, 17 May 2017 19:41:28 +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>, torvalds@...ux.intel.com,
        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 Wed, May 17, 2017 at 12:55:02PM -0400, Theodore Ts'o wrote:
> On Wed, May 17, 2017 at 01:27:02AM +0200, Luis R. Rodriguez wrote:
> > 
> > I have done the work though, however I can understand this might mean others
> > down the chain might need to burn some ink on this. Even if our position is:
> > 
> > "we rather avoid any attorneys burning any ink and we prefer to just always
> > require this 'dual or' language even for licenses which corporate attorneys
> > have vetted as compatible"
> > 
> > Wouldn't that still require a bit of ink?
> 
> What ink?  As far as the Kernel is concerned, it's dual-licensed GPLv2
> and copyleft-next.  So for all Kernel users there isn't any lawyer ink
> at all.

Here you seem to indicate no lawyers would need to be involved.

> The lawyer ink comes from contributors being willing to let their code
> contributions being dual-licensed with GPL2 plus a potentially
> unfamiliar, new copyright license.  But that's overhead that
> contributors would have to deal with in either case.

But here an overhead to developers would be incurred whether or not the or
clause approach would be used, but its unclear if you implied the overhead
is due to attorneys or not.

> In fact, if you
> try to go single-license copyleft-next, the contributors' corporate
> lawyer will need to figure out the GPLv2 compatibility issue, so it's
> *more* overhead with the proposed single-copyright license approach.

This argument I can understand, my question was that if such review is
needed, wouldn't it also be needed if the or clause thing was used?

> I'm not sure I understand what you believe to be the benefit of having
> kernel modules solely licensed under copyleft-next

If Linux kernel modules use copyleft-next license header on files / header
files on Linux, the Linux kernel modules would be licensed as GPLv2 as that
is what the license says. So to be clear the modules would not be licensed
under copyleft-next, it would just be license used for the files. Likewise
for these files built-in, when compiled on Linux as built-in they are all
GPLv2.

> and relying on
> lawyers to say, "no really, it's GPLv2 compatible"?  Could you say
> more about that?

Not sure if you mean my motivation for:

a) preferring copyleft-next, or
b) using a single copyleft-next license instead of the dual language

Either way I'll explain both:

a) Its a great effort to reduce legalese language to a maximum while retaining
GPLv2 compatibility as a goal, while also *enabling* copyleft to advance. To achieve
both I thought was an impossibility, and yet we have an effort which claims to have
reached both. I value copyleft and believe its evolution without church or state
to be important so think we are in a better world with such possibility in
particular because Linux is naturally GPLv2 and I contribute to it.

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.

====

Being able to use copyleft-next files with a small boiler plate interchangeably
between projects I work on keeps things simple and takes advantage of key
efforts on compatibility, while allowing me to also advance copyleft on my own
projects.

  Luis