Re: consolidate btrfs checksumming, repair and bio splitting

[Damien Le Moal <damien.lemoal@opensource.wdc.com>]

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