Include more non-SPDX identifiers to convert to SPDX

[aleixpol]

We'd gotten some bug reports about some licences being present, decided
to make sure ArchLinux licence identifiers are covered by this
conversion function.
https://archlinux.org/packages/core/any/licenses/files/

[ximion]

I'm not sure this is a great idea - the conversion is there to cover cases from before AppStream allowed only SPDX license identifiers, and to convert cases when the SPDX specification broke.
Nowadays, we always require SPDX identifiers, it is illegal to use anything else and the validation of metainfo files will fail in that case. So, I don't think we want to relax the SPDX requirement by adding even more exceptions, if anything we should actually strive to get rid of the ones we already have...

What bug does this actually fix, and why can't the upstream projects simply fix their metainfo files?

[Pointedstick]

and why can't the upstream projects simply fix their metainfo files?

They surely can, but it's the classic issue of them not doing so because getting app developers to care about metadata correctness is hard.

Also the equally classic issue of "fix the tool" vs "fix the world around it".

What bug does this actually fix,

This helps us to fix an issue in Discover; see https://bugs.kde.org/show_bug.cgi?id=454480#c6

[ximion]

They surely can, but it's the classic issue of them not doing so because getting app developers to care about metadata correctness is hard.

They will never do that when the validator accepts more incorrect stuff - the way that has been proven to work so far is to start with adding an "info" priority hint, then wait a bit and then bump it to a warning or error, which then makes people actually fix the problem (especially if they want to see their app in a software repository like Flathub).

The issue here is actually something different though: The listed apps do all either have no AppStream MetaInfo file, or have one where the project_license tag is missing (was allowed in older AppStream versions). And apparently some Linux distributions add the license set to the package as project_license in that case, and of course a lot of distributions have different specifications for how a license string should look like.
Debian/Ubuntu will actually leave the project license field empty.

So, in order to get correct free/non-free information, we actually operate on a repository level in GNOME Software, where the distributor adds a list of "free" repositories for which all apps will be considered free, regardless of their license.
See https://gitlab.gnome.org/GNOME/gnome-software/-/blob/main/data/org.gnome.software.gschema.xml#L96 for the configuration schema.
Then, the logic is:

if (app_source_is_distro_package and app_origin in list_of_free_origins)
    return APP_IS_FREE_SOFTWARE;
else if (as_license_is_free (component))
    return APP_IS_FREE_SOFTWARE;
else
    return APP_IS_NONFREE;

The origin is, for example for Debian, a string comprised of <project>-<suite>-<component>, e.g. debian-bookworm-main. So the list of acceptable free origins would be a glob like debian-*-main on Debian systems and ["ubuntu-*-main", "ubuntu-*-universe"] on Ubuntu.

I guess KDE Discover doesn't do this extra step and relies solely on license information, which won't work if the Linux distribution is synthesizing metadata.

I think there is a point here for adding this origin checking code to AppStream itself, so distributors can set this setting in one central place, rather than having to modify it in both GNOME Software and KDE Discover (see https://salsa.debian.org/gnome-team/gnome-software/-/blob/debian/master/debian/gnome-software.gsettings-override.in for the current override for Debian/Ubuntu for GNOME Software).

[aleixpol]

Fair enough, I can keep this mapping in Discover, I just thought it would make sense to keep it somewhere shared.

I don't think that showing properly in Discover will make people fix their metadata issues, if anything it might to properly check on flatpak-builder or when uploading to the different software stores.

[ximion]

I don't think that showing properly in Discover will make people fix their metadata issues, if anything it might to properly check on flatpak-builder or when uploading to the different software stores.

Yeah, that's in progress (as flatpak/flatpak-builder#418).

Do you think having a as_component_is_free or similar function in AppStream that takes the component origin into account makes sense for you? That would essentially implement the GNOME Software feature, but in libappstream instead of individually in each software center.

[Pointedstick]

Having the app/packaging be able to tell us definitively whether it's free or not might be a good idea, yeah. But wouldn't that be redundant if the app's licenses are already known to be free? Maybe make it a requirement only if any of the licenses listed elsewhere in the metadata are identified as something other than a "known free" license.

[ximion]

Yes, sure, that is how this would work anyway. If origin is trusted-free, consider it free software, otherwise check licenses for free-ness.