[AppStream] Adding agreements to AppStream

[Richard Hughes]

On 10 April 2018 at 21:16, Matthias Klumpp <matthias at tenstral.net> wrote:
>> "type=repository" does make me shudder from a yum-nightmares point of
>> view, but does make it clear what the component is for.
> Agreed. I would add that as new component type to the spec and
> libappstream immediately, so we can make use of it faster, and because
> it's an easy change.

Okay, I'll make the same change in appstream-glib, and also accept
"source" for compatibility.

> I would like to allow the "extends" tag for repository-type
> components, so they can be additions for specific other software.

Sure, makes sense.

>> I'm no sure if this should be <agreement_section> or just <section>
>
> I was also pondering that... It depends on what else we would do with
> a generic "section" tag in the AppStream spec.
> From just an aesthetic point of view, "section" is of course nicer :-)

I've played with this. I strongly think it should be
<agreement_section> now, for two reasons:

* We might want to add additional information about the section in the
agreement, e.g. if it was deleted or only applies for certain
countries. Keeping it agreement-specific means we can do that without
adding weird cases where <section> can only have certain attributes
with specific parent tags.

* We don't want people to try and misuse <section> to break up other
random parts of the Metainfo document, e.g. in the long application
description, or even trying to split the <screenshot>'s into sections.

> Is there any case where we have an agreement that does not actually
> need to be agreed on by the user?

In some agreements it's worded as "by continuing to use this software
you accept...."

> I wouldn't think so at time...
> For the type, it looks like we would - enum-wise - have GENERIC, GDPR
> and EULA at the moment.

I was hesitant to make them enums at this early stage, but otherwise
agreed about the naming.

> I think having generic as a "this is a generic
> agreement" kind which doesn't serve a particular special purpose would
> make sense. It also fits the rest of the spec well. And type value of
> "generic" can be left out in AppStream, so for a generic agreement you
> wouldn't need to annotate the agreement tag with a type property.

Works for me. I'll update the lvfs-website patch now.

> I am assuming here thogh that each and every agreement in a metainfo
> file has to be displayed to the user in some way, prior to installing
> the software.

Not necessarily prior; in some cases after install is fine. In the
before-install I suppose we'd have to rely on the EULA text to be put
into the master AppStream document, or in the case of fwupd, to fetch
the metainfo file manually.

> Eww, nah, giving users a "you did GDPR properly because you had a
> bunch of tags in an XML file" stamp feels very risky and wrong.

Sure, it's a can of worms. Some sections are hugely important in some
service types, but in another webapp they'd just be redundant.

> Okay - I very much like the concise and machine-readable nature of the
> thing though (although its current implementation looks a bit rough).

Lets leave it for now and we can circle back when all this has been
reviewed by the various UX and legal teams.

> version_id is something I can agree to - it makes it clear that this
> is something different from an ordinary sortable version number, but
> also highlights that this is indeed some kind of versioning. So, +1 on
> that.

Great, I've modified as-glib already.

> From a general point of view I like adding a tag a bit more, because
> it prevents enormous amounts of properties accumulating over time (why
> make a property if you can make a tag?) and is a bit easier to read
> for humans. This is a rather weak argument though.

Normally my rule for promoting from an attribute to a tag is this:

 * Can you have more than one of them?
 * Do I ever want to add more details about the attribute?
 * Does the attribute have a "type"?

So in this case version_id fails all three. The only other thing that
might make sense is when the version_id isn't a date, but then we
already use timestamp=123456 or date="yyyy-mm-dd" in that case
already.

Richard.