Abdelatif Laamrani
Lawyer at the Bars of Casablanca, Paris and Montreal
Doctor of law
What is the legal difference between ” Logiciel ” and “Prologiciel” ?
Generally, the IT contract connects a company, the SSII (or IT services and engineering company) and its client, another company which wishes either to acquire business software specific to its activity, or a generalized software package. This is why contracts relating to software are distinguished from those relating to software packages.
The software package is pre-existing, its implementation has already been carried out. It is provided to several people or several licensees, unlike specific software which is generally only licensed to a specific person, with some exceptions. This is why, legally, the software license is often granted on a non-exclusive basis and organizes the concession of the most limited possible right of use, while the software license is granted, at the same time, on the know-how that surrounds it, which is not the case for a software package license where the licensee can only use “mechanically” the said software package by following the instructions transmitted to it, without any specificity and without obtain special privileges. No personalized intellectual service is provided to the licensee who is generally confused with the mass of other licensees. From this fact arise the consequences on the delivery of the source code and on the precariousness of the rights on the said code for the licensee.
How do you know who owns the source code?
First, it is necessary to define the source code. By definition, source code is the description of software in a human-readable form in a computer language, code that is then transcribed into a computer-readable binary form, the object code. The latter is therefore a set of instructions in the form of numbers directly executable by the machine: it is more precisely the language used by the machine to execute the program. Source code, a programming language, is essential for understanding how software works and for modifying it. However, presented as such, it is not understandable by the computer. This is why it must be “converted” into object code: such a process is called “compilation”.
The source code belongs to the owner of the software (i.e. the licensor) who of course has his copyrights, which he can assign or rent or concede to the licensee, for compensation. Hence the importance of properly drafting the clause relating to source codes in the IT contract.
Precisely, what are the rules to be respected and the risks to be avoided in the drafting of this clause?
As a special piece of software, the fate of the source code deserves a lot of attention. Indeed, it represents more than a simple text because, without it, it would not be possible to understand the operation of the software. It is a kind of “right to understand” which must therefore be provided for in the contract in order to allow the licensee to use the software with efficiency and performance. Therefore, a clause will be specially provided to organize the “communication” of the source code to the licensee and to guarantee the use of the software over time. It should however be emphasized that the mere fact of making the source code available to the licensee does not mean that an assignment of copyright has been made. This is why the contract must provide for the consequences of failure to deliver the source code, implying that the licensee has not been granted the right to modify the software, an important right in this respect. If he modifies the source code without authorization, he risks being sued for infringement (because he would have broken into the property of others, by forcing the lock). Hence the interest of warning the licensee of the consequences of such actions.
In the event of refusal of access to the source code, blocking of the system or even liquidation of the licensor, what could the licensee do?
In order to guarantee access to the source code in certain circumstances, in particular in the event of the impossibility for the licensor to provide such access or refusal to guarantee the software (for example, in the event of a breakdown blocking its operation), the parties shall organize this discount. The assumptions, conditions and forms of this discount (listings, magnetic media, etc.), the terms of use of the codes, the version communicated, the associated documentation, etc. will be mentioned in the contract. The licensor may request guarantees from the licensee in return for this discount, such as a bank guarantee for the duration of the programs, as well as a confidentiality agreement.
But other solutions exist: one of a technical nature, this is what is called decompilation or “disassembly”, it is a question of translating a program from one language into another, more advanced, that is, to pass from object code to source code. Concretely, the structure of the software is “disassembled” to know and understand the data that allow its operation in order to ensure its compatibility with the interfaces of other software or computer devices. In other words, the goal is to allow the interoperability of the software with other software installed on the machine concerned and with the system itself of this machine, all of which must work together and without difficulty. The decompilation process is a part of reverse engineering and is permitted by law under strict conditions. It makes it possible to make software difficult to copy, the user having only a simplified and truncated version of the principle of its operation. The legality of this method has long been problematic and has generated much debate, in particular because, like reverse engineering, this process presents serious dangers for software designers, in other words, authors but also publishers. This is why the licenses contain very restrictive provisions regarding decompilation. This is also why the drafting or at least the revision of the source code clause authorizing decompilation must be done by a professional.
The second solution is what is called “escrow”. Thus, the contract may provide that the source code will be deposited with a third party such as a private organization – such as the Agency for the Protection of Programs (APP) – indicating the cases and the conditions under which the customer may have access to it. . This so-called “escrow” or “backup” procedure will consist in depositing with this third party copies of the software as well as the technical documentation used for its design/production. The deposit will be updated each time a modification or a new version of the software is installed by the licensee. Such measures are useful, for example, if the licensee modifies the configuration of its system and the software encounters operating difficulties that the licensor cannot resolve. Without help or reaction from him despite reminders, the licensee risks finding himself in a delicate situation. Thus, a cessation of activity of the licensor, voluntary or not, coupled with the absence of a successor, a judicial liquidation, a decision not to upgrade the functionalities of the software in the event of legislative or regulatory modification are all reasons justifying delivery of the source codes to the licensee. Jurisprudence admits in this respect that the latter may require their communication
