Evaluate the impacts based on technical characteristics: By providing a description of the equipment used as well as its usage conditions, the API is able to generate footprint factors. This is similar to a database of dynamic factors.

Layered architecture: The API follows a bottom-up approach. When possible, the equipment impacts are evaluated based on the cumulative impacts of their components. In the future, we aim to evaluate the impacts of digital systems and services based on the impacts of the equipment implemented.

Multi-criteria: To take into account the diversity of environmental impacts induced by digital technologies, the API is not limited to the evaluation of greenhouse gas emissions. 19 impact criteria are available, such as pollution, the use of resources and energy, and even land use. Due to the lack of public multi-criteria environmental footprint factors, all of the assets evaluated do not implement all of these criteria. For example, only 3 are available for servers.

Over the whole life cycle: The environmental impacts of digital technologies are not limited to the use phase and energy consumption of hardware. The main life cycle stages are evaluated by the API (extraction of raw materials, manufacture, use). The distribution and end-of-life phases are assessed where possible.

Simple or detailed interface to choose from: Extensive inventory data is used by the API as part of the evaluation. However, since most users do not have all of this data, the API is able to complete the missing attributes, according to different strategies:

• Dynamic completion based on other data. (e.g. CPU name)
• Data from the archetype, a pre-registered piece of equipment or component that is defined in the query, allowing to fulfill missing data.
• Default data.

To take into account the uncertainty generated by the completion of missing data, we set minimum and maximum limits on all inventory and impact data.

Transparency: Transparency is a key element in the creation of commons at Boavizta, especially in the growing context of digital technologies’ environmental assessments. In order to guarantee a high level of transparency, we document as much as possible the methodologie followed and send the data back to the users- in particular the completed data.

New features

The first versions of the API made it possible to create an MVP to test the usefulness of the a tool. With the release of v1, we hope to offer a more complete and more robust project that can be used in a variety of use cases and encourage collaboration. Among the major new features, we can cite:

• Assessment of the impacts of user terminals and peripherals based on NégaOctet data available on the Empreinte Base.
• Assessment of the impacts of IoT equipment based on a screening approach developed by Thibault Pirson and David Bol from UC Louvain, adapted into multi-criteria by TIDE.
• Assessment of the impacts of all equipment available for 3 to 19 PEF impact criteria
• Added margins of error in the form of min and max data. At this time, margins of error are based on the completeness of user data and not on the reliability of fingerprint factors
• Addition of warnings to demonstrate uncertainties in a qualitative manner when necessary.
• Added 2000+ CPU data for completion by name. To add new CPUs, see the dedicated documentation.
• Added utility routes to obtain the list of values available for some of the variables.
• Users can now choose the impact factors they want to calculate
• Adding new cloud provider in the API have been made easier

In order to offer a more robust version 1, many major modifications (breaking changes) have been introduced. So, if you were using former versions, you will have to modify some of your API requests. Do not hesitate to look at the release note in detail, open issues on GitHub to discuss it or even contribute to improving the documentation.

Boavizta’s tool approach

Open-Source

Why?

The members of Boavizta are, before being digital professionals, citizens aware of the risks and consequences of exceeding planetary limits and the growing role of digital technology in this regard. Several reasons motivate us to only produce and encourage open solutions and methods:

• The democratization of the complex subject of environmental impacts linked to digital technologies.
• Scaling up, in terms of understanding these impacts in organizations and their ability to reduce them.
• Better collaboration and therefore better quality of the tools and methods offered.
• Respect for all people (including us) who could be subject to new regulations in the future, motivated by environmental impact assessments. An evaluation, whether in the form of a study, a control table, or a figure shared in communication campaigns, is a political object. It has the potential to influence private or public policies. In our opinion, the people and societies affected by these policies must have a right to review the way in which these evaluations are constructed, to be able to criticize and question them.
• International sharing and collaboration, which we believe is essential for agreements to be reached on evaluation standards that are as reliable and transparent as possible.

The AGPL license

The AGPL or GNU Affero General Public License is an open source license intended to require services accessible via the network to publish their source code. This license appeared in a context where many online commercial services were built on free software, but do not provide any remuneration in any form to the maintainers of these projects. This license is said to be free and copyleft.

“Free” means that the author grants all the rights or part of the rights conferred on him by copyright, leaving at least four rights considered fundamental to users:

• use of the work;
• study of the work to understand how it works or adapt it to its needs;
• modification or incorporation of the work into a derivative work;
• redistribution of the work, that is to say its distribution to other users, including commercially.

“Copyleft” means that these rights are granted, to the extent that this same authorization remains preserved. The goal is to prevent the original work from being modified, then this new work not allowing the same rights to its users.

The BoaviztAPI is licensed under AGPL-3.0. Which means that any person or organization, giving access to people other than their collaborators to a self-hosted version of the API, whether modified or not, integrated into another tool or not, is in the obligation to communicate to its users a link to the source code of the active version of the API. Through this license, it is for us both to promote the work of contributors, to encourage users to contribute but above all to avoid modified use of the non-auditable API.

State of the art

The process/methodological discussion

We try to bring the methods and calculations implemented in the API as close as possible to the state of the art of research on the subject. To do this, methodological discussions often arise from the publication of a scientific article, which seems to bring a significant improvement for the evaluation of a given digital element (environmental impacts of a semiconductor, a screen, or of a specific component, for example). Discussions generally begin within the association, on our chat tool. Once an evaluation scope seems addressable thanks to these new discoveries, we generally open an issue on the BoaviztAPI Github project, by adding an “Enhancement” tag.

From there, the discussions are open publicly and anyone, member or not of the association, can take part in the reflection and suggest a way of implementing this methodology.

A person who is not a member of the association can also suggest implementing a new calculation method, by directly opening an issue on the Github project.

Microservices

The API plays a central role in the Boavizta ecosystem. It is the methodological framework and the calculation engine, which can be used in many contexts. It is the BoaviztAPI which provides the impact evaluations available via Datavizta. It is also the component responsible for impact assessment in the cloud-scanner project, which makes it possible to assess the impacts of resources consumed in an AWS account. Boagent is another example of using the API, intended for physical servers. This tool scans the hardware characteristics of a server and provides an impact assessment based on the BoaviztAPI. Cloud-scanner and Boagent are projects that embed the API as a software component. It is therefore necessary to update the version of the API used and deployed with the project, to benefit from its advances (and it is up to the contributors of these projects to adapt the tool to benefit from changes in the API to users).

The BoaviztAPI is capable of evaluating the impact of manufacturing equipment, but also of its use (given that the user provides usage hypotheses). The method used to do this is constantly evolving, but we came to the conclusion that a more structured project, using primary data collection, was necessary to improve it. The WIP Energizta project aims to power the API with better models for estimating the energy consumption of a machine in the future.

​