Dear Maintainer,

When parsing an image file as a binary blob, licenscheck report that the copyright of the image is owned by HP:

$ licensecheck --encoding utf8 --copyright --machine --deb-fmt --recursive docs/src/static/diagrams.key//Data/st0-311.jpg
docs/src/static/diagrams.key//Data/st0-311.jpg  UNKNOWN 1998 Hewlett-Packard CompanydescsRGB IEC61966-2.1sRGB IEC61966-2.1XYZ óQÌXYZ XYZ o¢8õXYZ b· / ±¹ÁÉÑÙáéòú / ®²·¼ÁÆËÐÕÛàåëðöû

I think licensecheck is misled by the copyright ownership of the color profile
of this image:

$ exiftool docs/src/static/diagrams.key//Data/st0-311.jpg | grep Profile
Profile CMM Type                : Linotronic
Profile Version                 : 2.1.0
Profile Class                   : Display Device Profile
Profile Connection Space        : XYZ
Profile Date Time               : 1998:02:09 06:49:00
Profile File Signature          : acsp
Profile Creator                 : Hewlett-Packard
Profile ID                      : 0
Profile Copyright               : Copyright (c) 1998 Hewlett-Packard Company
Profile Description             : sRGB IEC61966-2.1

The image itself has not Copyright information:

$ exiftool docs/src/static/diagrams.key//Data/st0-311.jpg | grep -i copyright
Profile Copyright               : Copyright (c) 1998 Hewlett-Packard Company

All the best

Hi Dominique,

Quoting Dominique Dumont (2020-01-31 19:34:08)
the image _does_ have copyright information - just not at its ideal
place.

Licensecheck checks for copyright and license statements in files.  It
does not promise to look only at ideal places - but also does not
promise to look in all possible ways, only it as much ways that it can.

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.
When I discover images containing embedded non-free ICC data (which in
my understanding includes data explicitly copyright protected without
explicit licensing, due to the [Berne Convention] - and in my
understanding the very reason we in Debian track not only licensing but
also copyrigh statements) then I report it, and have so far been met
with understanding and appreciation by upstream projects who generally
(if not in all cases) has chosen to replace or strip ICC profiles from
their graphics files - and several of them was in particular asking how
I discovered it and were happy to learn about the powerful exiftool.

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.

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?  Would you agree to turn this bugreport into a
wishlist reminder for making that side-note spiffy-ness happen?


Kind regards,

 - Jonas

[Berne Convention]: https://en.wikipedia.org/wiki/Copyright#International_copyright_treaties

Hi Jonas

Hmmf, you're right. I assumed wrongly that the ICC info was kind of a pointer,
not mapping data between colors.
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 :-)

ok, I'm wondering if you plan to include this information in "machine" output.
That may break the processing done by 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.

Sure.

All the best

control: severity -1 wishlist
control: retitle -1 licensecheck: detect additional (i.e. non-SPDX) qualities

Quoting Dominique Dumont (2020-02-06 10:17:26)

I am very happy that it worked out well.  Their response is similar to
what I generally experience: Positive surprise and (maybe after a bit of
confusion) full agreement that it should be fixed.

(I must admit I am commonly a bit scared of filing bugreports - which
makes me wonder not if but when and how I myself is scary to approach)
options "--machine" or "--deb-machine" - I assume you are talking about
the latter.

Yes, I plan to include most possible in machine-readable output, but
will (for the "--deb-machine" format) keep within the boundaries of
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ - so
what you should worry about should only be if you are making too strict
assumptions on that format.  In particular, beware that it is plain
wrong to only expect explicitly defined fields (as per § 4: "Extra
fields can be added to any paragraph").

On a related note, beware that the FIXMEs added to output is deliberate:
Licensecheck does not claim to know better than human reasoning what is
accurate, and therefore flag all its findings as needing human
confirmation.  If you wrap Licensecheck and hide/strip those FIXMEs then
_you_ take responsibility for the output being perceived as requiring
less/no human validation.  Now that I write this, it occurs to me that
it probably makes sense to expand those FIXMEs to add some explanatory
text.

I imagine that qualities are of different importance for different uses
of licensecheck.  An author might be interested in correcting errors,
and a larger organization of authors (e.g. KDE) might want to ensure
coherence both in writing style and in licensing "regime" (in lack of a
better word: which political field they want to stay within - e.g.
"GNU-compatible copyleft" or "Apache semi-copyleft without
GPL-contamination"), whereas a distributor like Debian is less
interested about style (we cannot change it anyway) except for details
directly harmful for our work (e.g. wrong contact information as has
happened with FSF changing postal address).
which is currently implied by the "FIXME" comments.

To clarify: When licensecheck says "GPL-2+ and/or MIT"" then it means
"this file is seemingly licensed under GPL-2+ and/or MIT (and/or
additional terms not auto-detected)" (not "this file is _only_ licensed
under GPL-2+ and/or MIT").

If cme warns about "and/or" needing human investigation but not FIXMEs,
then it implicitly says FIXMEs need less human investigation which is
plain wrong!

Done.  Thanks a lot for your input!


 - Jonas

Nope. cme use "--machine" option whose output is easier to parse.

I don't really need the "FIXME" tag as cme either provides a similar message
(although in a more verbose way) or provides the correct value (from control
information or using Software::LicenseMoreUtils)

Which makes it harder to parse.

Yes, I've been bitten by this. This is now taken care of [1].

Agreed.

Understood. I'm mostly focused on Debian use case.

The way I see it, the FIXME comment instructs user to find the license text.
 I assume that the license is correctly detected unless specified otherwise
(with "and/or"). I know that licensecheck is a heuristic tools and misdetections
are possible. But I cannot afford to systematically verify each file.

Adding  " and/or UNKNOWNS" to _all_ detections would make me question
the added value of licensecheck.

No problem.

cme uses "-m" option, so "FIXMEs" are currently not seen by cme. However,
cme either fills the blank with the correct license text or warns the user about
missing license text.

All the best

[1] https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/blob/master/lib/Config/Model/models/Dpkg/Copyright/Content.pl#L6

[ bug#950363 cloned as bug#1001635 ]

Quoting Dominique Dumont (2020-02-07 14:34:18)

Uncertainties in licensecheck is a distinct subclass of "FIXMEs" which I
think can be improved on.

Licensecheck generally attempts to classify and reference licensing
statements by shortnames, which are locally distinct and preferably also
globally well-known.

When Licensecheck gives up, it uses the pseudo-identifier UNKNOWN as
default.  Better if this was distinguished further:

  * COMPLEX: unknown how to classify strong licensing traits
  * MAYBE: unkown how to classify weak licensing traits
  * UNKNOWN: uncertain if licensing exist
  * NONE: certain that no licensing exist

"UNKNOWN" should be treated as "please examine this file closer".

I suspect that if distinguishing *why* a file needs further examination,
then wrapper tools like scan-copyright might more reliably suppress only
those subcategories that they can truly improve on, while leaving open
FIXMEs they cannot reliably deal with.


 - Jonas

Good morning,

 Attached please find your PDF account statement and invoice as of 05/11/2023. Please notice you have a past due balance  for invoice IN0099203.

 Please provide payment as soon as possible.




 Best Regards,
 Shawneen Chisholm
 Accounts Receivable Coordinator

 UNITED RENTALS, INC.
Branch L02 BONNYVILLE
4920 56TH AVE
BONNYVILLE AB T9N 2N8 CA
780-826-7610


 CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s). This may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message, please alert the sender immediately by reply email and then delete this message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited