Hi all,
I am starting a new thread, summarising a wild idea we've had when discussing how to combine the different ideas and expectations that have been raised in the threads regarding folder.license files and the deprecation of the DEP5 file.
Our suggestion would be to implement a new file: REUSE.yaml.
# Basic concept
The purpose would be quite similar to what we already do with DEP5 files [^1]: communicate copyright/licensing information for a whole (sub)directory, or also just a certain pattern, e.g. all .png files in a directory.
The first downside of DEP5 is that the tags are different from the normal SPDX/REUSE tags, and that it requires some other meta information out of REUSE's scope. The second downside is that the DEP5 file has to be stored in the .reuse/ folder, quite unintuitive and far away from the actual files.
As the name suggests, REUSE.yaml would follow the YAML syntax which is easy to read and write for humans, but it also pretty easy to parse in tools.
Another difference would be that there could be multiple REUSE.yaml files. Each one could only define the directory it is stored in, or also subdirectories or certain file patterns. So it can also serve as an alternative to the suggested folder.license files.
This would make things easier for devs and reusers alike: given that a repo contains a directory with hundreds of binary files (e.g. images), the maintainers could create a REUSE.yaml file in it. This way, copyright and licensing information is close by, but the maintainers would not have to create $file.license files for every single image, or store the bulk-information in a far-away file.
# Syntax
Now, if we went that route, we would need a rather fool-proof and easy way how to mark the REUSE information for a directory, subdirectory, or pattern. Here are four variants how to do that in YAML, but only one should be mandated by REUSE in the end:
1. Short Array: ``` - src/*: SPDX-FileCopyrightText: [ "2020 me", "© 2017 you" ] SPDX-License-Identifier: MIT ```
2. Short List: ``` - src/*: SPDX-FileCopyrightText: - 2020 Me - © 2017 You SPDX-License-Identifier: MIT ```
3. Short String: ``` - src/*: | SPDX-FileCopyrightText: 2020 Me SPDX-FileCopyrightText: © 2017 You SPDX-License-Identifier: MIT ```
4. Long: ``` - src/*: license: SPDX-License-Identifier: MIT copyright: | SPDX-FileCopyrightText: 2020 Me SPDX-FileCopyrightText: © 2017 You ```
Please help us here: what could possibly go wrong with any of these variants? Is there tooling for which you know that it would misbehave? What would make most sense to you as a user?
Also, in general, I would be pleased to learn what you think about a REUSE.yaml file that would be a preferred way how to bulk-license files.
Best, Max
[^1]: See the one of reuse-tool here as an example: https://github.com/fsfe/reuse-tool/blob/master/.reuse/dep5
Hello Max et al.,
I like the idea, but just a thought. There is the new yaml format in SPDX 2.2, and we are thinking around using this format to mark certain folders as open source component, so identifying components in a repository is eased for open source compliance management. Might be worth to look into the standard whether this is also suitable for your proposed use case before deciding on a format. What do you think?
Mit freundlichen Grüßen / Best regards
Dr. Lars Geyer-Blaumeiser
Project Delivery - Open Source Services (IOC/PDL4) Bosch.IO GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch.io Mobil +49 172 4815079 | lars.geyer-blaumeiser@bosch.io
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling
________________________________ Von: REUSE reuse-bounces@lists.fsfe.org im Auftrag von Max Mehl max.mehl@fsfe.org Gesendet: Montag, 20. Juli 2020 17:51:24 An: FSFE REUSE Betreff: [REUSE] REUSE.yaml
Hi all,
I am starting a new thread, summarising a wild idea we've had when discussing how to combine the different ideas and expectations that have been raised in the threads regarding folder.license files and the deprecation of the DEP5 file.
Our suggestion would be to implement a new file: REUSE.yaml.
# Basic concept
The purpose would be quite similar to what we already do with DEP5 files [^1]: communicate copyright/licensing information for a whole (sub)directory, or also just a certain pattern, e.g. all .png files in a directory.
The first downside of DEP5 is that the tags are different from the normal SPDX/REUSE tags, and that it requires some other meta information out of REUSE's scope. The second downside is that the DEP5 file has to be stored in the .reuse/ folder, quite unintuitive and far away from the actual files.
As the name suggests, REUSE.yaml would follow the YAML syntax which is easy to read and write for humans, but it also pretty easy to parse in tools.
Another difference would be that there could be multiple REUSE.yaml files. Each one could only define the directory it is stored in, or also subdirectories or certain file patterns. So it can also serve as an alternative to the suggested folder.license files.
This would make things easier for devs and reusers alike: given that a repo contains a directory with hundreds of binary files (e.g. images), the maintainers could create a REUSE.yaml file in it. This way, copyright and licensing information is close by, but the maintainers would not have to create $file.license files for every single image, or store the bulk-information in a far-away file.
# Syntax
Now, if we went that route, we would need a rather fool-proof and easy way how to mark the REUSE information for a directory, subdirectory, or pattern. Here are four variants how to do that in YAML, but only one should be mandated by REUSE in the end:
1. Short Array: ``` - src/*: SPDX-FileCopyrightText: [ "2020 me", "© 2017 you" ] SPDX-License-Identifier: MIT ```
2. Short List: ``` - src/*: SPDX-FileCopyrightText: - 2020 Me - © 2017 You SPDX-License-Identifier: MIT ```
3. Short String: ``` - src/*: | SPDX-FileCopyrightText: 2020 Me SPDX-FileCopyrightText: © 2017 You SPDX-License-Identifier: MIT ```
4. Long: ``` - src/*: license: SPDX-License-Identifier: MIT copyright: | SPDX-FileCopyrightText: 2020 Me SPDX-FileCopyrightText: © 2017 You ```
Please help us here: what could possibly go wrong with any of these variants? Is there tooling for which you know that it would misbehave? What would make most sense to you as a user?
Also, in general, I would be pleased to learn what you think about a REUSE.yaml file that would be a preferred way how to bulk-license files.
Best, Max
[^1]: See the one of reuse-tool here as an example: https://github.com/fsfe/reuse-tool/blob/master/.reuse/dep5
-- Max Mehl - Programme Manager - Free Software Foundation Europe Contact and information: https://fsfe.org/about/mehl | @mxmehl Become a supporter of software freedom: https://fsfe.org/join _______________________________________________ REUSE mailing list REUSE@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/reuse
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
Die 21. 07. 20 et hora 08:44 Geyer-Blaumeiser Lars (IOC/PDL4) scripsit:
I like the idea, but just a thought. There is the new yaml format in SPDX 2.2, and we are thinking around using this format to mark certain folders as open source component,
That is a great idea.
But you’d really go make a full SPDX valid file for that? How? There are quite a few fields there that are obligatory.
One potential issue might be the hash value. For marking 3rd party code that’s a great boon, but for marking your own living code that might be a bit of a issue, if you need to change the hash value every time the code changes.
cheers, Matija
~ Matija Šuklje [2020-07-22 13:54 +0200]:
Die 21. 07. 20 et hora 08:44 Geyer-Blaumeiser Lars (IOC/PDL4) scripsit:
I like the idea, but just a thought. There is the new yaml format in SPDX 2.2, and we are thinking around using this format to mark certain folders as open source component,
That is a great idea.
Yes, thanks for sharing this idea! Being compatible with other compliance projects is one of our core goals.
But you’d really go make a full SPDX valid file for that? How? There are quite a few fields there that are obligatory.
One potential issue might be the hash value. For marking 3rd party code that’s a great boon, but for marking your own living code that might be a bit of a issue, if you need to change the hash value every time the code changes.
I see the same issues. Additionally, I am always having user-friendliness in mind which is another big goal of REUSE. The SPDX document seems to work with e.g. "licenseId", "licenseConcluded", "licenseDeclared". While these make sense in the SPDX radius, REUSE users are used to work with License-Identifier and FileCopyrightText. Just like with the snippets I am afraid of different "keys" for the same information.
Best, Max
Hello Max, Matija,
from what I understand there will be further changes in SPDX 3.0 that will remove some of the mandatory stuff. I absolutely agree, that using SPDX should not add stuff not needed for the use case. And if this means that the SPDX file is not correct because some mandatory stuff is not included, this is a good hint for the SPDX community to think about the need for a mandatory field for the information.
Saying that, my basic intention is, that a REUSE.yaml file should not define fields and structures, which have the same meaning but are defined differently from SPDX. This would improve readability and processability of the files.
Mit freundlichen Grüßen / Best regards
Dr. Lars Geyer-Blaumeiser
Project Delivery - Open Source Services (IOC/PDL4) Bosch.IO GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch.io Mobil +49 172 4815079 | lars.geyer-blaumeiser@bosch.io
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling
________________________________ Von: REUSE reuse-bounces@lists.fsfe.org im Auftrag von Max Mehl max.mehl@fsfe.org Gesendet: Donnerstag, 23. Juli 2020 15:04:02 An: reuse@lists.fsfe.org Betreff: Re: [REUSE] REUSE.yaml
~ Matija Šuklje [2020-07-22 13:54 +0200]:
Die 21. 07. 20 et hora 08:44 Geyer-Blaumeiser Lars (IOC/PDL4) scripsit:
I like the idea, but just a thought. There is the new yaml format in SPDX 2.2, and we are thinking around using this format to mark certain folders as open source component,
That is a great idea.
Yes, thanks for sharing this idea! Being compatible with other compliance projects is one of our core goals.
But you’d really go make a full SPDX valid file for that? How? There are quite a few fields there that are obligatory.
One potential issue might be the hash value. For marking 3rd party code that’s a great boon, but for marking your own living code that might be a bit of a issue, if you need to change the hash value every time the code changes.
I see the same issues. Additionally, I am always having user-friendliness in mind which is another big goal of REUSE. The SPDX document seems to work with e.g. "licenseId", "licenseConcluded", "licenseDeclared". While these make sense in the SPDX radius, REUSE users are used to work with License-Identifier and FileCopyrightText. Just like with the snippets I am afraid of different "keys" for the same information.
Best, Max
-- Max Mehl - Programme Manager - Free Software Foundation Europe Contact and information: https://fsfe.org/about/mehl | @mxmehl Become a supporter of software freedom: https://fsfe.org/join _______________________________________________ REUSE mailing list REUSE@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/reuse
This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
Greetings all,
+1 on not defining overlapping or duplicating terms with SPDX. REUSE and SPDX are already reasonably well aligned in terms of definitions, so I don't think it would be too much of a stretch to leverage some of the formats.
The one feature missing from SPDX is a pattern match for the files - this may be a useful feature to add to SPDX in general.
I completely agree with the concern on too many required fields. The SPDX community has removed many of the mandatory fields when a "filesAnalyzed=false" is used. Of course this does require the "filesAnalyzed" field since the default is set to true for compatibility. Somewhat inconvenient and perhaps something we should address in SPDX 3.0.
Another mandatory field which can be problematic is the SPDX document namespace. The value of this is required to be in a URI format and is required to be unique.
Let me know if there are other fields which are of concern.
One other thing to note, we are adding profiles in SPDX 3.0. Profiles is a defined subset of fields for a specific purpose. A group of automotive manufacturers are already using a profile for "SDPX Lite" in SPDX version 2.2 (see https://spdx.github.io/spdx-spec/appendix-VIII-SPDX-Lite/). SPDX Lite is a valid SPDX document intended to be built with minimal or no tools.
Let me know if there is interest in creating a REUSE profile in SPDX. The REUSE group could determine which fields are mandatory and which fields are optional. Myself and the SPDX tech team would be happy to collaborate on the effort.
Best regards, Gary
From: REUSE reuse-bounces@lists.fsfe.org On Behalf Of Geyer-Blaumeiser Lars (IOC/PDL4) Sent: Thursday, July 23, 2020 7:22 AM To: Max Mehl max.mehl@fsfe.org; reuse@lists.fsfe.org Subject: Re: [REUSE] REUSE.yaml
Hello Max, Matija,
from what I understand there will be further changes in SPDX 3.0 that will remove some of the mandatory stuff. I absolutely agree, that using SPDX should not add stuff not needed for the use case. And if this means that the SPDX file is not correct because some mandatory stuff is not included, this is a good hint for the SPDX community to think about the need for a mandatory field for the information.
Saying that, my basic intention is, that a REUSE.yaml file should not define fields and structures, which have the same meaning but are defined differently from SPDX. This would improve readability and processability of the files.
Mit freundlichen Grüßen / Best regards
Dr. Lars Geyer-Blaumeiser
Project Delivery - Open Source Services (IOC/PDL4) Bosch.IO GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch.io http://www.bosch.io Mobil +49 172 4815079 | lars.geyer-blaumeiser@bosch.io mailto:lars.geyer-blaumeiser@bosch.io
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling
_____
Von: REUSE <reuse-bounces@lists.fsfe.org mailto:reuse-bounces@lists.fsfe.org > im Auftrag von Max Mehl <max.mehl@fsfe.org mailto:max.mehl@fsfe.org > Gesendet: Donnerstag, 23. Juli 2020 15:04:02 An: reuse@lists.fsfe.org mailto:reuse@lists.fsfe.org Betreff: Re: [REUSE] REUSE.yaml
~ Matija Šuklje [2020-07-22 13:54 +0200]:
Die 21. 07. 20 et hora 08:44 Geyer-Blaumeiser Lars (IOC/PDL4) scripsit:
I like the idea, but just a thought. There is the new yaml format in SPDX 2.2, and we are thinking around using this format to mark certain folders as open source component,
That is a great idea.
Yes, thanks for sharing this idea! Being compatible with other compliance projects is one of our core goals.
But you'd really go make a full SPDX valid file for that? How? There are quite a few fields there that are obligatory.
One potential issue might be the hash value. For marking 3rd party code
that's
a great boon, but for marking your own living code that might be a bit of
a
issue, if you need to change the hash value every time the code changes.
I see the same issues. Additionally, I am always having user-friendliness in mind which is another big goal of REUSE. The SPDX document seems to work with e.g. "licenseId", "licenseConcluded", "licenseDeclared". While these make sense in the SPDX radius, REUSE users are used to work with License-Identifier and FileCopyrightText. Just like with the snippets I am afraid of different "keys" for the same information.
Best, Max
Die 25. 07. 20 et hora 02:00 Gary O'Neall scripsit:
Let me know if there is interest in creating a REUSE profile in SPDX. The REUSE group could determine which fields are mandatory and which fields are optional. Myself and the SPDX tech team would be happy to collaborate on the effort.
Thanks Gary, that sounds like a great way forward! :D
While I can’t call any shots, my vote would definitely be to work together with SPDX and duplicate as little as possible between the two solutions.
cheers, Matija
~ Matija Šuklje [2020-07-27 15:32 +0200]:
Die 25. 07. 20 et hora 02:00 Gary O'Neall scripsit:
Let me know if there is interest in creating a REUSE profile in SPDX. The REUSE group could determine which fields are mandatory and which fields are optional. Myself and the SPDX tech team would be happy to collaborate on the effort.
Thanks Gary, that sounds like a great way forward! :D
While I can’t call any shots, my vote would definitely be to work together with SPDX and duplicate as little as possible between the two solutions.
I fully agree, and would love to have a light REUSE profile in SPDX!
Actually, according to our main goal, the two only fields relevant would concern the copyright and license information, both in the File and the Snippet scope (see other thread on snippets). Everything else is optional.
However, I am not sure how such a trimmed down YAML file will look like when following the SPDX YAML spec. From what I understand, SPDX seeks to cover a whole package here, while REUSE.yaml should be able to exist multiple times in the repository, covering only a subset of the files on the same and child level(s).
Also, as said above, it should be easy to understand for humans as well. Fields that have different names but the same meaning depending on where they are used (inside source code or inside YAML) don't really add to our common mission IMHO. Can you think of a way to establish that?
Best, Max
Hi all,
Here's a pleasant update on the matter of providing a REUSE.yaml file (working title).
For those who joined later, a short summary: for some special cases, REUSE allows to bulk-declare copyright/licensing for whole directories. This currently happens via Debian's DEP-5 format. However, we are not so happy about it for a number of reasons:
* The syntax and the keys are different from the SPDX tags REUSE users are expecting. * The file's location is a bit opaque and far away from the actual files it describes. * DEP-5 creates some dependencies for the REUSE tooling that are not that easy to work with. * It's not a SPDX-supported format.
That is why we aim to soft-deprecate DEP-5 by a more flexible file format.
~ Max Mehl [2020-07-28 12:38 +0200]:
~ Matija Šuklje [2020-07-27 15:32 +0200]:
Die 25. 07. 20 et hora 02:00 Gary O'Neall scripsit:
Let me know if there is interest in creating a REUSE profile in SPDX. The REUSE group could determine which fields are mandatory and which fields are optional. Myself and the SPDX tech team would be happy to collaborate on the effort.
Thanks Gary, that sounds like a great way forward! :D
While I can’t call any shots, my vote would definitely be to work together with SPDX and duplicate as little as possible between the two solutions.
I fully agree, and would love to have a light REUSE profile in SPDX!
Thanks to Kate and Gary from SPDX, we had a great chat in a recent SPDX tech meeting about an issue I created with SPDX:
https://github.com/spdx/spdx-spec/issues/502
This issue describes the wish to have a file that describes at least copyright and licensing for files in its own or child directories.
During the meeting, we figured that there are no big blockers to integrate this into SPDX spec 3.0. Gary provided an excellent summary in his most recent comment on this issue, if you are interested.
However, they need to run this by the SPDX legal team as well. So nothing is written in stone yet, but I am already excited to see REUSE offering a more elegant, flexible, and SPDX-standardised way to make repositories REUSE compliant!
If you have any comments on this, please share your opinion on the issue directly. Apart from that, as always, feel free to ask everyone here or me directly via mail.
Best, Max
Thanks for pointing this out, this is an interesting development. Having had to use the dep5 file to avoid many .license files, it felt odd to have a Debian-specific solution in place. This seems to fit better.
I'm missing any discussion on how the globbing will be implemented, but I expect it to work similar to a .gitignore file.
Thanks for working on this!
Nico Rikken
Hi Nico,
~ Nico Rikken [2021-05-04 23:20 +0200]:
I'm missing any discussion on how the globbing will be implemented, but I expect it to work similar to a .gitignore file.
True, we didn't touch that yet, as well as the exact format of the YAML or JSON file. From the four options we've shared for discussion [^1], only option 4 has been disapproved in the recent SPDX call as it introduces new keys ("license" and "copyright").
Regarding path globbing, there is the pathspec library [^2] that supports the gitignore patterns, which also is natively available on Debian for example. I could well imagine that this could be a viable globbing standard. However, please feel free to raise your voice if you have concerns or better ideas.
Best, Max
[^1]: https://lists.fsfe.org/pipermail/reuse/2020q3/000085.html
[^2]: https://pypi.org/project/pathspec/
Thanks for moving this forward, Max. Looking forward to the end results hopefully soon :)
cheers, Matija
Hi all,
We are getting a bit closer to introducing REUSE.yaml as a way to provide bulk-information about copyright and licensing for files.
Here's an issue asking for your opinions on possible formats and syntaxes of the files, including target and globbing rules as well as internal conflict resolution:
https://github.com/fsfe/reuse-docs/issues/81
Conflict resolution outside of a REUSE.yaml file between the different options how one can define information with REUSE is discussed here:
https://github.com/fsfe/reuse-docs/issues/70
Your feedback is highly appreciated, and very important so we can make a well-founded decision. Thank you.
Best, Max
~ Max Mehl [2021-05-04 12:06 +0200]:
Hi all,
Here's a pleasant update on the matter of providing a REUSE.yaml file (working title).
For those who joined later, a short summary: for some special cases, REUSE allows to bulk-declare copyright/licensing for whole directories. This currently happens via Debian's DEP-5 format. However, we are not so happy about it for a number of reasons:
- The syntax and the keys are different from the SPDX tags REUSE users are expecting.
- The file's location is a bit opaque and far away from the actual files it describes.
- DEP-5 creates some dependencies for the REUSE tooling that are not that easy to work with.
- It's not a SPDX-supported format.
That is why we aim to soft-deprecate DEP-5 by a more flexible file format.
~ Max Mehl [2020-07-28 12:38 +0200]:
~ Matija Šuklje [2020-07-27 15:32 +0200]:
Die 25. 07. 20 et hora 02:00 Gary O'Neall scripsit:
Let me know if there is interest in creating a REUSE profile in SPDX. The REUSE group could determine which fields are mandatory and which fields are optional. Myself and the SPDX tech team would be happy to collaborate on the effort.
Thanks Gary, that sounds like a great way forward! :D
While I can’t call any shots, my vote would definitely be to work together with SPDX and duplicate as little as possible between the two solutions.
I fully agree, and would love to have a light REUSE profile in SPDX!
Thanks to Kate and Gary from SPDX, we had a great chat in a recent SPDX tech meeting about an issue I created with SPDX:
https://github.com/spdx/spdx-spec/issues/502
This issue describes the wish to have a file that describes at least copyright and licensing for files in its own or child directories.
During the meeting, we figured that there are no big blockers to integrate this into SPDX spec 3.0. Gary provided an excellent summary in his most recent comment on this issue, if you are interested.
However, they need to run this by the SPDX legal team as well. So nothing is written in stone yet, but I am already excited to see REUSE offering a more elegant, flexible, and SPDX-standardised way to make repositories REUSE compliant!
If you have any comments on this, please share your opinion on the issue directly. Apart from that, as always, feel free to ask everyone here or me directly via mail.
Best, Max
Hi, I really like this idea! It would solve some use cases for me, where I was waiting for a better solution than the individual file.license files (e.g. folders with many icons, folders with test data). And I think that it is important that the file is easy to see, meaning it is not a hidden file. Same for the fact that it is easy to read by a human.
The only point I am a little bit undecided about is, if one should really allow arbitrary regular expressions in the REUSE.yaml files, especially going outside of the scope of the folder the file is stored in. This will make it harder to detect issues with contradicting license statements. However, the reuse lint tooling could be the answer for this.
Best regards, Andreas
~ Andreas Cord-Landwehr [2020-07-21 21:07 +0200]:
Hi, I really like this idea! It would solve some use cases for me, where I was waiting for a better solution than the individual file.license files (e.g. folders with many icons, folders with test data). And I think that it is important that the file is easy to see, meaning it is not a hidden file. Same for the fact that it is easy to read by a human.
Thanks for the positive feedback, Andreas!
The only point I am a little bit undecided about is, if one should really allow arbitrary regular expressions in the REUSE.yaml files, especially going outside of the scope of the folder the file is stored in. This will make it harder to detect issues with contradicting license statements. However, the reuse lint tooling could be the answer for this.
Three thoughts on your concerns:
1. That feature is already available via the DEP5 file [^1], so basically nothing new. Does not directly solve your concern, but perhaps good to know for your current work already. 2. I forgot to mention that we would explicitly disallow defining files above the current level, so definitions like "../../otherdir" would not be possible. But yes, defining subdirectories (subdir/yetanother/src) would. This is because some users might want to have only one REUSE.yaml file in their root directory. 3. Good that you mention contradictions. We've thought about the question of precedence as well, especially if we'd adopt REUSE.yaml, and I will open a thread on this soon. I just wanted to give people here the chance to comment on REUSE.yaml before I take this into the precedence considerations.
Does this alleviate some of your concerns?
Additionally, on the tool side, we would of course make sure that the specified precedence is respected. Also, we thought about a "convert" subcommand that converts the DEP5 file to REUSE.yaml in order to make migration to the new default as smooth as possible.
Best, Max
[^1]: https://reuse.software/faq/#bulk-license