Licenses

[rhubert]

A first shot of the suggestion in #258 (comment)

Uses a custom recipe property for some basic license expression checks and string functions to pick up the custom properties by a license class handling the packaging of the license files.

I'm not sure of I got the custom license handling right. At least I wasn't sure how to interpret the part before the colon in the example of the PKG_LICENSE_PATH? Should this go into a separate directory in $ID ? 🤔

Also I think the Id can be easily generated from the packageName so it might not be necessary to add a Id in the recipe?

As an example I used devel::m4 as it was the first package failing due to a missing license ;) The are many more to follow...

[jkloetzke]

Thanks for pushing this forward.

I'm not really sure that we should funnel the license through a custom property. After all, the license can be an expression where parts can be standard identifiers and another part a custom license. So my intention was that we keep the existing PKG_LICENSE for most parts.

The PKG_LICENSE_PATH should only be necessary if some custom license is involved. For standard licenses, we should be able to use the standard license texts, right? At least this is what Yocto is doing. Or do you think that we always need to copy the license file (if one exists) from the package?

My hope is that PKG_LICENSE is enough for standard licenses. For custom licenses, the part that comes after LicenseRef- needs to uniquely identify the license. Because there can be more than one custom license in the same package, the LicenseRef- identifier must be chosen by the recipe author and cannot be just the package name.

I'm not sure of I got the custom license handling right. At least I wasn't sure how to interpret the part before the colon in the example of the PKG_LICENSE_PATH? Should this go into a separate directory in $ID ? 🤔

Maybe that is Ok as well. I thought that for any $ID in LicenseRef-$ID, the license file is copied as .bob/licenses/$ID. So that there is a list of files in .bob/licenses/ that are names like the LicenseRef identifiers.

[rhubert]

The PKG_LICENSE_PATH should only be necessary if some custom license is involved. For standard licenses, we should be able to use the standard license texts, right? At least this is what Yocto is doing. Or do you think that we always need to copy the license file (if one exists) from the package?

For standard licenses it's IMO sufficient to put the license information (not the license text) into to package. Otherwise we'd need to have all texts somewhere available and all packages would depend on the license-texts package?

Anyway - how is it supposed to work to collect these licenses later if any standard-licensed-package has the same .bob/license file? 🤔

My hope is that PKG_LICENSE is enough for standard licenses. For custom licenses, the part that comes after LicenseRef- needs to uniquely identify the license. Because there can be more than one custom license in the same package, the LicenseRef- identifier must be chosen by the recipe author and cannot be just the package name.
Maybe that is Ok as well. I thought that for any $ID in LicenseRef-$ID, the license file is copied as .bob/licenses/$ID. So that there is a list of files in .bob/licenses/ that are names like the LicenseRef identifiers.

Sorry - I still don't get it. Can you give me an example? If there is a package with different licenses we'd have

metaEnvironment:
   PKG_LICENSE: "LicenseRef-MyExample"
   PKG_LICENSE_PATH: |
       lib1:foo_license.txt
       lib2:bar_license.txt

and package

.bob/license/MyExample1/lib1/foo_license.txt
.bob/license/MyExample1/lib2/bar_license.txt

or

.bob/license/MyExample1-lib1/foo_license.txt
.bob/license/MyExample1-lib2/bar_license.txt

?

[jkloetzke]

Anyway - how is it supposed to work to collect these licenses later if any standard-licensed-package has the same .bob/license file? 🤔

First of all, this file won't be a single license. It is a license expression. So it will contain something like GPL-2.0-or-later OR LicenseRef-ByMeABeer. So whatever gathers all the applicable licenses in the end, it has to read all .bob/license files to have a list of the involved licenses.

Sorry - I still don't get it. Can you give me an example? If there is a package with different licenses we'd have

metaEnvironment:
   PKG_LICENSE: "LicenseRef-MyExample"
   PKG_LICENSE_PATH: |
       lib1:foo_license.txt
       lib2:bar_license.txt

So the package contains two libraries with different licenses? Then I would say it should look like this:

metaEnvironment:
    PKG_LICENSE: "LicenseRef-Foo AND LicenseRef-Bar"
    PKG_LICENSE_PATH: |
        Foo:foo_license.txt
        Bar:bar_license.txt

If the libraries were not split into a multiPackage, I would argue that both licenses must be obeyed. Hence the "AND" in the license expression. Then the PKG_LICENSE_PATH provides the mapping to the individual license files. So the result should look like the following:

.bob/license  -> "LicenseRef-Foo AND LicenseRef-Bar"
.bob/licenses/Foo -> copy of foo_license.txt
.bob/licenses/Bar -> copy of bar_license.txt

Does this make sense?

[rhubert]

I updated the PR and added missing licenses. There are still some recipes without a PKG_LICENSE:

$ find recipes/ -type f -name "*.yaml" -exec grep -L "PKG_LICENSE" {} \; 
recipes/utils/pxargs.yaml
recipes/utils/which.yaml
recipes/libs/uclibc-l4re.yaml
recipes/libs/libc.yaml

recipes/net/make-ca.yaml

recipes/devel/host-compat-toolchain.yaml
recipes/devel/bootstrap-sandbox.yaml
recipes/devel/cross-toolchain.yaml
recipes/devel/autotools.yaml
recipes/devel/sandbox-toolchain.yaml
recipes/devel/bootstrap-fake-pkg-config.yaml
recipes/devel/sandbox.yaml
recipes/devel/bootstrap-host-toolchain.yaml

recipes/devel/win/cmake.yaml
recipes/devel/win/ninja.yaml
recipes/devel/win/msbuild.yaml
recipes/devel/win/vs2019-toolchain.yaml

recipes/devel/bootstrap-sandbox-toolchain.yaml
recipes/devel/autotools-2.69.yaml
recipes/devel/compat/cross-toolchain.yaml
recipes/kernel/linux-libc-headers.yaml

While many of them are expected and do not depend on the licenses class there are some recipes where I don't know the license, e.g. utils/which or the windows recipes. 🤷

Also I'd like to do the split into multipackages in a $later change if the is really necessary. Especially for the util-linux this seams to be near to impossible at all.

To avoid merge-conflicts I added the ninja-license to #282

[jkloetzke]

Almost there. Just a few nitpicks...

[rhubert]

Thanks for the review 👍

[jkloetzke]

CI is still failing because meson::libgreet does not have a license... Other than that, I guess we're ready to go?

[jkloetzke]

Thanks!