@pwithnall
Copy link
Contributor

There are a number of desktop apps which exist as clients for proprietary web services, and hence aren’t useful without those services. That might not be obvious to users before they install the apps, though. I think it would be useful if appstream had an element which could express that an app is significantly tied to a web service, and to express what the license of that web service is.

This could allow gnome-software to give users more notice that by using certain apps, they are potentially tying themselves into a proprietary web service which they can’t contribute to / export their data from / run their own instance of / etc. On the flipside, we could promote apps which integrate with FOSS web services where the user can do those things if they want.

I’m not sure of the best markup to recommend putting in the specification, as this is a bit of an odd crossover of <requires>/<recommends> and <project_license>.

How about a <web_service> element which goes within <requires>/<recommends>, which specifies:

  • A human-readable name for the web service
  • A URI for its home page
  • A URI for its privacy policy/license
  • A URI for downloading/installing/self-hosting it
  • Its license

Example markup:

<requires>
  <web_service name="Dropbox" license="Proprietary">
    <url type="homepage">https://dropbox.com</url>
    <url type="privacy_policy">https://dropbox.com/privacy</url>
  </web_service> 
</requires>
<requires>
  <web_service name="Nextcloud" license="AGPL-3.0-or-later">
    <url type="signup">https://nextcloud.com/signup/</url>
    <url type="download">https://nextcloud.com/install/</url>
  </web_service>
</requires>

Should the name be localisable? I’m not 100% sure about the URL types for self-hosted applications, but they might fit with some work.

/cc @wjt, because you’re interested in this kind of thingy