Extend metainfo.yaml files with License Information

[Andreas Cord-Landwehr]

Thanks! I will answer inline:

On Montag, 17. August 2020 17:47:40 CEST Harald Sitter wrote:
[...]
> > **First question:** Shall we only list ONE or ALL licenses, same for the
> > license information overview that should be on api.kde.org?
> 
> The primary use would be api.kde.org, no? A third party looks for a
> solution to hardware shenanigans with Qt and finds the solid docs and
> the solid docs say "you may use this thingy under LGPL-2.1". If so,
> then surely we ought to encode all artifacts and their licensing
> terms. What's more,. the artifact a given class belongs to becomes
> relevant and I guess that's a bit tricky to sort out.

api.kde.org will be the first user, but I already see more in the pipeline:
- for this plausibility tooling <https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/21> I would love to get a connection of the 
CMake target name and the stated outbound license
- for Yocto recipes we already have to state the licenses by hand and it 
should not be too hard to generate the Yocto information from a Yaml file
- in the long term I expect that this is what is useful for packages, who 
currently mostly look at the source files and have to guess

> > Now, I am wondering about the best approach to encode something like this
> > into the metainfo.yaml. I am currently considering a structure as
> > follows:
> > 
> > Attica's metainfo.yaml
> > [...]
> > 
> > outboundLicenses:
> >     libattica:
> >         - LGPL-2.1-only
> >         - LGPL-3.0-only
> > 
> > Baloo's metainfo.yaml
> > [...]
> > 
> > outboundLicenses:
> >     libbaloo:
> >         - LGPL-2.1-only
> >         - LGPL-3.0-only
> >     
> >     baloo-kioslave:
> >         - GPL-2.0-only
> 
> Why not actually use a SPDX expression? `LGPL-2.1-only OR LGPL-3.0-only`.
> 
> Some additional concerns that come to mind:
> - what 's the actual artifact name? for libraries we already have a
> target name so I guess we might just use that so for example that'd be
> KF5::Baloo. What about plugins or binaries though?
> - how would we make sure all artifacts are encoded? do we want to even?

Ouch, yes, the obvious choice, no idea why I did not see that by myself :) 
Yes, SPDX expressions should be the obvious way to go IMO. For the questions:
- for libraries, I agree that the target name should be easiest
- for plugins, we could use the library name as it is still a shared object
- for applications, we could use the executable name
- for anything that is "not changed but only installed" during the compile/
install steps, I would say for now that those are out of scope
In my understanding, we should strive for encoding all artifacts, but if we 
miss some we do not state something wrong. Moreover, what we state there 
should be covered by automated tests (see link above).

Cheers,
Andreas