[AppStream] Adding agreements to AppStream

Tue Apr 10 20:16:26 UTC 2018

2018-04-10 11:05 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> 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,

Jup, that is why I don't like it that much...

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

>> 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>

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 :-)

>>>   <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".

Is there any case where we have an agreement that does not actually
need to be agreed on by the user? 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 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.

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.

>>>       <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.

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.
We could do something like "hey, you miss a section required for GDPR,
please review the whole thing with your lawyers to be sure it is done
correctly" kind of warning message though.

>> 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.

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

>> 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.

Okay - let's ignore the "too much data" thing for now, I plan to
address that for the <releases/> tag anyway in the future, and it
feels like mixing this in here as well just makes the discussion more
complicated and less focused.
So, add the agreement tag first and see how and how much it is used
makes sense, I think.

>> 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".

Ok

>> 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.

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.
Whether it should be a property or a tag is something I am not sure
about - we actually have both kinds in the AppStream spec, so either
way would be fine.
>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.

Cheers,
    Matthias

-- 
I welcome VSRE emails. See http://vsre.info/