Bug#950363: licensecheck reports dubious (may be misleading) information for image files

Dominique Dumont dod at debian.org
Thu Feb 6 09:17:26 GMT 2020


Hi Jonas

On Friday, 31 January 2020 20:28:50 CET Jonas Smedegaard wrote:
> I agree with your analysis but not your conclusion: I will argue that
> the image _does_ have copyright information - just not at its ideal
> place.

Hmmf, you're right. I assumed wrongly that the ICC info was kind of a pointer, 
not mapping data between colors.

> Concretely I do think that you have spotted an issue with an image
> containing non-free code, and I recommend that you report or fix it.

Thanks for the advice. This worked quite well:
https://github.com/libuv/libuv/issues/2670
https://github.com/libuv/libuv/pull/2672

I'm prettysure the stripped images will be merged for libuv1 release.

Thanks for pushing me to do this :-)

> Just yesterday I wrote down in the TODO file for licensecheck (but not
> yet added that edit to git) that it would be nice if a set of
> "qualities" was expressed, besides the concrete task of finding
> copyright and licnesing statements.  It was inspired by the currently
> the only "side note" tracked - "(with wrong address)" - and presented
> only in default output (it really should be added as a Comment when
> generating DEP-5 output), but fits well with this example too.

ok, I'm wondering if you plan to include this information in "machine" output. 
That may break the processing done by cme.

> Here is the full list I wrote down:
> 
>  * Quality flagging
>    + ambiguous: license ref pointing to multiple license fulltexts
>      (e.g. "MIT" or "GNU" or "GPL"
>    + unlicensed: copyright holder(s) but no licensing
>    + ungranted: license fullref requiring explicit grant,
>      but no corresponding license grant
>    + incomplete: fractions of license fullref, but no complete fullref
>    + alien: license label but no license name
>    + unowned: license but no copyright holder
>    + uncertain: license ref and more unknown text
>      in same sentence/paragraph/section
>    + buried: license or copyright not at top of file
>    + unstructured: license/copyright not at ideal place of data structure
>      (e.g. in commend field of EXIF data, or in content o of PDF/HTML)
>    + unaligned: license/copyright out of sync between layers of structure
>      (e.g. ICC data and EXIF data of PNG, or content and metadata of
> PDF/HTML) + imperfect: license ref not following format documented in
> license fulltext + conflict: incompatible licenses
>      (e.g. GPL-3+ and GPL-2-only, or OpenSSL and GPL)
> 
> The example you present here would ideally (continue to report HP as
> copyright holder - and more reliably so, but that's a separate issue -
> and) be flagged as "unlicensed", "buried" and "unaligned".
> 
> Does that make sense?  

yes, but I'm not sure how I could exploit this information with cme.

May be a mechanism similer to "and/or" in license: a license statement with 
"and/or" is allowed but triggers a warning inviting cme user to investigate 
manually the problematic file and override the information extracted by 
licensecheck.

> Would you agree to turn this bugreport into a
> wishlist reminder for making that side-note spiffy-ness happen?

Sure.

All the best



More information about the pkg-perl-maintainers mailing list