add machine-readable copyright and license information

See https://reuse.software/ for a description.

changed milestone to %DUNE 2.9.0

I give up opposition to this type of change. Ansgar, thank you for providing the patches.

One last question: Is ensured that the the magic lines for vi and Emacs remain working?

If you enable modeline support, vim by default checks the first and last five lines of each file. Of course this is configurable.

Vim only looks at the first line? That is pretty limiting...

For the emacs setting, I would like to remove them and instead have one ".dirlocals.el" per module. I haven't found an equivalent for vim without extensions, but there are extensions like editorconfig that work with several editors (but requires non-standard extensions for common editors like emacs or vim).

Eh, I think I misunderstood that: vim checks the first five and last five lines.

But for file-local variables emacs only checks the first line and second line if the first is an interpreter (i.e., starts with "#!"):

In shell scripts, the first line is used to identify the script interpreter,
so you cannot put any local variables there. To accommodate this, Emacs
looks for local variable specifications in the second line if the first
line specifies an interpreter. The same is true for man pages which start
with the magic string ‘'\"’ to specify a list of troff preprocessors
(not all do, however). 

So we can either:

1. use editorconfig for emacs, vim and others
2. use .dirlocals.el for emacs, per-file modeline for vim
3. move editor config top end of file
4. change order to: emacs mode, vim mode, copyright

My preference would be 2. Can we rush this for 2.9? Should we write to the mailing list to involve more developers in this discussion?

We shouldn't push this for 2.9 I think - too much change. Would 4. work or does the copyright have to be in the first line?

What about 4b): change order to: emacs mode, copyright, vim mode now; replace eMacs mode by 2) after 2.9 and a proper discussion?

I thought vim would only work (without modification on the user side) if it was in the top 5 lines or did I misunderstand that.

I vote for 4): Put the copyright under the modelines. And I would prefer to have this in the release, so whoever does the Debian packaging can benefit from it.

Changes to the editor modelines are a separate question IMO, and can wait until after the release.

I agree with 4). When trying to look up the SPDX-docs if there's strict rules regarding the location I could only find the vague statement that this should be 'near to top'.

Regarding the question if this should be in 2.9 I have no strong opinion.

I updated this merge request and the one for -localfunctions to implement (4).

Thank you! I think somebody wanted (C) instead of ©. Can this be changed? Or is the © mandatory?

It could be changed. But is a standard symbol and everything should handle it these days, especially as it only used in a comment (with the exception of writegauss.mac which also writes it to the generated file).

I think option 4) as Oli discribed seems ok. But I also agree with Andreas that this is a lot of change. For example, the copyright line includes a non-standard character © which should be replaced by (C) in my opinion.

added 3 commits

• 8f52d2d1 - writequad.mac: write SPDX information in generated file
• 99b960a9 - add SPDX information
• 585caabf - .gitlab-ci.yml: run "reuse lint"

Compare with previous version

mentioned in commit bca0f2bf

merged

Should this have been merged without finding out what Robert's issue with the copyright symbol was?

As I understood the comment, it was a general concern about using non-legacy encodings. I think if there's any problem with using UTF-8, that's a bug that should be fixed (especially for just using it in a comment); depending on the issue one could also revert to using legacy constructs like "(C)" at that time.

This approach would maybe be ok, if this fix was just for the master. But if this issue comes up and this change is already in the release, it will be difficult to just fix that. So the safe option would be to use (C), in my opinion. Especially since it really does not matter whether it's (C) or that special sign.

If you prefer I can change it to "(C)" for the release branch.

Yes, please change it to (C). The information content is exactly the same.

I'm also in favor of changing it to (C).

While, theoretically, it should be fine to use UFT-8 characters in comments, there is no benefit and in the interaction of the many tools we are using it could very well be that one still has a bug. Why should we make our live possibly more difficult, just because of a single character?

While, theoretically, it should be fine to use UFT-8 characters in comments

We already did that before this change in almost all file types. I'm not sure there are any new ones besides "dune.module" where it indeed triggered a bug (which as said on the mailing list should be fixed pending someone who can do so deploying the change).

Do you propose to remove all those?

The decision to only change the symbol in the release 2.9 branch to (C) and leave it in the master branch as UTF-8 symbol (I don't know how to type it on the keyboard) was a bit unfortunate. It makes all currently active merge request complicated and in the end leaves the release branch in an inconsistent state. We cannot merge into master, then manually change all the symbols, create a new merge request, and merge into the release - the cherry-picking does not work directly anymore - at least I don't know how to do it properly.

I understood the proposal above so that we simple change the comment in all branches to the same, a pure (C) characters text.

Any suggestions how to proceed? Or any info how to make the merge requests into master and into release and have them consistent?

Yes, I was also surprised to see that. And I simply don't understand what the point of all of this is. All the license files should have been changed to (C) a long time ago.

Let us change it on master, too. I was okay with sticking to the symbol. The mixup now is a bad state.

mentioned in merge request !206 (merged)