EOLE 2020 Webinar #5 : Legal tools for public administrations to sustain the use of open source

This Webinar is part of the 13th edition of the EOLE conference which is held online this year due to the worldwide pandemic.

Initiative born in 2008 the European Open Source & Free Software Law Event (EOLE) aims to promote the share and dissemination of legal knowledge related to free software, as well as the development and promotion of good practices.

This fifth webinar, which focuses on “Legal tools for public administrations to sustain the use of open source”, has been facilitated by Benjamin Jean and was divided into the four following parts :

• 1. “Assessment of Open Source Software for Public Administrations” – Marco Conoscenti
• 2. “Best practices for helping Public Administrations work with Open Source” – Malcolm Bain
• 3. “JOINUP – The Licensing Assistant” – Patrice-Emmanuel Schmitz
• 4. Q&A

1. Assessment of Open Source Software for Public Administrations – Marco Conoscenti

Marco Conoscenti is a postdoctoral researcher at the Nexa Center for Internet and Society of Polytechnic University of Turin. He will share the guidelines published and promoted by the Agency for Digital Italy (AgID) in order to help and hold public administration to efficiently buy and use Open Source software.

Context

In May 2019 the Agency for Digital Italy (AgID) publishes the Guidelines on acquisition and re-use of software for the Public Administration. AgID is the most important agency in Italy for advancing its national digital agenda. These guidelines promote the use of Open Source software and reuse of already available software. For example, these guidelines say that when a public administration is searching for software, it must first consider Open Source software and software already developed by other public administrations. And only if there is no Open Source software available, they can look at a proprietary software. So the objective of the guidelines is to incentivize the use of Open Source software for public administrations.

Goal

In this context, the goal of our work was to produce a procedure to assess and compare Open Source software for public administrations. Our procedure considers both technical and economic aspects of software. Most importantly, it fully adheres to the AgID guidance. So the constraint of our work was to design a procedure that was totally compliant with the AgID guidelines.

Our work

First, the procedure is implemented in a spreadsheet so that it can be easily compiled by public administrations when they want to compare and to assess Open Source software. The procedure in itself consists of three main phases. First there is a technical assessment of the software then there is an economic assessment of these software. Finally there is a comparison which is based on the results on the scores obtained by the software both in the technical assessment and in the economic assessment.

For example a public administration compares three software to adopt one of them. The three software are technically assessed using the guideline assessment criteria defined by the AgID. The software are also economically assessed using a total cost of ownership model that we designed in this work. After the assessment, a multi-criteria decision-making algorithm is used to compare the software according to the technical and the economic assessment. This algorithm takes the weights of the criteria as input because each assessment criteria has a weight which define its importance. It also takes the weight of the total cost of ownership as input and the total scores that all the software obtained in the technical and economic assessment. Finally, this algorithm produces a ranking of the software from the best one to the worst one according to the criteria. This tool should help public administrations to decide which one of these three software to adopt.

Technical assessment

Each software is assessed according to the assessment criteria of the guidelines. Particularly in our work, we defined a quantitative measurement of the criteria in order to make the software comparable according to these criteria. The particular assessment criteria defined in the guidelines are : coverage of functional and non-functional requirements, interoperability, protection of personal data, security of the software and accessibility. There are also other criteria, such as the presence of a maintainer for the software, the presence of support for the installation, the dependencies with other software, the skills of the public administration in using the software, the number of public administrations that are interested in that software and finally, the vitality of the software project. The criteria involved are the ones that are mandatory because, according to the Italian Digital Law, when assessing software it is mandatory to at least evaluate and consider these criteria.

Economic assessment

For the economic assessment we estimate the total cost of ownership of the software. We did some research on already available Total Cost of Ownership (TCO) models and on the scientific literature. Based on this research, we designed a TCO model for the software. This model was then refined and reviewed together with the Piedmont Region which has great experience with economically evaluating software with TCO.

The TCO includes capital expenditure costs like the integration with existing systems, the cost of hardware, the cost of making the software compliant with the specifications and the verification of compliance with the legislation. It also includes service design, installation, data migration from other software, and the training of the people that will use the software.

The TCO also consider operational expenditure costs. It is for example the annual cost of software of a service in case the software is used as a service. It also considers software licenses. For example if you are comparing Open Source software with proprietary software there will be software licenses, and the TCO will take into account the cost of software maintenance, damages, etc. There are also additional parameters which are the estimated number of years of adoption (five by default) and also the number of public administrations that are interested in that same software, which can therefore divide the costs. It’s not mandatory to estimate each one of the costs but it’s mandatory to estimate the TCO of a software when comparing different software.

Comparison

The software are compared using Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS) which is a multi-criteria decision-making algorithm. This algorithm has been suggested by the Italian anti-corruption agency. That’s why we decided to adopt this argument to be compliant with the suggestion of the anti-corruption agency. So as input, the algorithm takes the results of the technical and economic assessments and also the weights of each assessment criteria. As output the algorithm produces a ranking of the software from the most satisfactory to the least satisfactory according to the criteria and today’s rates.

So we proposed a set of weights of the assessment criteria and these weights depend on the category the software belongs to. We imagine the different software categories (management software, software for networking, etc..) and for each of these categories, we provide a set of weights for all the assessment criteria. In January 2020, public administrations tested the procedure and evaluated it using a questionnaire that we presented them. Public administrations used this and we asked them to answer some questions regarding the tool. The main result is the difficulty of the procedure to be evaluated as low or medium by a public administration. So there was no public administration that considered the procedure particularly difficult and the majority of them compiled the procedure in two or four hours. We also proposed an extension of the assessment criteria. We suggested to include other criteria when evaluating software and there are two suggested instructions. The first was regarding the quality characteristics defined in the ISO/IEC 25010 standard. This standard contains the quality characteristics of software, for example interoperability or security. So we suggested that public administrations include all these standardized quality characteristics of software when comparing software. We also suggested to include aspects of context that we found in the literature when searching for tools that evaluate Open Source software, such as degree of responsiveness or activity of the community developing the software, and presence of trusted software developers in the software development project.

Conclusion

So we developed a procedure for technical and economic assessment of Open Source software. We hope that this procedure can be an easy-to-use tool to support public administrations in choosing the most appropriate, new, satisfactory software for their needs for future work development. We suggested a possible extension of the assessment criteria and to include the information necessary to compile the procedure in the software description, which was another interesting aspect that was noticed by the public administration that evaluated the procedure. For example, all the software used by public administration in Italy are uploaded onto a portal called Developers Italia. So it would be nice to have the information necessary to compile the procedure as a description of the software in this portal so that the public administrations can easily compare the software.

2. Best practices for helping Public Administrations work with Open Source” – Malcolm Bain

Malcolm Bain is an IT law expert at Across legal and also a researcher. He will talk about both the Barcelona Open Source technical framework which he helped to develop. He also contributes to Open Source within the organization and addresses the adaptation of Open Chain specifications for public administration needs.

Introduction

Open Source in public administration is, I think, one of the most exciting areas of Open Source at the moment. Indeed, public administration is probably 10-20 years behind the private sector in terms of doing things efficiently. But they’re getting there and it’s a great space for Open Source because it’s ideal for sharing amongst public administrations and the most efficient use of public money. But public administration are having difficulties. There is a lack of knowledge, a lack of best practices and a lack of incentives to work with Open Source after 50 years of working with private tenders and large private proprietary software platforms. So, I’ll go into some technical ideas about best practices. It’s mostly about culture change and changing the way projects are approached and how the internal I.T. departments manage their information technology projects. What we’ve been seeing is that in the private sector, there’s been quite a lot of push towards improving the processes for managing Open Source in supply chains and this is now moving towards the public sector. There’s a lot of reports of best practices that have been recommended. But to be frank in what I’ve seen of public sector, not much is happening compared to the size of the public sector I.T. infrastructures and budgets. So there’s a lot of work to do.

Here are two examples of best practices : Open Chain which is used by the private sector and comes from the supply chain of industry. a proposal of free software management guidelines made by Barcelona City Council.

It is a very detailed handbook on how to open, close, manage, contribute, and even procure Open Source based projects.

These two tools are complementary and both of them really go towards training for a culture change.

Open Chain

FOSS Compliance best practice : Open Chain

Open Chain is made for supply chains, for automotive or large industry where you have multiple layers of suppliers from chip sets to software embedded in the hardware, in a smart car, for example. The idea of Open Chain, is to ensure that the Open Source software compliance work is not repeated down the supply chain and that you can trust your supplier. Open Chain is now an international specification standard for supply chain information on Open Source. It sets a specification on the management of Open Source in the entity in terms of policy, of training, of managing licenses or source code and even contributing to the community and upstreaming it. It recommends a process for doing an Open Source review and maintaining the integrity of the different packages that are being provided. It can become very complex because it’s used by large industry players. Automotive is one but there are other sectors involved due to the internet of things (IoT), which makes our world more and more smart and more and more linux-embedded in everything we do, see and manipulate.

Open Chain is not just a set of requirements. Behind Open Chain there are tools and other specifications like SPDX which help this. When Open Chain is the process, SPDX is a language for identifying and specifying the legal issues of a code (licenses, authors, exceptions…), and below that, there is a set of tools for code scanning, storing the information best practices for reusing it. So it’s a pyramid of different elements.

Public administration is a member of the supply chain, although it is often at the end but it does provide digital services and it is now participating in Open Source projects. It is also passing on code to the open sector or passing on code to other public administrations. So this is relevant in terms of the legality and best practice in managing Open Source projects inside the public administration.

Open Chain defines a set of processes for coming code which means managing the code internally, passing the code and distributing it. This helps support the key characteristics of public code in terms of access, interoperability, security, etc. And when we looked at this for helping public administrations, in a couple of cases it is complex because the public administration cannot take on board the best practice.

Adaptation of Open Chain for Public Administrations

So what we’ve been looking at is how to adapt Open Chain for public administrations to simplify it. So the specification has five chapters. Open Chain has a chapter on program which consists in creating a policy and an environment for good Open Source management (FOSS Policy, Competence, Awareness, Scope, Licenses). It sets out roles that people play and what tasks they have in managing Open Source (access points, human resources…). It also sets out a process for reviewing and approving elements of Open Source : inbound building yourself, distributing, sharing with other entities (Bill of Materials, License Compliance). There is also a process for storing that evidence because some of this code can last for six months and some public administrations are still using it 15 years later. So it’s important to comply with the obligations to provide source code for example. And the last stage is engagement with the community and best practices in contributing code. This is all relevant to a public administration and we’ve been looking at how to simplify this to work in a more agile way. So it consists in changing the way different public administrations could apply these processes and manage all their projects but specifically their Open Source projects (and hopefully all their projects are Open Source projects). We distinguished between R&D innovation projects, in which it’s much easier to work with agile and Open Source, and projects which go into production which are much more complex to deal with in terms of long-term changes. This is the case, for example, for the city of Zaragoza where they changed the whole back end of the infrastructure of the city administration. Indeed all the servers were migrated to Linux and everything was moved to Open Source.

All of this refers to setting up a project office which is one of the recent recommendations of the European Commission and then looking at how to get the public administration to become a member of communities and working with them. This is strange because 15 years ago, the European Commission commissioned a report on public administration being a member of the community and it’s still very rare to find. There’s lots of it happening but given the size and the amount of budgets, technologies of entities, and public administrations, it’s actually comparatively quite small.

What we’ve been trying to do is just to set up some policies and procedures : which is a top down approach. This is a good approach but doesn’t necessarily give impetus to changing the way things happen. But at least, establishing a position is important and that was what Barcelona did three years ago with the Open Source, open, ethical digital standards and promoting Open Source as the the primary way of developing and procuring code. But internal work is also important, like setting up some roles and procedures, verifying that the projects they are using are compliant, seeing how to contribute as much as possible, defining how to upstream as much as possible, training staff and promoting a culture change. This is quite complex but there’s different activities in terms of slowly bringing the current status or the modus operandi of the public administration from one way of working to another way of working, changing the processes and training people.

Setting up a project office is one of the first tasks because it supports and creates a champion and sponsor. Internally, it creates a point of contact to talk to for the staff but also for the external people. It also creates a sustainable institution inside the public administration which will maintain sustainability. Indeed, public administrations change every four to eight years and change of boss, of procedures and everything is a nightmare for sustainability.

Barcelona Free Software Management Guidelines

More than two years ago Barcelona published its Open Source framework and ethical guidelines. Within that framework, one of the documents was a complex guidebook on managing Open Source projects, procuring, managing and distributing Open Source. This initiative comes from the public administration which consulted Open Source experts. I did a little bit of help on the legal side but colleagues in Barcelona working in projects like [Decidim](https://decidim.org/) also gave a lot of input. Indeed, Guillem Marpons, who was the president of Decidim, is the author of these guidelines. These guidelines are online on Github and under an Open Source license which allows them to change and be adapted. Basically, it sets out some principles and guidelines for public sector information technology departments on how to work with Open Source. There is a series of measures which are binding and recommendations which are best practices in relation to the different scenarios and different aspects of all projects. We tagged six use cases : integration : integrate existing components. It is necessary to install a new system that can be built on the basis of existing components. adaptation : modify an external component. Features need to be added to a component that is already available, or it needs to be improved by solving defects, adding translations, etc… creation of plugins : expand a platform with plugins. New components need to be created that can be integrated into a platform or framework available and which facilitates this task. build of new product : create a new component. A new solution needs to be created from scratch. publication : publish code from an existing own component. We have our own code, developed under previous contracts and never publicly distributed, and we want to make it available in a public repository, under a free software license. documentation : we have documentation that is not directly linked to a piece of software but we want to make it freely available in a public repository.

The measures are spread out on these different use cases and we divided this in the timeline. So people can observe which measures are relevant at which phase of the project because for each project there’s something like 40 different measures so it’s difficult to know where to start. So we had looked at four phases : preliminary design : measures to take into account when drawing up preliminary designs. procuring inbound : measures to take into account when drawing up the service procurement specifications day one : measures to be applied from the first day of the development stage release : measures to take into account when a new version of the product is released

For example you can filter the measures and recommendations according to a project’s advancement in order to see what you have to do at a specific time. For example, on the first day of a new project which involves Open Source, set up a repository, have a Readme file, etc.

Another example can be measures in the area of procurement for collaborative development. In this case the first measure is to award the contract to companies with experience in collaborative development. This would mean that when you’re tendering, giving points to the entities which can prove that they work on a collaborative basis is really important. The alternative here would be to enter into a subsidiary agreement where an external consultant comes in and helps out managing the project in an Open Source manner.

On the legal aspects obviously there’s the ownership question, that is define the owner of the code which is developed for the administration (the city, developer, how ?), the questions about which license to choose and how to put all the legal information in the repository, etc. So it’s like a kind of a handbook for setting up and running an Open Source project.

Conclusions

To conclude, industry is farther ahead than public administration in some areas, especially in quality. It has noticed and perceived the greater economic interest in working on Open Source. We’ve been repeating for the last 15 years that there are huge economic savings to be done in Open Source and we’re still finding public administrations trailing far behind in levels of adoption but we’re getting there. So there’s a lot to be done but we have these best practices and these tools. There are even computer tools for supporting it. A lot of the work is about change management and changing the way the internal I.T. departments work with projects and how they manage going towards agile methodologies, open and collaborative environment development. They’re mostly sponsoring projects rather than procuring projects and this is a real challenge, but we’re getting there.

JOINUP – The Licensing Assistant – Patrice-Emmanuel Schmitz

Patrice-Emmanuel Schmitz is a lawyer, ICT practitioner and legal expert in the framework of www.JOINUP.eu. He will share the JOINUP Licensing Assistance (JLA) initiative made available by the European Commission in order to ease and secure the use of Open Source software within public administrations.

Context

JOINUP is a tool that was presented a little bit more than a year ago during the previous EOLE session but it was then a simple project, a simple draft. Now it is an operational licensing assistant tool developed by the European Commission and entirely based on European Commission software. It is now running.

The problem

To make a tool you have to have a problem you intend to clarify. In this case, the problem is that there are too many licenses. Indeed there are more than 350 models in the [SPDX](https://spdx.dev/) repository. Some other analysis tools list up to a thousand licenses. For example, there are 1700 in the scan code tool from NEXT. Currently, there are some tools but no license analysis tools that focus on compatibility issues or that provide content-based license selection. In 2004, the Open Source initiative (OSI)] reported that license proliferation increased problems in compatibility. Moreover, developers are restricted in combining different software. They can extend independent software but combining creates compatibility issues, which means a lot of problems. Most of the tools currently analyze what the recipient can or must do and only that. Also there are many tools : choosealicense.com, openaire.eu, clipol.org, tldrlegal.com etc… So we had the idea to develop JOINUP and to make it easier for the user by extending the taxonomy, extending the analysis and by focusing a little bit on combining software.

Combining software

Combining depends on two criteria or factors. The first one is compatibility, which is the permission to merge code covered by various license in order to create a bigger result and with the permission to license and distribute this bigger result under a secondary license which is not always the same as the primary license. The second important factor is interoperability. Interoperability is a legal concept defined in the 91/250 directive which was recodified in 2004 (but the original text is still the same). It is the ability to exchange information between different independent programs and for that, the reproduction of interface that are defined as as the part of the program which provide for interconnection. This reproduction is authorized as a copyright exception meaning that no license, even a proprietary license, may restrict the legitimate license to construct interoperability between two programs by reusing interface (API, data structure…).

Joinup Licensing Assistant (JLA) categorisation, with contextual help

Finally we added three main criteria which are compatibility, legal aspects (what is the applicable law), and also the support provided by the community and the recognition provided by the big free software organizations like the OSI and the Free software foundation (FSF). These define the taxonomy that we use in the licensing assistant. We have six main categories: can, must, cannot, compatibility law, and support. We have more than 40 attributes or sub-categories and each one is explained. If you roll over any of them with your mouse, you have an explanation of what each one means. This is certainly not a perfect taxonomy and it will certainly be changed or undergo some evolutions but it’s already a beginning.

Moreover inside the tool, there are 51 analyzed licenses, which is already more than in many comparable tools. The tool will not cover all licenses because it will not be useful, but we will cover the most important and commonly-used ones. With this taxonomy, the first thing to do is to select a license based on the content you are dealing with, and then you can select many criteria. So if you select more criteria you will have a reduced result and if you select all the criteria the result will be zero at the end. However, it allows you to make a selection using the six main categories about any of the attributes. Once you have a selection you can also get a summary of the license and receive a brief analysis which is an original analysis. In addition you can make a selection based on the SPDX identifier and receive the text of the license. We did not reinvent the wheel because there is a very good repository in the SPDX project so there is a direct link to SPDX where you can read the full text of the license.

JLA Licence comparison

In addition to the selection we added a comparison. For comparing licenses, before or after you have made a selection, you can compare up to five different licenses. Why five ? Because of the readability. We can add more but then the screen become too small to read the comparison. So it’s possible to select up to five licenses and then there is a side by side comparison of all the licenses on your screen (for example a comparison between the AGPL the EUPL which says that some license are convenient for software as a service, some are mute on that point, etc.

JLA Compatibility checker

Another functionality that was added recently is the compatibility checker. What happens if you combine or merge code from two different components ? Under which license can you distribute it ? For that, we ask the user to select the inbound license, which is the license of the component that is used, and the outbound license which is the license planned for the distribution of the combined solution. As soon as you have selected the two licenses for comparison, the compatibility check button is activated. If you press the button you receive a brief analysis of the compatibility between the licenses you selected. Finally for the terms of use which are very ambiguous, we make a distinction between normal use and private use, with use defined as linking statically or dynamically between the two programs, which differ from use by merging different code.

In JOINUP, we receive about two to five legal questions every month for more than ten years now so it makes a legal base of about 300-400 questions. Based on that and on analysis, we managed to make a small expert system that can answer the most frequent combination cases and checks compatibility. Of course, there are disclaimers because this is not legal advice from a legal expert : it is not an opinion of the European Commission. It is just the result of that knowledge base.

Conclusions

Certainly it can be improved and for that there is a possibility to contact JOINUP and to express some concerns or some remarks about the tool and the solution. So the analysis will be improved in the future.

The source code of the tool is Open Source. It’s distributed under the EUPL license and available on Github. The tool is part of ISA program which is driven by the interoperability unit at the European Commission. So that’s evidence that interoperability is very important. For us it’s a word that you will find in nearly every communication made by the Commission. That’s the reason why it’s so important for us to make public sectors interoperable and working together across Member States and across borders.

Q&A

The tool described by Marco is for technical assessment. How far are the legal aspects considered in the assessment tool or in the assessment ? For example, how much is the license of the selected software permissive, compatible and interoperable ? Because i think these are aspects organizations like the Anti-Corruption Agency could have considered when selecting software ?

Marco Conoscenti: Regarding licenses we included it as a cost in the TCO. So if the software has particularly expensive licenses, the software will hopefully be at the lowest position in the rank produced by our tool. Another aspect in some way related to legislation, is that there is also a cost that considers the compliance with the legislation. So this is another cost that is considered in our procedure and will have an impact in the comparison.

You consider the licensing cost but perhaps not enough the fact, by selecting the software, that the license provides you the permission to redistribute and under which license. The Anti-Corruption Agency has a recent issue about that when distributing its own software because they had software under the AGPL license and they tried to distribute it under another license.

Marco Conoscenti: The guidelines say that public administrations searching for software have to look at Open Source software that can also be reused because there is a portal in Italy that is called [Developers Italia](https://developers.italia.it/) in which the public administrations upload the software that they use. They are incentivized to consider software that can be reused. So they can upload to their portal so that other public administrations can use and share it.

Malcolm Bain: This has been mandatory in Spain since 2010. Public administrations must look at open existing repositories before issuing any procurement for any software. The central government has a portal called the Centro de Transferencia de Tecnología (CTT)] which has eight projects. I think Barcelona has more public projects in Github than the CTT in centralized government so a further federated system of public code like JOINUP is really very welcome. And what we recommended in the Barcelona guidelines is that when the law says they must consult public repositories for existing solutions, it doesn’t just mean public repositories it also means Github Sourceforge, JOINUP and any other repository where code is publicly available. And this should be a mandatory step as part of the procurement process and the basis for canceling a procurement.

Benjamin Jean: There is a need for each public administration to have a database or just a list of such unique access points in order to know if there is already something which exists and what are the checklists they need to follow in order to do things right. In France we are doing interesting things in order to pool resources from different local authorities, but we don’t have yet a broader view about what is happening in Spain or Italy or in other countries so JOINUP is maybe the right place.

Malcolm Bain: I think we should sponsor a European project for developing an artificial intelligence for a code searcher so that you can plug in your required functionalities and which crawls all the open public repositories and comes up with a a list of suggested solutions.

In terms of feedback and understanding how much is the tool is being used, do you have a system set up so that you know if people are actually using the process and the tools you’re suggesting ? Is there a mandatory information process ?

Marco Conoscenti : Actually I’m not so able to reply maybe you should ask this question to […] because we were just asked to implement the tool and just do a short evaluation after the collaboration ended. So I don’t actually know the state of the tool now.

Malcolm Bain : That’d be interesting because we were looking at the transparency obligations of public administrations to force them to publish the pre-bid documentation. The idea is to show that they’ve done the evaluation that they are supposed to do. And I have not yet seen any transparency portal of a public administration when it issues a bid for technology acquisition. It publishes the bid documents, the tender, but it’d be interested to see if they publish the previous materials that they are required to. Under Spanish law, public administrations are required to make this internal evaluation of existing solutions.

Benjamin Jean : We have the same advice saying that before asking for any software even open software, you need to do a benchmark, not just an add. So they’re expected do it but they don’t share it now, even it would be really useful for both suppliers and more globally for society.

Discussion about the manifesto

Malcolm Bain : The Manifesto was part of the package when we were working. Paulo was advising us with Richard Stallman and other clever people. Unfortunately it came at the end of the mandate and it got overtaken by other events as is what often happens with political changes. It’s a Manifesto in favor of the use of Open Source and it’s a political statement for a free software foundation in terms of political freedom. I think it’s a very useful grounding or philosophical basis for then establishing policy and implementing tools and practices. It’s practical and says: these are our values, this is what we want to do and this is how we think it should be implemented. So it’s a tool but at a more philosophical and policy level rather than a practical tool like what Patrice-Emmanuel was showing us.

Benjamin Jean : In France we have a situation where local authorities might be interested in the same things because they want to build digital tools which are open and sustainable. But the way it is drafted is really political so it might be signed only by local authorities who have this understanding, and it’s just part of the French administration which are using [missing word] structure. But it’s a good starting point.

Malcolm Bain : One of the missions I’m working at now has a very practical approach. Indeed, I’m looking at helping a specific public administration to open up projects as fast as possible and in the best way possible. It’s a very agile basis of identifying the quick wins and the easy projects that are Open Source already but that the public administration is not [missing word]. What we’re trying to set up is a bit like Marco’s evaluation in terms of technology economics and legal, but not for procuring but for applying the same analysis to existing projects inside the administration. It’s a work in progress, we haven’t even really started and we are just thinking about it but not applying it. There’s much more Open Source being used by public administrations than the public administration actually knows and it’s a way of making this more visible and more open and transparent.

Should we reject projects or technologies that are not GDPR compliant ?

Malcolm Bain : That’s actually by law and technically speaking, public information should not implement any technology that is not GDPR compliant. The problem is usually that the GDPR compliance is not in the technology but in the way it’s implemented and who is taking care of the data and how it’s used. I think it’s a very strong argument in favor of Open Source that the tools themselves are transparent. It is for example the question of artificial intelligence and the black boxes. Open Source obviously brings full transparency on processing and therefore the public administration can do the right audits to be able to certify that it’s GDPR compliant (what data is collected, how the data is collected, how it’s processed, how it’s stored, how it’s transferred and if it’s been deleted, etc.). So I think it’s a great argument in favor of Open Source and a criteria for procurement and public projects but I don’t think it’s going to be a great way of filtering out proprietary bits. I mean the criteria is value for money along with additional criteria such as sustainability and openness.

Benjamin Jean : I think the only way to link GDPR and Open Source is by a common European law. That way, we’ll have the same need to apply and to be compliant with GDPR and to having a common Open Source tool in order to comply with GDPR. I would say it’s the only way because when we are assessing different Open Source solutions, GDPR or accessibility are very much part of what the organizations can do for the public administration and it’s not for the software by itself.

Malcolm Bain : I work with the [Cities coalition for Digital Rights](https://citiesfordigitalrights.org/) which was launched by Barcelona, Amsterdam and New York and which regroups many European cities and members. We are adapting the concept of the data protection impact assessment to a technology digital rights impact assessment. One of our digital rights is Open Source technologies. This is pushed by the UK which actually just Brexit but they are now requiring all projects to have a data protection impact assessment and publish it. We were trying to piggyback on that as a concept for doing an open technology impact assessment very much in line with what Marco is suggesting in this evaluation. So the the same criteria can be used in terms of understanding what the digital service does and how it’s implemented through open technologies.

Marco Conoscenti : In our tool there is an assessment criteria which is protection of personal data and it is obviously related to GDPR. So the public administration must reply to some questions like whether the tool actually uses cryptography for transferring data, whether it allows to delete personal data, etc. It’s just a small step but it goes into the direction of being compliant with the GDPR.