Re: Extend metainfo.yaml files with License Information

[Andreas Cord-Landwehr]

On Dienstag, 18. August 2020 12:34:42 CEST Harald Sitter wrote:
[...]
> > 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:def
> ine_property https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html

Yeah, I full agree!

In my opinion adding these information to the yaml files is a first step, which 
allows to work separately on the build system tooling part and the API 
documentation part. Actually, for the very same reason 
ecm_check_outbound_license already has a FILES parameter, which later could be 
simply replaced by a TARGET parameter to retrieve files automatically form a 
target ;)

To extend your pipedreaming, I even hope to get same standardized format out 
of this, which simply is generated by an arbitrary build system... :)

As first incremental step, I will prepare a MR for adding functionality to 
api.kde.org and a PoC yaml file for some of the repositories.

Cheers,
Andreas

Re: Extend metainfo.yaml files with License Information

[Harald Sitter]

On Mon, Aug 17, 2020 at 8:24 PM Andreas Cord-Landwehr
 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 
>  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

Re: 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 
 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

Re: Extend metainfo.yaml files with License Information

[Harald Sitter]

On Mon, Aug 17, 2020 at 2:16 PM Andreas Cord-Landwehr
 wrote:
>
> Hi, I am currently looking into extending our metainfo.yaml files to provide
> information about the outbound licenses of the artefacts that are provided by
> a framework. Here a few examples:
>
> Attica: Provides libattica, which is legally OK to be used as LGPL-2.1 or
> LGPL-3.0 (and of course also as GPL-2.0 or GPL-3.0).
>
> Baloo, which is quite complicated: The library is (supposed to be; there are a
> few license issues here at the moment) LGPL-2.1 and may also be used as
> LGPL-3.0. Moreover, there is the baloo-kioslave that is GPL, then there are a
> few tools balooctl, balooshow and baloosearch, which are all GPL-2.0 or
> GPL-3.0.
>
> **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.

> 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?

HS

Extend metainfo.yaml files with License Information

[Andreas Cord-Landwehr]

Hi, I am currently looking into extending our metainfo.yaml files to provide 
information about the outbound licenses of the artefacts that are provided by 
a framework. Here a few examples:

Attica: Provides libattica, which is legally OK to be used as LGPL-2.1 or 
LGPL-3.0 (and of course also as GPL-2.0 or GPL-3.0).

Baloo, which is quite complicated: The library is (supposed to be; there are a 
few license issues here at the moment) LGPL-2.1 and may also be used as 
LGPL-3.0. Moreover, there is the baloo-kioslave that is GPL, then there are a 
few tools balooctl, balooshow and baloosearch, which are all GPL-2.0 or 
GPL-3.0.

**First question:** Shall we only list ONE or ALL licenses, same for the 
license information overview that should be on api.kde.org?

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
balooctl:
- GPL-2.0-only
- GPL-3.0-only
balooshow:
- GPL-2.0-only
- GPL-3.0-only
   balooctl:
- GPL-2.0-only
- GPL-3.0-only

For repositories that are simpler, it might also be a good idea to provide a 
wildcard like "default" that allows you to omit all individual license 
statements.

Thanks for reading and I am hoping for some feedback :)

Cheers,
Andreas