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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6633ce02-7983-ad09-f95d-03cea6f54e31@redhat.com>
Date:	Mon, 16 May 2016 14:23:12 -0400
From:	Doug Ledford <dledford@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Christoph Hellwig <hch@....de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Sagi Grimberg <sagi@...mberg.me>,
	Bart Van Assche <bart.vanassche@...disk.com>
Subject: Re: CQ and RDMA READ/WRITE APIs

On 05/16/2016 01:46 PM, Linus Torvalds wrote:
> On Mon, May 16, 2016 at 7:51 AM, Doug Ledford <dledford@...hat.com> wrote:
>>
>> 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.
> 
> .. they do lose it if they have GPL'd code merged into them.
> 
> We do generally try pretty hard to respect dual licensing, though,
> just to make it easy to keep drivers that are intentionally shared
> with other projects still sharable.
> 
> That said, that is only true for individual drivers that started out
> that way. I missed the first part of the private discussion, but "new
> files into the subsystem" does not sound like that case, and them
> being GPL-only is pretty much the norm.

Agreed.  That was not my point of contention.

> That is particularly true if
> that new code came from other places in the kernel (or other GPLv2
> projects), where we don't even have a choice.

They were newly written by Christoph, so he has the right to license
them as he sees fit.

> In other words:
> 
>  - I _do_ heavily prefer that we keep dual-licensed drivers
> dual-licensed. It's not a _legal_ requirement, but it's certainly a
> matter of being polite.
> 
>    If the original author of a driver dual-licensed it (or licensed it
> under something like a two-clause BSD license that can be converted to
> GPLv2), it's just bad form to ignore that original license.
> 
>  - the dual-license thing is _particularly_ true if the other license
> is actively used by developers who actually give back. If it's some
> kind of "we want to keep it dual-licensed without helping maintain
> it", I honestly don't give a shit any more.
> 
>    IOW, if the people doing all the heavy lifting work on a particular
> file are GPL-only, then at that point there is nobody to be polite to
> any more.
> 
> Not knowing the details, I have a hard time making any sane judgement call.

In this particular case, the dual license is used by the OpenFabrics
Alliance.  They strip the RDMA stack in the kernel down to just the RDMA
stack files and ship those separate from the rest of the kernel, along
with the necessary user space stuff, and put the entire compilation
under the same dual GPL/BSD license.  That's what their OFED product is.

As I understand it, members of the OFA (Intel, Mellanox, Chelsio, etc.)
actually signed an agreement as part of their membership entry into OFA
that they would preserve that dual license when submitting code
upstream.  This was originally intended to make sure that the stack as a
whole could be used upstream, in distros, on switches, etc.  The idea
being that a unified stack that could be copied around would enhance
interoperability or something like that.

I can't speak to how actively used it is any more.  I think maybe on
switches or some other dedicated devices.  But, I was asked by the OFA
to try and preserve it.

In this particular case, Christoph wrote his code from scratch.  I'm not
concerned with it.  It was never dual licensed and need not be.  But he
did submit patches that modified existing dual license drivers to use
his new code and removed their own implementation of the same thing in
the process.  What used to be more or less functional drivers that could
be copied and used elsewhere will no longer be able to be copied in the
same way.  I'm just waiting for Sagi Grimberg to speak for iSER and for
Bart van Assche to speak for SRP and let me know that they are OK with
the change.  I think a patch set that will essentially change the
licensing nature of their code should carry their explicit approval of
the license change.

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

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