Convert license statements to SPDX and add license text files in LICENSES
folder as required by the REUSE specification.
Details
- Reviewers
krop - Maniphest Tasks
- T11550: Add SPDX License markers
- Commits
- R249:10971279a3e7: Ki18n: Convert license headers to SPDX statements
Diff Detail
- Repository
- R249 KI18n
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
LICENSES/LGPL-3.0-only.txt | ||
---|---|---|
16–18 | Actually, I have no idea. But according to the REUSE specification, the license files must no be changed and used exactly as provided by SPDX. |
LICENSES/LGPL-3.0-only.txt | ||
---|---|---|
16–18 | well, the SPDX text doesn't have these extra lines: |
LICENSES/LGPL-3.0-only.txt | ||
---|---|---|
16–18 | Just tested again with the reuse tool and it actually provides the license with these empty lines. I will report an issue on the reuse tool's bug tracker. For now, I would prefer to stick with these (strange) empty lines and update the license text only when REUSE is updating their tooling. |
Link to issue on reuse-tool tracker regarding empty lines in LGPL-3.0-only license text: https://github.com/fsfe/reuse-tool/issues/178
What about the COPYING.LIB file (containing LGLP 2.1 text) in the root directory? Could that not be removed given the new copy LICENSES/LGPL-2.1-only.txt?
Or are both copies required? If so, why? Similar question also for any other repo.
I agree, this file is obsolete. Yet, I did not touch it in any of the pull requests for the following reasons:
- Several of the COPYING.LIB files are stating the wrong license revision, since we have frameworks that are only licensed LGPL-2.0 (as a common denominator)
- This COPYING file is (in my perception) also understood as the outbound license of the whole library/application. Yet, this is a topic I only want to approach in a second step after clarifying the used licenses. The whole statement of the outbound license of a library is actually not defined yet AFAIS.
- I just created a ticket for REUSE (https://github.com/fsfe/reuse-docs/issues/56) and asking for clarification, mostly because the GPL HowTo suggests to adding this file (https://www.gnu.org/licenses/gpl-howto.html).
I will created another work item on the KF6 board for tracking the COPYING file handling, such that this does not block the progress for the SPDX identifier introduction.
So, how to move forward with this change? The two open discussion points are:
- How to handle COPYING files? --> IMO this is a general question that I want to address in a global change when we updated all the license headers. For this I created a task to track this question: https://phabricator.kde.org/T12730
- How to handle the unneeded empty lines in the license file? --> the license files must not be changed according to https://reuse.software/faq/, thus I created an upstream issue at SPDX (https://github.com/spdx/license-list-data/issues/60). but I am afraid that we have to wait for this issue to be fixed before we can update the license files on our side. Judging from experience, this will take quite some time and according to the REUSE guidelines we are doing everything correctly.
IMO, duplicating the license files is not necessary as long as there are no file refering to COPYING.LIB. This could be done now.
- How to handle the unneeded empty lines in the license file? --> the license files must not be changed according to https://reuse.software/faq/, thus I created an upstream issue at SPDX (https://github.com/spdx/license-list-data/issues/60). but I am afraid that we have to wait for this issue to be fixed before we can update the license files on our side. Judging from experience, this will take quite some time and according to the REUSE guidelines we are doing everything correctly.
Let's keep them until https://github.com/spdx/LicenseListPublisher/issues/61 is fixed.
Regarding the removal of the COPYING.LIB file, I would prefer to wait and remove all of them in all repositories in one run. It will be a trivial script to review.
My main argument is that I did not yet remove them in other pull requests, so for consistency I would like to keep them for now.