On Tue, Jun 24, 2025 at 10:34:40AM +0200, Cédric Le Goater wrote:
> + Daniel
> 
> On 6/23/25 11:30, John Levon wrote:
> > Add SPDX-License-Identifier to some files missing it in hw/vfio/.
> > 
> > Signed-off-by: John Levon <john.le...@nutanix.com>
> > ---
> >   hw/vfio/trace.h      | 3 +++
> >   hw/vfio/Kconfig      | 2 ++
> >   hw/vfio/meson.build  | 2 ++
> >   hw/vfio/trace-events | 2 ++
> >   4 files changed, 9 insertions(+)
> 
> I think that's OK to add a GPL-2.0-or-later SPDX tag on these files
> because they are simple infrastructure files, and we know when they
> come from. How useful it is ? that I don't know.
> 
> For other source files, without a license, if we have any, I think
> the answer would be much more complex.
> 
> Daniel, What would be our position on such files ?

The only hard requirement we have stated is that all /newly/ created
files ("new" as in git patch reports it as a new file) must have the
SPDX tag, and must NOT have license boilerplate. This is enforced by
checkpatch.

We are NOT expecting SPDX tags to be added to existing files in
general, whether they have a license boilerplate or not.

Adding SPDX tags to existing files without any boilerplate text
at all is likely the more interesting & beneficial scenario
though.

If adding SPDX tags to existing files, you must do due diligence
over the history of the file, in order to validate the implicit
license it would have had based on QEMU's rules when the file was
first created. We can't just blindly assume it was GPL-2.0-or-later,
as it might have been copied from elsewhere when first created and
thus inherit terms from another file.

For the specific 4 files in this patch, I think it is unlikely there
will be any surprises in their license history though. They all post-date
our top level  statement that new contributions are implicitly
GPL2.0-or-later, and also won't have been copied from elsewhere.

TL;DR: this patch looks reasonable, and we might as well take it, but
there is no expectation that people need to extend this work across the
code tree unless they love doing historical code tracing :-)

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


Reply via email to