Improve license documentation

[JayFoxRox]

@DobaMuffin recently added https://github.com/XboxDev/nxdk/wiki/NXDK-License-Information to the wiki.
This isn't the first attempt at this, so we can already predict some issues.

So while it is a good idea, that article has a couple of issues:

• It should be "nxdk" instead of "NXDK".
• Article is not linked from any other article or the sidebar, so it's not very visible.
• People likely won't know which files they are using in a larger project.
• The article will be outdated quickly as code moves around.
• It's dangerous to give "legal advice" if the information is not always accurate.

To avoid these problems, I believe the license documentation could be made more robust in a couple of ways:

• Slimming down nxdk: Less code = fewer licenses XboxDev has to document. I've already talked about slimming down nxdk in sdl2: Add SDL2_gfx submodule to nxdk/lib/sdl/SDL2_gfx #432 (comment).
• Machine-readable license identifiers in our tree: Adding something like https://en.wikipedia.org/wiki/Software_Package_Data_Exchange / https://spdx.dev/ids/ or similar standards; ideally something which can also handle license information for submodules without explicitly adding it in the submodule itself.
• Automated license identifier search: Using something like https://github.com/pivotal/LicenseFinder (would require https://github.com/conan-io/conan) / https://github.com/fossas/fossa-cli ($$$) to generate the documentation. I'd assume that there's an existing FOSS solution for this problem, like https://github.com/nexB/scancode-toolkit; also check in SPDX ecosystem: https://github.com/spdx.
• Provide a sample which does it right: A CI-compatible sample which correctly respects all licenses and generates this information would help.

[DobaMuffin]

The NXDK was a slipup as I know it's spelled nxdk but forgot to double check spelling of it (dumb mistake on my part). As for linking, I've never really used GitHub wiki so I don't know how to link it. My whole idea behind the wiki page was to have this information available so we can see what would need to be redone to remove any GPL'd code. My hopes was to update it with major changes like when the usb stack is replaced. My only question is what is meant by "It's dangerous to give 'legal advice' if the information is not always accurate."

[JayFoxRox]

The NXDK was a slipup as I know it's spelled nxdk but forgot to double check spelling of it (dumb mistake on my part).

I assumed this was the case (or that you wanted to avoid auto-capitalization as "Nxdk"). No big deal eitherway, just pointed it out for completeness.

As for linking, I've never really used GitHub wiki so I don't know how to link it.

The sidebar is an article on its own, see https://github.com/XboxDev/nxdk/wiki/_Sidebar/_edit
It's used to provide a more structured navigation, but it also means the default navigation menu ("Pages") isn't shown by default, so it's hard to discover your article.

My whole idea behind the wiki page was to have this information available so we can see what would need to be redone to remove any GPL'd code. My hopes was to update it with major changes like when the usb stack is replaced.

Yes, I understand the idea. It's very much appreciated.

However, we had similar user-facing resources in the past (like the code-tree overview in README.md), and they keep getting outdated when code is moved around or newly created.
I still think your article gives us a good opportunity to discuss this again, so thanks for getting the ball rolling on this.

Also, if the main focus is on removing GPL code (and not just providing an overview of licenses) then I'd recommend to create an issue about each portion of affected code (similar to some of these).
That way, it will be easier to keep track of progress for alternative code to replace it, or existing efforts to relicense existing code.

what is meant by "It's dangerous to give 'legal advice' if the information is not always accurate."

If someone took your wiki article as reference, they could claim that "This wiki article said the code that I'm using is under license XYZ", even if that information is outdated or incorrect.

• Example 1: Your article says "font_terminal.h -> public domain". If we now decide to replace it with a different font that isn't under public domain (unlikely, but say.. CC-BY-NC), then someone could take this new copyrighted font and claim that we gave permission to use it under public domain, by pointing at outdated / incorrect wiki information.
• Example 2: Someone looks at the wiki, but uses an older nxdk version (as required by some projects) and now copies a previous version of the file with entirely different contents which wasn't in public domain, thinking it is in public domain.

So there are cases where a user is either mistakenly taking these notes as fact, or they might purposely try to abuse incorrect / outdated information to claim damages (License trolling along the lines of: "We are company XYZ and you said we can use this file under MIT license. We have now learned that file is actually GPL we are unable to sell our product; this led to financial damages. Please pay us").

Therefore I recommend to tie the license (and author) information more closely to the repository and into the files themselves (or very close to them). If a file moves, it should still be 100% clear what license it is under.
If this is machine readable, we can also generate up-to-date license information which will be the single source of truth (and legally binding) - either for the entire nxdk source-tree, or for individual compiled files (by listing their dependencies / input files and their respective licenses).

[DobaMuffin]

[W]e had similar user-facing resources in the past (like the code-tree overview in README.md), and they keep getting outdated when code is moved around or newly created.

I still think your article gives us a good opportunity to discuss this again, so thanks for getting the ball rolling on this.

I know thrimbor had said that "I'm thinking about submitting a PR that just adds SPDX license identifiers everywhere" on the XboxDev discord so I guess that could be a potential solution for the time being. That way when the code is copied, we at least know what license it's under.

Also, if the main focus is on removing GPL code (and not just providing an overview of licenses) then I'd recommend to create an issue about each portion of affected code.

That way, it will be easier to keep track of progress for alternative code to replace it, or existing efforts to relicense existing code.

This makes total sense and I may see about doing that this afternoon.

what is meant by "It's dangerous to give 'legal advice' if the information is not always accurate."

If someone took your wiki article as reference, they could claim that "This wiki article said the code that I'm using is under license XYZ", even if that information is outdated or incorrect.

So there are cases where a user is either mistakenly taking these notes as fact, or they might purposely try to abuse incorrect / outdated information to claim damages (License trolling along the lines of: "We are company XYZ and you said we can use this file under MIT license. We have now learned that file is actually GPL we are unable to sell our product; this led to financial damages. Please pay us").

Would a disclaimer that says something like

"Disclaimer: none of the information on this page may be accurate as the nxdk changes, or if you use an older version of the nxdk. Therefore caution should be taken to see what licenses are in affect for your given version of the nxdk,"

work? That way we have a semi accurate overview for the current code, but it also lets people know that it may not be completely accurate and that they should do their own research too?

[JayFoxRox]

Would a disclaimer that says something like [...] work?

Not a lawyer, but that's probably better than nothing.

This makes total sense and I may see about doing that this afternoon.

Thanks for creating those issues.

"I'm thinking about submitting a PR that just adds SPDX license identifiers everywhere"

Yes please. For our own code, maybe even at specific functions (or we should break files apart).

---

I think another change regarding licenses should be to explain which flags trigger which libs, and also which license affects which .lib file (because it's a much shorter and more useful list for end-users). Obviously not necessary if we have proper SPDX.

[DobaMuffin]

"I'm thinking about submitting a PR that just adds SPDX license identifiers everywhere"

Yes please. For our own code, maybe even at specific functions (or we should break files apart).

@thrimbor would have to do that since he was the one who was thinking about doing it.

[JayFoxRox]

@thrimbor would have to do that since he was the one who was thinking about doing it.

That's not how it works.
If that was the case, the maintainers would have to do all tasks, because they are usually the ones with the most complete vision for the software, so they "thought about it first".

However, this is a trivial task that could be done by anyone. It's much better for the project if maintainers and experienced developers don't have to spend much time on it.

Because few (none?) of us have worked with SPDX before it will need proper documentation in the PR anyway.
So it's mostly:

• prepare: collect information about SPDX
• document: how can SPDX be implemented (how does linux or how does [...] do it?)
• implement: add metadata to codebase
• document: show how we can find license state with this new feature (does it work only for source or also binary?)
• document: future work to improve it

And most (all?) of these steps can be done by anybody - they don't need prior knowledge about the nxdk codebase.
You can also ask questions on Discord (or in this thread if absolutely necessary) which implementing it.
You could even break this into different steps, done by different people.

It will be reviewed anyway. It's enough if maintainers get involved to review it then (which also means a PR review shouldn't be dragged out by poor code quality or poor review feedback integration - because it's easier for maintainers to do it themselves then).

The experienced developers should focus on review and larger tasks which are actually hard to implement or difficult to justify (even if they make sense).

[DobaMuffin]

That makes sense. The only reason I had mentioned Thrimbor was because he was thinking of doing it before. But I can certainly give it a shot. I didn't mean it as Thrimbor had to do it, just that he thought of doing it.