Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of license files outside of the LICENSE folder #1070

Open
cordlandwehr opened this issue Sep 10, 2024 · 5 comments
Open

Handling of license files outside of the LICENSE folder #1070

cordlandwehr opened this issue Sep 10, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@cordlandwehr
Copy link

In the Yocto packaging world there I have the following use case:

  • I have a Yocto meta-layer that is in an abstract view a git repository with build description files
  • Yocto layers can provide license text files, which in later build steps need to be included in builds of the respective software packages
  • for Yocto purposes, those files have no ".txt" extension and are located in some other folder than LICENSES/ for technical reasons that are not fast/simple to change
  • most of those license file do not provide license texts for files inside the repository but for files in external repositories

All this makes reuse lint fail for me unless I assign a license to the license text file. By the same arguments why all files in LICENSES/ are also not included in the linter, I propose to add an option to e.g. the REUSE.toml file to define additional folders of licenses for which reuse lint does not complain when their licenses are not additionally stated.

@carmenbianca
Copy link
Member

Hi @cordlandwehr. Can you provide a link to an example repository? I'm interested in seeing the status quo.

@carmenbianca carmenbianca added the enhancement New feature or request label Sep 10, 2024
@cordlandwehr
Copy link
Author

@carmenbianca
Copy link
Member

carmenbianca commented Sep 10, 2024

Hmmm… This is not a trivial one.

I propose a few changes (loosely, brainstorming without overly much consideration), which will need to be reflected in the spec:

  1. Drop the requirement that all licence files have a file extension. This is not a super useful requirement anyway.
  2. One of two options:
  3. Add licenses as a valid name for a license directory, and allow LICENSES/licenses directories to be nested deeper than root. This should probably also imply that you can't use a licence that is nested deeper/elsewhere than the file in question. I'm not a mega fan of this, because it complicates the core logic of REUSE, but it would enable more megarepo things. Furthermore, I'm not sure that this is what you want.
  4. Allow REUSE.toml to declare additional license directories. Like the LICENSES/ in root, the linter will check that the name of every file in those declared directories is a valid SPDX identifier. I am not certain whether licenses in this declared directory should be available for use by all files anywhere in the project, or only files in the same sub-tree.

However, if I don't misunderstand, the real problem is that REUSE makes you declare copyright and licensing for the files in conf/licenses? The problem is NOT that you can't use them? Because if this is a correct reading, then the above proposal doesn't really help either. Because now these licenses will be flagged as unused by the linter.

Maybe a better solution, even if not ideal, is to glob that directory as 'Copyright = None/Various Authors' and 'SPDX-ID = LicenseRef-LicenseText' in REUSE.toml, where LicenseRef-LicenseText is a small custom licence that explains how the licence texts themselves are or aren't licensed.

Happy to brainstorm further with you. You've hit an interesting corner case.

@cordlandwehr
Copy link
Author

Hi, thank you for the detailed comment. Those points are very close to what I was thinking.

As a short term solution I will do the approach with globbing these license files in REUSE.toml and adding a LicenceRef- file that explains them just being licenses.

A proper solution though would be, in my opinion, that we can mark a file/multiple files to be a license file that is used exclusively as file artefact, which eg. is copied in the install step. And in this situation also the exclusion rules apply as for "normal" license files.
Because, if otherwise trying to put all files into LICENSES/ we would get into the "unused license" problem and it also would clutter the license information of the repository.

@carmenbianca
Copy link
Member

Hmm, I think maybe the problem is more abstract than that. The problem isn't that these are licence files; the problem is that they are unlicensed files. For licences, it's a metadata-of-metadata problem. What licence is a licence text under? (And recursively, if the licence text has a licence, how is that licence licensed?) This metadata-of-metadata problem is why I merged fsfe/reuse-website#83 recently.

But licence files aside, this happens more often. In https://github.com/fsfe/reuse-website I just realise that we incorrectly label the logo image files of third parties as CC-BY-SA-4.0. But fixing that would be tricky; are they proprietary? Are the licensed? For the FSFE logo, we use this halfway licence, which I assume was copied from the FSFE website at some point.

The easiest and probably most correct solution is to slap LicenseRef-Proprietary on these files, but it sucks to acknowledge that the truth is that there is proprietary stuff in your codebase (especially when you're the FSFE).

An even easier solution would be to say 'I really don't want to care about these files, please make the problem go away', and implement a way for REUSE to just ignore files. However, every time we've discussed such a thing internally, we've all agreed that implementing this is a terrible idea.

I don't yet have a perfect magical solution for this. I will create an issue to maybe expand on this in the website's FAQ.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants