Some repositories of mine are dual licensed,
and have license files that follow the LICENSE-ONE, LICENSE-TWO naming pattern.
For example https://git.sr.ht/~swalladge/searchr

These repositories display a warning about
"We couldn't find a license file for your repository".

Is this expected?

I guess I could rename one of the files to LICENSE,
but this pattern is used elsewhere, for example https://github.com/BurntSushi/ripgrep
or https://github.com/sfackler/rust-postgres-macros

Would it be acceptable for the heuristics on sr.ht to expand the filename
matching to something like {,UN}LICENSE{,-*} for example?

-- 
Samuel Walladge
https://swalladge.net | https://useplaintext.email/

IMHO a button to discard the warning would be more helpful than extending
the pattern, since the license file is not used by SourceHut in any way.

> Some repositories of mine are dual licensed,
> and have license files that follow the LICENSE-ONE, LICENSE-TWO naming
> pattern.
> For example https://git.sr.ht/~swalladge/searchr

Often there is also a COPYRIGHT/COPYING file, which is the "main"
license and where the other licenses are mentioned and explained how
dual-licensing works.

> Would it be acceptable for the heuristics on sr.ht to expand the
> filename
> matching to something like {,UN}LICENSE{,-*} for example?

I personally would agree. I don't know sr.ht's license checker, but it
may break sr.ht if there multiple license files associated.

> Would it be acceptable for the heuristics on sr.ht to expand the
> filename
> matching to something like {,UN}LICENSE{,-*} for example?

As someone who has "unlicensed" Projects, I'd agree with the prefix.
Right now I have it symlinked to LICENSE, but it just clutters the
working directory.

The matter of license naming has come up before. Right now, we support
something like 10 formats. It has been decided that we will not continue
to expand our matching code to support every possible naming convention
humans can come up with, and instead now ask projects to change their
approach to conform to one of the existing patterns.

If your project has several licenses then I recommend merging them into
one file with some prose which explains which license applies to what.

On Tue, Aug 17, 2021 at 12:16:16PM +0200, Drew DeVault wrote:
> If your project has several licenses then I recommend merging them into
> one file with some prose which explains which license applies to what.

As someone whose job is to deal with licenses (in the editorial world,
but it's kinda the same),[1] I can't stress enough that you follow this 
approach. Placing together a couple of licenses in different files and 
expect people to know what is going on is... bad practice.

One thing is you imported a module from somewhere and you put the
license notice inside that module... that's obvious; you don't need to
explain it further. But if you're offering more than a license for the
project, I wholeheartedly suggest you to explicitly state the 
conditions of relicensing under one of the available licenses and of
course if there's any sort of exceptions or additional terms you're
offering to licensees. A single file with all licensing information 
might be a bit long and legalese for your tastes (I can understand 
this), but it's way clearer... and way more in line with things are
done elsewhere, outside the FOSS bubble.

[1]: I'm not a lawyer, but I'm Foreign Rights Manager at an independent 
publishing house.

-- 
Ariadna Vigo
Web: <https://ariadnavigo.xyz>
PGP: 0xA3B1324836A669BD

On Tue, Aug 17, 2021 at 12:16:16PM +0200, Drew DeVault wrote:
> The matter of license naming has come up before. Right now, we support
> something like 10 formats. It has been decided that we will not continue
> to expand our matching code to support every possible naming convention
> humans can come up with, and instead now ask projects to change their
> approach to conform to one of the existing patterns.
> 
> If your project has several licenses then I recommend merging them into
> one file with some prose which explains which license applies to what.

Nah, use the REUSE specification which puts all of the licenses into one
directory, LICENSES/, and then use proper SPDX lines at the top of each
file to refer to the proper license(s) that that file is released under.

That is the format that many of us are working toward, and has been
already adopted by many projects (including the Linux kernel.)

For more information about the REUSE spec, please see:
	https://reuse.software/

and to see how well your project matches the spec, use the `reuse` tool.
For example, in the usbutils project, here is the resulting output:

~/src/usbutils $ reuse lint
# SUMMARY

* Bad licenses:
* Deprecated licenses:
* Licenses without file extension:
* Missing licenses:
* Unused licenses:
* Used licenses: GPL-2.0-only, GPL-2.0-or-later, GPL-3.0-only
* Read errors: 0
* Files with copyright information: 48 / 48
* Files with license information: 48 / 48

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


thanks,

greg k-h

Okay, this seems reasonable for us to support.

On 21/08/17 03:03, Drew DeVault wrote:
> Okay, this seems reasonable for us to support.

Hopefully, this will only extend, instead of replacing, the current behavior of
having license in the file LICENSE in the root of the repository?