[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Extend metainfo.yaml files with License Information
From:       Andreas Cord-Landwehr <cordlandwehr () kde ! org>
Date:       2020-08-17 12:15:59
Message-ID: 29587948.o0kJ8FhRvh () weatherwax
[Download RAW message or body]

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



[prev in list] [next in list] [prev in thread] [next in thread]