Protecția software-ului și regimul său juridic - Curs

Software-ul: particularismul său:

Știm că software-ul este un program trimis către un computer pentru a procesa informații. Principiul reținut de legiuitorii francezi și europeni este cel al protecția drepturilor de autor a software-ului. Dar software-ul trebuie să fie original pentru ca software-ul să fie protejat de drepturile de autor. Va fi calificat drept original dacă autorul său a demonstrat un efort personalizat care depășește simpla implementare a unei logici automate și obligatorii.

1: Protecție software:

În timp ce în trecut ne întrebam dacă software-ul nu ar trebui protejat de brevete, nu mai este contestat astăzi că software-ul este acoperit de drepturile de autor: particularismul său a fost consacrat într-o lege din 10 mai 1994, care transpunea în dreptul intern o directivă europeană.

De fapt, din hotărârea Pachot (Adunarea Plenară 7 martie 1986, D 1986, 405), s-a acceptat că software-ul era protejat de drepturile de autor. Întrucât tratatele internaționale interziceau brevetabilitatea programelor de calculator, SUA alesese să o protejeze prin drepturile de autor (acesta protejând investiția, software-ul integrat deosebit de bine în matrița drepturilor de autor), care în Uniunea Europeană a avut renunțat la protecția cu un drept sui generis, a rămas doar alegerea protecției prin drepturi de autor. Este o regulă a rațiunii mai mult decât un strigăt din inimă, chiar dacă software-ul este produsul activității intelectuale exprimate într-un anumit limbaj. De fapt, țările Uniunii s-au aliniat cu SUA, pentru a evita distorsiuni prea mari de protecție, și de aceea am adoptat receptacolul drepturilor de autor, chiar dacă este adevărat că astăzi, ne îndreptăm din nou către brevetabilitatea anumitor programe software [11] .

Într-adevăr, software-ul este ca un neg, deoarece hainele drepturilor de autor sunt grav tăiate pentru el, atât de mult încât a fost supus, parțial, unui regim derogatoriu în cadrul proprietății literare și artistice. Într-adevăr, ne îndepărtăm de artă, chiar utilitară. Cum să căutați amprenta personalității în instrucțiunile date unei mașini? Jurisprudența nu este păcălită, care folosește frecvent criteriul efortului personalizat.

Cu toate acestea, toate programele nu sunt protejate. Astfel, s-a apreciat că funcționalitățile (spunem și aplicații) ale unui software, și anume capacitatea acestuia de a îndeplini o sarcină determinată sau de a obține un anumit rezultat, nu sunt protejabile, deoarece acest lucru nu se referă la domeniul domeniului non-protejabil. idei (Civ 1 St Dec 13, 2005, JCP 2006.II. 1896, obs crit Masquart).

2 Regimul juridic al software-ului:

A) Domeniul de aplicare al drepturilor creatorului și atribuirea parțială a acestor drepturi utilizatorului:
a) Dreptul de exploatare:

Articolul L 122-6 din IPC descrie drepturile creatorului, drepturi pe care acesta le poate acorda, în totalitate sau parțial, utilizatorului. Deoarece reprezentarea nu are nicio semnificație pentru software, articolul menționează dreptul de reproducere și drepturile de traducere (într-o altă limbă pentru computer), adaptare, aranjare sau modificare.

Prin urmare, utilizatorul nu are dreptul, cu excepția cazului în care se specifică altfel, să modifice software-ul și să îl facă să evolueze (sub rezerva articolului 122-6-1 din CPI, pentru a corecta erorile și modificările care permit utilizarea software-ului în conformitate cu scopul propus), dar nu permit utilizatorului să dezvolte software-ul (în acest sens spiritul textului: Lamy Informatique, nr. 144), chiar dacă, în practică, când i s-a transmis codul sursă, el simte soluția opusă [12] .

Utilizatorul nu are dreptul să facă o copie privată (din contră, articolul 122-6 2 ° din IPC), cu excepția copiei de rezervă (a se vedea mai jos).

Exercitarea dreptului de adaptare presupune comunicarea codului sursă.

De foarte multe ori, niciun drept nu este transmis clientului în contractul de licență: se deduce că clientul are doar un drept simplu de utilizare.

b) Epuizarea drepturilor:

Se joacă fără a fi necesar să se facă distincția între reprezentare (acest drept fiind inexistent) și reproducere (articolul 122-6-3 ° din IPC). Se referă doar la vânzare și nu la închiriere (a se vedea jurisprudența Warner: CJCE 17 mai 1988, JCP ed E 1988.II.15297, obs Vivant și A. Lucas). Acest lucru face ilegal, în cazul unei vânzări (prin vânzare este necesar să se înțeleagă orice dobândire a unui drept de utilizare care nu ar fi o licență), clauza de netransferabilitate a contractului, precum și clauza de interoperabilitate care impune, pentru a achiziționa versiunea 2, pentru a justifica achiziționarea versiunii 1.

c) Comunicarea programelor sursă:

Când este vorba de un anumit software și nu de un software standard, ne putem întreba dacă există o obligație tacită de a transmite codul sursă: Bordeaux 24 septembrie 1984 (nepublicat) a crezut-o, dar în direcție contrară, sub sigiliul evident, TGI Paris (ref) 10 aprilie 2002 (Expertises 2002, 207), precum și Versailles 6 octombrie 1994 (Expertises 1995, 78), au estimat contrariul pentru un software specific. Pare logic să se refuze accesul la surse, atâta timp cât dreptul de modificare a software-ului nu a fost transmis de către titularul drepturilor asupra software-ului menționat prin intermediul unei cesiuni de drepturi. Cu toate acestea, s-ar putea lua în considerare o obligație de comunicare pe baza obligației de livrare dacă această comunicare a fost necesară pentru a atinge obiectivele stabilite prin contract. Acest lucru ar fi deosebit de util pentru corectarea erorilor (drept rezervat utilizatorului prin art. L 122-6-1): într-adevăr, corectarea erorilor implică și corectarea codului sursă. În practică, contractele de dezvoltare rareori prevăd comunicarea codului sursă, care leagă sponsorul de editor în ceea ce privește întreținerea.

Pentru software-ul gratuit, accesul liber este în general prevăzut de licență, deoarece este un software „open source” care este în filosofia proiectului să dezvolte și să permită duplicarea.

Pentru a evita să comunice utilizatorului codul sursă, care ar putea depăși astfel prerogativele care i-au fost acordate prin contract sau prin articolul 122-6-1, părțile îl pot încredința unui escrow terț, cum ar fi APP (Program Protection Agency) ), ceea ce este interesant pentru creatorul de software, care poate astfel contracta și controla accesul clienților săi la codul sursă și se poate furniza dovezi în cazul unui litigiu. obligație sau când furnizorul este în faliment. Faptele unei hotărâri pronunțate (Com 24 ianuarie 2006, Expertize 2006, 432, Lecardonnel) relevă dificultățile practice care pot fi întâmpinate. În acest caz, licențiatorul nu era proprietarul drepturilor și, prin urmare, lichidatorul companiei nu a fost împuternicit să autorizeze APP să furnizeze o copie a codului sursă. [13]