SPDX License status
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.
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?
How should we clean up that mess?
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie
Quoted 17 lines · Wolfgang Denk
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.
Quoted 8 lines
- 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).
Quoted 12 lines
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.
Quoted 7 lines
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.
Signature · 8 lines
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>
Dear Tom,
Quoted 5 lines · In message <20170819011542.GE17193@bill-the-cat> you wrote:
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).
Do I interpret this correctly that you think we should NOT insert SPDX tags into files imported from Linux (or other projects)? But how do we keep track of the origin of such files, then? Git meta data information is not useful for automatic tracking tools (or are there such clever tools available by now?)...
Quoted 3 lines
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
I tend to disagree here. THe process of inserting License tags makes automatic scanning easier, and it documents that somebody looked at this.
Quoted 7 lines
I would be quite happy to see more patches along the lines of
78e9e71c83cfwhich 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.
So what do we do for example with all the .dts / .dtsi files? Would you accept patches to insert SPDX tags for U-Boot? [I see no chance to do this in Linux mainline.]
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Minds are like parachutes - they only function when open.
Quoted 9 lines · Wolfgang Denk
Dear Tom,
Quoted 5 lines · In message <20170819011542.GE17193@bill-the-cat> you wrote:
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).
Quoted 5 lines
Do I interpret this correctly that you think we should NOT insert SPDX tags into files imported from Linux (or other projects)? But how do we keep track of the origin of such files, then? Git meta data information is not useful for automatic tracking tools (or are there such clever tools available by now?)...
Generally speaking, Linux Kernel is what we're pulling stuff from, and that's the project that doesn't care for SPDX tags being introduced, and we know what we sync largely there. For other projects, some evangelism about SPDX might work.
Quoted 7 lines
Quoted 3 lines
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
I tend to disagree here. THe process of inserting License tags makes automatic scanning easier, and it documents that somebody looked at this.
For the former, the SPDX tools handle the standard boilerplates fine, and they have to, since most projects aren't using tags. For the latter, given our automated conversion, that's not really true. And at the end of the day, the lawyers need to look it over at the end.
Quoted 11 lines
Quoted 7 lines
I would be quite happy to see more patches along the lines of
78e9e71c83cfwhich 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.So what do we do for example with all the .dts / .dtsi files? Would you accept patches to insert SPDX tags for U-Boot? [I see no chance to do this in Linux mainline.]
We leave the dts/dtsi files un-touched from upstream, yes. Thanks!
Signature · 8 lines
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/20170821/b6cc6966/attachment.sig>
Dear Tom,
Quoted 11 lines · In message <20170821192329.GF17193@bill-the-cat> you wrote:
Quoted 6 lines
Do I interpret this correctly that you think we should NOT insert SPDX tags into files imported from Linux (or other projects)? But how do we keep track of the origin of such files, then? Git meta data information is not useful for automatic tracking tools (or are there such clever tools available by now?)...
Generally speaking, Linux Kernel is what we're pulling stuff from, and that's the project that doesn't care for SPDX tags being introduced, and we know what we sync largely there. For other projects, some evangelism about SPDX might work.
I'm afraid a statement like "we know what we sync" is a bit shortsighted. It's simply not sufficient that we know something, we should be able to prove it. Even more, we should document it so nobody will ever have to ask us to prove it.
People using U-Boot in commercial projects have to undergo license clearing precedures, and for them such documentation is very important. What's in our heads is not very useful to them in such a situation.
My opinion is that we should add proper SPDX tags to all files that we import and that do not yet contain any such information.
Quoted 1 line
We leave the dts/dtsi files un-touched from upstream, yes. Thanks!
What about other files imported from Linux or other projects? Say source code?
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de What the gods would destroy they first submit to an IEEE standards committee.
Quoted 20 lines · Wolfgang Denk
Dear Tom,
Quoted 11 lines · In message <20170821192329.GF17193@bill-the-cat> you wrote:
Quoted 6 lines
Do I interpret this correctly that you think we should NOT insert SPDX tags into files imported from Linux (or other projects)? But how do we keep track of the origin of such files, then? Git meta data information is not useful for automatic tracking tools (or are there such clever tools available by now?)...
Generally speaking, Linux Kernel is what we're pulling stuff from, and that's the project that doesn't care for SPDX tags being introduced, and we know what we sync largely there. For other projects, some evangelism about SPDX might work.
I'm afraid a statement like "we know what we sync" is a bit shortsighted. It's simply not sufficient that we know something, we should be able to prove it. Even more, we should document it so nobody will ever have to ask us to prove it.
Quoted 7 lines
People using U-Boot in commercial projects have to undergo license clearing precedures, and for them such documentation is very important. What's in our heads is not very useful to them in such a situation.
My opinion is that we should add proper SPDX tags to all files that we import and that do not yet contain any such information.
We must not pull in files that are not properly licensed to start with. We must continue (and be better about) enforcing that when files come in from other projects, or re-sync with them we clearly point to a stable way to say when and where it came from (ie git hash, tag, release number). This type of traceability provides more useful information than just a license tag.
Quoted 4 lines
Quoted 1 line
We leave the dts/dtsi files un-touched from upstream, yes. Thanks!
What about other files imported from Linux or other projects? Say source code?
Actual code we have to take care with anyhow, but it's still up to the person that has to handle the syncing.
Signature · 8 lines
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/20170824/a4e1576b/attachment.sig>
Dear Tom,
Quoted 3 lines · In message <20170825012557.GK2827@bill-the-cat> you wrote:
Actual code we have to take care with anyhow, but it's still up to the person that has to handle the syncing.
Really? Should we not rather implement a common, consistent policy for the whole project?
Our patch submission already include a rule for new code [1]:
If you add new files, please always make sure that these contain your copyright note and a GPLv2+ SPDX-License-Identifier, for example like this:
(C) Copyright 2010 Joe Hacker <[email protected]>
SPDX-License-Identifier: GPL-2.0+
Should we not ask the same for code merged from other projects?
[1] Bullet #3 in http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de On mules we find two legs behind and two we find before. We stand behind before we find what those behind be for.
2017-08-25 16:46 GMT+09:00 Wolfgang Denk <[email protected]>:
Quoted 22 lines
Dear Tom,
Quoted 3 lines · In message <20170825012557.GK2827@bill-the-cat> you wrote:
Actual code we have to take care with anyhow, but it's still up to the person that has to handle the syncing.
Really? Should we not rather implement a common, consistent policy for the whole project?
Our patch submission already include a rule for new code [1]:
If you add new files, please always make sure that these contain your copyright note and a GPLv2+ SPDX-License-Identifier, for example like this:
(C) Copyright 2010 Joe Hacker <[email protected]>
SPDX-License-Identifier: GPL-2.0+
Should we not ask the same for code merged from other projects?
Quoted 7 lines
[1] Bullet #3 in http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign
Best regards,
Wolfgang Denk
--
As you may have already noticed, there seemed to be a progress in Linux.
https://lkml.org/lkml/2017/11/2/590
Signature · 2 lines
Best Regards Masahiro Yamada