Extend metainfo.yaml files with License Information

[Harald Sitter]

On Mon, Aug 17, 2020 at 8:24 PM Andreas Cord-Landwehr
<cordlandwehr at kde.org> wrote:
>
> 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).

It all sounds reasonable to me.

I'm pipedreaming a bit ... but given the ultimate goal of stringing
artifacts to licenses maybe a thing to consider is to actually encode
this stuff as cmake properties on the actual cmake targets. Perhaps
not as a first step, but as a longer term goal. The cmake targets
already know the output name of their artifact is (resolving the
what-do-we-call-it problem), they also know which sources contribute
to a target (improving the context capabilities for api.kde.org + the
plausability tooling could actually look at the targets rather than
the explicit list of files which of course are subject to human
error).

https://cmake.org/cmake/help/latest/command/define_property.html#command:define_property
https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html

HS