OK. I'm top posting on purpose. This request expands what I'm trying to do too much, in ways I think are unfair. The original authors didn't ask for a copyright line and we're hopelessly inconsistent about it in the tree. I'm not fixing that problem here. I'm sorry, but that's potentially a huge ask. I went through them all and found a couple with no author at all (a much bigger problem, but not my problem today) and a couple where Fabreise was included. I'll drop those for simplicity.
The deeper analysis turns a 10-minute project into an hours-long, detailed analysis. I don't have time for it, and the analysis likely won't produce better results because the rest of the tree has similar problems regardless of how we mark the source. And it seems to stand on too fine a point since the Linux kernel already set a much stronger precedent than I'm doing here. What I'm doing here is legally defensible and the hours-long analysis won't produce anything more defensible. The suggested analysis is, at best, incomplete since (a) authorship in this part of the tree is sloppy at times and (b) it doesn't consider the out-of-tree history, which sometimes produces different results with `git blame`. It's turtles all the way down here. And I've also gotten mixed messages in the past when I tried to attribute authorship for code I copied from linux-user in the past, so I lack a good set of criteria to do the analysis. I tried to highlight that these were old files in the [PATCH v4 00/24] bsd-user: Upstream misc system calls (System V IPC, reboot, etc) series, but I was still requested to add the SPDX headers instead since they were truly "new files." So I'm doing them all to avoid that in the future. Since I don't want arguments and when I push back I get inconsistent results for simimlar situations. I'm trying to not let my irritation show through too much, but I'm only 10k lines into 40k of upstreaming and these side trips are slowing things down too much. I appreciate the reviews that have found bugs in the code, but I'm struggling with requests like this. I really need to limit the scope of what I take on because there's a lot left to do and I'm doing it in my spare time. So does that sound like a good plan? Or what should I do? Warner P.S. Sorry if my frustration is showing through too much... On Tue, Mar 3, 2026 at 5:52 AM Daniel P. Berrangé <[email protected]> wrote: > On Tue, Mar 03, 2026 at 05:17:15AM -0700, Warner Losh wrote: > > On Tue, Mar 3, 2026 at 1:51 AM Daniel P. Berrangé <[email protected]> > > wrote: > > > > > On Mon, Mar 02, 2026 at 09:46:06PM -0700, Warner Losh wrote: > > > > Switch all the files over to using SPDX. This also corrects various > > > > small errors in the form of the copyright messages. It adds > copyright to > > > > those files that lack it. There's no functional change. > > > > > > > > Signed-off-by: Stacey Son <[email protected]> > > > > Signed-off-by: Warner Losh <[email protected]> > > > > --- > > > > Since I'll be upstreaming more files from bsd-user, and since qemu > now > > > > requires SPDX and prohibits boilerplate, this will make it easier. > I've > > > > converted all the relevant bits in bsd-user upstream. > > > > > > Note, QEMU / checkpatch.pl only requires SDPX on *newly* authored > files. > > > Existing code files, or new files whose content is copied from an > > > existing file (either inside or outside QEMU git) are exempt from this > > > and in fact required to be left without SPDX. > > > > > > The reasoning is that there is some uncertainty about the legality of > > > removing license header text from existing files due to the GPL clause > > > 1 which says > > > > > > "keep intact all the notices that refer to this License and > > > to the absence of any warranty;" > > > > > > I interpret that to mean we can not remove license header text from > > > files unless the person doing the removal is the exclusive copyright > > > holder, or has got recorded permission from all copyright holders > > > that apply to each file changed. > > > > > > It is confusing for people because Linux removed all their GPL header > > > text in favour of SPDX, but never provided any clear explanation of > > > why they considered that to be acceptable from the GPL compliance POV. > > > > > > > So I have Stacey's permission to do this, and he's the only actual > copyright > > holder on these files. If I messed up on any, specifically, please let me > > know. > > That's why I included his signed-off-by: he signed off on it and that > he's > > legally able to make the change. > > None of that was explained in the commit message, hence why I'm > raising this as review feedback. > > As a sanity check I did the following to list number of contributors > besides yourself & Stacey: > > $ for f in $(awk '{print $1}' < filelist.txt) ; do echo -n "$f: " ; git > log $f | grep ^Author |grep -v Stacey | grep -v Warner | sort | uniq | wc > -l ; done > bsd-user/aarch64/signal.c: 0 > bsd-user/aarch64/target_arch.h: 0 > bsd-user/aarch64/target_arch_cpu.c: 0 > bsd-user/aarch64/target_arch_cpu.h: 2 > bsd-user/aarch64/target_arch_elf.h: 1 > bsd-user/aarch64/target_arch_reg.h: 0 > bsd-user/aarch64/target_arch_signal.h: 0 > bsd-user/aarch64/target_arch_sigtramp.h: 0 > bsd-user/aarch64/target_arch_sysarch.h: 0 > bsd-user/aarch64/target_arch_thread.h: 0 > bsd-user/aarch64/target_arch_vmparam.h: 0 > bsd-user/aarch64/target_syscall.h: 0 > bsd-user/arm/signal.c: 1 > bsd-user/arm/target_arch.h: 2 > bsd-user/arm/target_arch_cpu.c: 1 > bsd-user/arm/target_arch_cpu.h: 3 > bsd-user/arm/target_arch_elf.h: 3 > bsd-user/arm/target_arch_reg.h: 1 > bsd-user/arm/target_arch_signal.h: 1 > bsd-user/arm/target_arch_sigtramp.h: 1 > bsd-user/arm/target_arch_sysarch.h: 1 > bsd-user/arm/target_arch_thread.h: 1 > bsd-user/arm/target_arch_vmparam.h: 1 > bsd-user/arm/target_syscall.h: 1 > bsd-user/bsd-file.h: 3 > bsd-user/bsd-mem.c: 1 > bsd-user/bsd-mem.h: 5 > bsd-user/bsd-proc.c: 2 > bsd-user/bsd-proc.h: 4 > bsd-user/bsdload.c: 5 > bsd-user/elfload.c: 21 > bsd-user/freebsd/os-misc.h: 2 > bsd-user/freebsd/os-proc.c: 3 > bsd-user/freebsd/os-proc.h: 3 > bsd-user/freebsd/os-stat.c: 1 > bsd-user/freebsd/os-stat.h: 3 > bsd-user/freebsd/os-strace.h: 0 > bsd-user/freebsd/target_os_elf.h: 2 > bsd-user/freebsd/target_os_siginfo.h: 2 > bsd-user/freebsd/target_os_stack.h: 3 > bsd-user/freebsd/target_os_thread.h: 1 > bsd-user/freebsd/target_os_user.h: 2 > bsd-user/freebsd/target_os_vmparam.h: 1 > bsd-user/i386/signal.c: 1 > bsd-user/i386/target_arch.h: 1 > bsd-user/i386/target_arch_cpu.c: 2 > bsd-user/i386/target_arch_cpu.h: 3 > bsd-user/i386/target_arch_elf.h: 2 > bsd-user/i386/target_arch_reg.h: 1 > bsd-user/i386/target_arch_signal.h: 0 > bsd-user/i386/target_arch_sigtramp.h: 1 > bsd-user/i386/target_arch_sysarch.h: 1 > bsd-user/i386/target_arch_thread.h: 1 > bsd-user/i386/target_arch_vmparam.h: 1 > bsd-user/i386/target_syscall.h: 2 > bsd-user/main.c: 47 > bsd-user/mmap.c: 14 > bsd-user/qemu-bsd.h: 1 > bsd-user/qemu.h: 24 > bsd-user/signal.c: 14 > bsd-user/strace.c: 6 > bsd-user/syscall_defs.h: 8 > bsd-user/x86_64/signal.c: 1 > bsd-user/x86_64/target_arch.h: 1 > bsd-user/x86_64/target_arch_cpu.c: 2 > bsd-user/x86_64/target_arch_cpu.h: 3 > bsd-user/x86_64/target_arch_elf.h: 2 > bsd-user/x86_64/target_arch_reg.h: 1 > bsd-user/x86_64/target_arch_signal.h: 1 > bsd-user/x86_64/target_arch_sigtramp.h: 1 > bsd-user/x86_64/target_arch_sysarch.h: 1 > bsd-user/x86_64/target_arch_thread.h: 2 > bsd-user/x86_64/target_arch_vmparam.h: 1 > bsd-user/x86_64/target_syscall.h: 3 > > > I checked a few of the cases where only 1/2/3 other authors are > listed, the changes they made appear to be trivial and could be > considered non-copyrightable. So converting most of the files > is probably OK with just yourself & Stacey's agreement. > > The big notable exceptions appear to be many of the files directly > in the bsd-user/ directory, as opposed to sub-dirs, which still > contain code dating back to the original impl of bsd-user. > > > Also, I did this to reduce friction in upstreaming bsd-user which has > been > > going on for 6ish years now. The SPDX rule is one more thing that slows > > that down. Rather than get an exception to the rule, I brought everything > > into compliance so it isn't yet another issue that takes more time > because > > I forgot to do it for a specific patch series. The more issues I have to > > have > > on my checklist, the more the works are gummed up and the slower the > > progress is. We still have somethign like ~30k lines to go last I > checked. > > > > > Also, these files have also been out of tree for over a decade. The new > > rule forces me to do what you're complaining about the Linux tree doing: > > remove GPL markings to get it into your tree. Well which is it? Either > it's > > wrong and I shouldn't have to do it for the old files. Or what I've done > > is proper since it's uniform. Your tree is just an arbitrary repo of > these > > files, and isn't special in any meaningful way. So I'm in a no-win > situation > > here by your argument. > > The checkpatch.pl script warnings indicate that SDPX is only required > on newly added files, and also states that this does not apply if > copying from existing code. If you've suggestions on how we can improve > the contributor docs or checkpatch script messages to better explain this > please feel free to say > > > Also, when I talk about a burdensome and cumbersome upstreaming process, > > this is yet another example. An arbitrary rule that causes friction, but > > provides > > no actual benefit. It's like the style rules: I have to arbitrarily > > reformat code that > > is like that in linux-user because this is "new code". So I spend a fair > > amount of > > time fetching different stones to obey the rules, but since now the code > is > > different > > it becomes harder to track linux-user or to ever converge them. Change > for > > the > > sake of compliance with an arbitrary rule that doesn't apply elsewhere > (for > > whatever > > reason) is one of the death by a thousand cuts I, and others doing this > > work, have > > been suffering for far too long. It's in large measure why things aren't > > further along: > > it steals what little time I have for this and it demotivates further > work > > for a while. > > There's always a tradeoff in these areas between having project standards > and the burden that places on contributors to comply with the standards. > It can't really be a total free-for-all in a project of the scale that > QEMU is. In addition, caution around license compliance is a key factor > for QEMU, as a critical infrastructure component underpinning a huge > ecosystem of projects and activities. > > I agree that the style formatting rules in particular are quite painful > because we never fix historic code to comply with the stated style. Most > other projects would enforce code style unconditionally across the code > base. I would very much like that situation to change. > > > So, having said that, is there any specific objection to anything I've > > done? Given > > Stacey's explicit blessing of this change (you'll recall from the patch > > series I just did > > I waited until I had contacted him before I changing it there), did I > mess > > up anywhere? > > Two simple changes from my pov: > > * Remove the changes to the files that have copyrightable code from > people besides yourself & Stacey. This looks to be mostly the older > files in the root bsd-user/ directory > > * Mention in the commit message that this change is being made only > to files where yourself & Stacey are the copyright holders. > > > With regards, > Daniel > -- > |: https://berrange.com ~~ https://hachyderm.io/@berrange :| > |: https://libvirt.org ~~ https://entangle-photo.org :| > |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :| > >
