[U-Boot] SPDX License status

[Tom Rini <trini@konsulko.com>]

On Thu, Aug 17, 2017 at 10:09:10AM +0200, Wolfgang Denk wrote:

> Dear Tom,
> 
> a quick check reveals that we have a very large number (4,300+) files
> in the U-Boot tree have no SPDX license tags, or - even worse - no
> license information at all.
> 
> I think this should be cleaned up.  And I am aware that this would
> be a lot of effort, and there will be discussions where this is
> needed and where not.
> 
> A few observations:
> 
> - There are some 600+ "Kconfig" files.
> 
> - There are some 500+ ".dts" and ".dtsi" files.  Many of these are
>   copied from the Linux kernel.
> 
> - There are nearly 100 ".cfg" files.
> 
> - There are 1,100+ ".defconfig" files.
> 
> - There are nearly 300 "README" files.
> 
> - There are 549 ".h" and 246 ".c" files.  Again, many of these are
>   copied from the Linux kernel.

So, it's true that it's been a while since I took a U-Boot release and
tossed it at the preferred SPDX-2.0 verifying tool and looked at the
output.  In my defense, I think that was in part because it changed from
an online tool to a local one, and I never got around to setting it up.
But, some advice I did get (I want to say from Karen @ SFC) was that
ignoring "Kconfig" and "Makefile" type files is fine.  I don't recall if
we talked about defconfig files and READMEs, but they too would fit in
that category.

For all of the dts/dtsi files that we copy in-place from Linux,
converting them to SPDX tags would be churn that has to be kept in-place
every update, and upstream does not want them (I had a chat with Frank
or Rob at some point, I think).

> Once upon a time there was an agreement that all files in U-Boot
> shall have proper license information, and that we will use SPDX
> tags for this purpose.  Obviously, this has been largely neglected
> in the past.
> 
> One of the arguments against changtes that I see coming is this:
> "But this file has been copied without changes from project XXX,
> and it must not be changed at all so that it is easy to update it
> when XXX provides new versions."  In many cases, XXX would be the
> Linux kernel.  IIUC this is especially the argument for not touching
> the .dts files, and many architecture header files.
> 
> But if we set ourself the goal to make License compliance for U-Boot
> easy to check, and with largely with automatic tools, then we must
> document the licensing of any imported file _withing_that_file_,
> and in the format defined for this purpose by U-Boot, i. e. using
> SPDX tags.
> 
> Do you agree on this?   Or what is your position?

So, when I've run U-Boot through the "old" SPDX-2.0 tools, it was quite
happy to diagnose the information on dts files from the kernel
correctly, so I don't see changing them to tags as being beneficial.  I
do recall it finding a number of files from the kernel that it either
couldn't deduce or decided was "GPLv1 or later" because of very loose
wording.  This was about 2 years ago, and at least for the few cases I
tracked down, they had been updated in the kernel and I pulled those
updates back in (see 78e9e71c83cf which really really feels like a post
ELCE 'let me dig at this while it's fresh in my mind' commit).

I would be quite happy to see more patches along the lines of
78e9e71c83cf which correct the missing information in files by pulling
in specific changes from their respective upstream (or at least a
specific release that contains the change) that corrects this
information.  I also suspect this will leave us with a few files that in
the kernel today have loose wording and we have to either live with it,
or talk to upstream about updating it.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170818/f18654f9/attachment.sig>