Criteria catalog for sustainable Software

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 w

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

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

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

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?

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

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 require

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)