Re: [PATCH for-4.18] docs: Delete kconfig docs to fix licensing violation

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/11/2023 11:59 pm, Stefano Stabellini wrote:
> On Thu, 9 Nov 2023, Jan Beulich wrote:
>> On 08.11.2023 15:37, Andrew Cooper wrote:
>>> These 3 Kconfig docs were imported from Linux erroneously.  They are
>>> GPL-2.0-only in Linux, but have no SPDX tag and were placed in such a way to
>>> be included by the blanket statement saying that all RST files are 
>>> CC-BY-4.0.
>>>
>>> We should not be carrying a shadow copy of these docs.  They aren't even 
>>> wired
>>> into our Sphinx docs, and anyone wanting to refer to Kconfig docs is going 
>>> to
>>> look at the Linux docs anyway.  These, and more docs can be found at:
>>>
>>>   https://www.kernel.org/doc/html/latest/kbuild/
>>>
>>> which also have corrections vs the snapshot we took.
>> Imo this reference ...
>>
>>> Fixes: f80fe2b34f08 ("xen: Update Kconfig to Linux v5.4")
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> ---
>>> CC: George Dunlap <George.Dunlap@xxxxxxxxxx>
>>> CC: Jan Beulich <JBeulich@xxxxxxxx>
>>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>> CC: Wei Liu <wl@xxxxxxx>
>>> CC: Julien Grall <julien@xxxxxxx>
>>> CC: Henry Wang <Henry.Wang@xxxxxxx>
>>> ---
>>>  docs/misc/kconfig-language.rst       | 701 ---------------------------
>>>  docs/misc/kconfig-macro-language.rst | 247 ----------
>>>  docs/misc/kconfig.rst                | 304 ------------
>>>  3 files changed, 1252 deletions(-)
>>>  delete mode 100644 docs/misc/kconfig-language.rst
>>>  delete mode 100644 docs/misc/kconfig-macro-language.rst
>>>  delete mode 100644 docs/misc/kconfig.rst
>> ... wants putting into, say, the last of these three files you delete, as
>> a replacement. I can't spot any other place where we would have such a
>> reference.
>>
>> One problem I see with deleting our shadow copy is that by referring to
>> Linux'es doc, the wrong impression may arise that whatever new features
>> they invent we also support. Thoughts? (If nothing else, I'd expect this
>> aspect to be mentioned / justified in the description.)
> I think the ideal solution would be to replace the shadow copies with a
> link to the Linux docs of a specific Linux tag (v5.4), instead of
> generic Linux master. I am not sure where to place the links though.

I don't personally think we need to keep any other reference around. 
They're not interesting, because they're not going to be found by anyone
except those who already know they're there, and won't need to refer to
them for the kind of content they provide.

Kconfig isn't a fast-moving target, and there's nothing new in Linux vs
what we've got here.  The only interesting difference between us and
Linux is the fact we don't use modules, and we didn't even strip that
out of the shadow copy.

We do have xen/tools/kconfig/README.source which states where it came from.

I could be persuaded to add the following hunk.  What we have isn't
precisely v5.4 anyway - we've got some reasonable differences in the
makefile side of things.

~Andrew

diff --git a/xen/tools/kconfig/README.source
b/xen/tools/kconfig/README.source
index 44631f68e8..ac394106b9 100644
--- a/xen/tools/kconfig/README.source
+++ b/xen/tools/kconfig/README.source
@@ -5,5 +5,7 @@ in this part of the Xen source tree.
 
 xen/tools/kconfig
 -----------------
-The kconfig directory was originally imported from the linux kernel
-git tree at kernel/git/torvalds/linux.git, path: scripts/kconfig
+The kconfig directory was originally imported from the Linux kernel
+git tree at kernel/git/torvalds/linux.git, path: scripts/kconfig of
+roughly v5.4.  Linux's documentation can be found at:
+https://www.kernel.org/doc/html/latest/kbuild/