Le mardi 25 août 2020 à 13:30 +0200, Mauro Carvalho Chehab a écrit : > Em Tue, 25 Aug 2020 05:29:29 +1000 > Dave Airlie <airl...@gmail.com> escreveu: > > > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart > > <laurent.pinch...@ideasonboard.com> wrote: > > > Hi Mauro, > > > > > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote: > > > > 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. > > > > > > Let's be serious for a moment. If you think there are legal issues in > > > taking GPL-v2.0-only patches and squashing them while retaining > > > authorship information through tags, the Linux kernel if *full* of that. > > > You also routinely modify patches that you commit to the media subsystem > > > to fix "small issues". > > > > > > The country of origin argument makes no sense either, the kernel code > > > base if full of code coming from pretty much all country on the planet. > > > > > > Keeping the patches separate make this hard to review. Please squash > > > them. > > > > I'm inclined to agree with Laurent here. > > > > Patches submitted as GPL-v2 with DCO lines and author names/companies > > should be fine to be squashed and rearranged, > > as long as the DCO and Authorship is kept somewhere in the new patch > > that is applied. > > > > Review is more important here. > > Sorry, but I can't agree that review is more important than to be able > to properly indicate copyrights in a valid way at the legal systems that > it would apply ;-)
Regardless of the "review-ability", our users distribute the Linux Kernel as a whole, so who contributed which specific line of code is already lost in a way. All we see in the distribution if a list of copyright holder and licenses. In this context, the per patches ownership have no legal implication. My two, non lawyer cents. > > In any case, there's an easy way to make the code easy to review: > I can write the patches against staging (where it is OK to submit > preserving the history) and then add a final patch moving it out > of staging. > > You can then just review the last patch, as it will contain the > entire code on it. > > Another alternative, as I'm already doing with Sam, is for me to > submit the folded code as a reply to 00/xx. You can then just > review the final code, without concerning about how the code reached > there. > > From review point of the view, this will be the same as reviewing > a folded patch, but, from legal standpoint, the entire copyright > chain will be preserved. > > Thanks, > Mauro
