Incoming rules on the security of IT products put free software at risk. The Python Foundation calls on programmers and developers to make themselves heard by Andrea Monti – Initially published in Italian by Wired.it
On 11 April, the Python Software Foundation warned about the consequences of two regulations the EU will enact: the Cyber Resilience Act and the Product Liability Directive. According to the creators of the language that runs a myriad of internet services and enhances machine learning, the development model based on code and information sharing, would be at risk.
The Cyber Resilience Act (CRA) and the Product Liability Directive (PLD) are two forthcoming European regulations that will revolutionise the world of security and software development.
On paper, they are well-intentioned measures: they stipulate —the former— that suppliers of digital equipment must guarantee, among other things, the security of the products they sell by carrying out vulnerability tests and making them available; and —the latter— that those who produce software are liable for damages caused by the ‘product’ (the reason for commenting the word will become apparent in a moment).
However, as is always the case in legal matters, the devil is in the details.
A closer reading of the CRA and the PLD reveals enormous criticalities, some of which directly concern the software development model that falls under the acronym FLOSS (Free and Libre/Open Source Software), the basis of the entire digital ecosystem in which we live and without which The Internet would not have developed to the level we know.
Article 16 of the CRA, notes the Python Software Foundation, states that ‘A natural or legal person, other than the manufacturer, the importer or the distributor, that carries out a substantial modification of the product with digital elements shall be considered a manufacturer for the purposes of this Regulation’. Consequently, concludes the PSF, any programmer who contributes to the development of software whose use is regulated by free licences becomes, legally, a manufacturer and therefore responsible ‘regardless’ even if he is not paid for the work he has done for the community. This conclusion, it must be added, is reinforced by Article 4 of the PLD, according to which ‘product’ also means electricity, digital manufacturing files and software, and ‘manufacturer’ identifies one who develops, produces or manufactures a product for his own use.
Therefore, assigning responsibility to each developer,’ writes the PSF, ‘would create less security, not more. Leaving individual and/or resource-poor developers in a legally dubious position when contributing to public repositories … would almost certainly discourage them. Only those who sell enough software or software/hardware combinations to absorb the consequences of product liability could continue to operate in the open. The user improvements and shared security benefits of global software collaboration would only be accessible to developers working for a few large companies. Growth and innovation would be stifled.
The problem is real, but the solution proposed by the PSF —not tout court to consider as ‘producer’ for the purposes of the CRA/PLA those who contribute to the development of FLOSS but do not use it commercially— does not solve the structural flaw of these regulations: the ambiguity of the legal definition of a computer programme.
To understand the consequences of this ambiguity, it is necessary to start with a consideration: FLOSS is based on the principle that the source code of a programme must be accessible and modifiable by anyone, and that anyone who accesses and modifies the source code must make the changes available under the same conditions. This is the so-called ‘viral characteristic’ of FLOSS, which, although varying according to the type of licence provided by the developers, guarantees the evolution and improvement of the programmes.
Like software in general, FLOSS is not ‘sold’ but licensed with an ‘as is’ clause, without guarantee. This approach is reasonable for ‘products’ that are free of charge and of which the source code is available; whoever decides to use it can verify any problems or criticalities before running it. On the contrary, when the software is ‘proprietary’ (i.e. it is licensed only in its ‘working’ version, without the ‘design’), the ‘seen and liked’ clause is less justifiable – nay, not at all. Any product, in fact, must meet standards of safety and security, and cannot be marketed if these standards are not met.
But, and here the shoe pinches, since 1991, i.e. when directive 250 was issued, the software has been legally qualified as the Divine Comedy, i.e. as a ‘literary work’, on the assumption that the object of legal protection is how a program is writte —hence, the source code— and not the result of its ‘compiling’ — i.e. the finished programme, ready to be used.
As a consequence, the software cannot be patented in the EU, and its sale is not subject to producer liability precisely because, according to the law, software are like a poem or a novel and not like CNC milling machines. However, ‘product’ and ‘literary work’ are two conditions that cannot coexist, so it is at least inconsistent that CRA and PLA do not consider this difference.
It has never been written in any book that ‘we do not guarantee that this work will meet the needs of all readers’ or that ‘its use is not permitted in activities that may endanger human life’; just as no machine designer has the right to object to the ‘mutilation’ of the work. So, on the one hand, it is undoubtedly correct to abandon the idea that software is a literary work, but this must be done in an absolute sense and not, as the PLD says, “for the purposes of this regulation”. At the same time, however, it is also necessary to recognise the cultural and economic importance of the production model based on the sharing of source code, which, as the facts show, has been and continues to be a fundamental element in the development of the information society.
Therefore, having established that software should be qualified as a product rather than “exempting” programmers from responsibility for what they invent and build, it would be appropriate to clarify that responsibility arises concerning the user’s ability to detect the presence of defects. In other words, there can be no product liability for those who develop FLOSS if those who decide to use it do so ‘blindly’, without being (reasonably) sure of what they are doing —a principle, moreover, already present in our civil code about the ‘defects’ of the thing sold. On the contrary, in the case of proprietary software, there should be total, presumed and ‘objective’ liability since the purchaser is not in a position to know (and above all, to prove) the existence of defects and their connection with the damage caused. It could be argued that it is unrealistic to ask end users to take it upon themselves to search for problems and criticalities in FLOSS, but this is not the case.
Furthermore, while it is true that there is no such thing as bug-free software, it is also true that not all defects cause harm and liability. The law should therefore consider only those defects that affect the fundamental rights and freedoms of individuals, companies and institutions. In practice, such a review could be carried out, for example, by independent bodies responsible for certifying the quality and reliability of FLOSS and proprietary software.
Another possibility would be to consider only the software in its executable form as a “product”, reserving copyright protection only for the source code. This would, in theory, make clear the difference between those who ‘create’ it and those who ‘use’ it or allow others to use it.
This, like the previous ones, is not a perfect solution. Still, it shows that there are alternative approaches worth exploring instead of writing rules that pay little attention to the cultural and social value of a massive knowledge-sharing project like the one built on the work of Richard Stallman, Bruce Perens, Eric Raymond and all the ‘visionaries’ to whom we owe all our gratitude for having contributed to creating an essential part of the world we live in.
The European Parliamentarians are probably unaware of the consequences that could result from the rules they will be asked to approve. However, it is not too late – there is still time, as the Python Software Foundation reminds us, until 26 April – to ask them to pause for a moment and think before they decide.