Not for the first time, there have been calls for open source regulation. Regulating open source software would be wholly inappropriate and would fail to solve the issues we see today. We need to regulate the use cases of software such as finance, regulated sectors, public infrastructure rather than the code. This regulation must apply to all software, not just open source. Proprietary code must come under the same levels of scrutiny.
Why are we here now?
The open source software industry has not only gone through a decade of mass adoption, but also a couple of decades of self-regulation and the creation of good practices culminating inthe Open Chain licence management standard and SPDX Bill of Materials standard being formally approved by the OSI. Microsoft’s Steph Walli is leading a work group building the same for community governance with IEEE.
Anyone with expertise in open source software and its governance will tell you that meeting the basic requirements of open source – putting code on a public repository like GitHub or Gitlab and applying an Open Source Initiative licence – is not really how you should go about open source software. Sadly however, this tick-box approach is what we are seeing in much of the public sector as loose ‘open source first’ policies are complied with, rather than with well managed guidance.
When a developer “scratches an itch” and creates some code to solve a problem, it’s likely many others will also feel the need to scratch that same itch too. Open source software in its true sense benefits from collaboration, community review and contribution, and this is what creates a great deal of the value that it generates. This is not achieved by simply dumping code in a GitHub repository. It is this collaboration and community that generates the best innovation. “Many eyes make bugs shallow,” as Linus Torvalds would say. That is what makes the problem go away.
This broader process of community doesn’t just happen either – it takes work and expertise. There will be a process of community engagement as well as the instigation of governance. This includes contribution and commit policies, gatekeeping, contribution agreements, and Developer Certificates of Originality for the code. Over time, this will expand to feature management and more long-term roadmaps. There is a huge amount of expertise around this here in the UK.
At a European Commission event in November 2019, I expressed the view that coding is like speech, and potentially should be protected as a freedom of speech. My main concern wasn’t the means by which the right and freedom to code is enshrined, but rather that there should not be restriction or regulation of this basic freedom. It was one of the few times in my life where I felt the overwhelming weight of approval of those in the room. This audience included multiple open source project founders, such as Gael Duval and many others from across Europe with deep understanding of open source. We have a real danger that regulators failing to understand these issues will actually make the situation worse, not better.
Why do we need more guidance?
Log4J is a common open source software tool used widely across the industry. The software vulnerability known as Log4Shell, discovered in late 2021, focused the minds of enterprises and Governments on how best to manage open source software. The US had already called out in May 2021 the need for a Bill of Materials through the Ordinance on Security of Software. The Bill of Materials approachsets out the code incorporated when open source is used.
In this instance, the big issue is not the vulnerability itself, but the ubiquity of the code. Log4J was used so widely that it affected millions. Well-managed open source software has good governance and its users know what they are using and where they got it, i.e. it will have been timestamped when downloaded from a repository and so can be maintained. The real issue with Log4Shell is where it has been used or incorporated without disclosure in proprietary code, and where users are not aware that they had this issue in their systems. This has flagged more than ever the need to have good practices and governance around how open source software gets used.
However, this is not simply an open source software issue. Let’s not be shy. We live in a digital world, which is software defined. We now need to manage transparency around that software. Of course that’s easier for open source than for proprietary code. The whole industry can benefit from the example of open source around good governance practices, and the use of software bill of materials will help in that regard.
We should also beware of those who benefit financially from proprietary software and closed standards /FRAND and Standard Essential Patent royalty revenues that are now calling for regulation of open source software.
A decade ago, I was the General Counsel of the UK’s leading open source company, Canonical. We worked hard to persuade people to adopt open source and to bust myths around risk. That has changed in the last decade. Like it or not, open source is the dominant software development approach today and integral to everything technology based.
Like the water flowing through the canals of Amsterdam there is no benefit in fighting it. The right approach is to work with it and manage it. In this case the canal walls of open source are the good practices and policies.
Amanda Brock is CEO of OpenUK
@amandabrockUK
