Ursa is out of policy for license and copyright indications

[dcmiddle]

While the LICENSE file is accurate, each source file is required to start with a license banner. Only about a dozen files do.
Please see: https://wiki.hyperledger.org/display/TSC/Copyright+and+License+Policy

[kdenhartog]

I know in the JS/TS ecosystem that there are linters that can help with this issue. On a quick search I wasn't seeing any features of clippy that support it. Does anyone (pinging @dhuseby ) know of one that I didn't spot?

[6r1d]

Tell me, is this header format helpful, or should we use the full license in addition to it?

[brentzundel]

Tell me, is this header format helpful, or should we use the full license in addition to it?

I think this looks excellent

[dcmiddle]

That's amazing you picked up this issue from 2020! ❤️
Just watch out for files which came from other projects and we should not add a copyright and especially that we should not relicense. For example bullet proofs: 6r1d@d007c15#diff-6b063ae2297ac4174310606e61a333e328d60f431fbad430b5048099fbf876c8
From #168 it seems like that code will be removed anyway.

In general you may be able to tell where the code came from using the commit history or looking at the existing headers. Otherwise you may be able to rely on the maintainers remembering where things came from when they do their code review.
Either way, thanks for picking this up!

[6r1d]

For now, I've updated the PR, removing some of the excess files and changing the header.
I am not sure if it's worth it to add a header to the files that are initially empty, so let's decide that.
This is the current state of the update.

I've also reviewed the Ursa development history to understand where to add the headers.
So far, I am not sure I can help with tracking the exact license for each code section, especially given the fact there are 882 commits today and I'm not acquainted with the dev history enough to be confident about every change.

[dcmiddle]

Thanks for the extra effort @6r1d. I'll defer to more active maintainers on how they would like to review. One possibility would be to break the commit into one commit per module and then target the review at the principal author for that module so that they can acknowledge the license is accurate. I think in most cases that might just boil down to our intrepid @mikelodder7 :) ... in which case maybe splitting up the commit is not necessary.