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 sixth webinar, which focuses on "Open Source Programme Office (OSPO) for public administration", has been facilitated by 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.
In previous sessions, EOLE took a dive into the difficulties of managing licensing, we looked at the difficulties of procurement and analyzed the challenges in managing and building community. In this session, we’ll be talking about the Open Source Programme Office (OSPO). It’s a trending term, not in the least because the European Commission’s Open Source strategy issued last year mentions it as one of the Commission’s action lines. It’s well past time that the Commission had an Open Source Project Office and it’s a great idea. We’re seeing that many cities and public institutions are setting up these project offices to help out engineers mainly but also people involved in adopting and disseminating, like business people and managers to understand Open Source, to use it and make the most of it. So it’s been happening for a long time and we’re coming to a moment where we’re actually trying to formalize this and use it as a useful tool for Open Source adoption.
What we want to focus on at this session is not just the general aspects of Open Source Project Offices but also the legal aspects, challenges, methods and tools. What can the legal community bring to the OSPO concept ? What knowledge needs to be acquired ? We will not just focus on law because obviously it’s a wider concept. There are many business, organizational and technical aspects, but what we’d like to try, is to bring to the forefront other legal issues. The actual commission document itself goes on to say that legal action needs to be taken in simplifying the rules about sharing and contributing to projects but also about gaining and sharing knowledge about the legal issues through these developing guidelines and best practices. One of today’s objectives is to see if we can build a small community of people around this to identify and to create the legal knowledge base.
This webinar was divided into the five following parts :
- 1. Gĳs Hillenius - Open Source Programme Office at European Commission (Belgium)
- 2. Leonardo Favario - Open Source Project Leader of the Department for the Digital Transformation at the Italian Government (Italy)
- 3. Philippe Bareille - Open Source Officer at Mairie de Paris (France)
- 5. John Whelan - ICT Commercialisation Manager at Trinity College (Ireland)
- 5. Question time
1. Gĳs Hillenius - Open Source Programme Office at European Commission
Gĳs Hillenius worked at the Open Source Observatory for about 14 years then moved to work at the Open Source Program Office at the European Commission in December 2020.
Open Source still is, and should be, a bottom-up process. It's really very widespread across the Commission that people who work in IT start using Open Source tools. We've been doing this for 20 years and you can literally find Open Source everywhere in the IT organization. I manage projects for the Commission based on an Open Source strategy. The Open Source strategy is basically a moment where the Commission leadership, not just the IT management but also the commissioners, start realizing that it is time for top-down support for this groundswell. This has been building for over two decades. It's already behind the industry; their top-down support for Open Source is completely a no-brainer. In public services they're always a little bit late, so it's coming now. In the Open Source strategy, we have identified ten tasks and two of the more pressing ones have to do with legal issues. One is to make sure that it become easier for Commission software to be published as Open Source. So the important thing here is to look at the way the Commission handles its information, its documents and its data. For this last category, there is already a legal process in place with the Open Data policy. It says Commission data should basically be shared as easily as possible and as widely as possible so that people can do with it whatever they want to do with it. This is the basis for the overall IP review of commission source code as well.
We're taking the data policy by basically using the same structure, the same source code and everything that comes with it. All should be made available as Open Source when this is relevant and when it makes sense for the Commission, and when there are no very serious security issues that might be a barrier. The other thing that happens there is that when commissioned Commission software developers use Open Source, and they use lots of it, they can find little bugs in the documentation or a little thing that they can fix. So we're going to make it easy for these bug fixes to go back into the upstream process. So these two legal changes are going to be in a new directive Commission decision for Open Source which we hope to announce relatively soon.
The other important thing that the OSPO is taking care of, is that commissioned Commission software developers are not really aware of the software development that's happening on other projects. This happens because the organization setup can create silos. So we have been put in place that for new IT projects that we're starting, everybody who has access to the development toolkit can have access to new projects. That means the documentation, the issues trackers, the bug trackers and the source code. For existing projects, we're encouraging everybody to share their projects as widely as possible but it depends a bit on the project. Some projects are ready for that and they're switching. Some projects are not ready for it because they haven't worked in this way ever and they realize that their code needs maybe a bit of a cleanup. So we're giving them the time to look into it and do that.
The skills of an OSPO are not necessarily new for public services that do Open Source. Things like IP clearance, procurement or contracting are things that public services do all the time. They've been doing that as long as public service has been around. What is important here is to have the necessary knowledge to make sure that the IP experts, the procurement experts and the contracting parts of the organization are aware of the differences when it comes to Open Source.
As an example, two years ago, the Commission got a big project FOSSA 2 that was given to us by the European Parliament. The idea was to try and find security holes in the Open Source software that the Commission was already using. One of the ways we did that was by organizing bug bounties. So we had an inventory done of all the Open Source tools that were around at the Commission, which is a really interesting inventory to look at. Then we selected with the help of the public, a bunch of tools that were very important to the Commission and to the public. Then we organized bug bounties on these tools. But we immediately ran into a legal problem because the Commission had never done bug bounties before. The fact that it requires reserving money that you might not spend doesn't work in the minds of most public procurement officials. So the trick for the FOSSA project was to talk with the procurement officers for a long time in weekly meetings so that the procurement people found a way to make it legally possible to budget money. It was then possible to not spend it, to use it for something else in the same bug bounty, or use it for something else in the same project.
Knowledge transfer requires people to have an eye on the entire organization. People in the OSPO should have experience within the Commission in this case. They should also have people in the OSPO that know what's going on in the Open Source world because you need to keep an eye on what's changing and what's current. That also means you need to be in touch with your peers. One of the suggestions for this session was : should there be a network of OSPOs ? The answer is clearly yes. I would expect it to become a natural thing because we need to work with our peers, we need to share our best practices and experiences. This is where we motivate each other but we're also making the same mistakes. It's the very best practice for us to learn from because the cheapest thing is to learn from mistakes makes made by others.
2. Leonardo Favario - Open Source Project Leader of the Department for the Digital Transformation at the Italian Government
Leonardo Favario works at the Department of Digital Transformation at the Ministry of Technological Innovation and Digital Transformation. The Open Source Competence and Reuse Center is formed both by the Agency for Digital Italy with Guido Pera at its head, and the department that Leonardo represents, which provides the technical support.
Legal situation in the Italian ecosystem
There is a primary law in Italy that is called the Code for Digital Administration which basically has two articles devoted to free and Open Source software. It was first published in 2005 and then the law evolved little by little over the years by trial and error, and seeing how the public sector reacted to it. However in 2018 the Digital Transformation Team and the Agency for Digital Italy understood that we needed something more. We needed to translate in some way what the primary norm was saying into something more practical, something that was easier for everyone to grasp. That's how the Guidelines for the acquisition and reuse of software in the Italian Public Administration were created.
The Guidelines are a practical tool both for public administrators and for suppliers and also maybe for free and Open Source developers. Those practical tools help the procurement phase and also help in the licensing phase. They provide recommendations in order to understand all the procurement phases : what needs to be done, how and in what order. They provide a lot of references to tools, for example developers.italia.it, which is a catalog of the free and Open Source resources. It contains a lot of software, libraries, tools and a Software Development Kit that allow people to interact with the public sector.
Novel processes (and challenges) for many public administrations
So this law and these guidelines introduce something more and new for many people working with public administrations. It's novel processes and novel challenges of course. So for example we deal with licensing. We also deal with community world which is not so straight forward for someone that has always been far from the free and Open Source world. We deal with that changes in the contracts and of course this implies a change in the procurement phases. So that is what led us to the creation of the first competent centers on reuse and Open Source.
Competence center on reuse and Open Source (CCROS)
The CCROS was started by the Agency for Digital Italy together with the Department for the Digital Transformation. We're trying to tackle all the issues and to provide practical tools and suggestions in order to help public administrations understand what they have to do, and then to put it in practice. For example, we identify models, we provide tools and we try to promote the idea of community and what community really means in the general Free and Open Source sector and ecosystem. It is something that can be seen as very foreign to the public administration. So it's a great challenge to merge the two worlds together. Then of course, we need to provide technical and legal support.
Starting with the licensing aspect, we have a lot of questions from public administrations when they develop a software from scratch. What happens when there is a fork ? What about modifications ? Beforehand, when they didn't even know that the Free and Open Source world existed, they didn't have this problem. In some ways they already had it, but many times they just didn't deal with it. With the new legislation and guidelines, you have to publish whatever you produce with a Free and Open Source license and whenever you modify it. So you have to be very careful about the licensing scheme you use. We call this the compatibility matrix : you cannot just pick a single license however you want, stick it into your code and then publish it. You have to be careful about it and you have to understand that there's a world behind it. So this is something that the legal office of the Competence Center is providing as a service to public administrations. And we really have a huge amount of questions and doubts about it. So it's an ongoing discussion. We also deal with infringements which happen from time to time. We see them on many different repositories where unfortunately the first step of asking for direction and which is the best license to pick was not correctly handled. So many administrations end up publishing software with some licenses that are somehow not really the correct ones and they are infringing something. So this is a great role that Competence Centers or OSPOs have to deal with. They have to provide this support because most of the time, this knowledge doesn't exist inside public administrations.
The second point is about communities. What we are trying to tell public administrations is that they need to understand what the community world means and they need to start embracing it. Because this is something that probably the law doesn't really explicitly tell. The law says you have to create your piece of software and then publish it with a Free and Open Source license. However what we want to do, is to start with an open by design approach. This means starting with a Free and Open Source approach from the very beginning. Then you don't only push your last commit out into the open but you want to create a community around it. Because community permits to tackle the issues, reply to the issues, you want to accept merge and pull requests and contributions from the outside world. This is something really hard to explain to the public sector because it's something that never really happened before on the IT and software world. It's something that we need to deal with daily and we still need to understand exactly how to embrace it and to let public administrations embrace it in the best possible way. Free and Open Source also has to do with governance in some ways. There are many business models and community governance model to think of. What we do in our conversation with public administrations is to try to underline all the possibilities that are available out there that have been tested and tried in the past by many Free and Open Source communities. Then we try to understand with administrations which is the best one that can fit their needs.
When we talk about community, we have two ways of displaying it. The first one is the intra-administration community. It's two or more administrations that form a community that deal with the same problems on a daily basis. This is the first type of community. The second one is the broader community. It is for example accepting contributions coming from the outside world from Free software developers that want to provide a solution to a problem. That opens up a new discussion because it's a broader community where you have to involve and include people coming from other sectors or other ecosystems. This is a great challenge.
One of the first issues we face many times is the concept of ownership transfer. The primary law and the primary norm tells public administrations they may have a contractor and a supplier that develop the code for them, but at the end of this process, the administration is expected to acquire the ownership. So there is an ownership transfer that sometimes goes back to the public administration. But many times, this is not a reality. What happens is that a public administration has the will and the right position to publish the code although this transfer ownership was not written inside the contract. It becomes difficult to go through it from a legal perspective afterwards when the contract has been signed and finalized. This is a slight challenge that we we're seeing and we're trying to face. Smarter contacts mean going open by design. We have to insert all these points from the very beginning in the contract so that it becomes easier whenever the product is delivered to publish it as Free and Open Source.
The guidelines really guide administrations through the procurement phases and the national Competence Centers are providing assistance both in order to understand how the different procedures may change, and how to optimize them. If we are able to understand what the requirements are, and we are able to have a global view of the requirements on the territory, we can identify public administrations that have the same needs. This means that we can optimize them and look for a sort of contract or community for them to produce something that is easily reused by the other administrations, and therefore not duplicate efforts and investments which would spend a lot of public money in the worst possible way. So this is something that the Competence Centers is also providing.
CCROS: The Vision
The Competence Center started in 2017 with the drafting of the guidelines and right now we are kind of the national Competence Center : the Digital Transformation Department together with the Agency of Digital Italy. The current situation is that we have public administrations that interact on a one-on-one, peer-to-peer basis with us daily. The vision we have is to move towards a more decentralized model in the near future, which means that we won't have to be a single Competence Center which also risks being a single point of failure. Instead, we should be able to distribute Open Source Program Offices all around the region. Why ? Not only because of decentralization but also because Italy is highly decentralized. We saw when we're living it day by day that the national requirements and vision in many ways are very different from the local ones. If we are not able to establish territorial hubs or a network of Open Source Program Offices throughout the country, it means that we'd have a different vision of the real issues that concern local public administrations. In our view we have to try to distribute this model all over the territory in order to have local Competence Centers that really fill the needs and are able to understand how to provide solutions for local or regional governments.
Open Challenges and talking points
One of the open challenges is establishing local hubs, which means better outreach and easier creation of communities and sharing of best practices and solutions. We have to be very careful with Open Source Program Offices that should be designed in a way that doesn't create a barrier for entry. If we design it in a way that is very bureaucratic, not lean or agile at all, the public administration may see it as yet another burden, difficulty or rock to climb. If we do it that way, we'll probably fail. But if we design it in a way that is very agile from the very beginning, very lean and very simple for a public administration to put into practice in order to create and form one of these hubs, we may reach our goals and have many different ones all over the territory. This will help administrators understand that this is not an issue, but rather a possible solution. This is something easy to set up that can provide benefits. Of course, a lot of distributing means having a trust-based model. There has to be a trust model to set it up and put it in place in order to have trust between your national administration and your local Competence Center or your local administrations and respective Competence Centers, and then between local Centers themselves. This is a good challenge.
3.Philippe Bareille - Open Source Officer at Mairie de Paris
Philippe Bareille is Open Source officer at Mairie de Paris. He is in charge of partnerships with Pierre Lévy.
At the city of Paris we are both users and contributors of Open Source. We developed a city services engine called Lutèce. We have developed it in-house for 20 years now. The first project was designed as a Content Management System (CMS) made to administrate the websites of the 20 districts of Paris. Over the years, as new needs came out, we quickly externalized a core project, made the CMS features available as plugins and moved on adding reusable plugins. Shortly after the project was launched, the newly elected council of Paris decided to promote an Open Source strategy for the city. They voted to share and Open Source the software that was developed by the City Hall. So they strongly believed that the public money should benefit other municipalities or administrations and therefore citizens who would only pay once for the public code. So the license we chose for the software was BSD, to facilitate as much as possible its adoptions, reuses, and contributions. Our goal is not to protect our code but to make it as easy as possible for anyone to join, contribute, read, and trust. Since then, the city of Paris has continuously improved its Open Source software and at the same time has been making the source code freely available. The project now has grown a lot and it offers more than 200 digital services on shelf, more than 4.6 million lines of code and can be used to generate multi-step forms based on a powerful workflow engine. It also offers an appointment booking system, and a 3-1-1 type application to report non-emergency incidents in the public place. It's called "Dans ma rue". There is also a participatory budgeting tool that has been used to implement citizens projects which worth a hundred million euros per year as well a citizen relationship management system. All these are based on standard and reusable plugins which make a solid and reliable software for our municipality to use. So thanks to this strategy the impact of Lutèce has gone beyond Paris and France's borders.
Even without a so-called OSPO, we've always tried our best to promote our software, foster the use of Open Source within the city and join Open Source programs every time our needs match with an Open Source software. That's how various institutions joined us in the development of Lutèce since it was released. Some came as users only and some decided to contribute back. We can also count on many people which form a whole community. For example we can count of the very helpful contributions of the Bloomberg associates for marketing and consulting on the product which make it more visible within cities around the globe. We're on the board of the 0W2 consortium that helps us scale, valuate and promote Lutèce throughout Europe. A few years back, Moss Labs came to us and connected us to Baltimore institutions in the U.S. such as the Johns Hopkins university, which featured Lutèce at their HopHacks Fall 2018 hackathon. That provides a team of researchers as well as students to help us do some translation and we'll soon deploy an instance for a local non-profit community-based organization with Lutèce. Another example would be more recently with the city of Budapest, Hungary. The city came and saw how we implemented our participatory budgeting solution in Paris. To learn and benefit from our six-year experience and launch their own, they decided to reuse our software. They hired one developer to implement the specifics and contribute back to our source code. So we shall soon have a bunch of plugins available in Hungarian. All this was made without an OSPO. But now that we have seen this tendency, we should institutionalize it.
Institutionalize this tendency
There are different ways of doing Open Source. Organizations may implement agile project management differently. Danese Cooper says that Open Source can be done as a noun, which only relates to the code and as a verb, which is how you use it. To successfully Open Source your code, it's not enough to just make it available under an Open Source license and publish it. As a verb, Open Source is about method and community management, openness, transparency and bringing trust between citizens and their administration. So as an example, Red Hat OSPO doesn't do the noun. When it comes to compliance, they have another department that deals with legal matters and that takes care of it. American Airlines OSPO does deal with both licensing and compliance. So when a project is led by operational needs it does open code but not Open Source. This is what we are currently focusing on. So in the public sector there aren't a lot of examples and more specifically in the municipal context of OSPOs. We've been doing Open Source for 20 years, trying to gather a community of users and contributors until it is self-sustained, because managing such community takes time and our community is still growing to reach it. At least with a BSD license, we hope the legal won't interfere with its growth.
Now there are other projects we are building too. One called Botalista, which lists and makes a whole database of all trees and plants. We're working with the cities of Geneva, Bordeaux, and others to contribute to that project because as users feel like we have to contribute back to it. There's another one called Espace Numérique de Travaille (ENT) which is like an open classroom which more than two and a half hundred schools are using in Paris. We're part of it because we need it and we need to implement it to be part of it. There are other projects to which we contribute and where the legal is actually handled by the managing entity. As a municipality, were not focused on sales, but we're focused on the benefit for our users, who are also citizens, and an efficient stewardship of public money. So we fully expect that we'll have to deal with a noun. It's on our roadmap but our pinpoint right now is that the verbs partner, build a sustainable community, call for action, community management and grow together. So thanks to the work of the OW2 consortium we will soon also rely on their good governance initiative which is a blueprint to build our roadmap based on goals such as usage, trust, culture, engagement, Open Source strategy, supported by activities and verified by scorecards. We needed that frame, which is a more practical and institutionalized way to set up our OSPO. At this point, we need other cities to come together around this initiative and this is why we were very excited to read the OFE study that recommended the European Commission help build 20 public sector OSPOs. Paris would be very happy to be part of this if it's implemented. In our opinion, this will bring together municipalities to the table as well as work together, share our needs and help in workshops, but it also permits to share the risk because it's all about that.
4. John Whelan - ICT Commercialisation Manager at Trinity College
John Whelan works at Trinity college in Dublin.
We have recently formed an Open Source Program Office (OSPO) but we've just put what we were doing for many years under a new banner. Trinity College is very much in favor of promoting innovation and entrepreneurship. We would be the top university in Europe in one measure in producing entrepreneurs. There's a survey of data that comes out from an American venture capital database called Pitchbook. It ranks universities by the number of their graduates that raise venture capital or private equity. We're the only European university that appears in the top 50. We're the number one for that.
We're coming from knowledge transfer and technology transfer. Traditionally people would have viewed us as being kind of anti-Open Source to be honest, but I come from a software background. I used to be a software developer and I had a number of software startups that raised venture capital. And I was using Open Source in the real world before I came to work in the university. I think that experience really helped us to see that it is a valid way of doing business. Free and Open Source doesn't mean free commercially, it means free to use. This is the point that's often made and people need to understand. About the academic implications of Open Source, it is a fact that universities own academic research publishing. When you look at Covid, everything that comes out is verified by peer-reviewed journals and they're curated by universities. Universities have been doing this for years, but they do not own software publishing. Academic institutions have been doing this for years but they do not own software publishing. Companies own that and the community own that. So we need to engage more with the community of software developers that are out there in industry, in startups and people working on Open Source from their own homes, not just researchers.
Trinity Open Source Experience
In practical terms, our office is all about commercializing research, forming campus, companies, spin-outs, and we've had a lot of success with that over the years. Back in 2012 we had our first campus company that was based solely on an Open Source business model : Software Radio Systems, a software radio platform. The Irish government had put a lot of money into the development of this system, and for me to push for this to be Open Source was, to be honest, a little bit of a struggle. It took some convincing and I had to prove that the business model was valid, but that company is doing very well at the moment.
More recently another company called TerminusDB came out of a European Horizon 2020 project. It's a non-relational database, but it has been Open Source from the very beginning to compete. These two areas, telecoms and non-relational database, are areas where Open Source is really making a big difference and it's really important. Particularly in telecoms, where it's so fragmented and now that software has become so important because it can control 5G radio systems, we have to drive it from an Open Source perspective.
Another deal we have done is that we sold some IP to Google a few years ago for Android audio, and this was all based on Open Source even though we had patents. We could talk a lot about how Google and other big multinationals are engaging and working with Open Source because it's kind of tricky. Another success story is Zorin. It was created by students in Trinity, two Ukrainian brothers, the Zorin brothers. It's a fork of Linux called Zorin OS. They have 15 million users and they have 1.7 million downloads just a few weeks after their latest version. It's a dual licensed model and a lot of cities are actually using it as a Linux fork.
We've done a lot of dual licenses. People do come to us. For example, we worked on part of a big GPL project, but we did one component of it. We did say for this component that it was available for commercial license, and people do come and contact me out of the blue and we have done commercial licenses for this. We did one commercial license.
What not to do
We would see ourselves as both being supportive of Open Source, but being compliant with the grant conditions that are applied. We try to explain to the agencies that are funding research how Open Source can be a valid model. Many researchers and developers don't understand the legals and they think Open Source is free and you just give it away for free. We have an example of one of our research projects from 2003, where people put up the software, download it, and use it and they say it's free. But as we all know from a legal aspect, it isn't free because there is no license attached so the copyright is held by the institution and the copyright creators. In this case, a well-funded US startup contacted us and said they wanted a license to this 17 years later. People have come to look for a commercial license for this software even though the researchers thought that they were making it available for free. So our challenge is to educate researchers so they know to avoid this. A lot of people put stuff up in Github with no license and think that it's legally correctly managed, but of course as we know it isn't. In our office we also often look at things that companies say are dual licenses, but haven't done properly and that could mislead developers.
Do you think it would be feasible to build a network of OSPOs ? And would it be useful to work towards a kind of legal playbook of the common challenges, common issues, good practices for dealing with this ?
Leonardo Favario : From my perspective definitely yes. The point is that there are a lot of resources available on the web. So I think we should start by collecting them and trying to shape something. Then we should try to publish it Open Source way and then see suggestions and comments. This playbook could be a great resource. Of course we need to translate it in all the possible languages because that could be another barrier.
Philippe Bareille : There are many projects we contribute to and where we leave the legal issues to the either entrepreneurs or the leaders of the projects. But it's not because we don't care or we don't want to face it. It's because we think it's suitable. We agree with the terms of reusing and with the terms of the licenses chosen by those entities. For our development work we've chosen the most open one to reduce that barrier for contributors or potential contributors. But of course we would need help and I think we would need an entity, some kind of institution or organization which would be able to gather cities like us that share the same vision and philosophy of doing open things. So it would be very valuable to gather those cities because we share the same needs, will and philosophy.
There's a lot of questions about what license to use. Is that something where we can help as a legal community ?
John Whelan : I think, and this related to your last question about a framework or a playbook, it's all about communication. To software developers, if you call it a legal framework they're not going to read it. But we could learn a lot from Creative Commons and the way they communicate and the way the license chooser is put forth. It's quite simple and yet it's quite complex too. So some model like that could be developed by somebody or by Europe. The compatibility matrix, as Leonardo said, is a good way to communicate with developers. You just have to think like developers, respect them and show the openness. As you said it's about people and we're not the big bad technology transfer administrators. We believe in the power of Open Source and we're part of this movement. We want to help developers and work with them but it is important to be careful and explain why because of what can happen.
Do you have a license chooser support tool in JOINUP ?
Gĳs Hillenius : Yes ISA has done a tremendous amount of work to help public administration on this topic from inserting texts into procurement proposals to come up with a license compatibility check. At the Commission, we have our IP experts who can walk us through. I think in the Open Source space it's actually a lot easier to deal with legal issues. And I agree that it would be good to have a cookbook or a common approach. But I expect that this will happen over time. Because it is a lot easier to do it in Open Source and actually the only possible way to do it is in the Open Source space. The license compatibility index was built with a whole bunch of experts in this field. I wasn't really involved in it directly. I'm assuming that it is being used in communicating with member states because that's what ISA does. They bring their projects to public services across the EU and then this is one of the things that they're going along with.
Are your OSPOs actually thinking about setting up the infrastructures and the tooling for doing like code scanning, license scanning and all things like this ? SPDX editing tools and things like this ?
Gĳs Hillenius : Yes this is what we're doing at the Commission.
John Whelan : To be honest I didn't know there were Open Source because years ago we did look at a commercial one. Universities work with this concept of invention and software disclosures. In our software disclosure system process we ask about Open Source but it's just down to the researcher. We don't use tools. We've had cases where we've had to swap stuff out. Usually it's something minor that if there's some GPL in there you can replace it with other things. Again it's about the culture of awareness.
A lot of people thought that just putting up the tools and knowledge on the web would create community but that's not true. As a legal community working with Open Source we can't just put things up on the web and expect that to create the right critical mass of networking to become a standard or to become a model. Do you think that's something on we should put an extra emphasis and not just expect that the community will manage itself ?
Leonardo Favario : Definitely yes. We've seen it also with the pandemic that communities are rising. They are slightly changing. I think that community management is really a key value here since we've seen in on our experience that if we don't have one and if we don't have this role defined the community has issues. Of course you have to push the community a little bit to create it and then at some point eventually it will continue by itself. You have to empower people inside in different roles and people can somehow find ways to keep the community growing. But if you don't push it in the first moments, that's going to be a little bit harder. What we did for example is that when it was possible, back in 2017, we had hackathons or events. Those were moments where people could see each other and work together on things. Then when the event closes you keep working on a virtual fashion. Of course right now it's quite hard to have physical events but we have to evolve and to try. For example I know many communities that do virtual events and virtual hackathons. That could be something that put people together to work on something and then the community will grow.
In some ways, Mairie de Paris is a local hub. How do you see the relationship with the national level ?
Philippe Bareille : Yes we're in touch with what is called the DINUM in France. It is the inter-ministerial institution for digital issues. They're more focused on the ministries and on larger local territories like regions. They don't get down to the city level. I know for a fact they're working with mayors of large cities in order to build a catalog of Open Source software for them to use or foster the use of Open Source. I know they're willing to establish an Open Source Program Office, but they won't gather cities in that way. They have way too much on their own plate for this and they welcome more large territories rather than cities. But maybe at some point they will. I know they're very interested in that OFE study too and with the Bothorel report.
John Whelan: Software communities by definition are bottom up and that's the challenge facing governments, agencies and the Commission. You have to find some middle ground and it's not easy. In Ireland we don't have a responsible agency within the government, but we're looking at it actively. There's a steering group I'm in involved, but it's political to find where it will sit, it might be Knowledge Transfer Ireland, but we have to wait and see.
What do you think will come in the next year, and what's your wish list for promoting OSPO ?
Gĳs Hillenius: I would really love to see published work that I and Jean-Claude wrote. We are working on guidelines that will tell people inside the Commission how to apply the new IP regime that makes it easier for source code to become Open Source. We're going to explain the steps that they have to go through. This is not complicated stuff but just one or two steps that they have to do, think of, and check to make sure that we pick the right license and the security check. They describe also where to publish it and where do you put the license information and if you want to use a copyright statement. It would be great if that document became public by the end of the year.
Leonardo Favario : I think free software is vital for the public sector as a whole. So I'm curious about the OSPO word because I'd like to see it transition from being a buzzword that we are hearing right now to a pilot phase. At least this is what we're trying to do in Italy. We would like to really define some pilots, test it, and get feedback. I think that in this case, we really need to go through all the trial and error phases and quickly challenge ourselves and try to patch the issues and see where we're going. So my wish for the future is to test it in reality and see what happens.
Philippe Bareille : I think the elected officials need to engage because we're at their service, implement their projects and their vision. We need a reliable and long-term vision from a team of elected officials that are not necessarily following a political agenda. They need to be transverse. No matter who has the power at that time, there needs to be a neutral mission built to implement some kind of Open Source for public good. A philanthropic mission that would actually take care of implementing these directly from top to bottom. Even though we know how correlated it can be with politics, I think they need to see a long-term vision and to have us implement that long-term vision.
John Whelan : I think it looks very complex but there's an opportunity in Open Source hardware for Europe and also Open Access publishing, Open Data and Open Science. Again for a research institution, Covid has really thrown up huge opportunities in Open Science and I think that's going to really help Open Source software. But there still has to be money coming from somewhere. That balance is the challenge.