Bug#1025143: licensecheck: file type: lua is missing

[Jonas Smedegaard]

Quoting Jérémy Lal (2022-11-30 13:29:18)
> Le mer. 30 nov. 2022 à 12:47, Jonas Smedegaard <jonas at jones.dk> a écrit :
> 
> > Quoting Jérémy Lal (2022-11-30 12:27:34)
> > > Le mer. 30 nov. 2022 à 12:21, Jonas Smedegaard <jonas at jones.dk> a écrit
> > :
> > > > Quoting Jérémy Lal (2022-11-30 10:06:07)
> > > > > it seems that licensecheck doesn't know .lua is an extension for the
> > Lua
> > > > Programming Language.
> > > >
> > > > Sorry, I don't understand what is the issue reported.
> > > >
> > > > Do licensecheck fail is some specific situation, or do you expect it to
> > > > have certain use of knowing about lua as a language?
> > > >
> > > > Perhaps if you provide a concrete example case it helps me
> > understand...
> > > >
> > >
> > > The default check regex does not include files with a *.lua extension.
> >
> > Ahh.  Thanks.
> >
> > Yes, by default licensecheck scans only a somewhat arbitrary subset of
> > files based on their file extension.  I find that fundamentally flawed
> > (i.e. not fixable by changing the set of extensions) and I expected a
> > future release of licensecheck to move away from extension-based
> > selection (either by default or altogether).
> >
> > If you see some particular need for current extension-based selection
> > (just extended to include .lua) then please do share - perhaps I am
> > simply lacking in imagination.
> >
> 
> Yes, as I'm involved more and more with some packages having lua files,
> and being a (new) user of "cme update dpkg-copyright", I would find it
> awesome
> if licensecheck had those lua files in the default set of extensions.
> 
> The default set looks indeed somewhat arbitrary, indeed.
> Maybe licensecheck could expect other languages to setup their own config
> somewhere in
> /etc/licensecheck/conf.d/lua.conf
> but that would be a huge change, and I'm not sure it's worth it.
> 
> Exemple of a lua file containing a copyright:
> https://salsa.debian.org/nginx-team/libnginx-mod-http-lua/-/blob/master/t/lib/Redis.lua

Thanks for the concrete examples.  What I meant was not examples of
statements contained in .lua files, however, but cases of it being
sensible to continue to have a default extension-based skiplist.

Sorry - I see now that my point was vague previously.

Licensecheck does not distinguish between code languages: It scans
plaintext content for human-language license- and copyright-statements.

What is broken about the default extention-based skiplist is not that it
misses .lua files, but that it misses *ALL* files with a
not-assumed-relevant content.  Adding .lua extension to default list
will only fool users working with lua code, same as it is already
fooling users working with C and perl and python code now: When
licensecheck reports that it found no copyright or licensing, you get
fooled into thinking that there are no licensing when really the message
should have included a warning that not all files were examined at all.

For those using licensecheck directly, I recommend to override the
default to scan everything, and then explicitly exclude unwanted files
(either because licensecheck chokes on them containing non-text content,
or because they are huge and known to not contain relevant data - e.g.
extremely large JSON or dictionary files).

But as you mention that you use licensecheck directly only indirectly
through cme, I can just suggest that you discuss with the author of cme
what is sensible for that tool: I have already implemented other
user-targeted warnings for uncertainties requiring action, which cme
deliberately strip, so we disagree about what users should be bothered
to care about in a copyright- and licensing scanner and you might be in
agreement with the cme author about simply including .lua files and then
living in bliss.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/attachments/20221130/7952dc71/attachment.sig>