Add additional tips related to license configuration

As a way to follow some common guidelines while working on license
configuration add additional tips and examples to illustrate how to
proceed on different common scenarios.

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

content/guides/component_guide.md

@@ -614,7 +614,19 @@ license, or fails to process it correctly, there are three ways to fix this:
 
    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.
+   when it detects an incorrect license declared inside a file.
+
+   It is important to note that `ci-license-scan` tries to resolve unknown licenses
+   with metadata from different sources, in some cases this leads to files appearing
+   with an incorrect license. However, since the license is not declared inside
+   the file, but filled from other sources, using the `license` keyword is enough.
+
+   Another common issue that falls into this type are files under `debian/patches`
+   which inherit the license of `debian` folder. This is usually an upstream
+   bug in `debian/copyright` which should be reported since the expectation is
+   that patches respect the license of the file they patch. However, since upstream
+   could take some time to fix the issue, an entry for `debian/patches` should
+   be added with a `license` keyword pointing to the correct information.
 
    {{% notice warning %}}
    Since `override-license` will override the reported license it should be
@@ -628,10 +640,16 @@ license, or fails to process it correctly, there are three ways to fix this:
    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
+   Apertis but which won't affect the license of the generated image. A
    common example of this situation are the tests that run at build time, which
    will not be part of the binary package.
 
+   Another example for this type of exceptions are files that are not meant to be
+   installed in images such as
+   - Documentation, which is excluded thanks to dpkg exclusions
+   - Sample programs or tools part of `-dev` packages which are used as build
+     dependencies
+
    {{% notice note %}}
    The whitelisting will allow license information to be
    stored in the report, which could potentially be not suitable for Apertis,