DPDK community structure changes
 help / color / Atom feed
* [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
@ 2016-11-30 16:01 O'Driscoll, Tim
  2016-11-30 17:10 ` Thomas Monjalon
  2016-11-30 17:39 ` Michael Dolan
  0 siblings, 2 replies; 19+ messages in thread
From: O'Driscoll, Tim @ 2016-11-30 16:01 UTC (permalink / raw)
  To: moving

Here are my notes from Tuesday's call. Please feel free to correct any errors or to add additional details.

Attendees: Dave Neary (Red Hat), Ed Warnicke (Cisco), Francois-Frederic Ozog (Linaro), Hemant Agrawal (NXP), Jan Blunck (Brocade), Jaswinder Singh (NXP), Jerin Jacob (Cavium), Jim St. Leger (Intel), John McNamara (Intel), Keith Wiles (Intel), Olga Shern (Mellanox), Thomas Monjalon (6WIND), Tim O'Driscoll (Intel), Vincent Jardin (6WIND). Note that there may have been others, but as people joined at different times it was difficult to keep track.

Firstly, here are some links to help keep track of things:
Project Charter: https://docs.google.com/document/d/1x43ycfW3arJNX-e6NQt3OVzAuNXtD7dppIhrY48FoGs
Summary of discussion at Userspace event in Dublin: http://dpdk.org/ml/archives/dev/2016-October/049259.html
Minutes of October 31st call: http://dpdk.org/ml/archives/moving/2016-November/000031.html
Minutes of November 8th call: http://dpdk.org/ml/archives/moving/2016-November/000058.html
Minutes of November 15th call: http://dpdk.org/ml/archives/moving/2016-November/000061.html
Minutes of November 22nd call: http://dpdk.org/ml/archives/moving/2016-November/000085.html
Current technical governance, including composition of the Tech Board: http://dpdk.org/doc/guides/contributing/index.html & http://dpdk.org/dev.


1. Discussed Contributor License Agreement (CLA) vs Developer Certificate of Origin (DCO)
- Current process is to use a DCO.
- Francois-Frederic proposed using a CLA. This is based on input from the Linaro legal team and some Linaro members who have indicated that not having a CLA prevents them contributing to or using DPDK.
- Discussed what benefit they think they'll get from CLA. The main thing it adds is patent protection. This could be achieved in other ways, for example using the Apache 2.0 license. Neither solution would apply to existing DPDK code though so any benefit would only apply to new code.
- Vincent asked if there are problems with other BSD licensed projects. We agreed to check with the Linux Foundation (Mike Dolan) to see if they have any guidance based on other BSD licensed projects. I'll ask Mike.

2. Discussed comments on project charter
- Agreed that the Governing Board does not specify requirements for the Technical Board to implement. The two boards are peers. One can make suggestions to the other at any time, but these aren't requirements and don't have to be accepted.
- Discussed how members are added to/removed from the Technical Board. Agreed that the TB approves adding/removing members. Agreed that the TB needs to consider technical contributions from the individuals and support for all architectures when making these decisions.
- Discussed Dave's proposal for a representative of the technical community on the GB (in addition to the rep from the TB). Agreed not to do this and just to keep the single rep from the TB on the GB. Also discussed whether there should be a GB rep on the TB and agreed that this did not make sense.
- For voting, agreed that the quorum for a meeting for either board is 50% of the members. Majority required to pass a vote is 50% of the total board except for: a) changes to the charter require 2/3 of the GB; b) licensing exceptions require 2/3 of the GB.
- I've updated the charter (section 3 - Project Governance) to reflect these changes.


Next Meeting:
Tuesday December 6th at 3pm GMT, 4pm CET, 10am EST, 7am PST. We'll focus on the comments on the Membership and Technical Governance sections of the charter, and also discuss CLA/DCO if we have more input/guidance on this from the LF.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-11-30 16:01 [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th O'Driscoll, Tim
@ 2016-11-30 17:10 ` Thomas Monjalon
  2016-11-30 22:08   ` O'Driscoll, Tim
  2016-11-30 17:39 ` Michael Dolan
  1 sibling, 1 reply; 19+ messages in thread
From: Thomas Monjalon @ 2016-11-30 17:10 UTC (permalink / raw)
  To: moving; +Cc: O'Driscoll, Tim

2016-11-30 16:01, O'Driscoll, Tim:
> - For voting, agreed that the quorum for a meeting for either board is 50% of the members. Majority required to pass a vote is 50% of the total board except for: a) changes to the charter require 2/3 of the GB; b) licensing exceptions require 2/3 of the GB.

The current quorum for the TB is 6/7. 50% is a big change.

> - I've updated the charter (section 3 - Project Governance) to reflect these changes.

I wonder what part of the TB process must be in this charter.
I think we agreed that the TB process must be documented elsewhere?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-11-30 16:01 [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th O'Driscoll, Tim
  2016-11-30 17:10 ` Thomas Monjalon
@ 2016-11-30 17:39 ` Michael Dolan
  2016-11-30 20:55   ` Dave Neary
  2016-12-01 17:40   ` O'Driscoll, Tim
  1 sibling, 2 replies; 19+ messages in thread
From: Michael Dolan @ 2016-11-30 17:39 UTC (permalink / raw)
  To: O'Driscoll, Tim; +Cc: moving

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

Hi Tim, sorry I couldn't make it with a LF Board meeting conflict
yesterday. As for 1), most/all of our projects facing this issue decide to
go Apache 2. A CLA is less preferably particularly with the BSD license.
Where we do use a CLA on a project it's usually the same as the Apache
CCLA/ICLA and that combined with the BSD license will I'm fairly certain
not achieve what Linaro legal is probably concerned about.

My guess is the members here are 90% or more of the contributors and a
relicensing effort could be done within a reasonable timeframe. The project
could also start under the LF with all new contributions under the Apache 2
license which is compatible with all prior BSD contributions. Or you could
just required Apache 2 on any future contributions and keep the prior BSD
if the relicensing is not agreeable to others.

Just some thoughts on how other projects tackled this question. It would
probably be best if we push any further discussion on this to a small group
of your legal counsel as the various levers have different implications and
I'm uncomfortable continuing this discussion without your counsel being
involved.

Thanks,

Mike



On Wed, Nov 30, 2016 at 9:01 AM, O'Driscoll, Tim <tim.odriscoll@intel.com>
wrote:

> Here are my notes from Tuesday's call. Please feel free to correct any
> errors or to add additional details.
>
> Attendees: Dave Neary (Red Hat), Ed Warnicke (Cisco), Francois-Frederic
> Ozog (Linaro), Hemant Agrawal (NXP), Jan Blunck (Brocade), Jaswinder Singh
> (NXP), Jerin Jacob (Cavium), Jim St. Leger (Intel), John McNamara (Intel),
> Keith Wiles (Intel), Olga Shern (Mellanox), Thomas Monjalon (6WIND), Tim
> O'Driscoll (Intel), Vincent Jardin (6WIND). Note that there may have been
> others, but as people joined at different times it was difficult to keep
> track.
>
> Firstly, here are some links to help keep track of things:
> Project Charter: https://docs.google.com/document/d/1x43ycfW3arJNX-
> e6NQt3OVzAuNXtD7dppIhrY48FoGs
> Summary of discussion at Userspace event in Dublin:
> http://dpdk.org/ml/archives/dev/2016-October/049259.html
> Minutes of October 31st call: http://dpdk.org/ml/archives/
> moving/2016-November/000031.html
> Minutes of November 8th call: http://dpdk.org/ml/archives/
> moving/2016-November/000058.html
> Minutes of November 15th call: http://dpdk.org/ml/archives/
> moving/2016-November/000061.html
> Minutes of November 22nd call: http://dpdk.org/ml/archives/
> moving/2016-November/000085.html
> Current technical governance, including composition of the Tech Board:
> http://dpdk.org/doc/guides/contributing/index.html & http://dpdk.org/dev.
>
>
> 1. Discussed Contributor License Agreement (CLA) vs Developer Certificate
> of Origin (DCO)
> - Current process is to use a DCO.
> - Francois-Frederic proposed using a CLA. This is based on input from the
> Linaro legal team and some Linaro members who have indicated that not
> having a CLA prevents them contributing to or using DPDK.
> - Discussed what benefit they think they'll get from CLA. The main thing
> it adds is patent protection. This could be achieved in other ways, for
> example using the Apache 2.0 license. Neither solution would apply to
> existing DPDK code though so any benefit would only apply to new code.
> - Vincent asked if there are problems with other BSD licensed projects. We
> agreed to check with the Linux Foundation (Mike Dolan) to see if they have
> any guidance based on other BSD licensed projects. I'll ask Mike.
>
> 2. Discussed comments on project charter
> - Agreed that the Governing Board does not specify requirements for the
> Technical Board to implement. The two boards are peers. One can make
> suggestions to the other at any time, but these aren't requirements and
> don't have to be accepted.
> - Discussed how members are added to/removed from the Technical Board.
> Agreed that the TB approves adding/removing members. Agreed that the TB
> needs to consider technical contributions from the individuals and support
> for all architectures when making these decisions.
> - Discussed Dave's proposal for a representative of the technical
> community on the GB (in addition to the rep from the TB). Agreed not to do
> this and just to keep the single rep from the TB on the GB. Also discussed
> whether there should be a GB rep on the TB and agreed that this did not
> make sense.
> - For voting, agreed that the quorum for a meeting for either board is 50%
> of the members. Majority required to pass a vote is 50% of the total board
> except for: a) changes to the charter require 2/3 of the GB; b) licensing
> exceptions require 2/3 of the GB.
> - I've updated the charter (section 3 - Project Governance) to reflect
> these changes.
>
>
> Next Meeting:
> Tuesday December 6th at 3pm GMT, 4pm CET, 10am EST, 7am PST. We'll focus
> on the comments on the Membership and Technical Governance sections of the
> charter, and also discuss CLA/DCO if we have more input/guidance on this
> from the LF.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 6573 bytes --]

<div dir="ltr">Hi Tim, sorry I couldn&#39;t make it with a LF Board meeting conflict yesterday. As for 1), most/all of our projects facing this issue decide to go Apache 2. A CLA is less preferably particularly with the BSD license. Where we do use a CLA on a project it&#39;s usually the same as the Apache CCLA/ICLA and that combined with the BSD license will I&#39;m fairly certain not achieve what Linaro legal is probably concerned about.<div><br></div><div>My guess is the members here are 90% or more of the contributors and a relicensing effort could be done within a reasonable timeframe. The project could also start under the LF with all new contributions under the Apache 2 license which is compatible with all prior BSD contributions. Or you could just required Apache 2 on any future contributions and keep the prior BSD if the relicensing is not agreeable to others.</div><div><br></div><div>Just some thoughts on how other projects tackled this question. It would probably be best if we push any further discussion on this to a small group of your legal counsel as the various levers have different implications and I&#39;m uncomfortable continuing this discussion without your counsel being involved.</div><div><br></div><div>Thanks,</div><div><br></div><div>Mike</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">







<p><br></p></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Nov 30, 2016 at 9:01 AM, O&#39;Driscoll, Tim <span dir="ltr">&lt;<a href="mailto:tim.odriscoll@intel.com" target="_blank">tim.odriscoll@intel.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here are my notes from Tuesday&#39;s call. Please feel free to correct any errors or to add additional details.<br>
<br>
Attendees: Dave Neary (Red Hat), Ed Warnicke (Cisco), Francois-Frederic Ozog (Linaro), Hemant Agrawal (NXP), Jan Blunck (Brocade), Jaswinder Singh (NXP), Jerin Jacob (Cavium), Jim St. Leger (Intel), John McNamara (Intel), Keith Wiles (Intel), Olga Shern (Mellanox), Thomas Monjalon (6WIND), Tim O&#39;Driscoll (Intel), Vincent Jardin (6WIND). Note that there may have been others, but as people joined at different times it was difficult to keep track.<br>
<br>
Firstly, here are some links to help keep track of things:<br>
Project Charter: <a href="https://docs.google.com/document/d/1x43ycfW3arJNX-e6NQt3OVzAuNXtD7dppIhrY48FoGs" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>document/d/1x43ycfW3arJNX-<wbr>e6NQt3OVzAuNXtD7dppIhrY48FoGs</a><br>
Summary of discussion at Userspace event in Dublin: <a href="http://dpdk.org/ml/archives/dev/2016-October/049259.html" rel="noreferrer" target="_blank">http://dpdk.org/ml/archives/<wbr>dev/2016-October/049259.html</a><br>
Minutes of October 31st call: <a href="http://dpdk.org/ml/archives/moving/2016-November/000031.html" rel="noreferrer" target="_blank">http://dpdk.org/ml/archives/<wbr>moving/2016-November/000031.<wbr>html</a><br>
Minutes of November 8th call: <a href="http://dpdk.org/ml/archives/moving/2016-November/000058.html" rel="noreferrer" target="_blank">http://dpdk.org/ml/archives/<wbr>moving/2016-November/000058.<wbr>html</a><br>
Minutes of November 15th call: <a href="http://dpdk.org/ml/archives/moving/2016-November/000061.html" rel="noreferrer" target="_blank">http://dpdk.org/ml/archives/<wbr>moving/2016-November/000061.<wbr>html</a><br>
Minutes of November 22nd call: <a href="http://dpdk.org/ml/archives/moving/2016-November/000085.html" rel="noreferrer" target="_blank">http://dpdk.org/ml/archives/<wbr>moving/2016-November/000085.<wbr>html</a><br>
Current technical governance, including composition of the Tech Board: <a href="http://dpdk.org/doc/guides/contributing/index.html" rel="noreferrer" target="_blank">http://dpdk.org/doc/guides/<wbr>contributing/index.html</a> &amp; <a href="http://dpdk.org/dev" rel="noreferrer" target="_blank">http://dpdk.org/dev</a>.<br>
<br>
<br>
1. Discussed Contributor License Agreement (CLA) vs Developer Certificate of Origin (DCO)<br>
- Current process is to use a DCO.<br>
- Francois-Frederic proposed using a CLA. This is based on input from the Linaro legal team and some Linaro members who have indicated that not having a CLA prevents them contributing to or using DPDK.<br>
- Discussed what benefit they think they&#39;ll get from CLA. The main thing it adds is patent protection. This could be achieved in other ways, for example using the Apache 2.0 license. Neither solution would apply to existing DPDK code though so any benefit would only apply to new code.<br>
- Vincent asked if there are problems with other BSD licensed projects. We agreed to check with the Linux Foundation (Mike Dolan) to see if they have any guidance based on other BSD licensed projects. I&#39;ll ask Mike.<br>
<br>
2. Discussed comments on project charter<br>
- Agreed that the Governing Board does not specify requirements for the Technical Board to implement. The two boards are peers. One can make suggestions to the other at any time, but these aren&#39;t requirements and don&#39;t have to be accepted.<br>
- Discussed how members are added to/removed from the Technical Board. Agreed that the TB approves adding/removing members. Agreed that the TB needs to consider technical contributions from the individuals and support for all architectures when making these decisions.<br>
- Discussed Dave&#39;s proposal for a representative of the technical community on the GB (in addition to the rep from the TB). Agreed not to do this and just to keep the single rep from the TB on the GB. Also discussed whether there should be a GB rep on the TB and agreed that this did not make sense.<br>
- For voting, agreed that the quorum for a meeting for either board is 50% of the members. Majority required to pass a vote is 50% of the total board except for: a) changes to the charter require 2/3 of the GB; b) licensing exceptions require 2/3 of the GB.<br>
- I&#39;ve updated the charter (section 3 - Project Governance) to reflect these changes.<br>
<br>
<br>
Next Meeting:<br>
Tuesday December 6th at 3pm GMT, 4pm CET, 10am EST, 7am PST. We&#39;ll focus on the comments on the Membership and Technical Governance sections of the charter, and also discuss CLA/DCO if we have more input/guidance on this from the LF.<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-11-30 17:39 ` Michael Dolan
@ 2016-11-30 20:55   ` Dave Neary
  2016-12-01 17:40   ` O'Driscoll, Tim
  1 sibling, 0 replies; 19+ messages in thread
From: Dave Neary @ 2016-11-30 20:55 UTC (permalink / raw)
  To: Michael Dolan, O'Driscoll, Tim; +Cc: moving

Hi Mike,

On 11/30/2016 12:39 PM, Michael Dolan wrote:
> Hi Tim, sorry I couldn't make it with a LF Board meeting conflict
> yesterday. As for 1), most/all of our projects facing this issue decide
> to go Apache 2. A CLA is less preferably particularly with the BSD
> license. Where we do use a CLA on a project it's usually the same as the
> Apache CCLA/ICLA and that combined with the BSD license will I'm fairly
> certain not achieve what Linaro legal is probably concerned about.

A follow-on question: Has the Linux Foundation ever taken on a BSD
licensed project in the past? Given that the project has an existing
history and license, a license change might be a more involved change
(both practically and culturally) than the technical community woiuld be
prepared for.

> Just some thoughts on how other projects tackled this question. It would
> probably be best if we push any further discussion on this to a small
> group of your legal counsel as the various levers have different
> implications and I'm uncomfortable continuing this discussion without
> your counsel being involved.

Hopefully an answer specifically about what has been done in the past
would be OK - I understand you don't want to get into the area of advice
here.

Thanks,
Dave.

> On Wed, Nov 30, 2016 at 9:01 AM, O'Driscoll, Tim
> <tim.odriscoll@intel.com <mailto:tim.odriscoll@intel.com>> wrote:
> 
>     Here are my notes from Tuesday's call. Please feel free to correct
>     any errors or to add additional details.
> 
>     Attendees: Dave Neary (Red Hat), Ed Warnicke (Cisco),
>     Francois-Frederic Ozog (Linaro), Hemant Agrawal (NXP), Jan Blunck
>     (Brocade), Jaswinder Singh (NXP), Jerin Jacob (Cavium), Jim St.
>     Leger (Intel), John McNamara (Intel), Keith Wiles (Intel), Olga
>     Shern (Mellanox), Thomas Monjalon (6WIND), Tim O'Driscoll (Intel),
>     Vincent Jardin (6WIND). Note that there may have been others, but as
>     people joined at different times it was difficult to keep track.
> 
>     Firstly, here are some links to help keep track of things:
>     Project Charter:
>     https://docs.google.com/document/d/1x43ycfW3arJNX-e6NQt3OVzAuNXtD7dppIhrY48FoGs
>     <https://docs.google.com/document/d/1x43ycfW3arJNX-e6NQt3OVzAuNXtD7dppIhrY48FoGs>
>     Summary of discussion at Userspace event in Dublin:
>     http://dpdk.org/ml/archives/dev/2016-October/049259.html
>     <http://dpdk.org/ml/archives/dev/2016-October/049259.html>
>     Minutes of October 31st call:
>     http://dpdk.org/ml/archives/moving/2016-November/000031.html
>     <http://dpdk.org/ml/archives/moving/2016-November/000031.html>
>     Minutes of November 8th call:
>     http://dpdk.org/ml/archives/moving/2016-November/000058.html
>     <http://dpdk.org/ml/archives/moving/2016-November/000058.html>
>     Minutes of November 15th call:
>     http://dpdk.org/ml/archives/moving/2016-November/000061.html
>     <http://dpdk.org/ml/archives/moving/2016-November/000061.html>
>     Minutes of November 22nd call:
>     http://dpdk.org/ml/archives/moving/2016-November/000085.html
>     <http://dpdk.org/ml/archives/moving/2016-November/000085.html>
>     Current technical governance, including composition of the Tech
>     Board: http://dpdk.org/doc/guides/contributing/index.html
>     <http://dpdk.org/doc/guides/contributing/index.html> &
>     http://dpdk.org/dev.
> 
> 
>     1. Discussed Contributor License Agreement (CLA) vs Developer
>     Certificate of Origin (DCO)
>     - Current process is to use a DCO.
>     - Francois-Frederic proposed using a CLA. This is based on input
>     from the Linaro legal team and some Linaro members who have
>     indicated that not having a CLA prevents them contributing to or
>     using DPDK.
>     - Discussed what benefit they think they'll get from CLA. The main
>     thing it adds is patent protection. This could be achieved in other
>     ways, for example using the Apache 2.0 license. Neither solution
>     would apply to existing DPDK code though so any benefit would only
>     apply to new code.
>     - Vincent asked if there are problems with other BSD licensed
>     projects. We agreed to check with the Linux Foundation (Mike Dolan)
>     to see if they have any guidance based on other BSD licensed
>     projects. I'll ask Mike.
> 
>     2. Discussed comments on project charter
>     - Agreed that the Governing Board does not specify requirements for
>     the Technical Board to implement. The two boards are peers. One can
>     make suggestions to the other at any time, but these aren't
>     requirements and don't have to be accepted.
>     - Discussed how members are added to/removed from the Technical
>     Board. Agreed that the TB approves adding/removing members. Agreed
>     that the TB needs to consider technical contributions from the
>     individuals and support for all architectures when making these
>     decisions.
>     - Discussed Dave's proposal for a representative of the technical
>     community on the GB (in addition to the rep from the TB). Agreed not
>     to do this and just to keep the single rep from the TB on the GB.
>     Also discussed whether there should be a GB rep on the TB and agreed
>     that this did not make sense.
>     - For voting, agreed that the quorum for a meeting for either board
>     is 50% of the members. Majority required to pass a vote is 50% of
>     the total board except for: a) changes to the charter require 2/3 of
>     the GB; b) licensing exceptions require 2/3 of the GB.
>     - I've updated the charter (section 3 - Project Governance) to
>     reflect these changes.
> 
> 
>     Next Meeting:
>     Tuesday December 6th at 3pm GMT, 4pm CET, 10am EST, 7am PST. We'll
>     focus on the comments on the Membership and Technical Governance
>     sections of the charter, and also discuss CLA/DCO if we have more
>     input/guidance on this from the LF.
> 
> 
> 
> 

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-11-30 17:10 ` Thomas Monjalon
@ 2016-11-30 22:08   ` O'Driscoll, Tim
  2016-12-01  9:20     ` Thomas Monjalon
  0 siblings, 1 reply; 19+ messages in thread
From: O'Driscoll, Tim @ 2016-11-30 22:08 UTC (permalink / raw)
  To: Thomas Monjalon, moving


> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, November 30, 2016 5:10 PM
> To: moving@dpdk.org
> Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>
> Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux
> Foundation" call, November 29th
> 
> 2016-11-30 16:01, O'Driscoll, Tim:
> > - For voting, agreed that the quorum for a meeting for either board is
> 50% of the members. Majority required to pass a vote is 50% of the total
> board except for: a) changes to the charter require 2/3 of the GB; b)
> licensing exceptions require 2/3 of the GB.
> 
> The current quorum for the TB is 6/7. 50% is a big change.

I'm not sure where 6/7 was agreed,  but I'd be against that for a few reasons:
- Requiring a 6/7 majority makes it very difficult to pass a vote because almost everybody has to be available, in attendance and in agreement.
- It means that companies that have two representatives on the board (currently Intel and 6WIND) effectively have a veto.
- A minor point, but whatever level we decide on should be expressed as a percentage so that it's applicable if/when the board size changes.

> 
> > - I've updated the charter (section 3 - Project Governance) to reflect
> these changes.
> 
> I wonder what part of the TB process must be in this charter.
> I think we agreed that the TB process must be documented elsewhere?

All the other LF project charters that I've looked at include the composition/responsibilities/process of their Tech Board/TSC. If this body is responsible for technical oversight of the project, then I think it needs to be agreed and documented in the charter.

My proposal is that we include the Tech Board in the charter doc, but leave the lower-level details of the day-to-day governance (maintainers, how they're added/removed etc.) to the Contributor's Guidelines. We can discuss and agree how much needs to be in the charter at the next meeting.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-11-30 22:08   ` O'Driscoll, Tim
@ 2016-12-01  9:20     ` Thomas Monjalon
  2016-12-01  9:40       ` O'Driscoll, Tim
  0 siblings, 1 reply; 19+ messages in thread
From: Thomas Monjalon @ 2016-12-01  9:20 UTC (permalink / raw)
  To: O'Driscoll, Tim; +Cc: moving

2016-11-30 22:08, O'Driscoll, Tim:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-11-30 16:01, O'Driscoll, Tim:
> > > - For voting, agreed that the quorum for a meeting for either board is
> > 50% of the members. Majority required to pass a vote is 50% of the total
> > board except for: a) changes to the charter require 2/3 of the GB; b)
> > licensing exceptions require 2/3 of the GB.
> > 
> > The current quorum for the TB is 6/7. 50% is a big change.
> 
> I'm not sure where 6/7 was agreed,

It was defined by the technical board.

> but I'd be against that for a few reasons:
> - Requiring a 6/7 majority makes it very difficult to pass a vote because almost everybody has to be available, in attendance and in agreement.

No, it is an attendance quorum. It means we cannot take a decision
if too many members are missing.
The vote is at majority (50%).

> - It means that companies that have two representatives on the board (currently Intel and 6WIND) effectively have a veto.

See above, 50% avoid such veto.

> - A minor point, but whatever level we decide on should be expressed as a percentage so that it's applicable if/when the board size changes.

Yes, that's why I've suggested in the charter a 70% quorum if I remember well
(but I cannot find it anymore and history is disabled).

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01  9:20     ` Thomas Monjalon
@ 2016-12-01  9:40       ` O'Driscoll, Tim
  0 siblings, 0 replies; 19+ messages in thread
From: O'Driscoll, Tim @ 2016-12-01  9:40 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: moving


> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, December 1, 2016 9:21 AM
> To: O'Driscoll, Tim <tim.odriscoll@intel.com>
> Cc: moving@dpdk.org
> Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux
> Foundation" call, November 29th
> 
> 2016-11-30 22:08, O'Driscoll, Tim:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 2016-11-30 16:01, O'Driscoll, Tim:
> > > > - For voting, agreed that the quorum for a meeting for either
> board is
> > > 50% of the members. Majority required to pass a vote is 50% of the
> total
> > > board except for: a) changes to the charter require 2/3 of the GB;
> b)
> > > licensing exceptions require 2/3 of the GB.
> > >
> > > The current quorum for the TB is 6/7. 50% is a big change.
> >
> > I'm not sure where 6/7 was agreed,
> 
> It was defined by the technical board.
> 
> > but I'd be against that for a few reasons:
> > - Requiring a 6/7 majority makes it very difficult to pass a vote
> because almost everybody has to be available, in attendance and in
> agreement.
> 
> No, it is an attendance quorum. It means we cannot take a decision
> if too many members are missing.
> The vote is at majority (50%).

That makes sense. Apologies for my misunderstanding. I think having the majority required to pass a vote at 50% is good. We can discuss the quorum required for a meeting again, but the concern that was expressed with making it higher was just that it makes it more difficult to get enough people together to proceed.

> 
> > - It means that companies that have two representatives on the board
> (currently Intel and 6WIND) effectively have a veto.
> 
> See above, 50% avoid such veto.
> 
> > - A minor point, but whatever level we decide on should be expressed
> as a percentage so that it's applicable if/when the board size changes.
> 
> Yes, that's why I've suggested in the charter a 70% quorum if I remember
> well
> (but I cannot find it anymore and history is disabled).

I'm far from an expert in Google docs, but I can see the revision history via File -> See Revision history, and see all the comments (including those marked as resolved) by opening the comments thread via the "Comments" button in the top right corner. As above though, the concern over a higher quota was just the difficult in getting enough people together for a meeting to proceed in a timely manner. We can discuss again though and see if this should be higher.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-11-30 17:39 ` Michael Dolan
  2016-11-30 20:55   ` Dave Neary
@ 2016-12-01 17:40   ` O'Driscoll, Tim
  2016-12-01 17:46     ` Ed Warnicke
                       ` (2 more replies)
  1 sibling, 3 replies; 19+ messages in thread
From: O'Driscoll, Tim @ 2016-12-01 17:40 UTC (permalink / raw)
  To: Michael Dolan, moving

Thanks Mike. I realise you can’t say too much in public about what is essentially a legal issue.

To summarise, these are the options we seem to have:

1. Continue with BSD license and DCO:
Advantages: Easy (nothing changes). This combination has worked well for several years with many companies contributing to the project and deploying DPDK-based solutions. No CLA required.
Disadvantages: Some Linaro members may not be able to contribute and/or deploy DPDK-based solutions.

2. Use Apache 2 for new contributions:
Advantages: It’s a fairly easy change. Provides patent protection for new contributions. No CLA required.
Disadvantages: Doesn’t cover the existing DPDK code so the actual benefit of this is very small.

3. Use Apache 2 and re-license existing code:
Advantages: Patent protection for everything. No CLA required.
Disadvantage: We need to re-license everything. I suspect that’s a big effort and it will be very difficult to get agreement from everybody who's contributed. We would also need to consider DPDK code that’s dual-licensed. We have some code that’s dual BSD-GPLv2. IANAL, and I'm far from an expert on SW licensing, but I think Apache 2 is not compatible with GPLv2, so this might need to become Apache 2/GPLv3.

4. Use BSD and CLA:
Advantages: No license change. Provides patent protection for new contributions.
Disadvantages: Doesn’t cover the existing DPDK code so the actual benefit of this is very small. Need for a CLA is a problem for some contributors due to the need to get legal approval. Mike expressed concerns below about the combination of the Apache CLA and BSD license, so we'd need to create and agree a custom CLA.

5. Use BSD and CLA, and have the CLA apply retrospectively to existing code:
Advantages: No license change. Patent protection for everything.
Disadvantages: Don't know if this is even possible - can a CLA apply retrospectively to existing code? Need for a CLA is a problem for some contributors due to the need to get legal approval (presumably an even bigger problem if the CLA applies retrospectively). Mike expressed concerns below about the combination of the Apache CLA and BSD license, so we'd need to create and agree a custom CLA. Same logistical issues as for re-licensing - we'd need to track down and get agreement from all previous contributors.

Note that I’m assuming that the combination of Apache 2 and a CLA isn't an option because this seems redundant as both include patent protection. Maybe there are other reasons that would make this a valid combination though.

We do need to reach a conclusion on this and move forward. We should aim to resolve it at next week's meeting, so people should consider their position in advance of that. My vote would be for option 1.


Tim

> From: Michael Dolan [mailto:mdolan@linuxfoundation.org] 
> Sent: Wednesday, November 30, 2016 5:39 PM
> To: O'Driscoll, Tim <tim.odriscoll@intel.com>
> Cc: moving@dpdk.org
> Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
>
> Hi Tim, sorry I couldn't make it with a LF Board meeting conflict yesterday. As for 1), most/all of our projects facing this issue decide to go Apache 2. A CLA is less preferably particularly with the BSD license. Where we do use a CLA on a project it's usually the same as the Apache CCLA/ICLA and that combined with the BSD license will I'm fairly certain not achieve what Linaro legal is probably concerned about.
>
> My guess is the members here are 90% or more of the contributors and a relicensing effort could be done within a reasonable timeframe. The project could also start under the LF with all new contributions under the Apache 2 license which is compatible with all prior BSD contributions. Or you could just required Apache 2 on any future contributions and keep the prior BSD if the relicensing is not agreeable to others.
>
> Just some thoughts on how other projects tackled this question. It would probably be best if we push any further discussion on this to a small group of your legal counsel as the various levers have different implications and I'm uncomfortable continuing this discussion without your counsel being involved.
>
> Thanks,
>
> Mike
>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 17:40   ` O'Driscoll, Tim
@ 2016-12-01 17:46     ` Ed Warnicke
  2016-12-01 18:01     ` Michael Dolan
  2016-12-01 18:41     ` Dave Neary
  2 siblings, 0 replies; 19+ messages in thread
From: Ed Warnicke @ 2016-12-01 17:46 UTC (permalink / raw)
  To: O'Driscoll, Tim; +Cc: Michael Dolan, moving

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

A major disadvantage to all of the CLA+BSD options in terms of covering
patent issues is: most people look to the license for comfort on patent
issues, and so the CLA doesn't *really* buy us any comfort for most
downstream consumers on those issues.

Ed

On Thu, Dec 1, 2016 at 11:40 AM, O'Driscoll, Tim <tim.odriscoll@intel.com>
wrote:

> Thanks Mike. I realise you can’t say too much in public about what is
> essentially a legal issue.
>
> To summarise, these are the options we seem to have:
>
> 1. Continue with BSD license and DCO:
> Advantages: Easy (nothing changes). This combination has worked well for
> several years with many companies contributing to the project and deploying
> DPDK-based solutions. No CLA required.
> Disadvantages: Some Linaro members may not be able to contribute and/or
> deploy DPDK-based solutions.
>
> 2. Use Apache 2 for new contributions:
> Advantages: It’s a fairly easy change. Provides patent protection for new
> contributions. No CLA required.
> Disadvantages: Doesn’t cover the existing DPDK code so the actual benefit
> of this is very small.
>
> 3. Use Apache 2 and re-license existing code:
> Advantages: Patent protection for everything. No CLA required.
> Disadvantage: We need to re-license everything. I suspect that’s a big
> effort and it will be very difficult to get agreement from everybody who's
> contributed. We would also need to consider DPDK code that’s dual-licensed.
> We have some code that’s dual BSD-GPLv2. IANAL, and I'm far from an expert
> on SW licensing, but I think Apache 2 is not compatible with GPLv2, so this
> might need to become Apache 2/GPLv3.
>
> 4. Use BSD and CLA:
> Advantages: No license change. Provides patent protection for new
> contributions.
> Disadvantages: Doesn’t cover the existing DPDK code so the actual benefit
> of this is very small. Need for a CLA is a problem for some contributors
> due to the need to get legal approval. Mike expressed concerns below about
> the combination of the Apache CLA and BSD license, so we'd need to create
> and agree a custom CLA.
>
> 5. Use BSD and CLA, and have the CLA apply retrospectively to existing
> code:
> Advantages: No license change. Patent protection for everything.
> Disadvantages: Don't know if this is even possible - can a CLA apply
> retrospectively to existing code? Need for a CLA is a problem for some
> contributors due to the need to get legal approval (presumably an even
> bigger problem if the CLA applies retrospectively). Mike expressed concerns
> below about the combination of the Apache CLA and BSD license, so we'd need
> to create and agree a custom CLA. Same logistical issues as for
> re-licensing - we'd need to track down and get agreement from all previous
> contributors.
>
> Note that I’m assuming that the combination of Apache 2 and a CLA isn't an
> option because this seems redundant as both include patent protection.
> Maybe there are other reasons that would make this a valid combination
> though.
>
> We do need to reach a conclusion on this and move forward. We should aim
> to resolve it at next week's meeting, so people should consider their
> position in advance of that. My vote would be for option 1.
>
>
> Tim
>
> > From: Michael Dolan [mailto:mdolan@linuxfoundation.org]
> > Sent: Wednesday, November 30, 2016 5:39 PM
> > To: O'Driscoll, Tim <tim.odriscoll@intel.com>
> > Cc: moving@dpdk.org
> > Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux
> Foundation" call, November 29th
> >
> > Hi Tim, sorry I couldn't make it with a LF Board meeting conflict
> yesterday. As for 1), most/all of our projects facing this issue decide to
> go Apache 2. A CLA is less preferably particularly with the BSD license.
> Where we do use a CLA on a project it's usually the same as the Apache
> CCLA/ICLA and that combined with the BSD license will I'm fairly certain
> not achieve what Linaro legal is probably concerned about.
> >
> > My guess is the members here are 90% or more of the contributors and a
> relicensing effort could be done within a reasonable timeframe. The project
> could also start under the LF with all new contributions under the Apache 2
> license which is compatible with all prior BSD contributions. Or you could
> just required Apache 2 on any future contributions and keep the prior BSD
> if the relicensing is not agreeable to others.
> >
> > Just some thoughts on how other projects tackled this question. It would
> probably be best if we push any further discussion on this to a small group
> of your legal counsel as the various levers have different implications and
> I'm uncomfortable continuing this discussion without your counsel being
> involved.
> >
> > Thanks,
> >
> > Mike
> >
>

[-- Attachment #2: Type: text/html, Size: 5456 bytes --]

<div dir="ltr">A major disadvantage to all of the CLA+BSD options in terms of covering patent issues is: most people look to the license for comfort on patent issues, and so the CLA doesn&#39;t *really* buy us any comfort for most downstream consumers on those issues.<div><br></div><div>Ed</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 1, 2016 at 11:40 AM, O&#39;Driscoll, Tim <span dir="ltr">&lt;<a href="mailto:tim.odriscoll@intel.com" target="_blank">tim.odriscoll@intel.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Mike. I realise you can’t say too much in public about what is essentially a legal issue.<br>
<br>
To summarise, these are the options we seem to have:<br>
<br>
1. Continue with BSD license and DCO:<br>
Advantages: Easy (nothing changes). This combination has worked well for several years with many companies contributing to the project and deploying DPDK-based solutions. No CLA required.<br>
Disadvantages: Some Linaro members may not be able to contribute and/or deploy DPDK-based solutions.<br>
<br>
2. Use Apache 2 for new contributions:<br>
Advantages: It’s a fairly easy change. Provides patent protection for new contributions. No CLA required.<br>
Disadvantages: Doesn’t cover the existing DPDK code so the actual benefit of this is very small.<br>
<br>
3. Use Apache 2 and re-license existing code:<br>
Advantages: Patent protection for everything. No CLA required.<br>
Disadvantage: We need to re-license everything. I suspect that’s a big effort and it will be very difficult to get agreement from everybody who&#39;s contributed. We would also need to consider DPDK code that’s dual-licensed. We have some code that’s dual BSD-GPLv2. IANAL, and I&#39;m far from an expert on SW licensing, but I think Apache 2 is not compatible with GPLv2, so this might need to become Apache 2/GPLv3.<br>
<br>
4. Use BSD and CLA:<br>
Advantages: No license change. Provides patent protection for new contributions.<br>
Disadvantages: Doesn’t cover the existing DPDK code so the actual benefit of this is very small. Need for a CLA is a problem for some contributors due to the need to get legal approval. Mike expressed concerns below about the combination of the Apache CLA and BSD license, so we&#39;d need to create and agree a custom CLA.<br>
<br>
5. Use BSD and CLA, and have the CLA apply retrospectively to existing code:<br>
Advantages: No license change. Patent protection for everything.<br>
Disadvantages: Don&#39;t know if this is even possible - can a CLA apply retrospectively to existing code? Need for a CLA is a problem for some contributors due to the need to get legal approval (presumably an even bigger problem if the CLA applies retrospectively). Mike expressed concerns below about the combination of the Apache CLA and BSD license, so we&#39;d need to create and agree a custom CLA. Same logistical issues as for re-licensing - we&#39;d need to track down and get agreement from all previous contributors.<br>
<br>
Note that I’m assuming that the combination of Apache 2 and a CLA isn&#39;t an option because this seems redundant as both include patent protection. Maybe there are other reasons that would make this a valid combination though.<br>
<br>
We do need to reach a conclusion on this and move forward. We should aim to resolve it at next week&#39;s meeting, so people should consider their position in advance of that. My vote would be for option 1.<br>
<br>
<br>
Tim<br>
<br>
&gt; From: Michael Dolan [mailto:<a href="mailto:mdolan@linuxfoundation.org">mdolan@<wbr>linuxfoundation.org</a>]<br>
&gt; Sent: Wednesday, November 30, 2016 5:39 PM<br>
<span class="im HOEnZb">&gt; To: O&#39;Driscoll, Tim &lt;<a href="mailto:tim.odriscoll@intel.com">tim.odriscoll@intel.com</a>&gt;<br>
&gt; Cc: <a href="mailto:moving@dpdk.org">moving@dpdk.org</a><br>
&gt; Subject: Re: [dpdk-moving] Minutes from &quot;Moving DPDK to Linux Foundation&quot; call, November 29th<br>
&gt;<br>
</span><div class="HOEnZb"><div class="h5">&gt; Hi Tim, sorry I couldn&#39;t make it with a LF Board meeting conflict yesterday. As for 1), most/all of our projects facing this issue decide to go Apache 2. A CLA is less preferably particularly with the BSD license. Where we do use a CLA on a project it&#39;s usually the same as the Apache CCLA/ICLA and that combined with the BSD license will I&#39;m fairly certain not achieve what Linaro legal is probably concerned about.<br>
&gt;<br>
&gt; My guess is the members here are 90% or more of the contributors and a relicensing effort could be done within a reasonable timeframe. The project could also start under the LF with all new contributions under the Apache 2 license which is compatible with all prior BSD contributions. Or you could just required Apache 2 on any future contributions and keep the prior BSD if the relicensing is not agreeable to others.<br>
&gt;<br>
&gt; Just some thoughts on how other projects tackled this question. It would probably be best if we push any further discussion on this to a small group of your legal counsel as the various levers have different implications and I&#39;m uncomfortable continuing this discussion without your counsel being involved.<br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Mike<br>
&gt;<br>
</div></div></blockquote></div><br></div>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 17:40   ` O'Driscoll, Tim
  2016-12-01 17:46     ` Ed Warnicke
@ 2016-12-01 18:01     ` Michael Dolan
  2016-12-01 18:41     ` Dave Neary
  2 siblings, 0 replies; 19+ messages in thread
From: Michael Dolan @ 2016-12-01 18:01 UTC (permalink / raw)
  To: O'Driscoll, Tim; +Cc: moving

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

> ...
> Note that I’m assuming that the combination of Apache 2 and a CLA isn't an
> option because this seems redundant as both include patent protection.
> Maybe there are other reasons that would make this a valid combination
> though.
> ...
>

Tim, I think this is a perfect example of why I'm suggesting we get all of
your counsel on a call together to discuss. The default for Apache 2 was to
use a CLA in combination. That's precisely why the Apache CCLA and ICLA
agreements exist.

The issue I think some are missing is not all CLAs are the same and have
very different purposes. Node.js under Joyent's stewardship tried to patch
over the BSD license with a CLA and it caused a lot of issues and they
ultimately abandoned the CLA entirely - but now they don't have the
protections offered by the CLA going forward and have to figure out what to
do.

The best path forward IMO is to have everyone on a call with their counsel
and we can discuss how to move forward. I don't have confidence everyone
here understands the full implications of what their being asked to decide
- this isn't a trivial detail to change things. Relaying to counsel and
coming back with an answer is also not ideal as those who are entrusted to
provide legal guidance are not at the table of discussion and may not
understand the full context.

A further option is to have the Governing Board resolve this later. We'll
know who the decision makers are and can work with their counsel to figure
this out if it's an issue the GB thinks needs addressed.

-- Mike


>
> Tim
>
> > From: Michael Dolan [mailto:mdolan@linuxfoundation.org]
> > Sent: Wednesday, November 30, 2016 5:39 PM
> > To: O'Driscoll, Tim <tim.odriscoll@intel.com>
> > Cc: moving@dpdk.org
> > Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux
> Foundation" call, November 29th
> >
> > Hi Tim, sorry I couldn't make it with a LF Board meeting conflict
> yesterday. As for 1), most/all of our projects facing this issue decide to
> go Apache 2. A CLA is less preferably particularly with the BSD license.
> Where we do use a CLA on a project it's usually the same as the Apache
> CCLA/ICLA and that combined with the BSD license will I'm fairly certain
> not achieve what Linaro legal is probably concerned about.
> >
> > My guess is the members here are 90% or more of the contributors and a
> relicensing effort could be done within a reasonable timeframe. The project
> could also start under the LF with all new contributions under the Apache 2
> license which is compatible with all prior BSD contributions. Or you could
> just required Apache 2 on any future contributions and keep the prior BSD
> if the relicensing is not agreeable to others.
> >
> > Just some thoughts on how other projects tackled this question. It would
> probably be best if we push any further discussion on this to a small group
> of your legal counsel as the various levers have different implications and
> I'm uncomfortable continuing this discussion without your counsel being
> involved.
> >
> > Thanks,
> >
> > Mike
> >
>

[-- Attachment #2: Type: text/html, Size: 3882 bytes --]

<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...<br>
Note that I’m assuming that the combination of Apache 2 and a CLA isn&#39;t an option because this seems redundant as both include patent protection. Maybe there are other reasons that would make this a valid combination though.<br>...<br></blockquote><div><br></div><div>Tim, I think this is a perfect example of why I&#39;m suggesting we get all of your counsel on a call together to discuss. The default for Apache 2 was to use a CLA in combination. That&#39;s precisely why the Apache CCLA and ICLA agreements exist.</div><div><br></div><div>The issue I think some are missing is not all CLAs are the same and have very different purposes. Node.js under Joyent&#39;s stewardship tried to patch over the BSD license with a CLA and it caused a lot of issues and they ultimately abandoned the CLA entirely - but now they don&#39;t have the protections offered by the CLA going forward and have to figure out what to do.</div><div><br></div><div>The best path forward IMO is to have everyone on a call with their counsel and we can discuss how to move forward. I don&#39;t have confidence everyone here understands the full implications of what their being asked to decide - this isn&#39;t a trivial detail to change things. Relaying to counsel and coming back with an answer is also not ideal as those who are entrusted to provide legal guidance are not at the table of discussion and may not understand the full context.</div><div><br></div><div>A further option is to have the Governing Board resolve this later. We&#39;ll know who the decision makers are and can work with their counsel to figure this out if it&#39;s an issue the GB thinks needs addressed.</div><div><br></div><div>-- Mike</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Tim<br>
<br>
&gt; From: Michael Dolan [mailto:<a href="mailto:mdolan@linuxfoundation.org">mdolan@<wbr>linuxfoundation.org</a>]<br>
&gt; Sent: Wednesday, November 30, 2016 5:39 PM<br>
<span class="im HOEnZb">&gt; To: O&#39;Driscoll, Tim &lt;<a href="mailto:tim.odriscoll@intel.com">tim.odriscoll@intel.com</a>&gt;<br>
&gt; Cc: <a href="mailto:moving@dpdk.org">moving@dpdk.org</a><br>
&gt; Subject: Re: [dpdk-moving] Minutes from &quot;Moving DPDK to Linux Foundation&quot; call, November 29th<br>
&gt;<br>
</span><div class="HOEnZb"><div class="h5">&gt; Hi Tim, sorry I couldn&#39;t make it with a LF Board meeting conflict yesterday. As for 1), most/all of our projects facing this issue decide to go Apache 2. A CLA is less preferably particularly with the BSD license. Where we do use a CLA on a project it&#39;s usually the same as the Apache CCLA/ICLA and that combined with the BSD license will I&#39;m fairly certain not achieve what Linaro legal is probably concerned about.<br>
&gt;<br>
&gt; My guess is the members here are 90% or more of the contributors and a relicensing effort could be done within a reasonable timeframe. The project could also start under the LF with all new contributions under the Apache 2 license which is compatible with all prior BSD contributions. Or you could just required Apache 2 on any future contributions and keep the prior BSD if the relicensing is not agreeable to others.<br>
&gt;<br>
&gt; Just some thoughts on how other projects tackled this question. It would probably be best if we push any further discussion on this to a small group of your legal counsel as the various levers have different implications and I&#39;m uncomfortable continuing this discussion without your counsel being involved.<br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Mike<br>
&gt;<br>
</div></div></blockquote></div><br></div></div>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 17:40   ` O'Driscoll, Tim
  2016-12-01 17:46     ` Ed Warnicke
  2016-12-01 18:01     ` Michael Dolan
@ 2016-12-01 18:41     ` Dave Neary
  2016-12-01 18:50       ` Dave Neary
  2016-12-01 20:33       ` O'Driscoll, Tim
  2 siblings, 2 replies; 19+ messages in thread
From: Dave Neary @ 2016-12-01 18:41 UTC (permalink / raw)
  To: O'Driscoll, Tim, Michael Dolan, moving

Hi,

On 12/01/2016 12:40 PM, O'Driscoll, Tim wrote:
> Thanks Mike. I realise you can’t say too much in public about what is essentially a legal issue.
> 
> To summarise, these are the options we seem to have:
> 
> 1. Continue with BSD license and DCO:
> Advantages: Easy (nothing changes). This combination has worked well for several years with many companies contributing to the project and deploying DPDK-based solutions. No CLA required.
> Disadvantages: Some Linaro members may not be able to contribute and/or deploy DPDK-based solutions.
> 
> 2. Use Apache 2 for new contributions:
> Advantages: It’s a fairly easy change. Provides patent protection for new contributions. No CLA required.
> Disadvantages: Doesn’t cover the existing DPDK code so the actual benefit of this is very small.
> 
> 3. Use Apache 2 and re-license existing code:
> Advantages: Patent protection for everything. No CLA required.
> Disadvantage: We need to re-license everything. I suspect that’s a big effort and it will be very difficult to get agreement from everybody who's contributed. We would also need to consider DPDK code that’s dual-licensed. We have some code that’s dual BSD-GPLv2. IANAL, and I'm far from an expert on SW licensing, but I think Apache 2 is not compatible with GPLv2, so this might need to become Apache 2/GPLv3.

This might be a smaller task that you might think.

We get to 99%+ with 7-8 companies. Each company will probably want to do
a patent review on code they are contributing to see what they are
licensing (and this can be a lengthy task, but for some of the bigger
participants, this may already be an ongoing activity, or an acceptable
level of risk). You only need agreement from copyright holders, and it
is entirely possible that most participants work for companies that
retain the copyright to contributions.

Still, these can be a pain and a drag on momentum.

> Note that I’m assuming that the combination of Apache 2 and a CLA isn't an option because this seems redundant as both include patent protection. Maybe there are other reasons that would make this a valid combination though.

The Apache Software Foundation requires CLAs with copyright assignment
to the foundation for official Apache projects - this is to allow for
future license changes (an Apache v3 license), and also reflects some of
the difficulties of a 30 year old project (several of the original
copyright holders are no longer with the project, or have died, and the
succession rights for copyright materials can sometimes result in
unfortunate conflicts between the estates and open source projects).

> We do need to reach a conclusion on this and move forward. We should aim to resolve it at next week's meeting, so people should consider their position in advance of that. My vote would be for option 1.

My preference is to minimise change. I have no strong preference between
BSD + DCO and Apache v2. I would like to avoid a CLA.

Regards,
Dave.

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 18:41     ` Dave Neary
@ 2016-12-01 18:50       ` Dave Neary
  2016-12-01 19:09         ` Francois Ozog
  2016-12-01 20:33       ` O'Driscoll, Tim
  1 sibling, 1 reply; 19+ messages in thread
From: Dave Neary @ 2016-12-01 18:50 UTC (permalink / raw)
  To: O'Driscoll, Tim, Michael Dolan, moving



On 12/01/2016 01:41 PM, Dave Neary wrote:
>> Note that I’m assuming that the combination of Apache 2 and a CLA isn't an option because this seems redundant as both include patent protection. Maybe there are other reasons that would make this a valid combination though.
> 
> The Apache Software Foundation requires CLAs with copyright assignment
> to the foundation for official Apache projects - this is to allow for
> future license changes (an Apache v3 license), and also reflects some of
> the difficulties of a 30 year old project (several of the original
> copyright holders are no longer with the project, or have died, and the
> succession rights for copyright materials can sometimes result in
> unfortunate conflicts between the estates and open source projects).

A small but important correction: The ASF CLA is a grant of a broad
copyright license which allows, among other things, the ASF to
redistribute the software under a different license. It is not a
copyright assignment.

Thanks,
Dave.

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 18:50       ` Dave Neary
@ 2016-12-01 19:09         ` Francois Ozog
  2016-12-01 19:44           ` Michael Dolan
  2016-12-01 21:33           ` O'Driscoll, Tim
  0 siblings, 2 replies; 19+ messages in thread
From: Francois Ozog @ 2016-12-01 19:09 UTC (permalink / raw)
  To: Dave Neary; +Cc: O'Driscoll, Tim, Michael Dolan, moving

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

Hello,

please find the Linaro CLA that passed many large companies lawyers for IP:
http://opendataplane.org/contributor/individual/

Compnies that already signed it (not all are listed): ARM, Broadcom,
Canonical, Cavium, Cisco, Comcast, Ericsson, ENEA, Facebook, Hisilicon, HP
Enterprise, Huawei, MontaVista, Nokia, NXP, Qualcomm, RedHat, Samsung,
Socionext, Spreadtrum, ST microelectronics, Texas Instruments, Wind River,
ZTE

I wonder how to read "Need for a CLA is a problem for some contributors due
to the need to get legal approval."

Is it: "let's mask the problem to lawyers because they may NOT allow us to
continue our technical fun?" or is it "this is just a burden that may take
long and I don't want to lose time".

Cordially,

FF

On 1 December 2016 at 19:50, Dave Neary <dneary@redhat.com> wrote:

>
>
> On 12/01/2016 01:41 PM, Dave Neary wrote:
> >> Note that I’m assuming that the combination of Apache 2 and a CLA isn't
> an option because this seems redundant as both include patent protection.
> Maybe there are other reasons that would make this a valid combination
> though.
> >
> > The Apache Software Foundation requires CLAs with copyright assignment
> > to the foundation for official Apache projects - this is to allow for
> > future license changes (an Apache v3 license), and also reflects some of
> > the difficulties of a 30 year old project (several of the original
> > copyright holders are no longer with the project, or have died, and the
> > succession rights for copyright materials can sometimes result in
> > unfortunate conflicts between the estates and open source projects).
>
> A small but important correction: The ASF CLA is a grant of a broad
> copyright license which allows, among other things, the ASF to
> redistribute the software under a different license. It is not a
> copyright assignment.
>
> Thanks,
> Dave.
>
> --
> Dave Neary - NFV/SDN Community Strategy
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
>



-- 
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

[-- Attachment #2: Type: text/html, Size: 4700 bytes --]

<div dir="ltr">Hello,<div><br></div><div>please find the Linaro CLA that passed many large companies lawyers for IP: <a href="http://opendataplane.org/contributor/individual/" target="_blank" style="font-size:12.8px">http://opendataplane.org/<wbr>contributor/individual/</a></div><div><br></div><div>Compnies that already signed it (not all are listed): ARM, Broadcom, Canonical, Cavium, Cisco, Comcast, Ericsson, ENEA, Facebook, Hisilicon, HP Enterprise, Huawei, MontaVista, Nokia, NXP, Qualcomm, RedHat, Samsung, Socionext, Spreadtrum, ST microelectronics, Texas Instruments, Wind River, ZTE</div><div><br></div><div>I wonder how to read &quot;<span style="font-size:12.8px">Need for a CLA is a problem for some contributors due to the need to get legal approval.</span><span style="font-size:12.8px">&quot;</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Is it: &quot;let&#39;s mask the problem to lawyers because they may NOT allow us to continue our technical fun?&quot; or is it &quot;this is just a burden that may take long and I don&#39;t want to lose time&quot;.</span></div><div><br></div><div>Cordially,</div><div><br></div><div>FF</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 December 2016 at 19:50, Dave Neary <span dir="ltr">&lt;<a href="mailto:dneary@redhat.com" target="_blank">dneary@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 12/01/2016 01:41 PM, Dave Neary wrote:<br>
&gt;&gt; Note that I’m assuming that the combination of Apache 2 and a CLA isn&#39;t an option because this seems redundant as both include patent protection. Maybe there are other reasons that would make this a valid combination though.<br>
&gt;<br>
&gt; The Apache Software Foundation requires CLAs with copyright assignment<br>
&gt; to the foundation for official Apache projects - this is to allow for<br>
&gt; future license changes (an Apache v3 license), and also reflects some of<br>
&gt; the difficulties of a 30 year old project (several of the original<br>
&gt; copyright holders are no longer with the project, or have died, and the<br>
&gt; succession rights for copyright materials can sometimes result in<br>
&gt; unfortunate conflicts between the estates and open source projects).<br>
<br>
</span>A small but important correction: The ASF CLA is a grant of a broad<br>
copyright license which allows, among other things, the ASF to<br>
redistribute the software under a different license. It is not a<br>
copyright assignment.<br>
<br>
Thanks,<br>
<div class="HOEnZb"><div class="h5">Dave.<br>
<br>
--<br>
Dave Neary - NFV/SDN Community Strategy<br>
Open Source and Standards, Red Hat - <a href="http://community.redhat.com" rel="noreferrer" target="_blank">http://community.redhat.com</a><br>
Ph: <a href="tel:%2B1-978-399-2182" value="+19783992182">+1-978-399-2182</a> / Cell: <a href="tel:%2B1-978-799-3338" value="+19787993338">+1-978-799-3338</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><table style="font-size:small" border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="padding-right:10px" valign="top"><a href="http://www.linaro.org/" title="Linaro" style="color:rgb(17,85,204)" target="_blank"><img src="http://www.mydesignpad.com/email-sig/linaro/linaro-logo-web.png" alt="Linaro" border="0" height="46px" width="72px"></a></td><td valign="top"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family:Arial,Helvetica,&#39;Sans Serif&#39;;white-space:nowrap;font-size:9pt;padding-top:0px;color:rgb(87,87,87)" valign="top"><span style="font-weight:bold">François-Frédéric Ozog</span> <span style="color:rgb(161,161,161)">|</span> <i>Director Linaro Networking Group</i></td></tr><tr><td style="font-family:Arial,Helvetica,&#39;Sans Serif&#39;;white-space:nowrap;font-size:9pt;padding-top:2px;color:rgb(87,87,87)" valign="top">T: <a href="tel:%2B33.67221.6485" value="+393384075993" style="color:rgb(17,85,204)" target="_blank">+33.67221.6485</a><br><a href="mailto:francois.ozog@linaro.org" style="color:rgb(87,87,87);text-decoration:none" target="_blank">francois.ozog@linaro.org</a> <span style="color:rgb(161,161,161)">|</span> Skype: ffozog</td></tr></tbody></table></td></tr></tbody></table></div></div></div></div></div><div><div><br style="font-size:small"></div></div></div></div></div></div></div>
</div>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 19:09         ` Francois Ozog
@ 2016-12-01 19:44           ` Michael Dolan
  2016-12-01 20:20             ` O'Driscoll, Tim
  2016-12-01 21:33           ` O'Driscoll, Tim
  1 sibling, 1 reply; 19+ messages in thread
From: Michael Dolan @ 2016-12-01 19:44 UTC (permalink / raw)
  To: Francois Ozog; +Cc: Dave Neary, O'Driscoll, Tim, moving

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

Can we setup a call next week with the counsel for the major contributors?
If it's 7-9 companies this shouldn't be difficult to resolve. I hate to be
difficult but this topic will not be resolved on a public mailing list
unless everyone is willing to punt on the issue until there is a governing
board to make the decision.

I am willing to schedule and host the call. I just need the names and
emails of your counsel. Please email me directly and not on the list.

Thanks,

Mike

---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250   Cell: +1.440.552.5322  Skype: michaelkdolan
mdolan@linuxfoundation.org
---

On Thu, Dec 1, 2016 at 2:09 PM, Francois Ozog <francois.ozog@linaro.org>
wrote:

> Hello,
>
> please find the Linaro CLA that passed many large companies lawyers for
> IP: http://opendataplane.org/contributor/individual/
>
> Compnies that already signed it (not all are listed): ARM, Broadcom,
> Canonical, Cavium, Cisco, Comcast, Ericsson, ENEA, Facebook, Hisilicon, HP
> Enterprise, Huawei, MontaVista, Nokia, NXP, Qualcomm, RedHat, Samsung,
> Socionext, Spreadtrum, ST microelectronics, Texas Instruments, Wind River,
> ZTE
>
> I wonder how to read "Need for a CLA is a problem for some contributors
> due to the need to get legal approval."
>
> Is it: "let's mask the problem to lawyers because they may NOT allow us to
> continue our technical fun?" or is it "this is just a burden that may take
> long and I don't want to lose time".
>
> Cordially,
>
> FF
>
> On 1 December 2016 at 19:50, Dave Neary <dneary@redhat.com> wrote:
>
>>
>>
>> On 12/01/2016 01:41 PM, Dave Neary wrote:
>> >> Note that I’m assuming that the combination of Apache 2 and a CLA
>> isn't an option because this seems redundant as both include patent
>> protection. Maybe there are other reasons that would make this a valid
>> combination though.
>> >
>> > The Apache Software Foundation requires CLAs with copyright assignment
>> > to the foundation for official Apache projects - this is to allow for
>> > future license changes (an Apache v3 license), and also reflects some of
>> > the difficulties of a 30 year old project (several of the original
>> > copyright holders are no longer with the project, or have died, and the
>> > succession rights for copyright materials can sometimes result in
>> > unfortunate conflicts between the estates and open source projects).
>>
>> A small but important correction: The ASF CLA is a grant of a broad
>> copyright license which allows, among other things, the ASF to
>> redistribute the software under a different license. It is not a
>> copyright assignment.
>>
>> Thanks,
>> Dave.
>>
>> --
>> Dave Neary - NFV/SDN Community Strategy
>> Open Source and Standards, Red Hat - http://community.redhat.com
>> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
>>
>
>
>
> --
> [image: Linaro] <http://www.linaro.org/>
> François-Frédéric Ozog | *Director Linaro Networking Group*
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
>
>

[-- Attachment #2: Type: text/html, Size: 6327 bytes --]

<div dir="ltr">Can we setup a call next week with the counsel for the major contributors? If it&#39;s 7-9 companies this shouldn&#39;t be difficult to resolve. I hate to be difficult but this topic will not be resolved on a public mailing list unless everyone is willing to punt on the issue until there is a governing board to make the decision.<div><br></div><div>I am willing to schedule and host the call. I just need the names and emails of your counsel. Please email me directly and not on the list.</div><div><br></div><div>Thanks,</div><div><br></div><div>Mike</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">







<p><font size="2">---<br>Mike Dolan<br>VP of Strategic Programs<br>The Linux Foundation<br>Office: +1.330.460.3250   Cell: +1.440.552.5322  Skype: michaelkdolan<br><a href="mailto:mdolan@linuxfoundation.org" target="_blank">mdolan@linuxfoundation.org</a><br>---</font></p></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Dec 1, 2016 at 2:09 PM, Francois Ozog <span dir="ltr">&lt;<a href="mailto:francois.ozog@linaro.org" target="_blank">francois.ozog@linaro.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>please find the Linaro CLA that passed many large companies lawyers for IP: <a href="http://opendataplane.org/contributor/individual/" style="font-size:12.8px" target="_blank">http://opendataplane.org/c<wbr>ontributor/individual/</a></div><div><br></div><div>Compnies that already signed it (not all are listed): ARM, Broadcom, Canonical, Cavium, Cisco, Comcast, Ericsson, ENEA, Facebook, Hisilicon, HP Enterprise, Huawei, MontaVista, Nokia, NXP, Qualcomm, RedHat, Samsung, Socionext, Spreadtrum, ST microelectronics, Texas Instruments, Wind River, ZTE</div><div><br></div><div>I wonder how to read &quot;<span style="font-size:12.8px">Need for a CLA is a problem for some contributors due to the need to get legal approval.</span><span style="font-size:12.8px">&quot;</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Is it: &quot;let&#39;s mask the problem to lawyers because they may NOT allow us to continue our technical fun?&quot; or is it &quot;this is just a burden that may take long and I don&#39;t want to lose time&quot;.</span></div><div><br></div><div>Cordially,</div><div><br></div><div>FF</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 1 December 2016 at 19:50, Dave Neary <span dir="ltr">&lt;<a href="mailto:dneary@redhat.com" target="_blank">dneary@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
On 12/01/2016 01:41 PM, Dave Neary wrote:<br>
&gt;&gt; Note that I’m assuming that the combination of Apache 2 and a CLA isn&#39;t an option because this seems redundant as both include patent protection. Maybe there are other reasons that would make this a valid combination though.<br>
&gt;<br>
&gt; The Apache Software Foundation requires CLAs with copyright assignment<br>
&gt; to the foundation for official Apache projects - this is to allow for<br>
&gt; future license changes (an Apache v3 license), and also reflects some of<br>
&gt; the difficulties of a 30 year old project (several of the original<br>
&gt; copyright holders are no longer with the project, or have died, and the<br>
&gt; succession rights for copyright materials can sometimes result in<br>
&gt; unfortunate conflicts between the estates and open source projects).<br>
<br>
</span>A small but important correction: The ASF CLA is a grant of a broad<br>
copyright license which allows, among other things, the ASF to<br>
redistribute the software under a different license. It is not a<br>
copyright assignment.<br>
<br>
Thanks,<br>
<div class="m_8894648396787410839HOEnZb"><div class="m_8894648396787410839h5">Dave.<br>
<br>
--<br>
Dave Neary - NFV/SDN Community Strategy<br>
Open Source and Standards, Red Hat - <a href="http://community.redhat.com" rel="noreferrer" target="_blank">http://community.redhat.com</a><br>
Ph: <a href="tel:%2B1-978-399-2182" value="+19783992182" target="_blank">+1-978-399-2182</a> / Cell: <a href="tel:%2B1-978-799-3338" value="+19787993338" target="_blank">+1-978-799-3338</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_8894648396787410839gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><table style="font-size:small" border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="padding-right:10px" valign="top"><a href="http://www.linaro.org/" title="Linaro" style="color:rgb(17,85,204)" target="_blank"><img src="http://www.mydesignpad.com/email-sig/linaro/linaro-logo-web.png" alt="Linaro" border="0" height="46px" width="72px"></a></td><td valign="top"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family:Arial,Helvetica,&#39;Sans Serif&#39;;white-space:nowrap;font-size:9pt;padding-top:0px;color:rgb(87,87,87)" valign="top"><span style="font-weight:bold">François-Frédéric Ozog</span> <span style="color:rgb(161,161,161)">|</span> <i>Director Linaro Networking Group</i></td></tr><tr><td style="font-family:Arial,Helvetica,&#39;Sans Serif&#39;;white-space:nowrap;font-size:9pt;padding-top:2px;color:rgb(87,87,87)" valign="top">T: <a href="tel:%2B33.67221.6485" value="+393384075993" style="color:rgb(17,85,204)" target="_blank">+33.67221.6485</a><br><a href="mailto:francois.ozog@linaro.org" style="color:rgb(87,87,87);text-decoration:none" target="_blank">francois.ozog@linaro.org</a> <span style="color:rgb(161,161,161)">|</span> <wbr>Skype: ffozog</td></tr></tbody></table></td></tr></tbody></table></div></div></div></div></div><div><div><br style="font-size:small"></div></div></div></div></div></div></div>
</font></span></div>
</blockquote></div><br></div>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 19:44           ` Michael Dolan
@ 2016-12-01 20:20             ` O'Driscoll, Tim
  2016-12-01 20:47               ` Wiles, Keith
  0 siblings, 1 reply; 19+ messages in thread
From: O'Driscoll, Tim @ 2016-12-01 20:20 UTC (permalink / raw)
  To: Michael Dolan, Francois Ozog; +Cc: Dave Neary, moving

> From: Michael Dolan [mailto:mdolan@linuxfoundation.org] 
> Sent: Thursday, December 1, 2016 7:45 PM
> To: Francois Ozog <francois.ozog@linaro.org>
> Cc: Dave Neary <dneary@redhat.com>; O'Driscoll, Tim <tim.odriscoll@intel.com>; moving@dpdk.org
> Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
>
> Can we setup a call next week with the counsel for the major contributors? If it's 7-9 companies this shouldn't be difficult to resolve. I hate to be difficult but this topic will not be resolved on a public mailing list unless everyone is willing to punt on the issue until there is a governing board to make the decision.
>
> I am willing to schedule and host the call. I just need the names and emails of your counsel. Please email me directly and not on the list.

We could do that, but I suspect that if we do we're heading into months of legal debate. The intent of the initiative to move the project to LF was to do so with minimal changes. The adoption of a CLA and/or a licensing change clearly doesn't fall into that category.

You have a valid point that this is a significant issue and we shouldn't rush into a decision on it, or make one without fully considering the legal implications. So, my preference would be to use the charter to document the current process (BSD license and DCO). Then, when we have a governing board in place, anybody that wants to can propose a change and it can be dealt with by the board.

What do others think?


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 18:41     ` Dave Neary
  2016-12-01 18:50       ` Dave Neary
@ 2016-12-01 20:33       ` O'Driscoll, Tim
  1 sibling, 0 replies; 19+ messages in thread
From: O'Driscoll, Tim @ 2016-12-01 20:33 UTC (permalink / raw)
  To: Dave Neary, Michael Dolan, moving

> From: Dave Neary [mailto:dneary@redhat.com]
> Sent: Thursday, December 1, 2016 6:41 PM
> To: O'Driscoll, Tim <tim.odriscoll@intel.com>; Michael Dolan
> <mdolan@linuxfoundation.org>; moving@dpdk.org
> Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux
> Foundation" call, November 29th
> 
> Hi,
> 
> On 12/01/2016 12:40 PM, O'Driscoll, Tim wrote:
> > Thanks Mike. I realise you can’t say too much in public about what is
> essentially a legal issue.
> >
> > To summarise, these are the options we seem to have:
> >
> > 1. Continue with BSD license and DCO:
> > Advantages: Easy (nothing changes). This combination has worked well
> for several years with many companies contributing to the project and
> deploying DPDK-based solutions. No CLA required.
> > Disadvantages: Some Linaro members may not be able to contribute
> and/or deploy DPDK-based solutions.
> >
> > 2. Use Apache 2 for new contributions:
> > Advantages: It’s a fairly easy change. Provides patent protection for
> new contributions. No CLA required.
> > Disadvantages: Doesn’t cover the existing DPDK code so the actual
> benefit of this is very small.
> >
> > 3. Use Apache 2 and re-license existing code:
> > Advantages: Patent protection for everything. No CLA required.
> > Disadvantage: We need to re-license everything. I suspect that’s a big
> effort and it will be very difficult to get agreement from everybody
> who's contributed. We would also need to consider DPDK code that’s dual-
> licensed. We have some code that’s dual BSD-GPLv2. IANAL, and I'm far
> from an expert on SW licensing, but I think Apache 2 is not compatible
> with GPLv2, so this might need to become Apache 2/GPLv3.
> 
> This might be a smaller task that you might think.
> 
> We get to 99%+ with 7-8 companies. Each company will probably want to do
> a patent review on code they are contributing to see what they are
> licensing (and this can be a lengthy task, but for some of the bigger
> participants, this may already be an ongoing activity, or an acceptable
> level of risk). You only need agreement from copyright holders, and it
> is entirely possible that most participants work for companies that
> retain the copyright to contributions.

I did a quick scan of the copyright lines in the DPDK repo. It was only a quick look so this isn't an exhaustive list, it was just to get an idea of scale. Purely based on who has asserted copyright in the file headers, the people who would need to agree to re-licensing or applying a retrospective CLA include:

Intel
6WIND
RehiveTech
Vladimir Medvedkin
Akamai Technologies
Cavium Networks
Tilera
Neil Horman
Freescale Semiconductor
Netronome Systems
IGEL
Canonical
John Linville
Broadcom
Chelsio
Linaro
EZchip
Ethan Zhuang
Hannes Frederic Sowa
CESNET
Cisco
Nuova Systems
Mellanox

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 20:20             ` O'Driscoll, Tim
@ 2016-12-01 20:47               ` Wiles, Keith
  0 siblings, 0 replies; 19+ messages in thread
From: Wiles, Keith @ 2016-12-01 20:47 UTC (permalink / raw)
  To: O'Driscoll, Tim; +Cc: Michael Dolan, Francois Ozog, Dave Neary, moving


> On Dec 1, 2016, at 2:20 PM, O'Driscoll, Tim <tim.odriscoll@intel.com> wrote:
> 
>> From: Michael Dolan [mailto:mdolan@linuxfoundation.org] 
>> Sent: Thursday, December 1, 2016 7:45 PM
>> To: Francois Ozog <francois.ozog@linaro.org>
>> Cc: Dave Neary <dneary@redhat.com>; O'Driscoll, Tim <tim.odriscoll@intel.com>; moving@dpdk.org
>> Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
>> 
>> Can we setup a call next week with the counsel for the major contributors? If it's 7-9 companies this shouldn't be difficult to resolve. I hate to be difficult but this topic will not be resolved on a public mailing list unless everyone is willing to punt on the issue until there is a governing board to make the decision.
>> 
>> I am willing to schedule and host the call. I just need the names and emails of your counsel. Please email me directly and not on the list.
> 
> We could do that, but I suspect that if we do we're heading into months of legal debate. The intent of the initiative to move the project to LF was to do so with minimal changes. The adoption of a CLA and/or a licensing change clearly doesn't fall into that category.
> 
> You have a valid point that this is a significant issue and we shouldn't rush into a decision on it, or make one without fully considering the legal implications. So, my preference would be to use the charter to document the current process (BSD license and DCO). Then, when we have a governing board in place, anybody that wants to can propose a change and it can be dealt with by the board.
> 
> What do others think?

Well I agree with you (if that means anything) on handling this issue later, it just makes sense for moving quickly.

Regards,
Keith

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 19:09         ` Francois Ozog
  2016-12-01 19:44           ` Michael Dolan
@ 2016-12-01 21:33           ` O'Driscoll, Tim
  2016-12-02  9:00             ` Francois Ozog
  1 sibling, 1 reply; 19+ messages in thread
From: O'Driscoll, Tim @ 2016-12-01 21:33 UTC (permalink / raw)
  To: Francois Ozog, Dave Neary; +Cc: Michael Dolan, moving


> From: Francois Ozog [mailto:francois.ozog@linaro.org] 
> Sent: Thursday, December 1, 2016 7:09 PM
> To: Dave Neary <dneary@redhat.com>
> Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>; Michael Dolan <mdolan@linuxfoundation.org>; moving@dpdk.org
> Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
>
> Hello,
>
> please find the Linaro CLA that passed many large companies lawyers for IP: http://opendataplane.org/contributor/individual/
>
> Compnies that already signed it (not all are listed): ARM, Broadcom, Canonical, Cavium, Cisco, Comcast, Ericsson, ENEA, Facebook, Hisilicon, HP Enterprise, Huawei, MontaVista, Nokia, NXP, Qualcomm, RedHat, Samsung, Socionext, Spreadtrum, ST microelectronics, Texas Instruments, Wind River, ZTE
>
> I wonder how to read "Need for a CLA is a problem for some contributors due to the need to get legal approval."
>
> Is it: "let's mask the problem to lawyers because they may NOT allow us to continue our technical fun?" or is it "this is just a burden that may take long and I don't want to lose time".
>

The concern that several people have expressed is that a CLA adds overhead for contributors to the project. If somebody wants to contribute, they would need to go through the extra step of getting the CLA reviewed and approved by their legal department. Depending on their company's legal policy, that may slow down or block contributions.

Mike is correct that the legal details are better handled by lawyers, but before that it would be good to make sure we're clear on the problem you're trying to address. You said on Tuesday that some Linaro members would not be able to contribute to DPDK and/or use it in production without some form of patent protection. Looking at the list of LNG members, many of them are already significant contributors to DPDK, so that statement doesn't make sense to me. Can you perhaps clarify what exactly the problem you're trying to address is, just to make sure we all understand it properly?

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
  2016-12-01 21:33           ` O'Driscoll, Tim
@ 2016-12-02  9:00             ` Francois Ozog
  0 siblings, 0 replies; 19+ messages in thread
From: Francois Ozog @ 2016-12-02  9:00 UTC (permalink / raw)
  To: O'Driscoll, Tim; +Cc: Dave Neary, Michael Dolan, moving

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

Hi Tim,

First, thank you for being so patient. As per LNG members, you have silicon
vendors, distro vendors, NEPs. I am sure you saw that not all NEPs are
contributing. Some may, some are not contributing code at all even if they
active in the community.

More importantly, contributing does not mean building and selling products
that include DPDK. DPDK can be/become a playground to learn about userland
network IO while products are built on derived proprietary technology.


Let's rephrase: I am not mandating a CLA, I just stress that intellectual
property and licensing aspects are better off handled at the bengining. As
per Mike Dolan, Apache 2 is also a good approach. I hope every contributor
have gone (or are going to go) through due dilligence about selling
products based on DPDK with its counsel.

When you say "Depending on their company's legal policy, that may slow down
or block contributions.": hopefully you don't think there is a need for
legal intervention for each contribution. right? there is just one CLA to
be established at the first contribution.
And I hope you don't mean that people don't go to legal because they know
they will block contributions so they keep low profile and contribute: that
would be a very bad corporate responsability behavior!


Cordially,

François-Frédéric



On 1 December 2016 at 22:33, O'Driscoll, Tim <tim.odriscoll@intel.com>
wrote:

>
> > From: Francois Ozog [mailto:francois.ozog@linaro.org]
> > Sent: Thursday, December 1, 2016 7:09 PM
> > To: Dave Neary <dneary@redhat.com>
> > Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>; Michael Dolan <
> mdolan@linuxfoundation.org>; moving@dpdk.org
> > Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux
> Foundation" call, November 29th
> >
> > Hello,
> >
> > please find the Linaro CLA that passed many large companies lawyers for
> IP: http://opendataplane.org/contributor/individual/
> >
> > Compnies that already signed it (not all are listed): ARM, Broadcom,
> Canonical, Cavium, Cisco, Comcast, Ericsson, ENEA, Facebook, Hisilicon, HP
> Enterprise, Huawei, MontaVista, Nokia, NXP, Qualcomm, RedHat, Samsung,
> Socionext, Spreadtrum, ST microelectronics, Texas Instruments, Wind River,
> ZTE
> >
> > I wonder how to read "Need for a CLA is a problem for some contributors
> due to the need to get legal approval."
> >
> > Is it: "let's mask the problem to lawyers because they may NOT allow us
> to continue our technical fun?" or is it "this is just a burden that may
> take long and I don't want to lose time".
> >
>
> The concern that several people have expressed is that a CLA adds overhead
> for contributors to the project. If somebody wants to contribute, they
> would need to go through the extra step of getting the CLA reviewed and
> approved by their legal department. Depending on their company's legal
> policy, that may slow down or block contributions.
>
> Mike is correct that the legal details are better handled by lawyers, but
> before that it would be good to make sure we're clear on the problem you're
> trying to address. You said on Tuesday that some Linaro members would not
> be able to contribute to DPDK and/or use it in production without some form
> of patent protection. Looking at the list of LNG members, many of them are
> already significant contributors to DPDK, so that statement doesn't make
> sense to me. Can you perhaps clarify what exactly the problem you're trying
> to address is, just to make sure we all understand it properly?
>



-- 
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

[-- Attachment #2: Type: text/html, Size: 6257 bytes --]

<div dir="ltr"><div>Hi Tim,</div><div><br></div>First, thank you for being so patient. As per LNG members, you have silicon vendors, distro vendors, NEPs. I am sure you saw that not all NEPs are contributing. Some may, some are not contributing code at all even if they active in the community.<div><br></div><div>More importantly, contributing does not mean building and selling products that include DPDK. DPDK can be/become a playground to learn about userland network IO while products are built on derived proprietary technology. </div><div><br></div><div><br></div><div>Let&#39;s rephrase: I am not mandating a CLA, I just stress that intellectual property and licensing aspects are better off handled at the bengining. As per Mike Dolan, Apache 2 is also a good approach. I hope every contributor have gone (or are going to go) through due dilligence about selling products based on DPDK with its counsel.</div><div><br></div><div>When you say &quot;<span style="font-size:12.8px">Depending on their company&#39;s legal policy, that may slow down or block contributions.&quot;: hopefully you don&#39;t think there is a need for legal intervention for each contribution. right? there is just one CLA to be established at the first contribution.</span></div><div><span style="font-size:12.8px">And I hope you don&#39;t mean that people don&#39;t go to legal because they know they will block contributions so they keep low profile and contribute: that would be a very bad corporate responsability behavior!</span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div>Cordially,</div><div><br></div><div>François-Frédéric<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 December 2016 at 22:33, O&#39;Driscoll, Tim <span dir="ltr">&lt;<a href="mailto:tim.odriscoll@intel.com" target="_blank">tim.odriscoll@intel.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; From: Francois Ozog [mailto:<a href="mailto:francois.ozog@linaro.org">francois.ozog@linaro.<wbr>org</a>]<br>
&gt; Sent: Thursday, December 1, 2016 7:09 PM<br>
&gt; To: Dave Neary &lt;<a href="mailto:dneary@redhat.com">dneary@redhat.com</a>&gt;<br>
&gt; Cc: O&#39;Driscoll, Tim &lt;<a href="mailto:tim.odriscoll@intel.com">tim.odriscoll@intel.com</a>&gt;; Michael Dolan &lt;<a href="mailto:mdolan@linuxfoundation.org">mdolan@linuxfoundation.org</a>&gt;; <a href="mailto:moving@dpdk.org">moving@dpdk.org</a><br>
<span class="">&gt; Subject: Re: [dpdk-moving] Minutes from &quot;Moving DPDK to Linux Foundation&quot; call, November 29th<br>
&gt;<br>
</span><span class="">&gt; Hello,<br>
&gt;<br>
&gt; please find the Linaro CLA that passed many large companies lawyers for IP: <a href="http://opendataplane.org/contributor/individual/" rel="noreferrer" target="_blank">http://opendataplane.org/<wbr>contributor/individual/</a><br>
&gt;<br>
&gt; Compnies that already signed it (not all are listed): ARM, Broadcom, Canonical, Cavium, Cisco, Comcast, Ericsson, ENEA, Facebook, Hisilicon, HP Enterprise, Huawei, MontaVista, Nokia, NXP, Qualcomm, RedHat, Samsung, Socionext, Spreadtrum, ST microelectronics, Texas Instruments, Wind River, ZTE<br>
&gt;<br>
&gt; I wonder how to read &quot;Need for a CLA is a problem for some contributors due to the need to get legal approval.&quot;<br>
&gt;<br>
&gt; Is it: &quot;let&#39;s mask the problem to lawyers because they may NOT allow us to continue our technical fun?&quot; or is it &quot;this is just a burden that may take long and I don&#39;t want to lose time&quot;.<br>
&gt;<br>
<br>
</span>The concern that several people have expressed is that a CLA adds overhead for contributors to the project. If somebody wants to contribute, they would need to go through the extra step of getting the CLA reviewed and approved by their legal department. Depending on their company&#39;s legal policy, that may slow down or block contributions.<br>
<br>
Mike is correct that the legal details are better handled by lawyers, but before that it would be good to make sure we&#39;re clear on the problem you&#39;re trying to address. You said on Tuesday that some Linaro members would not be able to contribute to DPDK and/or use it in production without some form of patent protection. Looking at the list of LNG members, many of them are already significant contributors to DPDK, so that statement doesn&#39;t make sense to me. Can you perhaps clarify what exactly the problem you&#39;re trying to address is, just to make sure we all understand it properly?<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><table style="font-size:small" border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="padding-right:10px" valign="top"><a href="http://www.linaro.org/" title="Linaro" style="color:rgb(17,85,204)" target="_blank"><img src="http://www.mydesignpad.com/email-sig/linaro/linaro-logo-web.png" alt="Linaro" border="0" height="46px" width="72px"></a></td><td valign="top"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family:Arial,Helvetica,&#39;Sans Serif&#39;;white-space:nowrap;font-size:9pt;padding-top:0px;color:rgb(87,87,87)" valign="top"><span style="font-weight:bold">François-Frédéric Ozog</span> <span style="color:rgb(161,161,161)">|</span> <i>Director Linaro Networking Group</i></td></tr><tr><td style="font-family:Arial,Helvetica,&#39;Sans Serif&#39;;white-space:nowrap;font-size:9pt;padding-top:2px;color:rgb(87,87,87)" valign="top">T: <a href="tel:%2B33.67221.6485" value="+393384075993" style="color:rgb(17,85,204)" target="_blank">+33.67221.6485</a><br><a href="mailto:francois.ozog@linaro.org" style="color:rgb(87,87,87);text-decoration:none" target="_blank">francois.ozog@linaro.org</a> <span style="color:rgb(161,161,161)">|</span> Skype: ffozog</td></tr></tbody></table></td></tr></tbody></table></div></div></div></div></div><div><div><br style="font-size:small"></div></div></div></div></div></div></div>
</div>

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, back to index

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-30 16:01 [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th O'Driscoll, Tim
2016-11-30 17:10 ` Thomas Monjalon
2016-11-30 22:08   ` O'Driscoll, Tim
2016-12-01  9:20     ` Thomas Monjalon
2016-12-01  9:40       ` O'Driscoll, Tim
2016-11-30 17:39 ` Michael Dolan
2016-11-30 20:55   ` Dave Neary
2016-12-01 17:40   ` O'Driscoll, Tim
2016-12-01 17:46     ` Ed Warnicke
2016-12-01 18:01     ` Michael Dolan
2016-12-01 18:41     ` Dave Neary
2016-12-01 18:50       ` Dave Neary
2016-12-01 19:09         ` Francois Ozog
2016-12-01 19:44           ` Michael Dolan
2016-12-01 20:20             ` O'Driscoll, Tim
2016-12-01 20:47               ` Wiles, Keith
2016-12-01 21:33           ` O'Driscoll, Tim
2016-12-02  9:00             ` Francois Ozog
2016-12-01 20:33       ` O'Driscoll, Tim

DPDK community structure changes

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/moving/0 moving/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 moving moving/ http://inbox.dpdk.org/moving \
		moving@dpdk.org
	public-inbox-index moving


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.moving


AGPL code for this site: git clone https://public-inbox.org/ public-inbox