appstream

appstream copied to clipboard

Hi,

https://appstream.debian.org/sid/main/issues/0xffff.html

metainfo-license-invalid The metainfo file does not seem to be licensed under a permissive license. Valid permissive licenses include FSFAP, CC0-1.0 or MIT. Permissive licenses are required to allow distributors to include the metadata in mixed data collections without the risk of license violations due to mutually incompatible licenses. If you think this message is an error and 'ISC' is actually valid, please file a bug against AppStream.

If MIT is ok, ISC should also be ok, which is shorter and less ambiguous: https://en.wikipedia.org/wiki/ISC_license

-- Sebastian

@hughsie I have no objections to allowing ISC as well - do you see any issues allowing it would cause for you / Red Hat / Fedora?

It would cause issues; it means changing the metadata license of all the things in production shipping AppStream. We've agreed various things with other legal entities, and changing the license of the data we provide means having to re-check and possibly renegotiate all of that. I thought we had a small set to avoid this kind of license explosion? I guess one solution would be for libappstream-glib to ignore any of the new licenses, although that's going to be confusing for all involved. I mean, what's next, do we allow (MIT or CC0-1.0) and FSFAP? Should we allow other content licenses like GFDL?

Please stop changing the legal and licensing parts of the spec unless absolutely required. In my opinion it's making adopting AppStream more difficult to adopt in companies and will lead to fragmentation.

@hughsie I agree in principle, and I really don't want to add more licenses. Personally I think just having FSFAP should satisfy all requirements. With ISC being so close to MIT, and MIT being a license we do actually support, I think and exception could be made though.

Originally, I was going to allow all permissive licenses, which later turned out to not be a great idea, therefore the license list was restricted to its current form. Unfortunately you did the same with a different list of licenses, at least that's what I read into your comment. Just to be sure that we're on the same page, these are the license AppStream currently accepts for metadata:

• FSFAP
• MIT
• 0BSD
• CC0-1.0
• CC-BY-3.0
• CC-BY-4.0
• CC-BY-SA-3.0
• CC-BY-SA-4.0
• GFDL-1.1
• GFDL-1.2
• GFDL-1.3
• BSL-1.0
• FTL
• FSFUL

(I also think I should change the wording in the spec to clarify that only these licenses are allowed, instead of just saying "permissive licenses" are okay)

On Sat, 21 Jul 2018 at 15:01, Matthias Klumpp [email protected] wrote:

Just to be sure that we're on the same page, these are the license AppStream currently accepts for metadata:

AppStream-Glib just supports CC0-1.0, CC-BY-3.0, CC-BY-4.0, CC-BY-SA-3.0, CC-BY-SA-4.0, GFDL-1.1, GFDL-1.2, GFDL-1.3, FSFAP

When was MIT, 0BSD and FTL added? Why were they added? CC0 is basically the same as a BSD license. MIT isn't really a content license. This is very concerning for me; licencing isn't something we can just change on a whim, it's a legal thing that needs careful consideration and involvement from lots of different stakeholders.

When was MIT, 0BSD and FTL added? Why were they added?

Since AppStream existed, as originally it was allowing all permissive licenses. So at first, I just compiled a list of commonly used permissive licenses and allowed those (without updating the list, that's why it isn't that large now, actually). Appstream-glib came a bit later and had more restrictions, but I wasn't even aware of that because I completely avoided looking at asglib code for quite a long time...

CC0 has the disadvantage that is technically requires people to ship a copy of the (long) license - using BSL-1.0 would be more useful (BSL-1.0 is essentially a globalized public-domain statement (for countries that don't have the public domain), or FSFAP of course). People often prefer to have their metainfo file have the same license as their project (gnome-terminal....), that's why the license selection was bigger. Also, having the license replicated somewhere is actually an issue for some projects (an issue that allowing FSFAP has fixed nicely).

FWIW, I run into that in libu2f-udev in Debian.

I “fixed” it by relicensing the scripts that generate the AppStream metadata under LGPL-2.1+ (which is the same as the data they consume to produce the metadata).

@mariobl LGPL is no permissive license, so this change will be rejected as well. You will want something like the FSFAP license. AppStream will currently only recognize those licenses as valid:

• FSFAP
• MIT
• 0BSD
• CC0-1.0
• CC-BY-3.0
• CC-BY-4.0
• CC-BY-SA-3.0
• CC-BY-SA-4.0
• GFDL-1.1
• GFDL-1.2
• GFDL-1.3
• BSL-1.0
• FTL
• FSFUL

So only one of these will actually work.

@ximion Yes, I saw the list. Unfortunately, there's an issue mentioned in the commit message: since the Appstream metadata is generated from data (a udev rules file) licensed under LGPL, for which I do not own the copyright (so I cannot relicense it), I'm unsure what is the legal situation.

My understanding in that collections of pure facts, arranged without creativity (like a phone book), aren't subject to copyright (at least in the EU and US), and that would include this collection of USB vendors and devices ids.

I am however not a lawyer, so I made it easy: code licensed under the LGPL, processing data licensed under the LGPL, producing metadata that's also licensed under the LGPL.

@nbraud Could you maybe just ask upstream for clarification? We can't accept copyleft licenses in metainfo because the data contained in them gets aggregated into one big file, which would be a license violation if multiple copyleft licenses (or other licenses not in the allowed list) clash with each other.

@ximion I think upstream made it pretty clear (see https://github.com/Yubico/libu2f-host/issues/71) that the udev rules are licensed under the LGPL, but I will ask them to comment on the metadata situation.

I think at this point it's fairly clear that we don't want to add more metadata licenses unless there is a very string case for that...