From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54873C433E3 for ; Thu, 20 Aug 2020 07:03:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 32CA42078B for ; Thu, 20 Aug 2020 07:03:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597907020; bh=rxLdO7cakOHvaDBZxCktkD2vNW5pXxH+L8dnLiX+3l0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=TKBXIMaVGH2ctBVPBFe+JkV9o8B33NpofcPmciR5CWzVHyUiFLDVmuzDdvxXC5bTK yKNkCy6Su85ZKxOMfoFQtJonoVWkiPDFvsT/7rQ+CGjWU0tKpM2OK1mVYiv17Vhj++ t/XkFoPejgLfx31zkM0uxcuxmBdgxxJY8K1VJXPM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726851AbgHTHDi (ORCPT ); Thu, 20 Aug 2020 03:03:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:33356 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725797AbgHTHDh (ORCPT ); Thu, 20 Aug 2020 03:03:37 -0400 Received: from coco.lan (ip5f5ad5a3.dynamic.kabel-deutschland.de [95.90.213.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0D65C20738; Thu, 20 Aug 2020 07:03:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597907017; bh=rxLdO7cakOHvaDBZxCktkD2vNW5pXxH+L8dnLiX+3l0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZqoFqS0Qk5EvC6CMaAigGknwQX73VDCtk2GLWe6mI2YG3xO28JIlb4JiNpLdRRVN9 bYuy9Uqckq5vYNH22NQGflnygdTrodblOQ8XYx5iE+rBj05fEeWdD5XeV6ZzhjYIvj OD4L++Wn3c+kTd2qDyL5dNQdO1HmnIJgomtu35bc= Date: Thu, 20 Aug 2020 09:03:26 +0200 From: Mauro Carvalho Chehab To: John Stultz Cc: Laurent Pinchart , Sam Ravnborg , Neil Armstrong , David Airlie , Wanchun Zheng , linuxarm@huawei.com, dri-devel , Andrzej Hajda , driverdevel , Daniel Borkmann , John Fastabend , Xiubin Zhang , Wei Xu , Xinliang Liu , Xinwei Kong , Tomi Valkeinen , Bogdan Togorean , Jakub Kicinski , Laurentiu Palcu , linux-media , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Liwei Cai , Jesper Dangaard Brouer , Manivannan Sadhasivam , Chen Feng , Alexei Starovoitov , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Rob Herring , mauro.chehab@huawei.com, Rob Clark , linux-arm-kernel , Greg Kroah-Hartman , lkml , Liuyao An , Network Development , Rongrong Zou , BPF Mailing List , "David S. Miller" Subject: Re: [PATCH 00/49] DRM driver for Hikey 970 Message-ID: <20200820090326.3f400a15@coco.lan> In-Reply-To: References: <20200819152120.GA106437@ravnborg.org> <20200819153045.GA18469@pendragon.ideasonboard.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu: > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart > wrote: > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: =20 > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote= : =20 > > > > This patch series port the out-of-tree driver for Hikey 970 (which > > > > should also support Hikey 960) from the official 96boards tree: > > > > > > > > https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > > > Based on his history, this driver seems to be originally written > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > > implementation for FB dev API. > > > > > > > > As I need to preserve the original history (with has patches from > > > > both HiSilicon and from Linaro), I'm starting from the original > > > > patch applied there. The remaining patches are incremental, > > > > and port this driver to work with upstream Kernel. > > > > =20 > ... > > > > - Due to legal reasons, I need to preserve the authorship of > > > > each one responsbile for each patch. So, I need to start from > > > > the original patch from Kernel 4.4; =20 > ... > > > I do acknowledge you need to preserve history and all - > > > but this patchset is not easy to review. =20 > > > > Why do we need to preserve history ? Adding relevant Signed-off-by and > > Co-developed-by should be enough, shouldn't it ? Having a public branch > > that contains the history is useful if anyone is interested, but I don't > > think it's required in mainline. =20 >=20 > Yea. I concur with Laurent here. I'm not sure what legal reasoning you > have on this but preserving the "absolute" history here is actively > detrimental for review and understanding of the patch set. >=20 > Preserving Authorship, Signed-off-by lines and adding Co-developed-by > lines should be sufficient to provide both atribution credit and DCO > history. I'm not convinced that, from legal standpoint, folding things would be enough. See, there are at least 3 legal systems involved here among the different patch authors: - civil law; - common law; - customary law + common law. Merging stuff altogether from different law systems can be problematic, and trying to discuss this with experienced IP property lawyers will for sure take a lot of time and efforts. I also bet that different lawyers will have different opinions, because laws are subject to=20 interpretation. With that matter I'm not aware of any court rules=20 with regards to folded patches. So, it sounds to me that folding=20 patches is something that has yet to be proofed in courts around the globe. At least for US legal system, it sounds that the Country of origin of a patch is relevant, as they have a concept of "national technology" that can be subject to export regulations. =46rom my side, I really prefer to play safe and stay out of any such legal discussions. Thanks, Mauro From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CAC0BC433E4 for ; Thu, 20 Aug 2020 07:03:42 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9E5E12078B for ; Thu, 20 Aug 2020 07:03:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZqoFqS0Q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E5E12078B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 6880B882A4; Thu, 20 Aug 2020 07:03:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1bEtcavF84Q; Thu, 20 Aug 2020 07:03:41 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by hemlock.osuosl.org (Postfix) with ESMTP id 2DCC38829B; Thu, 20 Aug 2020 07:03:41 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 03EE41BF388 for ; Thu, 20 Aug 2020 07:03:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id DD84721517 for ; Thu, 20 Aug 2020 07:03:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wZW0mlbKLR5 for ; Thu, 20 Aug 2020 07:03:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by silver.osuosl.org (Postfix) with ESMTPS id 8D4FA20358 for ; Thu, 20 Aug 2020 07:03:37 +0000 (UTC) Received: from coco.lan (ip5f5ad5a3.dynamic.kabel-deutschland.de [95.90.213.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0D65C20738; Thu, 20 Aug 2020 07:03:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597907017; bh=rxLdO7cakOHvaDBZxCktkD2vNW5pXxH+L8dnLiX+3l0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZqoFqS0Qk5EvC6CMaAigGknwQX73VDCtk2GLWe6mI2YG3xO28JIlb4JiNpLdRRVN9 bYuy9Uqckq5vYNH22NQGflnygdTrodblOQ8XYx5iE+rBj05fEeWdD5XeV6ZzhjYIvj OD4L++Wn3c+kTd2qDyL5dNQdO1HmnIJgomtu35bc= Date: Thu, 20 Aug 2020 09:03:26 +0200 From: Mauro Carvalho Chehab To: John Stultz Subject: Re: [PATCH 00/49] DRM driver for Hikey 970 Message-ID: <20200820090326.3f400a15@coco.lan> In-Reply-To: References: <20200819152120.GA106437@ravnborg.org> <20200819153045.GA18469@pendragon.ideasonboard.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Neil Armstrong , David Airlie , Wanchun Zheng , linuxarm@huawei.com, dri-devel , Andrzej Hajda , Laurent Pinchart , Sam Ravnborg , driverdevel , Daniel Borkmann , John Fastabend , Xiubin Zhang , Wei Xu , Xinliang Liu , Xinwei Kong , Tomi Valkeinen , Bogdan Togorean , Jakub Kicinski , Laurentiu Palcu , linux-media , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Liwei Cai , Jesper Dangaard Brouer , Manivannan Sadhasivam , Chen Feng , Alexei Starovoitov , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Rob Herring , mauro.chehab@huawei.com, Rob Clark , linux-arm-kernel , Greg Kroah-Hartman , lkml , Liuyao An , Network Development , Rongrong Zou , BPF Mailing List , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu: > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart > wrote: > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > > > > This patch series port the out-of-tree driver for Hikey 970 (which > > > > should also support Hikey 960) from the official 96boards tree: > > > > > > > > https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > > > Based on his history, this driver seems to be originally written > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > > implementation for FB dev API. > > > > > > > > As I need to preserve the original history (with has patches from > > > > both HiSilicon and from Linaro), I'm starting from the original > > > > patch applied there. The remaining patches are incremental, > > > > and port this driver to work with upstream Kernel. > > > > > ... > > > > - Due to legal reasons, I need to preserve the authorship of > > > > each one responsbile for each patch. So, I need to start from > > > > the original patch from Kernel 4.4; > ... > > > I do acknowledge you need to preserve history and all - > > > but this patchset is not easy to review. > > > > Why do we need to preserve history ? Adding relevant Signed-off-by and > > Co-developed-by should be enough, shouldn't it ? Having a public branch > > that contains the history is useful if anyone is interested, but I don't > > think it's required in mainline. > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you > have on this but preserving the "absolute" history here is actively > detrimental for review and understanding of the patch set. > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by > lines should be sufficient to provide both atribution credit and DCO > history. I'm not convinced that, from legal standpoint, folding things would be enough. See, there are at least 3 legal systems involved here among the different patch authors: - civil law; - common law; - customary law + common law. Merging stuff altogether from different law systems can be problematic, and trying to discuss this with experienced IP property lawyers will for sure take a lot of time and efforts. I also bet that different lawyers will have different opinions, because laws are subject to interpretation. With that matter I'm not aware of any court rules with regards to folded patches. So, it sounds to me that folding patches is something that has yet to be proofed in courts around the globe. At least for US legal system, it sounds that the Country of origin of a patch is relevant, as they have a concept of "national technology" that can be subject to export regulations. >From my side, I really prefer to play safe and stay out of any such legal discussions. Thanks, Mauro _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF783C433E1 for ; Thu, 20 Aug 2020 07:04:59 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9C22A20738 for ; Thu, 20 Aug 2020 07:04:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="zc87txLg"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZqoFqS0Q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C22A20738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=B5bUQNRW42fh/d2r34iGQvjDI3KRoCIb+iFcFnc73GA=; b=zc87txLgRSLt2tx+NqW0WvXmC 6h4KNpP3AmPM0n7xywCfKFW4pNDP8QvH/JDdh1RTNBTIOyo6wZ8Yjl9ivgXehBJ//gEpSgfmmg343 kYXle/80Mdv1FF8W5wzXEtxxNZo/LbpZgE4d6/vTlPVmxBfVfcB0HV8ajBYrI1X/kaYUqbr2NRZqr Da23pdJsuLVJF6XQNf6QUDIiYcXPwYgJQqJA0L6loWcRINLsm3FGLYB7oR6GjGmGGvHoum6d1FBp1 oshvy2NrKhWrERJuoWf59dAGsteWIBJxYBBpBfERCpqsaodPHJXGjCcQ/THCWyQQMaKEw9I/RvGxE mbtShDS8A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8ebt-0007dY-Jx; Thu, 20 Aug 2020 07:03:41 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8ebq-0007cn-Dh for linux-arm-kernel@lists.infradead.org; Thu, 20 Aug 2020 07:03:39 +0000 Received: from coco.lan (ip5f5ad5a3.dynamic.kabel-deutschland.de [95.90.213.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0D65C20738; Thu, 20 Aug 2020 07:03:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597907017; bh=rxLdO7cakOHvaDBZxCktkD2vNW5pXxH+L8dnLiX+3l0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZqoFqS0Qk5EvC6CMaAigGknwQX73VDCtk2GLWe6mI2YG3xO28JIlb4JiNpLdRRVN9 bYuy9Uqckq5vYNH22NQGflnygdTrodblOQ8XYx5iE+rBj05fEeWdD5XeV6ZzhjYIvj OD4L++Wn3c+kTd2qDyL5dNQdO1HmnIJgomtu35bc= Date: Thu, 20 Aug 2020 09:03:26 +0200 From: Mauro Carvalho Chehab To: John Stultz Subject: Re: [PATCH 00/49] DRM driver for Hikey 970 Message-ID: <20200820090326.3f400a15@coco.lan> In-Reply-To: References: <20200819152120.GA106437@ravnborg.org> <20200819153045.GA18469@pendragon.ideasonboard.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200820_030338_671751_B96A8F7E X-CRM114-Status: GOOD ( 31.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Neil Armstrong , David Airlie , Wanchun Zheng , linuxarm@huawei.com, dri-devel , Andrzej Hajda , Laurent Pinchart , Sam Ravnborg , driverdevel , Daniel Borkmann , John Fastabend , Xiubin Zhang , Wei Xu , Xinliang Liu , Xinwei Kong , Tomi Valkeinen , Bogdan Togorean , Jakub Kicinski , Laurentiu Palcu , linux-media , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Liwei Cai , Jesper Dangaard Brouer , Manivannan Sadhasivam , Chen Feng , Alexei Starovoitov , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Rob Herring , mauro.chehab@huawei.com, Rob Clark , linux-arm-kernel , Greg Kroah-Hartman , lkml , Liuyao An , Network Development , Rongrong Zou , BPF Mailing List , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu: > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart > wrote: > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > > > > This patch series port the out-of-tree driver for Hikey 970 (which > > > > should also support Hikey 960) from the official 96boards tree: > > > > > > > > https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > > > Based on his history, this driver seems to be originally written > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > > implementation for FB dev API. > > > > > > > > As I need to preserve the original history (with has patches from > > > > both HiSilicon and from Linaro), I'm starting from the original > > > > patch applied there. The remaining patches are incremental, > > > > and port this driver to work with upstream Kernel. > > > > > ... > > > > - Due to legal reasons, I need to preserve the authorship of > > > > each one responsbile for each patch. So, I need to start from > > > > the original patch from Kernel 4.4; > ... > > > I do acknowledge you need to preserve history and all - > > > but this patchset is not easy to review. > > > > Why do we need to preserve history ? Adding relevant Signed-off-by and > > Co-developed-by should be enough, shouldn't it ? Having a public branch > > that contains the history is useful if anyone is interested, but I don't > > think it's required in mainline. > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you > have on this but preserving the "absolute" history here is actively > detrimental for review and understanding of the patch set. > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by > lines should be sufficient to provide both atribution credit and DCO > history. I'm not convinced that, from legal standpoint, folding things would be enough. See, there are at least 3 legal systems involved here among the different patch authors: - civil law; - common law; - customary law + common law. Merging stuff altogether from different law systems can be problematic, and trying to discuss this with experienced IP property lawyers will for sure take a lot of time and efforts. I also bet that different lawyers will have different opinions, because laws are subject to interpretation. With that matter I'm not aware of any court rules with regards to folded patches. So, it sounds to me that folding patches is something that has yet to be proofed in courts around the globe. At least for US legal system, it sounds that the Country of origin of a patch is relevant, as they have a concept of "national technology" that can be subject to export regulations. >From my side, I really prefer to play safe and stay out of any such legal discussions. Thanks, Mauro _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77DD5C433DF for ; Thu, 20 Aug 2020 07:03:39 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4DBB62078B for ; Thu, 20 Aug 2020 07:03:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZqoFqS0Q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4DBB62078B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 91B4E6E8AC; Thu, 20 Aug 2020 07:03:38 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id 88C716E8AC for ; Thu, 20 Aug 2020 07:03:37 +0000 (UTC) Received: from coco.lan (ip5f5ad5a3.dynamic.kabel-deutschland.de [95.90.213.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0D65C20738; Thu, 20 Aug 2020 07:03:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597907017; bh=rxLdO7cakOHvaDBZxCktkD2vNW5pXxH+L8dnLiX+3l0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZqoFqS0Qk5EvC6CMaAigGknwQX73VDCtk2GLWe6mI2YG3xO28JIlb4JiNpLdRRVN9 bYuy9Uqckq5vYNH22NQGflnygdTrodblOQ8XYx5iE+rBj05fEeWdD5XeV6ZzhjYIvj OD4L++Wn3c+kTd2qDyL5dNQdO1HmnIJgomtu35bc= Date: Thu, 20 Aug 2020 09:03:26 +0200 From: Mauro Carvalho Chehab To: John Stultz Subject: Re: [PATCH 00/49] DRM driver for Hikey 970 Message-ID: <20200820090326.3f400a15@coco.lan> In-Reply-To: References: <20200819152120.GA106437@ravnborg.org> <20200819153045.GA18469@pendragon.ideasonboard.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Neil Armstrong , David Airlie , Wanchun Zheng , linuxarm@huawei.com, dri-devel , Andrzej Hajda , Laurent Pinchart , Sam Ravnborg , driverdevel , Daniel Borkmann , John Fastabend , Xiubin Zhang , Wei Xu , Xinliang Liu , Xinwei Kong , Tomi Valkeinen , Bogdan Togorean , Jakub Kicinski , Laurentiu Palcu , linux-media , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Liwei Cai , Jesper Dangaard Brouer , Manivannan Sadhasivam , Chen Feng , Alexei Starovoitov , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Rob Herring , mauro.chehab@huawei.com, Rob Clark , linux-arm-kernel , Greg Kroah-Hartman , lkml , Liuyao An , Network Development , Rongrong Zou , BPF Mailing List , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu: > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart > wrote: > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote: > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote: > > > > This patch series port the out-of-tree driver for Hikey 970 (which > > > > should also support Hikey 960) from the official 96boards tree: > > > > > > > > https://github.com/96boards-hikey/linux/tree/hikey970-v4.9 > > > > > > > > Based on his history, this driver seems to be originally written > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original > > > > driver used to depend on ION (from Kernel 4.4) and had its own > > > > implementation for FB dev API. > > > > > > > > As I need to preserve the original history (with has patches from > > > > both HiSilicon and from Linaro), I'm starting from the original > > > > patch applied there. The remaining patches are incremental, > > > > and port this driver to work with upstream Kernel. > > > > > ... > > > > - Due to legal reasons, I need to preserve the authorship of > > > > each one responsbile for each patch. So, I need to start from > > > > the original patch from Kernel 4.4; > ... > > > I do acknowledge you need to preserve history and all - > > > but this patchset is not easy to review. > > > > Why do we need to preserve history ? Adding relevant Signed-off-by and > > Co-developed-by should be enough, shouldn't it ? Having a public branch > > that contains the history is useful if anyone is interested, but I don't > > think it's required in mainline. > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you > have on this but preserving the "absolute" history here is actively > detrimental for review and understanding of the patch set. > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by > lines should be sufficient to provide both atribution credit and DCO > history. I'm not convinced that, from legal standpoint, folding things would be enough. See, there are at least 3 legal systems involved here among the different patch authors: - civil law; - common law; - customary law + common law. Merging stuff altogether from different law systems can be problematic, and trying to discuss this with experienced IP property lawyers will for sure take a lot of time and efforts. I also bet that different lawyers will have different opinions, because laws are subject to interpretation. With that matter I'm not aware of any court rules with regards to folded patches. So, it sounds to me that folding patches is something that has yet to be proofed in courts around the globe. At least for US legal system, it sounds that the Country of origin of a patch is relevant, as they have a concept of "national technology" that can be subject to export regulations. >From my side, I really prefer to play safe and stay out of any such legal discussions. Thanks, Mauro _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel