[Ofa_boardplus] OFA and Open Source

[Coulter, Susan K]

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 <dledford at redhat.com<mailto: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 <grun at cray.com<mailto: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
Ofa_boardplus at lists.openfabrics.org<mailto: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
Ofa_boardplus at lists.openfabrics.org<mailto:Ofa_boardplus at lists.openfabrics.org>
http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus

--
Doug Ledford <dledford at redhat.com<mailto:dledford at redhat.com>>
   GPG KeyID: B826A3330E572FDD
   Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

================================
Susan Coulter
LANL / USRC / HPC-DES
Network Lead
(505) 412-6525
Lokah Samastah Sukhino Bhavantu
================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofa_boardplus/attachments/20180315/86b272e8/attachment.html>