meson.build files are missing copyright/license headers

meson.build files are missing copyright/license headers

[Peter Maydell]

 It looks like the new meson.build files are missing the usual
copyright-and-license header comment. Could somebody add them,
please?

scripts/ninjatool.py does have a copyright line but is missing
the license statement.

thanks
-- PMM

Re: meson.build files are missing copyright/license headers

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

Hi

On Mon, Aug 24, 2020 at 1:44 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

>  It looks like the new meson.build files are missing the usual
> copyright-and-license header comment. Could somebody add them,
> please?
>
> scripts/ninjatool.py does have a copyright line but is missing
> the license statement.
>
>
Afaik, most makefiles didn't have any, so it falls under the default GPL2+
LICENSE rule.

If it's a matter of prepending

# SPDX-License-Identifier: GPL-2.0-or-later

On each meson.build file, I can prepare a patch. If you expect something
different, it's time to tell.

thanks
-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 1134 bytes --]

Re: meson.build files are missing copyright/license headers

[Peter Maydell]

On Mon, 24 Aug 2020 at 19:29, Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
> On Mon, Aug 24, 2020 at 1:44 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>>  It looks like the new meson.build files are missing the usual
>> copyright-and-license header comment. Could somebody add them,
>> please?
>>
>> scripts/ninjatool.py does have a copyright line but is missing
>> the license statement.
>>
>
> Afaik, most makefiles didn't have any, so it falls under the default GPL2+ LICENSE rule.

Yep, but the rule is that new files should have them, even if
old files didn't always.

> If it's a matter of prepending
>
> # SPDX-License-Identifier: GPL-2.0-or-later
>
> On each meson.build file, I can prepare a patch.

Everything needs at least a copyright line (in this case, judging
by existing files in the tree it will probably be something like
"Copyright (c) 2020 Red Hat, Inc." but check with your legal
department what they like ;-)), plus a statement that clearly
defines the license the code is under. We don't mandate SPDX[*],
but it will do the job if you want to use it.

[*] Mostly because nobody's cared enough to say "we should
standardize on this and convert existing files and add the
check to checkpatch that new files have an SPDX line".

thanks
-- PMM

Re: meson.build files are missing copyright/license headers

[Thomas Huth]

On 24/08/2020 20.46, Peter Maydell wrote:
> On Mon, 24 Aug 2020 at 19:29, Marc-André Lureau
> <marcandre.lureau@gmail.com> wrote:
>> On Mon, Aug 24, 2020 at 1:44 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>>>   It looks like the new meson.build files are missing the usual
>>> copyright-and-license header comment. Could somebody add them,
>>> please?
>>>
>>> scripts/ninjatool.py does have a copyright line but is missing
>>> the license statement.
>>>
>>
>> Afaik, most makefiles didn't have any, so it falls under the default GPL2+ LICENSE rule.
> 
> Yep, but the rule is that new files should have them, even if
> old files didn't always.
> 
>> If it's a matter of prepending
>>
>> # SPDX-License-Identifier: GPL-2.0-or-later
>>
>> On each meson.build file, I can prepare a patch.
> 
> Everything needs at least a copyright line (in this case, judging
> by existing files in the tree it will probably be something like
> "Copyright (c) 2020 Red Hat, Inc." but check with your legal
> department what they like ;-)), plus a statement that clearly
> defines the license the code is under. We don't mandate SPDX[*],
> but it will do the job if you want to use it.
> 
> [*] Mostly because nobody's cared enough to say "we should
> standardize on this and convert existing files and add the
> check to checkpatch that new files have an SPDX line".

We should standardize on this and convert existing files and add the
check to checkpatch that new files have an SPDX line! :-)

Ok, now sombody said it loud. Would there be any objections to enforce 
this via checkpatch on new files?

  Thomas

Re: meson.build files are missing copyright/license headers

[Peter Maydell]

On Tue, 25 Aug 2020 at 06:57, Thomas Huth <thuth@redhat.com> wrote:
>
> On 24/08/2020 20.46, Peter Maydell wrote:
> > We don't mandate SPDX[*],
> > but it will do the job if you want to use it.
> >
> > [*] Mostly because nobody's cared enough to say "we should
> > standardize on this and convert existing files and add the
> > check to checkpatch that new files have an SPDX line".
>
> We should standardize on this and convert existing files and add the
> check to checkpatch that new files have an SPDX line! :-)
>
> Ok, now sombody said it loud. Would there be any objections to enforce
> this via checkpatch on new files?

I wouldn't object, indeed I think checkpatch-enforcement is an
important part of the process. I think that if we're going
to move to SPDX we should:
 * look at the SPDX spec and identify what we need to do beyond
   just adding SPDX lines (eg do we need a LICENSES/ subdir
   like the kernel has with a file per license?)
 * document (in docs/devel?) that we require SPDX
 * decide what our plan is for 3rd-party code (libvixl, etc)
   [where any SPDX line we add will be lost again next time
   we resync our copy of the code]
 * put in a checkpatch check for new files (presumably the
   Linux kernel has one we can borrow)
 * update existing files (I think the kernel folks probably
   have scripted stuff for the easy parts of this; multi-license
   files like fpu/softfloat.c likely need by-hand conversion)

Mostly I think if we're going to do this we should find somebody
who wants to put in the work to push it forwards so we don't
have a half-and-half interminably extended transition between
old-style license notices and SPDX.

thanks
-- PMM

Re: meson.build files are missing copyright/license headers

[Thomas Huth]

On 25/08/2020 11.53, Peter Maydell wrote:
> On Tue, 25 Aug 2020 at 06:57, Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 24/08/2020 20.46, Peter Maydell wrote:
>>> We don't mandate SPDX[*],
>>> but it will do the job if you want to use it.
>>>
>>> [*] Mostly because nobody's cared enough to say "we should
>>> standardize on this and convert existing files and add the
>>> check to checkpatch that new files have an SPDX line".
>>
>> We should standardize on this and convert existing files and add the
>> check to checkpatch that new files have an SPDX line! :-)
>>
>> Ok, now sombody said it loud. Would there be any objections to enforce
>> this via checkpatch on new files?
> 
> I wouldn't object, indeed I think checkpatch-enforcement is an
> important part of the process. I think that if we're going
> to move to SPDX we should:
>  * look at the SPDX spec and identify what we need to do beyond
>    just adding SPDX lines (eg do we need a LICENSES/ subdir
>    like the kernel has with a file per license?)

Ack

>  * document (in docs/devel?) that we require SPDX

Ack

>  * decide what our plan is for 3rd-party code (libvixl, etc)
>    [where any SPDX line we add will be lost again next time
>    we resync our copy of the code]

For things like libvixl, I wonder why this is not a git submodule instead?

For other things that we sync manually, I guess it should be ok to add
the SPDX tags there since the files are likely out of sync anyway.

>  * put in a checkpatch check for new files (presumably the
>    Linux kernel has one we can borrow)

Ack

>  * update existing files (I think the kernel folks probably
>    have scripted stuff for the easy parts of this; multi-license
>    files like fpu/softfloat.c likely need by-hand conversion)

Yes. I think we have to be very careful here with old files - adding the
tags is likely ok, but e.g. removing the boilerplate text in the various
headers at the same time could be problematic (e.g. the MIT license says
"... this permission notice shall be included in all copies or
substantial portions of the Software")...

> Mostly I think if we're going to do this we should find somebody
> who wants to put in the work to push it forwards so we don't
> have a half-and-half interminably extended transition between
> old-style license notices and SPDX.

Agreed. I'd certainly be interested in helping here, but I currently
don't have time to fully drive this. So if someone has spare time for
this that would be very welcome - otherwise I might have a closer look
at the topics in a couple of weeks or months.

 Thomas

Re: meson.build files are missing copyright/license headers

[Peter Maydell]

On Tue, 25 Aug 2020 at 14:58, Thomas Huth <thuth@redhat.com> wrote:
> On 25/08/2020 11.53, Peter Maydell wrote:
> >  * decide what our plan is for 3rd-party code (libvixl, etc)
> >    [where any SPDX line we add will be lost again next time
> >    we resync our copy of the code]
>
> For things like libvixl, I wonder why this is not a git submodule instead?

Because we only take a few files from it, not the whole thing
(which is massive and includes an assembler and a simulator).

> >  * update existing files (I think the kernel folks probably
> >    have scripted stuff for the easy parts of this; multi-license
> >    files like fpu/softfloat.c likely need by-hand conversion)
>
> Yes. I think we have to be very careful here with old files - adding the
> tags is likely ok, but e.g. removing the boilerplate text in the various
> headers at the same time could be problematic (e.g. the MIT license says
> "... this permission notice shall be included in all copies or
> substantial portions of the Software")...

Presumably the kernel folks have been down this route before us...

thanks
-- PMM

Re: meson.build files are missing copyright/license headers

[Daniel P. Berrangé]

On Tue, Aug 25, 2020 at 03:04:57PM +0100, Peter Maydell wrote:
> On Tue, 25 Aug 2020 at 14:58, Thomas Huth <thuth@redhat.com> wrote:
> > On 25/08/2020 11.53, Peter Maydell wrote:
> > >  * decide what our plan is for 3rd-party code (libvixl, etc)
> > >    [where any SPDX line we add will be lost again next time
> > >    we resync our copy of the code]
> >
> > For things like libvixl, I wonder why this is not a git submodule instead?
> 
> Because we only take a few files from it, not the whole thing
> (which is massive and includes an assembler and a simulator).
> 
> > >  * update existing files (I think the kernel folks probably
> > >    have scripted stuff for the easy parts of this; multi-license
> > >    files like fpu/softfloat.c likely need by-hand conversion)
> >
> > Yes. I think we have to be very careful here with old files - adding the
> > tags is likely ok, but e.g. removing the boilerplate text in the various
> > headers at the same time could be problematic (e.g. the MIT license says
> > "... this permission notice shall be included in all copies or
> > substantial portions of the Software")...
> 
> Presumably the kernel folks have been down this route before us...

Advice I've received is that, in general, removing existing license
header text NOT OK unless you are the exclusive copyright holder.

IIUC the kernel folks went through a bunch of work behind the scenes,
involving lawyers to make what they did ok.

IOW, don't compare QEMU to kernel based solely on the public commits
you see doing the change in linux.git, as that would miss any of the
background work involved.

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