Re: consolidate btrfs checksumming, repair and bio splitting

Damien Le Moal
2022-10-25T00:03:27Z

On 10/25/22 02:34, Chris Mason wrote:
> On 10/24/22 1:10 PM, David Sterba wrote:
>> On Mon, Oct 24, 2022 at 11:25:04AM -0400, Chris Mason wrote:
>>> On 10/24/22 10:44 AM, Christoph Hellwig wrote:
>>>> On Mon, Oct 24, 2022 at 08:12:29AM +0000, Johannes Thumshirn wrote:
>>>>> 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.

>
>>
>> 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.
>
>>
>> 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