back ⇧

3 User autonomy

Does the manufacturer of the software product respect user autonomy in dealing with the purchased product?

This main criterion assumes that a relevant number of users is interested in using software in a resource-efficient way. If they can do so without functional disadvantages, they will try to work with a small amount of hardware capacity (which they generally pay for) and keep energy consumption low (which is also financially relevant or at least impacts the battery life of mobile devices). However, users can do so only if they are not forced to consume unnecessary amounts of resources and if they understand how they can avoid unnecessary resource consumption.

The ideal is a software product that respects the freedom of users to decide about utilizing hardware capacities (and thus indirectly about using resources) when using the product, as far as possible.

The following criteria are to be evaluated from the perspective of target groups that are not technical specialists; in other words, they will generally not be fulfilled simply by the fact that an expert can fulfill them. Criterion 3.1.2 is an exception in this regard.

3.1 Transparency and interoperability

Can users understand resource-relevant aspects of the software product with a reasonable amount of time and effort? Are they free to re-use data they produced with this software product with other software products?

Is sufficient documentation provided for the data formats (file or data stream formats) used by the software product to enable interoperability? Do the data formats comply with open standards enabling further use of the data with another software product?*

To apply this criterion, it must first be defined which standards are considered open standards at the time of awarding a label.

Indicators:

a) Review of manuals and technical data sheets, comparison with known open standards

b) Check of compliance with known and open standards.


*This is decisive to prevent customer lock-in (dependence on the software product), which may force unnecessary resource consumption, both in the case of retaining an inefficient product and in the case of switching to a different product, which may require resources as well.

Are application programming interfaces (APIs) clearly documented, and are dissemination and further development of the program supported? Do the interfaces comply to open standards to enable interoperability?

Weighting of indicators may be highly dependent on context. The effects of open source code and licensing models on resource use cannot be assessed in terms of a general rule.

Indicators:

a) If APIs exist: Review of the documentation of the interfaces on the basis of the documentation of the software product and its APIs

b) Is the source code open?

c) Is the software released under a license that allows it to further develop it??

Can the software product be used for longer periods of time without serious negatives (in particular IT security problems) occurring, and does the user have the option to avoid unnecessary updates?1

Indicators:

a) How long is the time period for which the supplier guarantees future support for the product, including security updates?

b) Does the manufacturer respond promptly when security gaps (vulnerabilities) become known?

c) Can the user influence the frequency of updates by configuring the software product and when doing so differentiate between security updates and other updates?

d) Is it possible to receive differential updates only?2


[1] A high frequency of updates causes resource consumption and makes it more difficult to maintain transparency. It is difficult to define the “necessity” of updates objectively; however, it makes at least sense to differentiate between security-relevant (and thus doubtless necessary) updates and other updates; this is addressed by indicator b).

[2] This avoids replacing the entire program, which can cause significant resource consumption if performed frequently.

Does the software product inform users that it is automatically launching or running tasks in the background that are possibly not being used?

Indicators:

a) On the basis of the installation and the execution of standard usage patterns, test which processes are automatically launched by the software product and whether it informs users of this (Scale: informs users of all such processes/informs users of some such processes/does not inform users)

b) If the software product is automatically launched at system start (“autostart”): does it inform users that this is the case?

c) If the user carries out an action that can be understood as ending the program, but at least one of the tasks remains active: does the software product inform the user that this is the case?

3.2 Uninstallability

Can the software product be uninstalled easily, without leaving traces, and without avoidable disadvantages? 

Does the user receive sufficient support to uninstall the program without leaving traces?

Indicators:

a) Uninstallation of the software and comparison with the condition prior to installation, which must be identical.

Does the user receive sufficient support when erasing data generated during operation of the software product as desired?

This criterion is intended specially to avoid the case that compliance with high IT security standards following uninstallation of the software product can be guaranteed only by physically destroying hardware.

Indicators:

a) After erasing of the data explicitly stored by the user and comparison with the condition prior to installation, are the two states identical in relevant respects?

b) Does the software product provide transparency about the places where it stores data?

c) Is the user supported in erasing data stored on remote storage devices without leaving traces?

3.3 Maintenance functions

Does the software product provide easy-to-use functions permitting users to repair damage to data and programs?

Can the data be recovered in its last condition following an abnormal termination?

Indicators:

a) Does the manufacturer provide specifications and can they be validated by means of a test?

b) Can the user set the periodicity at which changes are automatically saved?

Can the installed instance of the software product be recovered following the occurrence of an inconsistent state?

Indicators:

a) Manufacturer specifications and review by means of a test

3.4 Independence of outside resources

Can the software product be operated as independently as possible of resources not subject to the users' control?

To what extent does the software product avoid forced connectivity that is not necessary for providing the functionality?*

Indicators:

a) Testing on the basis of the standard usage scenario (Scale: offline operation possible/possible with limitations/impossible)


* Examples of unnecessarily forced connectivity: establishing a connection to the license server, repeated download of fonts required.

3.5 Quality of product information

Does the information provided about the software product support its resource-efficient use?

Is all the information easy for users to understand?

Indicators:

a)      Inspection by reviewers; test with actual users

Does the product information include everything that users need to minimize resource consumption by the software product in a structured form, and is the information correct?

The long-term goal is to develop standardized product descriptions for resource-relevant product information. As soon as a satisfactory standard exists in this regard, compliance with it can be included as an indicator.

Indicators:

a) Qualitative assessment of completeness and comprehensibility

b) Does the product information refer to the current version of the product?

c) Inspection whether the information is correct (information is conclusive / partially conclusive / non-conclusive)