From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.161.172]) by dpdk.org (Postfix) with ESMTP id EC5CE3B5 for ; Tue, 29 Nov 2016 15:25:39 +0100 (CET) Received: by mail-yw0-f172.google.com with SMTP id i145so138720848ywg.2 for ; Tue, 29 Nov 2016 06:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1IQ7X/wlNG0Bxg3tW4f8jIPHoI3QQ/QlOZNzSe72gZ0=; b=iZUQRuXaNsi14zONfsNMmszLeWlDksWBUmbdnZ1zKbw849Orhzse75B+3pWgNErhpJ 8L4avKmGejnrTt2NUhSh/m2GahO9Sso7pKVmryo09mOQnph47qe9csoyIy+UYwkKKJIc NSUo4+/A/bu2LFalnDNUG0VYGMtTml52UV9XU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1IQ7X/wlNG0Bxg3tW4f8jIPHoI3QQ/QlOZNzSe72gZ0=; b=I69N56v+qk0lO/JYkoJvm2SQI6vWl4ft0Ay/5Y0/hcU2iMoYDUlPWy/zJS8gtJb8yn /BxFWCaIcmt/OdqNmShK86jb7slh/RpH1tItM85CuPNmBFC06EwDt3GGUMx4p86XTeTc EXt9Y9iag1r/E25CiTCHnTLQ9qIU6l4nyJHHtFuGe3D24MArK5d1r/Q9BOiXZHdehEik zcUMk/4iBOkeSmH+AjVCLdtHJ8KXeuNPwyAg7zlwHUeKLY2QTOZ869CB9wOrQeknbrug nPvGrrjsmD6ehOFtyTZDnKtKvIj1nJOfEBWj0BiReJ/UQVCAa5iYpKMsJ/8sPhNtjBqQ gm3w== X-Gm-Message-State: AKaTC03UZEzXcTLBvaxepK+qDEJjRxu12vEF4Ph0fvRwFhkm3tgUQKVoPonnJURZjvW5Qo/x49Z8Zmsk+dLmlWfX X-Received: by 10.129.163.69 with SMTP id a66mr34394136ywh.175.1480429539150; Tue, 29 Nov 2016 06:25:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.164.99 with HTTP; Tue, 29 Nov 2016 06:25:38 -0800 (PST) In-Reply-To: <1582367.tENoNDAmhm@xps13> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA67622717@IRSMSX108.ger.corp.intel.com> <1582367.tENoNDAmhm@xps13> From: Francois Ozog Date: Tue, 29 Nov 2016 15:25:38 +0100 Message-ID: To: Thomas Monjalon Cc: Matt Spencer , "O'Driscoll, Tim" , Dave Neary , moving@dpdk.org Content-Type: multipart/alternative; boundary=94eb2c128138cc2aea0542715ceb Subject: Re: [dpdk-moving] Reminder on Today's Meeting and Updated Charter X-BeenThere: moving@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK community structure changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 14:25:40 -0000 --94eb2c128138cc2aea0542715ceb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 November 2016 at 14:50, Thomas Monjalon wrote: > 2016-11-29 14:20, Francois Ozog: > > Hi Matt, > > > > I coy/paste Mike Dolan's comment on CLA: > > > > "Most of our projects use the Apache CCLA if a CLA is required. We have= a > > fully automated e-signature management system for CLA signings. You can > see > > the CCLA for Kubernetes for example here: > > https://identity.linuxfoundation.org/content/cncf-corporate-contributor= - > license-agreement > > linuxfoundation.org/content/cncf-corporate-contributor- > license-agreement&sa=3DD&ust=3D1480344167438000&usg=3D > AFQjCNEbhgdm3M7dTLB1Xxwp8af7LJcC-A> > > " > > > > I had Linaro member companie lawyers have a look at it and they said it > is > > fine. > > > > So it should be nice to have such CCLA in place in DPDK. > > Why? > In an early mail I said: "I am not a lawyer and I am out of my league here. That said, we all know that NDA's cannot be executed by any employee of a company. So, the DPDK signoff is nice, but why implement a policy that is less binding for something that may be involving very high liability issues? DPDK says precisely "The purpose of the signoff is explained in the Developer=E2=80=99s Certificate of Origin section of the Linux kernel guide= lines.". The following note says the contributor has to "understand" DCO... So unless I have missed something, nothing says that a contributor SHALL COMPLY to anything. And even if you change the sentences to include the word comply: - their should be a DPDK DCO not a pointer to some external project - do you have properly recorded in your books a paer signed by an authorized representative of a company ? - the DCO itslef is somewhat loose: "The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license". It does not say it is: . free from patents . free to use in large scale production by an end customer (not a developper). Or more precisely, the developper (say the NEP) has the right to sell and the customer (the operator) has been transfered the right to use. Bottom line, it is desirable that companies properly engage their responsability for licence, patents and copyright aspects. The CLA should be signed by each contributor company at the moment of joining: the company liability is engaged, not just the employee when submitting patches. There is probably some additional statement to be done for already contributed code." --=20 [image: Linaro] Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog --94eb2c128138cc2aea0542715ceb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 29 November 2016 at 14:50, Thomas Monjalon <thomas.monjalon@6wi= nd.com> wrote:
2016-11-29 14:20, Francois Ozog:
> Hi Matt,
>
> I coy/paste Mike Dolan's comment on CLA:
>
> "Most of our projects use the Apache CCLA if a CLA is required. W= e have a
> fully automated e-signature management system for CLA signings. You ca= n see
> the CCLA for Kubernetes for example here:
> https:= //identity.linuxfoundation.org/content/cncf-corporate-contributor= -license-agreement
> <https://www.google.com/url?q=3D= https://identity.linuxfoundation.org/content/cncf-corporate-= contributor-license-agreement&sa=3DD&ust=3D14803441674380= 00&usg=3DAFQjCNEbhgdm3M7dTLB1Xxwp8af7LJcC-A>
> "
>
> I had Linaro member companie lawyers have a look at it and they said i= t is
> fine.
>
> So it should be nice to have such CCLA in place in DPDK.

Why?

In an early mail I said:

"I am not a lawyer and I am out of my league here. That said, we all k= now that=C2=A0NDA's cannot be executed by any employee of a company. So, the DPDK = signoff is nice, but why implement a policy that is less binding for someth= ing that may be involving very high liability issues?=C2=A0


=
DPDK says precisely "The purpose of th= e signoff is explained in the Developer=E2=80=99s Certificate of Origin sec= tion of the Linux kernel guidelines.". The following note says the con= tributor has to "understand" DCO...
So unless I have missed something, nothing says that a contributor = SHALL COMPLY to anything. And even if you change the sentences to include t= he word comply:
- their should be a DP= DK DCO not a pointer to some external project
- do you have properly recorded in your books a paer signed by an a= uthorized representative of a company ?
- the DCO itslef is somewhat loose: "The contribution is based upon = previous work that, to the best of my knowledge, is covered under an approp= riate open source license". It does not say it is:
=C2=A0 =C2=A0 =C2=A0. free from patents
=C2=A0 =C2=A0 =C2=A0. free to use in large scale prod= uction by an end customer (not a developper). Or more precisely, the develo= pper (say the NEP) has the right to sell and the customer (the operator) ha= s been transfered the right to use.


Bottom line, it is desirab= le that companies properly engage their responsability for licence, patents= and copyright aspects.

=
The CLA should be signed by each contr= ibutor company at the moment of joining: the company liability is engaged, = not just the employee when submitting patches.

The= re is probably some additional statement to be done for already contributed= code."


--
3D=Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog= =C2=A0|=C2=A0Director Lina= ro Networking Group
T:=C2=A0= +33.67221.6485
francois.ozog@l= inaro.org=C2=A0|=C2=A0Sky= pe:=C2=A0ffozog

<= /div>
--94eb2c128138cc2aea0542715ceb--