Looks like the license detection logic currently just looks for LICENSE
and COPYING.  While we're suggesting paths to search for, I'd like to
throw UNLICENSE into the hat.  People who want to put their code in
the public domain sometimes do so by placing a copyright waiver in a
file called "UNLICENSE".

All the best,
Alex

On Tue, 07 Apr 2020 12:28:18 +0900, Alex Sayers wrote:
> Looks like the license detection logic currently just looks for LICENSE
> and COPYING.  While we're suggesting paths to search for, I'd like to
> throw UNLICENSE into the hat.  People who want to put their code in
> the public domain sometimes do so by placing a copyright waiver in a
> file called "UNLICENSE".

While it's probably sensible to extend the list of considered files for
licence detection, I think we should be wary of adding support for a
'special' licence like the Unlicense, especially considering all the
problems [0] with that specific piece of text.

Something else we could look at is supporting dual licencing.
In the Rust universe it's common to use both Apache-2.0 and MIT. The
file names used for the two licences are somewhat less standardised
unfortunately, but generally a pattern like 'LICENSE-APACHE' and
'LICENSE-MIT' is used.

Perhaps we could do some fairly strict text matching on anything in the
root directory with 'LICENSE' in it?


[0]: https://web.archive.org/web/20170301020915/https://lists.opensource.org/pipermail/license-review/2012-January/001386.html

Cheers,
-- 
Richard Bradfield

Putting your code into the public domain is still expressing a license.
It should be LICENSE.

---
Mike

On 2020-04-07 13:28, Alex Sayers wrote:
> Looks like the license detection logic currently just looks for LICENSE
> and COPYING.  While we're suggesting paths to search for, I'd like to
> throw UNLICENSE into the hat.  People who want to put their code in
> the public domain sometimes do so by placing a copyright waiver in a
> file called "UNLICENSE".
> 
> All the best,
> Alex

On Tue, 7 Apr 2020, at 4:48 PM, Richard Bradfield wrote:
> I think we should be wary of adding support for a
> 'special' licence like the Unlicense, especially considering all the
> problems [0] with that specific piece of text.

The purpose of the warning is (I assume) to make sure the user hasn't
forgotten to add a license. If there's a file called UNLICENSE you
at least know they haven't forgotten. (You may be right about the
unlicense being ill-conceived - I just think it's beside the point.)

Alex

On Tue, 07 Apr 2020 17:27:20 +0900, Alex Sayers wrote:
> The purpose of the warning is (I assume) to make sure the user hasn't
> forgotten to add a license. If there's a file called UNLICENSE you
> at least know they haven't forgotten. (You may be right about the
> unlicense being ill-conceived - I just think it's beside the point.)

I see your point, perhaps, just for hiding the warning, it could be as
simple as looking for substring matches for 'COPY' and 'LICENSE'?

-- 
Richard Bradfield

> I see your point, perhaps, just for hiding the warning, it could be as
> simple as looking for substring matches for 'COPY' and 'LICENSE'?

That seems like a good approach to me, and would make the license detection to 
be more flexible.

As an alternative, could the notification box just have a hide/ignore button?

> On Apr 7, 2020, at 07:01, Adam Jimerson <vendion@gmail.com> wrote:
> 
> 
>> 
>> I see your point, perhaps, just for hiding the warning, it could be as
>> simple as looking for substring matches for 'COPY' and 'LICENSE'?
> 
> That seems like a good approach to me, and would make the license detection to 
> be more flexible.