fsfe / reuse-tool

reuse is a tool for compliance with the REUSE recommendations.
https://reuse.software
392 stars 149 forks source link

linter does not support dep5 of git submodules #163

Open dmorn opened 4 years ago

dmorn commented 4 years ago

Steps to reproduce

Create a new reuse project under git. Add a git submodule which is compliant with the reuse specification, but covers some files with debian's dep5 mechanism. If you run the linter on the parent directory (not the submodule), it will complain that the submodule is not reuse complaint.

Example

Let's create an empty git repo first, add the submodule and check its complaincy:

danielmorandini@jecoz ~ % git init reuse-test && cd reuse-test                     
Initialized empty Git repository in /Users/danielmorandini/reuse-test/.git/
danielmorandini@jecoz reuse-test % git submodule add https://github.com/kim-company/pmux.git
Cloning into '/Users/danielmorandini/reuse-test/pmux'...
remote: Enumerating objects: 27, done.
remote: Counting objects: 100% (27/27), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 421 (delta 5), reused 20 (delta 3), pack-reused 394
Receiving objects: 100% (421/421), 2.29 MiB | 4.13 MiB/s, done.
Resolving deltas: 100% (194/194), done.
danielmorandini@jecoz reuse-test % cd pmux 
danielmorandini@jecoz pmux % reuse lint
# SUMMARY

* Bad licenses:
* Missing licenses:
* Unused licenses:
* Used licenses: MIT
* Read errors: 0
* Files with copyright information: 22 / 22
* Files with license information: 22 / 22

Congratulations! Your project is compliant with version 3.0 of the REUSE Specification :-)

Now make a step back and check from the parent git repo.

danielmorandini@jecoz pmux % cd ..
danielmorandini@jecoz reuse-test % reuse lint
# MISSING COPYRIGHT AND LICENSING INFORMATION

The following files have no copyright and licensing information:
* .gitmodules
* pmux/README.md
* pmux/examples/config.json
* pmux/go.mod
* pmux/go.sum

# MISSING LICENSES

'MIT' found in:
* pmux/.gitignore
* pmux/.goreleaser.yml
* pmux/cmd/root.go
* pmux/cmd/server.go
* pmux/cmd/wrap.go
* pmux/examples/list-sessions.go
* pmux/examples/mockcmd/main.go
* pmux/http/pmuxapi/handlers.go
* pmux/http/pmuxapi/router.go
* pmux/http/pwrapapi/router.go
* pmux/http/pwrapapi/server.go
* pmux/main.go
* pmux/makefile
* pmux/pwrap/pwrap.go
* pmux/pwrap/pwrap_test.go
* pmux/pwrap/ucb.go
* pmux/tmux/tmux.go
* pmux/tmux/tmux_test.go

# SUMMARY

* Bad licenses:
* Missing licenses: MIT
* Unused licenses:
* Used licenses:
* Read errors: 0
* Files with copyright information: 18 / 23
* Files with license information: 18 / 23

Unfortunately, your project is not compliant with version 3.0 of the REUSE Specification :-(

Hint

I'm not a python fan and I did not dig into the code, but it looks like reuse is not taking into consideration nested .reuse folders.

Context

OS: Darwin jecoz.local 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64 reuse version: reuse 0.5.2

carmenbianca commented 4 years ago

reuse 0.5.2

This version is outdated. Can you try with a newer version? Newer versions of reuse should—by default—completely ignore submodules unless you do reuse --include-submodules lint. In which case it might still not recognise nested .reuse folders, but I'm not sure.

dmorn commented 4 years ago

Hi @carmenbianca (I notice now I heard you speaking at the SFScon! 😊), yes you'r right: I updated the tool, now I'm running version 0.8.0, and it does not check submodules. --include-submodules fails as above though.

hoijui commented 2 years ago

I am running latest git version of reuse as of today (exactly v1.0.0), and it does check git submodules again, and in my case fails because of this.

hoijui commented 2 years ago

What would we want to happen, optimally?

  1. search for all sub-paths .reuse/dep5, instead of just in the project-/scan-root?
  2. If we are in a git repo, check if a .reuse/dep5 exists for each git sub-module?
  3. dep5 does not seem to support an import functionality, where one could link to sub-modules dep5s from the root one.
Tachi107 commented 2 years ago

dep5 does not seem to support an import functionality, where one could link to sub-modules dep5s form the root one.

I'm not sure I understand this point, could you explain it a bit further? Why would it be useful? (by the way, the current dep5 specification is available here)

hoijui commented 2 years ago

I am not sure it would be good to use (my feeling is rather, not so much, as it would be too manual/work intensive), but as it seems not to exist, I would say it makes little sense that we go deeper into it. What I mean is something similar like you have in programming languages, like import in python, or #include in C/C++.

buxtonpaul commented 1 year ago

Not sure on the status of this, but going back to the original posters problem. Given a sub-directory that is reuse compliant it would be useful if when running the reuse tools on a parent project for the license information be properly propagated up. This would seem to me to be a common use case where for example a large project has dependencies on several other projects. In an ideal world those dependencies would also be using reuse and developers of the parent project should only need to declare license information for their own files.