DPDK community structure changes
 help / color / mirror / Atom feed
From: "O'Driscoll, Tim" <tim.odriscoll@intel.com>
To: Michael Dolan <mdolan@linuxfoundation.org>,
	"moving@dpdk.org" <moving@dpdk.org>
Subject: Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, November 29th
Date: Thu, 1 Dec 2016 17:40:56 +0000
Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA676277F4@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <CAFV=PSFsFogPcb1CJ9=DhkpJzyo8CePQdGG6kP6S8cv=vaE_yg@mail.gmail.com>

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
>

  parent reply	other threads:[~2016-12-01 17:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-30 16:01 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26FA93C7ED1EAA44AB77D62FBE1D27BA676277F4@IRSMSX108.ger.corp.intel.com \
    --to=tim.odriscoll@intel.com \
    --cc=mdolan@linuxfoundation.org \
    --cc=moving@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK community structure changes

This inbox may be cloned and mirrored by anyone:

	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

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.moving


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