Re: consolidate btrfs checksumming, repair and bio splitting

Chris Mason
2022-10-24T18:57:45Z

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.

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