Re: consolidate btrfs checksumming, repair and bio splitting
From: Damien Le Moal <hidden>
Date: 2022-10-25 00:03:27
Also in:
linux-btrfs, linux-fsdevel
On 10/25/22 02:34, Chris Mason wrote:
On 10/24/22 1:10 PM, David Sterba wrote:quoted
On Mon, Oct 24, 2022 at 11:25:04AM -0400, Chris Mason wrote:quoted
On 10/24/22 10:44 AM, Christoph Hellwig wrote:quoted
On Mon, Oct 24, 2022 at 08:12:29AM +0000, Johannes Thumshirn wrote:quoted
David, what's your plan to progress with this series?FYI, I object to merging any of my code into btrfs without a proper copyright notice, and I also need to find some time to remove my previous significant changes given that the btrfs maintainer refuses to take the proper and legally required copyright notice. So don't waste any of your time on this.Christoph's request is well within the norms for the kernel, given that he's making substantial changes to these files. I talked this over with GregKH, who pointed me at: https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects Even if we'd taken up some of the other policies suggested by this doc, I'd still defer to preferences of developers who have made significant changes.I've asked for recommendations or best practice similar to the SPDX process. Something that TAB can acknowledge and that is perhaps also consulted with lawyers. And understood within the linux project, not just that some dudes have an argument because it's all clear as mud and people are used to do things differently.The LF in general doesn't give legal advice, but the link above does help describe common practices. It's up to us to bring in our own lawyers and make decisions about the kinds of changes we're willing to accept. We could ask the TAB (btw, I'm no longer on the TAB) to weigh in, but I think we'll find the normal variety of answers based on subsystem. It's also up to contributors to decide on what kinds of requirements they want to place on continued participation. Individuals and corporations have their own preferences based on advice from their lawyers, and as long as the change is significant, I think we can and should honor their wishes. Does this mean going through and retroactively adding copyright lines? I'd really rather not. If a major contributor comes in and shows a long list of commits and asks for a copyright line, I personally would say yes.
I am not aware of any long list of copyright holders in kernel source code files. I personally thought that the most common practice is to add a copyright notice for the creator (or his/her employer) of a new source file, or if for someone who almost completely rewrite a file. That is I think perfectly acceptable, as adding a new file generally means that a contribution is substantial.
quoted
The link from linux foundation blog is nice but unless this is codified into the process it's just somebody's blog post. Also there's a paragraph about "Why not list every copyright holder?" that covers several points why I don't want to do that.I'm also happy to gather advice about following the suggestions in the LF post. I understand your concerns about listing every copyright holder, but I don't think this has been a major problem in the kernel in general.quoted
But, if TAB says so I will do, perhaps spending hours of unproductive time looking up the whole history of contributors and adding year, name, company whatever to files.I can't imagine anyone asking you to spend time this way. -chris
-- Damien Le Moal Western Digital Research