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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot