try another color:
try another fontsize: 60% 70% 80% 90%
Institut für Rechtsfragen der Freien und Open Source Software

The right to fix software and repair hardware

by Florian Idelberger

Two interesting developments regarding the right to repair took place recently – a request for a preliminary ruling (Working Document) was brought before the Court of Justice of the European Union, in January in which the court is asked to clarify Article 5 of Council Directive 91/250/EEC regarding decompilation to fix errors in software or disable certain functionality that is malfunctioning, and in a recent issue of Jipitec, the anti-competitive impact of software TPMs (technological protection measures) preventing repair by third parties or consumers was analysed. Both these instances are not directly connected as such, but they highlight ongoing legal uncertainty and potential hardship in applying the law on software licensing in specific cases such as repairing systems that employ TPMs and fixing software using decompilation tools or similar measures.

In the court case, where Selor, a body for selection and applications of administrative staff, used a system designed by ‘Top System’ that develops programs and has developed its own ‘Top System Framework’, and Top System had developed Selor Applications that used the Top System Framework. Due to a string of problems, Selor decided to try to fix the app itself. Top Systems noticed this, and after evidence was recovered, Top System filed suit before a Belgian primary court, asking to find that exclusive rights were infringed and this constituted counterfeiting of a work and to order compensation. This was ruled unfounded, so Top System appealed. The Belgian Appelate court, then referred to the Court of Justice and asks

Is Article 5(1) of Council Directive 91/250/EEC 1 of 14 May 1991 on the legal protection of computer programs to be interpreted as permitting the lawful purchaser of a computer program to decompile all or part of that program where such decompilation is necessary to enable that person to correct errors affecting the operation of the program, including where the correction consists in disabling a function that is affecting the proper operation of the application of which the program forms a part?

In the event that that question is answered in the affirmative, must the conditions referred to in Article 6, or any other conditions, also be satisfied?

In effect, the Belgian court is asking in how far Art. 5(1) of the Directive allows for compilation to fix errors or even disable functionality, and in how far the conditions of Art 6 must also be satisfied.

At issue is first whether under contract law Selor had the right to the sources, which it only had partially, and it claims in the contract Top Systems waived the exclusive rights, whereas Top Systems disagrees and makes a distinction between the applications and the framework, arguing that the Framework was not developed nor funded by Selor. The court of appeal notes that not the entirety of the source code was delivered, but Selor should have put Top System on notice before taking any actions on its own.

Regarding decompilation, Selor claims that pursuant to Directive 91/250 it was allowed to correct errors, and to observe and study. Top System on the other hand claims that first here were no errors, and that the Directive only allows decompilation for study or maintaining interoperability, not to correct errors. It asks for referral of the matter and furthermore with regard to Article 5 (3) of the directive, Top System makes a distinction between ‘testing environment’ and ‘development environment’.

The court of appeal finds that correction or errors would not be permitted by the directive, contrary to what was found in first instance. At issue is then still whether the Directive as transposed into national law allows the use as it supposedly

“permits all of the acts contemplated by Article 4(b) of the directive to be carried out and thus, in addition to translation, adaptation and arrangement, ‘any other alteration of a computer program and the reproduction of the results thereof.”

The court of appeal further found that the actions went beyond Art. 5(3) as that pertains only to observing, study and testing. Neither wording nor case law is found to be sufficient, so it is asked how to interpret the articles.

Leaving aside potential contractual provisions and arguments, let us focus on the Directive and its interpretation here. First, it is doubtful if some of the textual interpretations here can be adequately resolved by a court, or how they even could be adequately be resolved by a court – most prominently whether a work environment is a ‘testing environment’ or ‘development environment’ as often they are probably one and the same.

The situation is indeed uncertain, in so far the court of appeals is right. (though a different court still might have decided not to refer) Reading the provisions, there is no connection between Art 6 and Art. 5. In many legislative documents, provisions are linked explicitly or by structure, whereas here there is no connection such as referring back to Art. 5 or stating explicitly that it is restricted further. That is at least some evidence that these two articles deal with different matters, Art 5 with general exceptions, where error correction is allowed, and Art. 6 primarily concerned with interoperability of potentially competing products and due to this, restrictions are tougher there.

Assuming these articles deal with different matters, interpreting them such that error correction would not be allowed, even though explicitly allowed in Art 5(1), would actually put anyone not working towards interoperability (such as a licensee that just wants to use the licensed product) in a worse position than someone creating a competing product or otherwise falling under Art. 6 of the directive, which to me does not seem like it makes sense.

Linking back to TPM devices, the paper by J.D. Anthony Rosborough argues that the EUs software TPM framework restricts competition and thus helps to form dominant positions. Primarily, and this also links the two instances together, it focuses on the “inconsequential and distinct legal status given to TPMs which protect software from other types of works” (i.e. that software TPMs have a distinct legal status) and that hinder competition, specifically this also is partially based on Directive 91/250 as while decompilation is allowed for interoperability, the results may not be shared and this specifically hinders the distribution of circumvention measures and thus repair, interoperability and competition due to competitors and independent business offering services having no means of sharing knowledge. It would further be interesting to analyze this in more detail in regard to how the concept of interoperability is generally used in copyright and competition law in the EU and if looking at older caselaw can shed some light on likely outcomes.