Criteria catalog for sustainable Software

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?

3.1.1 Transparency of data formats and data portability

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.


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 w


3.1.2 Transparency and interoperability of the programs

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.


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

3.1.3 Continuity of the software product

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


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.


3.1.4 Transparency of task management

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


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?

3.2.1 Uninstallability of programs

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


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

3.2.2 Capability to erase data

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.


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?

3.3.1 Recoverability of data

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


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?

3.3.2 Self-recoverability

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


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?

3.4.1 Offline capability

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


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 require

3.5 Quality of product information

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

3.5.1 Comprehensibility and manageability of product documentation, licensing conditions, and terms of use

Is all the information easy for users to understand?


a)      Inspection by reviewers; test with actual users

3.5.2 Resource relevance of product information

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.


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)

Term Description
Energy efficiency Generally, the amount of “useful work” divided by the amount of energy it requires. In the context of this document, “useful work” is operationalized as the successful execution of standard usage scenarios.
Hardware The material goods required to run programs or to store or transport data.
Hardware capacity Quantifiable characteristic of a hardware system which represents its performance limit on a given dimension of performance (e.g., working memory capacity, computing power, bandwidth).
Hardware system Delimitable unit of hardware that performs defined functions.
Indicator An empirically determinable quantity that provides insight into a matter that cannot be measured directly. The indicators proposed in this document have different levels of measurement. In some cases, researchers will have to settle for an ordinal scale (e.g., “insufficient”, “sufficient”, “good”, “very good”, or even merely “fulfilled”, “not fulfilled”) to avoid giving the false impression of non-existent precision arising from a cardinal scale.
Reference system A hardware system that is defined as generally customary in terms of its most important capacities (e.g., working memory, processor performance) during a defined period of time (e.g., one year). The purpose of the reference system is to be able to express indicators such as “minimum local memory” in relation to a reference value (currently “customary” memory).
Resource In the context of this document, a natural resource, in particular a raw material, a form of energy, or also the capacity of an environmental medium to absorb emissions. To differentiate natural resources from technical ones, especially hardware resources, the more precise term “hardware capacities” is used here for the latter. Since using hardware capacities always results in using natural resources, this distinction (which ultimately amounts to a definitionally difficult differentiation between the ecosphere and the technosphere) is not of decisive importance here.
Resource efficiency Generally, the amount of “useful work” divided by the amount of resources it requires. In the context of this document, “useful work” is operationalized as the successful execution of standard usage scenarios.
Software Programs and data in digital form.
Software product A delimitable unit of programs and data for which a license is available.
Standard configuration A set of conditions, defined as a reference, under which a given software product is run; it includes the parameter settings selected during installation or operation, the system software provided, potentially additional software products required for operation, as well as the reference system at the hardware level.
Standard usage scenario A usage scenario that is used for testing a software product and is supposed to be as representative as possible for the customary use case.
Usage pattern Abstracted form of a sequence of interactions with a given software product.
Usage scenario Description of a usage pattern which is generally machine executable.
back-to-top nach oben