Re: CQ and RDMA READ/WRITE APIs

Re: CQ and RDMA READ/WRITE APIs

[Christoph Hellwig]

[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, as they assumed
Linux code in genral is.  Іf dual-licensing is possible at all it would
require a lot of work, which I don't think is worth it.  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.

Re: CQ and RDMA READ/WRITE APIs

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 3289 bytes --]

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@redhat.com>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: CQ and RDMA READ/WRITE APIs

[Linus Torvalds]

On Mon, May 16, 2016 at 7:51 AM, Doug Ledford <dledford@redhat.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. 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.

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.

                  Linus

Re: CQ and RDMA READ/WRITE APIs

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 3860 bytes --]

On 05/16/2016 01:46 PM, Linus Torvalds wrote:
> On Mon, May 16, 2016 at 7:51 AM, Doug Ledford <dledford@redhat.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@redhat.com>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: CQ and RDMA READ/WRITE APIs

[Bart Van Assche]

On 05/16/2016 11:23 AM, Doug Ledford wrote:
> 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.

(+linux-rdma)

Hello Doug,

As far as I know SanDisk, a Western Digital Company, is fine with 
changing the license of the code under drivers/infiniband/ulp/srpt from 
dual licensed into GPL-only. However, if OFA members want that the 
entire RDMA core is dual licensed I think we will have to talk to Tejun:

$ PAGER= git grep EXPORT_SYMBOL_GPL drivers/infiniband/
drivers/infiniband/core/device.c:EXPORT_SYMBOL_GPL(ib_wq);

$ git show f06267104dd9112f11586830d22501d0e26245ea
commit f06267104dd9112f11586830d22501d0e26245ea
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Oct 19 15:24:36 2010 +0000

     RDMA: Update workqueue usage

[ ... ]
+struct workqueue_struct *ib_wq;
+EXPORT_SYMBOL_GPL(ib_wq);
[ ... ]

$ PAGER= git grep -lw ib_wq drivers/infiniband/
drivers/infiniband/core/cache.c
drivers/infiniband/core/device.c
drivers/infiniband/core/roce_gid_mgmt.c
drivers/infiniband/core/sa_query.c
drivers/infiniband/core/umem.c
drivers/infiniband/hw/qib/qib_iba7220.c
drivers/infiniband/hw/qib/qib_iba7322.c
drivers/infiniband/hw/qib/qib_init.c

Bart.

Re: CQ and RDMA READ/WRITE APIs

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 3442 bytes --]

On 05/17/2016 01:29 PM, Bart Van Assche wrote:
> On 05/16/2016 11:23 AM, Doug Ledford wrote:
>> 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.
> 
> (+linux-rdma)
> 
> Hello Doug,
> 
> As far as I know SanDisk, a Western Digital Company, is fine with
> changing the license of the code under drivers/infiniband/ulp/srpt from
> dual licensed into GPL-only. However, if OFA members want that the
> entire RDMA core is dual licensed I think we will have to talk to Tejun:
> 
> $ PAGER= git grep EXPORT_SYMBOL_GPL drivers/infiniband/
> drivers/infiniband/core/device.c:EXPORT_SYMBOL_GPL(ib_wq);
> 
> $ git show f06267104dd9112f11586830d22501d0e26245ea
> commit f06267104dd9112f11586830d22501d0e26245ea
> Author: Tejun Heo <tj@kernel.org>
> Date:   Tue Oct 19 15:24:36 2010 +0000
> 
>     RDMA: Update workqueue usage
> 
> [ ... ]
> +struct workqueue_struct *ib_wq;
> +EXPORT_SYMBOL_GPL(ib_wq);
> [ ... ]
> 
> $ PAGER= git grep -lw ib_wq drivers/infiniband/
> drivers/infiniband/core/cache.c
> drivers/infiniband/core/device.c
> drivers/infiniband/core/roce_gid_mgmt.c
> drivers/infiniband/core/sa_query.c
> drivers/infiniband/core/umem.c
> drivers/infiniband/hw/qib/qib_iba7220.c
> drivers/infiniband/hw/qib/qib_iba7322.c
> drivers/infiniband/hw/qib/qib_init.c

Nice catch there Bart.  That was well before my role as maintainer and
so settles things well enough for me.  IOW, I don't feel I need to worry
about trying to maintain the dual license nature of the RDMA stack as it
was broken long before I took over.  Thanks for pointing that out.


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: CQ and RDMA READ/WRITE APIs

[Linus Torvalds]

On Tue, May 17, 2016 at 10:32 AM, Doug Ledford <dledford@redhat.com> wrote:
>
> Nice catch there Bart.  That was well before my role as maintainer and
> so settles things well enough for me.  IOW, I don't feel I need to worry
> about trying to maintain the dual license nature of the RDMA stack as it
> was broken long before I took over.  Thanks for pointing that out.

Ok, so it sounds like there isn't really a problem. Good.

              Linus

Re: CQ and RDMA READ/WRITE APIs

[Parav Pandit]

Hi Doug,

On Tue, May 17, 2016 at 11:02 PM, Doug Ledford <dledford@redhat.com> wrote:
> Nice catch there Bart.  That was well before my role as maintainer and
> so settles things well enough for me.  IOW, I don't feel I need to worry
> about trying to maintain the dual license nature of the RDMA stack as it
> was broken long before I took over.  Thanks for pointing that out.
>

Does it mean we can submit new code files under GPL only license?
I submitted RDMA cgroup related code in ib_core under GPLv2 only license.
Existing files which are calling those new APIs will continue to be
dual license (similar to CQ and RDMA APIs)?

Parav

Re: CQ and RDMA READ/WRITE APIs

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

On 05/17/2016 10:48 PM, Parav Pandit wrote:
> Hi Doug,
> 
> On Tue, May 17, 2016 at 11:02 PM, Doug Ledford <dledford@redhat.com> wrote:
>> Nice catch there Bart.  That was well before my role as maintainer and
>> so settles things well enough for me.  IOW, I don't feel I need to worry
>> about trying to maintain the dual license nature of the RDMA stack as it
>> was broken long before I took over.  Thanks for pointing that out.
>>
> 
> Does it mean we can submit new code files under GPL only license?

You always could.

> I submitted RDMA cgroup related code in ib_core under GPLv2 only license.

You did and you didn't.  For instance, in patch 1/3, the new
cgroup_rdma.c file has a notice of GPLv2, but no notice of copyright, so
it's incomplete.  You need to put a copyright notice in the file too.
And in the file cgroup_rdma.h you have neither a copyright notice or a
license statement.  It's a plain file.

In patch 2/3, the file infiniband/core/cgroup.c has a copied dual
license (not necessary, it can be GPL only), but again, it is missing
the copyright notice.

You need to finish the conversation you and Christoph were having in
that thread, but you also need a v11 of the patchset that fixes the
copyright issues.

> Existing files which are calling those new APIs will continue to be
> dual license (similar to CQ and RDMA APIs)?

Yes.


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: CQ and RDMA READ/WRITE APIs

[Parav Pandit]

On Wed, May 18, 2016 at 7:37 PM, Doug Ledford <dledford@redhat.com> wrote:
> On 05/17/2016 10:48 PM, Parav Pandit wrote:
>> Hi Doug,
>>
>> On Tue, May 17, 2016 at 11:02 PM, Doug Ledford <dledford@redhat.com> wrote:
>>> Nice catch there Bart.  That was well before my role as maintainer and
>>> so settles things well enough for me.  IOW, I don't feel I need to worry
>>> about trying to maintain the dual license nature of the RDMA stack as it
>>> was broken long before I took over.  Thanks for pointing that out.
>>>
>>
>> Does it mean we can submit new code files under GPL only license?
>
> You always could.
>
>> I submitted RDMA cgroup related code in ib_core under GPLv2 only license.
>
> You did and you didn't.  For instance, in patch 1/3, the new
> cgroup_rdma.c file has a notice of GPLv2, but no notice of copyright, so
> it's incomplete.  You need to put a copyright notice in the file too.
> And in the file cgroup_rdma.h you have neither a copyright notice or a
> license statement.  It's a plain file.
>
> In patch 2/3, the file infiniband/core/cgroup.c has a copied dual
> license (not necessary, it can be GPL only), but again, it is missing
> the copyright notice.
>
ok. I will fix this part too in v11.

> You need to finish the conversation you and Christoph were having in
> that thread, but you also need a v11 of the patchset that fixes the
> copyright issues.
>
Yes. I will ping Christoph and Tejun as I am waiting for their responses.

Re: CQ and RDMA READ/WRITE APIs

[Christoph Hellwig]

Hi Linus,

we're not talking about a driver here - we're talking about a new API
lifted from a driver to generic code because it's commonly useful.

It's also in entirely new files and not a modification of existing code,
and it's always been clear how it is.  Some of the code has been in
since Linux 4.5 with a properly clear copyright.

I really don't understand Doug's objection, and as said if they have
a weird problem with it we can simply move it to a separate module.

Re: CQ and RDMA READ/WRITE APIs

[Christoph Lameter]

On Tue, 17 May 2016, Christoph Hellwig wrote:

> It's also in entirely new files and not a modification of existing code,
> and it's always been clear how it is.  Some of the code has been in
> since Linux 4.5 with a properly clear copyright.


The problem is that the RDMA subsystem is rather more than a driver. Its a
subsystem that contains drivers.  Dual licensed drivers can use the
features that Christoph provides. This is more infrastructure and thus GPL
I thought.

Re: CQ and RDMA READ/WRITE APIs

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

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, as they assumed
> Linux code in genral is.  Іf dual-licensing is possible at all it would
> require a lot of work, which I don't think is worth it.  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.
> 

BTW, please keep me on the Cc: for any replies as I don't track
linux-kernel.

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]