Support directories in `referenced_filenames` for rules

[AyanSinhaMahapatra]

Sometimes references to license files are in terms of specific directories instead of one/multiple filename/paths.

See for example: https://github.com/avnet-iotconnect/iotc-azurertos-sdk/blob/0e6fe7c9ede4f97a81203eafc930577906736455/README.md?plain=1#L157

A simple way to support this would be to have simple glob patterns like:

referenced_filenames:
    - azrtos-licenses/*

And check if there are glob patterns in the referenced_filenames and only then process these, otherwise fallback to the simple filename based processing which should be much faster.

[Spurgeon008]

can i do this?

[Aditya-PS-05]

Hey @AyanSinhaMahapatra , I am looking to contribute to AboutCode. I would love to work on this.

[suhas007-sketch]

can I work on it

[hesa]

👍

..... Reuse, as I am sure you know, puts license files under LICENSES

A Project MUST include a License File for every license under which Covered Files are licensed.

Each License File MUST be placed in the LICENSES/ directory in the root of the Project. The name of the License File MUST be the SPDX License Identifier of the license followed by an appropriate file extension (example: LICENSES/GPL-3.0-or-later.txt). The License File MUST be in plain text format.

See: https://reuse.software/spec-3.3/

[suhas007-sketch]

I implemented support for resolving wildcard references like LICENSES/* in the resolver. However, while testing I noticed that the existing rule unknown-license-reference_see-license_1.RULE always emits referenced_filenames: ["LICENSE"], so the resolver never receives LICENSES/. Should REUSE support come from a new detection rule (or parser change) that emits LICENSES/, or did you intend the resolver alone to handle this?

[SidheshwarSarangal]

I checked the current develop implementation. Both find_referenced_resource() and find_referenced_resource_from_package() resolve referenced_filenames using exact codebase.get_resource() path lookups, so a pattern such as azrtos-licenses/* is not currently expanded.
My proposed approach is to preserve the existing fast exact-path lookup for ordinary filenames and only perform pattern matching when the reference contains glob characters. I would add tests for literal-path compatibility, directory patterns, multiple matches, and matching relative to both the current resource and codebase root.
Since the current resolver returns one resource, should a glob matching multiple files resolve and combine the license detections from all matching files?