Add tips to deal with license issues

In order to make it clear the preferred approach to deal with different
scenarios of licensing issues, add additional tips and examples.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>

content/guides/component_guide.md

@@ -790,12 +790,32 @@ license, or fails to process it correctly, there are three ways to fix this:
    Please also verify `debian/copyright` specifies the correct license, and if
    it doesn’t, submit a patch to Debian.
 
+   The `license` statement should be used when the license scan fails to determine a
+   license (reporting it as as `UNKNOWN`), while `override-license` should be used
+   when it reports an incorrect one.
+
+   {{% notice warning %}}
+   Since `override-license` will override the reported license it should be
+   used with caution and only if it is needed.
+   {{% /notice %}}
+
 2. Add the file to the list of ignored files,
    `debian/apertis/copyright.whitelist`. This file is formatted the same way as
    `gitignore`, please refer to the
    [gitignore](https://manpages.debian.org/buster/git-man/gitignore.5.en.html)
    manpage for more information.
 
+   This approach is useful in cases where a file has a license unsuitable for
+   Apertis but which won't affect the license of the generated package. A
+   common example of this situation are the tests that run at build time, which
+   will not be part of the binary package.
+
+   {{% notice note %}}
+   The whitelisting will allow license information to be
+   stored in the report, which could potentially be not suitable for Apertis,
+   while not raising an error on the CI pipeline.
+   {{% /notice %}}
+
 3. If the file is under a license not suitable for Apertis, it can be removed
    from the package by either repackaging the tarball or patching it out, in
    which case the scanner will not take it into account.