Add SPDX-License-Identifier to Falcon aarch64

[cothan]

This PR add requested license header as in liboqs PR discussion

Let me know if you have any question.

[thomwiggers]

On the one hand, this seems like a "no harm done" type of change. But this is also the kind of change that might get wiped out by a future update of the Falcon implementation, because PQClean doesn't necessarily care about this. So I'm a bit hesitant on merging this if we're not going to be adding/tracking this for all schemes....

Might this issue not be easier solved by OQS putting the license info into the upstream source script and then automatically inserting the right comment at the top of each file?

[baentsch]

Might this issue not be easier solved by OQS putting the license info into the upstream source script and then automatically inserting the right comment at the top of each file?

What do you mean by "upstream source script"? copy_from_upstream? This script is not meant to change licensing information from the upstreams. It has a patching mechanism -- but such patches need to be done for a) for each file and b) anew for each new code revision imported. Also they may be wrong: Not much of an issue for code --CI will help-- but going undetected in case of comments...

PQClean doesn't necessarily care about this.

Do you mean it as I understand it? PQClean doesn't care about (tracking/having) proper licensing information of the algorithms it contains? If so(?) then indeed, liboqs needs to follow a different approach for handling this: there are folks --licensing-wary US corporations, typically-- caring about this; as those guys are taking over OQS they'll then probably also want this fixed in OQS where they can control it. In that case I´d indeed suggest closing this PR and apologize to @cothan for suggesting to do an upstream fix :-(

[thomwiggers]

PQClean tracks and enforces LICENSE files. It's perfectly possible to have LICENSE files that make clear where the source code is coming from and designate that different files are under different licenses.

[baentsch]

Thanks for the explanation. This doesn't permit fully automated in- (or ex-)clusion of algorithms as per open-quantum-safe/liboqs#1514, though.

But anyway, the addition of the many Linux Foundation lawyers to OQS in the near future won't make this a necessity any more: They can then sort this manually (and we finally have found a sink for the foundation membership fees :-)

As for this PR, I'd agree that it should be closed without merge: It clearly doesn't fit the license management and code integration procedures described above.

[thomwiggers]

If it would be helpful to other projects we can revisit this issue, but we'd have to add the license identifier strings to every implementation and add a CI test that enforces it (and their correctness).