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