[Ofa_boardplus] OFA and Open Source

Jason Gunthorpe jgg at ziepe.ca
Thu Mar 15 13:00:28 PDT 2018

To be *extremely* clear, rdma-core has something like 7 licenses in
it. Only a few of those use the official OFA sanctioned BSD 2 clause
license text.

The best we can say about it is that it is all usable under GPLv2,
talk to your lawyers if you want to use rdma-core under a permissive
license, because 'it depends'.

For instance, some of the license varients prohibit advertising. So
printing "Product Foo! Now with rdma-core feature XYZ!" may contravene
the license if a non GPLv2 option is choosen.

This kind of license prolifieration is exactly what the OFA should
have prevented, and indeed tried to prevent via the license caluse in
the membership agreement. It is just unfortunate the agreement wasn't


On Thu, Mar 15, 2018 at 07:49:11PM +0000, Coulter, Susan K wrote:
>    Thank you Doug for pointing out kernel versus user space.
>    You are correct that the rdma-core repo was and is clean - my bad
>    there.
>    In fact, now that you remind me - you and Jason agreed to try and
>    retain dual license in that repo.  :)
>    Perhaps it was Woody who said the kernel was tainted before we (the OFA
>    board) fully took on discussing the dual license issue.
>    I know it was very clear to me early on that we had GPL-only code in
>    the code base and removing it was a non-starter.
>    ( hence my conviction that it was not introduced by moving the repo )
>    Again, thanx for the correction/clarification.
>    On Mar 15, 2018, at 1:37 PM, Doug Ledford <[1]dledford at redhat.com>
>    wrote:
>    On Thu, 2018-03-15 at 19:07 +0000, Coulter, Susan K wrote:
>      In my opinion, the dual license issue is dead and has been for a
>      while.
>      What I mean by that is - the ship has sailed - regardless of how or
>      why.
>    Agreed ;-)
>      It is my understanding from a recent side conversation that dual
>      license was never really expected to hold.
>      Dual license was agreed to early on to help the OFA members who
>      needed and relied on it.
>      It was more or less a given (amongst some) that as the code base
>      matured and disseminated, it would be nearly impossible to retain.
>      When Jason and company moved the code base from OFA to github, he
>      immediately reviewed the state of the licenses.
>      There were ~7 different licenses and we already had non-dual-license
>      code in the repo.
>    I'm pretty sure the rdma-core repo is still dual license clean at this
>    point.  But, I could  be wrong.  In any case, it was really the kernel
>    side where the lack of dual license is an issue.  And there, the
>    problem
>    crept in a while back due to code contributions from people that
>    specifically didn't want dual license.
>      So …
>      It is a fact that dual license was broken before the repo was moved.
>      The word “control” is pretty strong; we probably should use
>      “steward”.
>    Yes, steward is much better.  And in that context, it's easier to
>    understand why the dual license in the kernel was impossible to
>    maintain.  When someone writes code that significantly improves upon
>    existing code, and includes new code written from scratch in a new
>    file,
>    and places that code under GPL only, your stewardship is called into
>    question when you refuse to accept was is clearly an improvement to the
>    overall code base because it has a license you don't like but that is
>    the preferred, accepted license for the kernel itself.  This is why
>    breaking the dual license was mostly inevitable once the RDMA code made
>    it into the upstream kernel.  Outside actors doing good work.
>      The OFA was, in fact, the steward of the code in the beginning and
>      as it gained acceptance.
>      Whether or not the OFA actually failed as a “steward” is not a
>      question I can answer, but I am open to the fact that we may have
>      been remiss.
>      There are other OFA programs and processes that have atrophied
>      and/or we were remiss in staying actively on top of.
>      It is >possible< we missed a step somewhere.
>      I’m not saying these things to flog ourselves, but to honestly look
>      at our path.
>      As my husband and I like to ask at critical junctures:  “Where are
>      we, how did we get here, and where are we going?"
>      On Mar 15, 2018, at 12:50 PM, Paul Grun <[2]grun at cray.com> wrote:
>      I want to find closure on one open source/dual license item
>      discussed today.
>      It seems that there is broad agreement in the value of open source.
>       There is also some demand to continue to maintain dual licensing.
>      In the early days, OFA code (called OFS) was maintained in an OFA
>      repo created per the bylaws.
>      Hence the OFA could enforce the dual license provisions because the
>      OFA controlled the maintainer of that repo.
>      But since OFS was open source, anybody could fork the repo and
>      effectively deprecate the OFA repo, which is what happened.
>      Once the open source community made the choice to fork the code and
>      assign maintainers, the OFA could no longer rigorously enforce dual
>      license provisions, except by a gentleman’s / gentlewoman’s
>      agreement.
>      The OFA could not have prevented that from happening.
>      There are reasons why the community chose to do so (e.g.
>      dissatisfaction with an absentee maintainer or other reasons) that
>      perhaps the OFA could address
>      But at the end of the day, there is no legal agreement that would
>      prevent that from happening if someone were motivated to do so.
>      Hence, in my view, the notion of losing control is illusory, since
>      no such control exists, because OFS was open source.
>      Please educate me if this isn’t accurate.
>      -Paul
>      Advanced Technology Group
>      Cray, Inc.
>      Office  – (503) 620 – 8757
>      Mobile – (503) 703 - 5382
>      _______________________________________________
>      Ofa_boardplus mailing list
>      [3]Ofa_boardplus at lists.openfabrics.org
>      http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus
>      ================================
>      Susan Coulter
>      LANL / USRC / HPC-DES
>      Network Lead
>      (505) 412-6525
>      Lokah Samastah Sukhino Bhavantu
>      ================================
>      _______________________________________________
>      Ofa_boardplus mailing list
>      [4]Ofa_boardplus at lists.openfabrics.org
>      [5]http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus
>    ================================
>    Susan Coulter
>    Network Lead
>    (505) 412-6525
>    Lokah Samastah Sukhino Bhavantu
>    ================================
> References
>    1. mailto:dledford at redhat.com
>    2. mailto:grun at cray.com
>    3. mailto:Ofa_boardplus at lists.openfabrics.org
>    4. mailto:Ofa_boardplus at lists.openfabrics.org
>    5. http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus
>    6. mailto:dledford at redhat.com

> _______________________________________________
> Ofa_boardplus mailing list
> Ofa_boardplus at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus

More information about the Ofa_boardplus mailing list