Thread (101 messages) 101 messages, 11 authors, 2022-11-11

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help