linux-kernel - Re: CQ and RDMA READ/WRITE APIs

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]

Date:	Mon, 16 May 2016 10:51:23 -0400
From:	Doug Ledford <dledford@...hat.com>
To:	Christoph Hellwig <hch@....de>
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: CQ and RDMA READ/WRITE APIs

On 05/16/2016 07:49 AM, Christoph Hellwig wrote:
> [adding Linus and linux-kernel to Cc]
> 
> On Fri, May 13, 2016 at 08:04:17PM -0400, Doug Ledford wrote:
>> You submitted new files into the subsystem under GPL only license in
>> contrast to the rest of the subsystem.  This presents a problem.  I'm in
>> the position where I need to either revert them, or I need your
>> permission to make them dual license GPL/BSD to match the rest of the
>> subsystem.  Were you intentionally trying to make the OFED work illegal,
>> or just an oversight?
> 
> Hi Doug,
> 
> the RDMA code was developed for a GPLed driver and moved to the code,
> and lots of people contributed to it under the GPL,

The contributions are under the same license as the file you are
modifying.  So if the file you modify is dual license, then the
contribution in the form of modifications to that file are also dual
license unless your submissions clearly and explicitly states otherwise.
 See the standard definition of "Signed-off-by:" as maintained on the
Linux Foundation website, which spells out that this is the case.

> as they assumed
> Linux code in genral is.

The linux kernel as a whole is, but individual files still retain their
separate copyright, they don't loose it just because they are shipped as
part of the larger kernel.

>  Іf dual-licensing is possible at all it would
> require a lot of work, which I don't think is worth it.

Running the RDMA code under a dual license is probably not possible.
But the files that are dual licensed retain their licensure, which means
someone working on BSD based system could freely interchange source code
between this stack and their own.  Some of the groups originally
involved with the RDMA stack used to do exactly this.  In the most
recent past, I think some of those companies are moving away from that
setup to running plain kernels (in which case their kernel is obviously
under the GPL).

>  If you don't
> want GPL code in the core rdma.ko module we can move it to a rdma-gpl.ko
> module, but that would be a little bit odd.

That's somewhat of my concern, but not the primary concern.  The issue
here is that I feel obligated to go to the primary maintainers of
several pieces of code that are under dual license and make sure that
they understand what is happening here.  You made some nice API
additions to the core.  Great.  That API is under GPL only terms.  OK,
it's your code, do as you wish.  In addition to adding the API, you then
ported several upper layer drivers to your API and in the process
removed the previous code from the drivers that allowed them to work
without your API.  In so doing, you made their code completely dependent
upon your code.  What used to be able to be pulled out as a complete,
functional, dual licensed chunk no longer can be.  I feel obligated to
point this out to those code maintainers and make sure they are aware of
this and specifically acknowledge it.  If their fine with it, then so be
it.  If they would prefer to maintain their dual license nature and not
be dependent on a piece that breaks that for them, then I think that's
their choice to make.

-- 
Doug Ledford <dledford@...hat.com>
              GPG KeyID: 0E572FDD

Download attachment "signature.asc" of type "application/pgp-signature" (885 bytes)