Защита на софтуера и неговият правен режим - Курс

Софтуерът: неговата особеност:

защита

Знаем, че софтуерът е програма, изпратена до компютър с цел обработка на информация. Принципът, запазен от френските и европейските законодатели, е този на защита на авторските права на софтуера. Но софтуерът трябва да е оригинален, за да може софтуерът да бъде защитен с авторски права. Той ще бъде квалифициран като оригинален, ако авторът му е показал персонализирани усилия, които надхвърлят простото прилагане на автоматична и обвързваща логика.

  • 1: Софтуерна защита:

Докато в миналото се чудехме дали софтуерът не трябва да бъде защитен с патенти, днес вече не се оспорва, че софтуерът е обект на авторско право: неговият партикуларизъм е залегнал в закон от 10 май 1994 г., който транспонира във вътрешното законодателство европейска директива.

Всъщност от решението Pachot (Пленарна асамблея на 7 март 1986 г., D 1986, 405) се приема, че софтуерът е защитен с авторски права. Тъй като международните договори забраняват патентоспособността на компютърните програми, които САЩ са избрали да ги защитят с авторските права (този, който защитава инвестицията, софтуерът е интегриран особено добре във формата на авторските права), че в рамките на Европейския съюз отказали се от защита с право sui generis, остава само изборът на защита по авторско право. Това е правило на разума повече от вик от сърце, дори ако софтуерът е продукт на интелектуална дейност, изразена на определен език. Всъщност страните от Съюза се присъединиха към САЩ, за да избегнат прекалено големи изкривявания на защитата и затова приехме резервоара за авторските права, дори и да е вярно, че днес, хуей, ние отново вървим към патентоспособността на определен софтуер [11] .

В действителност, софтуерът е като брадавица, тъй като облеклото на авторските права е силно разкроено за него, дотолкова, че е подложено, отчасти, на унизителен режим в рамките на литературната и художествена собственост. Всъщност ние се отдалечаваме от изкуството, дори утилитарно. Как да търсите отпечатъка на личността в инструкциите, дадени на машина? Съдебната практика не се заблуждава, което често използва критерия за персонализирани усилия.

Всички програми обаче не са защитени. По този начин беше преценено, че функционалностите (ние също казваме приложения) на даден софтуер, а именно неговата способност да изпълни определена задача или да получи определен резултат, не са защитими, тъй като това не касае тази на областта на незащитимата идеи (Civ 1-ви декември 13, 2005, JCP 2006.II. 1896, obs крит Маскарт).

  • 2 Правният режим на софтуера:
  1. А) Обхватът на правата на създателя и частичното приписване на тези права на потребителя:
  2. а) Правото на експлоатация:

Член L 122-6 от CPI описва правата на създателя, права, които той може да предостави, изцяло или частично, на потребителя. Тъй като представянето няма значение за софтуера, статията споменава правото на възпроизвеждане и правата за превод (на друг компютърен език), адаптация, подреждане или модификация.

Следователно потребителят няма право, освен ако не е предвидено друго, да модифицира софтуера и да го накара да се развива (при спазване на член 122-6-1 от CPI, да коригира грешки и модификации, които позволяват използването на „софтуер в съответствие с предназначението му), но не позволяват на потребителя да разработва софтуера (в този смисъл духа на текста: Lamy Informatique, n ° 144), дори ако на практика, когато изходният код му е бил предаден, той чувства обратното решение [12] .

Потребителят няма право да прави лично копие (член 122-6 2 ° от CPI, напротив), с изключение на резервното копие (виж по-долу).

Упражняването на правото на адаптация предполага предаването на изходния код.

Много често никакви права не се предават на клиента в лицензионния договор: това се извежда, че клиентът има само просто право на ползване.

  1. б) Изчерпването на правата:

Играе, без да се налага да прави разлика между представителство (това право не съществува) и възпроизвеждане (член 122-6-3 ° от ИПЦ). То се отнася само за продажбата, а не за наема (вж. Съдебна практика на Warner: CJCE 17 май 1988 г., JCP ed E 1988.II.15297, obs Vivant и A. Lucas). Това прави незаконни, в случай на продажба (при продажба е необходимо да се разбере всяко придобиване на право на ползване, което не би било лиценз), клаузата за непрехвърляемост на договора, както и клаузата за оперативна съвместимост, която налага, за придобиване на версия 2, за да оправдае закупуването на версия 1.

  1. в) Комуникация на изходни програми:

Когато става въпрос за конкретен софтуер, а не за стандартен софтуер, може да се запитаме дали има мълчаливо задължение за предаване на изходния код: Бордо 24 септември 1984 г. (непубликуван) го е помислил, но в обратна посока, под печата на очевидно е, че TGI Париж (справка) 10 април 2002 г. (Expertises 2002, 207), както и Версай 6 октомври 1994 г. (Expertises 1995, 78), оценяват обратното за конкретен софтуер. Изглежда логично да се откаже достъп до източниците, стига правото на модификация на софтуера да не е било предадено от притежателя на правата върху споменатия софтуер чрез прехвърляне на права. Въпреки това може да се помисли за задължение за комуникация въз основа на задължението за доставка, ако това съобщение е необходимо за постигане на целите, определени от договора. Това би било особено полезно за коригиране на грешки (правото запазено за потребителя съгласно чл. L 122-6-1): всъщност коригирането на грешки включва и коригиране на изходния код. На практика договорите за разработка рядко предвиждат комуникация на изходния код, който свързва спонсора с издателя по отношение на поддръжката.

За безплатния софтуер отвореният достъп обикновено се предоставя от лиценза, тъй като именно софтуерът с „отворен код“ е във философията на проекта да разработва и позволява дублиране.

За да не се налага да съобщава на потребителя изходния код, който по този начин може да надхвърли прерогативите, предоставени му по договор или по член 122-6-1, страните могат да го поверят на ескроу на трета страна като APP (Агенция за защита на програмата) ), което е интересно за създателя на софтуера, който по този начин може да сключи и контролира достъпа на своите клиенти до изходния код и да си предостави доказателство в случай на спор. Приоритет на създаването му или във връзка с изпълнението на поддръжката задължение или когато доставчикът е в несъстоятелност. Фактите от постановено решение (Com 24 януари 2006 г., Expertises 2006, 432, Lecardonnel) разкриват практическите трудности, с които могат да се сблъскат. В този случай лицензодателят не е собственик на правата и поради това ликвидаторът на дружеството не е оправомощен да упълномощи APP да предостави копие на изходния код. [13]