[AppStream] Adding agreements to AppStream

[Richard Hughes]

On 10 April 2018 at 04:16, Matthias Klumpp <matthias at tenstral.net> wrote:
> Sounds good. For that to work we need to have a "remote" component
> type upstream first though.

Right, agree.

> I would suggest either type="repository" or type="remote", with a
> preference for the first one as it feels more explicit.

Remote is more logically correct, although does have the unfortunate
overlap with the opposite of "local", e.g. for icons. So,
"type=repository" does make me shudder from a yum-nightmares point of
view, but does make it clear what the component is for.

> While I would not want to add code for a feature that can be achieved
> better some other way (showing the EULA on first run of the
> application), if we add facilities to AppStream for GDPR & Co. anyway,
> we could support EULAs upon installation of a program without much
> overhead and pretty easily. So in that case, I have no objections.

We can also show the runtime EULA using the AppStream data; some
flatpak apps already show the long description and donation URLs by
parsing their own MetaInfo files themelves.

>>   <agreement type="eula">
>>     <agreement_section>

I'm no sure if this should be <agreement_section> or just <section>

>>   <agreement type="warning">
> Looks good to me - but what's a "warning" type agreement? Is an
> agreement a warning?

Well, better names welcome. It's the text you have to agree before you
can enable the repository, and in this case acts as a warning. Maybe
we just leave out the "type" in this case? Or have something like
"type=usage" or "type=generic".

>>       <value key="wiped">
>>         When the firmware is deleted.
>>       </value>
> Uuh, that looks complex. For these sections, do we need machine
> readable identifiers?

>From a "validating if you did the GDPR properly" point-of-view yes,
but I think validating a GDPR statement might be a can of worms we
don't want to open.

> That looks more like an agreement_summary to me, the details are
> actually in the <agreement/> full text.

I'm happy to drop the agreement_detail bits for now.

> Therefore, I wonder if we should allow projects to define an agreement
> template in some way, and then reference that:
>     <agreement url="https://gnome.org/legal/privacy.xml"
> id="gnome-privacy-agreement"/>

This isn't a privacy policy for the organisation, this is a privacy
policy for this *explicit* service. If we try to make a generic
privacy policy we'd have a huge unreadable document than was so
generic that it didn't make any sense. For the GDPR you need to be
very specific about what data you're talking about, and what the data
is being used for, how it's backed up etc and this would be very
service specific.

> Speaking of collection XML: Can we combine multiple different
> agreements in the same document without issues? I assume the answer is
> yes, but it's better to be sure.

Yes, as long as they have a different "type".

> For your <agreement_detail/> block (where I currently feel
> agreement_summary is more accurate) each value tag would need a <p/>
> paragraph child, so we can easily translate those texts as well (and
> that would also be more consistent with the rest of AppStream). We
> could potentially also only allow only one paragraph in there.

Right, I'll come up with a proposal for that.

>>   <agreement type="eula" version="1.0">
>> But I guess we could also have:
>>   <agreement type="eula">
>>      <version>1.0</version>
> I wouldn't call this a version if it's some arbitrary identifier... I
> would reserve "version" for things where we expect version comparison
> functions to work on, most commonly SEMVER version numbers.

Good point. But it is a version identifier, even if that version is
just 2017.4USA.

> If lawyers like crazy IDs where we can't be sure that they can be
> sorted by our version comparison algorithms, and the only point of
> those is to see if we need to show them again if the ID changes, I
> would rather call this "custom_id" or "agreement_id", "text_id" etc.
> (or something that's not "id" because all id properties in AppStream
> are currently enum-type and not arbitrary text, but I currently can't
> think of any better names)

version_id is the obvious choice. It's clearly not a version *number*
but can be used to version the agreement and be used as part of a
database ID.

Richard.