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