Захист програмного забезпечення та його правовий режим - Курс

Програмне забезпечення: його особливості:

його

Ми знаємо, що програмне забезпечення - це програма, що надсилається на комп’ютер для обробки інформації. Принцип, який зберігають французькі та європейські законодавці, полягає в захист авторських прав на програмне забезпечення. Але програмне забезпечення має бути оригінальним, щоб програмне забезпечення було захищене авторським правом. Він буде кваліфікований як оригінальний, якщо його автор продемонстрував персоналізовані зусилля, які виходять за рамки простої реалізації автоматичної та обов'язкової логіки.

  • 1: Захист програмного забезпечення:

Хоча раніше ми задавались питанням, чи не слід захищати програмне забезпечення патентами, сьогодні вже не оспорюється, що програмне забезпечення охороняється авторським правом: його партикуляризм був закріплений у законі від 10 травня 1994 р., Який транспонував у внутрішнє законодавство європейську директиву.

Фактично, з рішення Пачо (Пленарна асамблея 7 березня 1986, D 1986, 405) було визнано, що програмне забезпечення захищається авторським правом. Оскільки міжнародні договори забороняють патентоспроможність комп’ютерних програм, що США вирішили захистити їх авторським правом (цей захищає інвестиції, програмне забезпечення особливо добре інтегрується у форму авторських прав), що в Європейському Союзі відмовившись від захисту правом sui generis, залишався лише вибір захисту авторським правом. Це правило розуму - це більше, ніж крик від серця, навіть якщо програмне забезпечення є продуктом інтелектуальної діяльності, вираженою певною мовою. Насправді країни Союзу приєдналися до США, щоб уникнути занадто великих спотворень захисту, і саме тому ми прийняли вміст авторських прав, навіть якщо це правда, що сьогодні, хуей, ми знову рухаємось до патентоспроможність певного програмного забезпечення [11] .

По правді кажучи, програмне забезпечення схоже на бородавку, оскільки одяг, захищений авторським правом, для нього погано вирізаний, настільки, що він частково зазнав принизливого режиму в межах літературної та художньої власності. Дійсно, ми відходимо від мистецтва, навіть утилітарного. Як шукати відбиток особистості в інструкціях, що даються машині? Судова практика не оманлива, що часто використовує критерій персоніфікованих зусиль.

Однак усі програми не захищені. Таким чином, було визнано, що функціональні можливості (ми також називаємо додатки) програмного забезпечення, а саме його здатність виконувати визначене завдання або отримувати певний результат, не захищаються, оскільки це не стосується функцій домену, що не захищається ідеї (Civ 1-го грудня 13, 2005, JCP 2006.II. 1896, об. критик Маскарт).

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

Стаття L 122-6 CPI описує права творця, права, які він може надати користувачеві повністю або частково. У поданні, що не має значення для програмного забезпечення, у статті згадується право на відтворення та права на переклад (на іншу комп'ютерну мову), адаптацію, упорядкування чи модифікацію.

Тому користувач не має права, якщо не вказано інше, модифікувати програмне забезпечення та змусити його еволюціонувати (відповідно до статті 122-6-1 ІСЦ, виправляти помилки та модифікації, що дозволяють використовувати програмне забезпечення відповідно до призначення), але не дозволяють користувачеві розробляти програмне забезпечення (у цьому сенсі суть тексту: Lamy Informatique, № 144), навіть якщо на практиці, коли вихідний код йому передано, він відчуває протилежне рішення [12] .

Користувач не має права робити приватну копію (навпаки, стаття 122-6 2 ° ІСЦ), за винятком резервної копії (див. Нижче).

Здійснення права на адаптацію передбачає передачу вихідного коду.

Дуже часто жодні права не передаються замовнику в ліцензійному контракті: це виходить з того, що замовник має лише просте право користування.

  1. б) Вичерпання прав:

Він грає без необхідності розрізняти представництво (цього права не існує) та відтворення (стаття 122-6-3 ° ІСЦ). Це стосується лише продажу, а не оренди (див. Прецедентне право Warner: CJCE 17 травня 1988 р., JCP ed E 1988.II.15297, obs Vivant and A. Lucas). Це робить незаконним у разі продажу (під продажем необхідно розуміти будь-яке придбання права користування, яке не було б ліцензією), положення про непереданість договору, а також положення про сумісність, яке накладає, для придбання версії 2, щоб обґрунтувати придбання версії 1.

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

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

Для вільного програмного забезпечення відкритий доступ, як правило, передбачений ліцензією, оскільки саме програмне забезпечення з «відкритим кодом» і є основою проекту, щоб розробити та дозволити дублювання.

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

Слід зазначити, що реформа 2006 року (відома як DAVSI = авторське право та суміжні права в інформаційному суспільстві) передбачає, що спільне використання програмного забезпечення має бути предметом попередньої декларації державі з передачею коду.

  1. d) Резервна копія: (ст. 122-6-1.II ІПК)

Користувач має право лише на одну резервну копію, за винятком випадків, коли йому було надано право на відтворення.

  1. e) Декомпіляція: (стаття 122-6-1.IV ІСЦ)

Це зворотна інженерія вихідного коду та його дублювання (див. Пінто і Тейлор, декомпіляція програмного забезпечення: право на паразитизм, Dalloz 1999, doctr. 463). Наприклад, при зміні операційної системи, коли стикається з технічною проблемою, мова йде про доступ до вихідного коду програмного забезпечення для його аналізу та вирішення проблеми. Вихідний код зазвичай не постачається з програмним забезпеченням, на відміну від об'єктного коду, який є бінарною мовою, зрозумілою машині. Потім комп’ютерний спеціаліст «здійснить інженерну розробку» об’єктного коду та переведе його на зрозумілу для людей мову збірки (конкретно вам потрібно зробити копію програми). Це розкриє ідеї та принципи, висловлені мовою. Звичайно, коли ви купуєте програмне забезпечення, ви зазвичай маєте лише двійковий код, а не вихідний код, що не дозволяє вам змінювати вихідний код. Але з бінарного коду хороший технік зможе повернутися, частково, принаймні, до вихідного коду і таким чином здійснити піратство. Отже, небезпека полягає в тому, що комп'ютерні вчені декомпілюють програмне забезпечення своїх конкурентів для повторного використання своїх ідей. Тому будівельники вороже ставилися до декомпіляції, просунутого бастіону клонування

Нарешті, європейська директива дозволила це лише за суворих умов, коли "важливо отримати інформацію, необхідну для сумісності з іншим програмним забезпеченням".

Зловживання важко виявити, звідси і мізерність судової практики. Але факт залишається фактом: частіше за все до декомпіляції вдаються вдумливі конкуренти.

  1. Б) Інші аспекти правового статусу:
  2. а) Створення працівника та "фрілансера":

Кодекс передбачає, що робота належить роботодавцю in initio (стаття L 113-9 CPI), яка відступає від загального законодавства про авторське право, наближає програмне забезпечення до патенту та вилучає його із статусу баз даних, з якими він має, проте загальні правила.

Це правило не гармонізоване європейською директивою, і рішення різняться залежно від країни.

Увага ! Цей партикуляризм не стосується замовлених робіт. Якби твір було створено спільно працівниками та самозайнятими особами ("фрілансерами"), кваліфікація колективної роботи, якби вона була збережена, привела б до того ж результату, а саме до надання права власності на права ab initio на компанія-роботодавець та спонсор.

  1. б) Винагорода:

Що стосується програмного забезпечення, це можна виправити: стаття 131-4 5 ° ІСЦ.

Якщо права належать роботодавцю, чи повинен працівник отримувати винагороду, крім заробітної плати, за її створення? У кодексі нічого не сказано, що, однак, передбачає можливість фіксованої винагороди у разі передачі прав (ст. L 131-4-5 °), гіпотеза, яка нас тут не стосується, оскільки за гіпотезою це не стосується немає прав на передачу прав, які на законних підставах належать роботодавцю.

  1. в) Тривалість захисту:

Це, як і в звичайному праві, 70 років, що є непотрібним періодом, оскільки це занадто довго, враховуючи тривалість життя програмного забезпечення. Початковий пункт граничного терміну: створення твору, якщо правовласником є ​​юридична особа, смерть творця, якщо це фізична особа.

  1. г) Моральні права (L 121-7 ІСЦ):

У цій галузі ми ближчі до патенту, ніж до авторського права.

  • Нічого в праві розголошення: якщо творець є співробітником, ми обговорюємо, позбавлений творця цієї прерогативи чи ні.
  • Стаття прямо позбавляє автора, якщо не передбачено інше, права на відмову або покаяння
  • Право на ім'я обговорюється через мовчання закону
  • Що стосується права на повагу, стаття L 121-7 ІПЦ вміщує копію статті 6 біс Бернської конвенції: автор може виступити проти модифікації лише в тому випадку, якщо це завдає шкоди його "честі або репутації", що не має сенсу для програмного забезпечення. Важко зрозуміти, як модифікація програмного забезпечення може зашкодити честі його творця. Ви також можете визнати, що конкретного права на повагу немає.
  1. e) Порушення судом:

Стаття 332-4 є загальним положенням щодо баз даних (для читання). Зверніть увагу на обмеження часу, яке має бути встановлене постановою, щоб призначити його по суті. Так само щодо авторських прав.

  1. f) застава:

Що стосується патенту, до якого він подібний у цьому питанні, він передбачений у тексті (стаття L 132-4 CPI), але він не використовується на практиці, оскільки цінність програмного забезпечення є занадто нестабільною та швидкоплинною, щоб надихнути довіра.

  1. g) Закон від 1 серпня 2006 р. (DAVSI):

Стаття 15 передбачає, що імпорт із держави-члена Європейського Союзу програмного забезпечення, здатного обробляти захищені роботи та включаючи заходи технічного захисту, повинен бути предметом попередньої декларації державним службам, відповідальним за комп'ютерну безпеку, а також передача вихідного коду. Мета - мати можливість контролювати розповсюдження програмного забезпечення для спільного використання.

  1. В) Інші аспекти правового режиму:
  2. а) Програмне забезпечення, похідна робота:
  • Якщо адаптація оригінальна, замовник матиме подвійне право користування (складений твір): перший на адаптований твір, другий на адаптацію, в межах простого права використання або прав, зазначених у контракті з постачальник
  • Якщо це нова версія, існує допоміжна робота, якщо доповнення становить "персоналізоване зусилля". Сумнівне рішення підтвердило, що цього не було у справі, що подається (Версаль, 4 жовтня 2001 р., JCP, видання E 2002, 1334, № 1, повідомлення Сардейн).
  • Якщо постачальник забезпечує слабку адаптацію стандартного L (просте налаштування та адаптація до потреб замовника), результат адаптації належить творцю 1-ї роботи, оскільки постачальник не зробив оригінальної роботи. Це те, що справедливо судив Париж 14 червня 2006 р. (GP 18-19 квітня 2007 р., С. 41).

NB: конфігурація - це завершення програми: наприклад, для програмного забезпечення для розрахунку ПДВ мова піде про впровадження ставок ПДВ.

  1. б) Недобросовісна конкуренція:

Грабувати ідеї програмного забезпечення легко. Як зазначив М. Ле Турно (Шалені ідеї щодо ідей, CCE, лютий 2001 р., № 4), "легко змінити зовнішній вигляд програмного забезпечення, зберігаючи його функції, структуру та ефективність". Потім рішення полягає в тому, щоб захистити себе дією в умовах недобросовісної конкуренції, оскільки ідеї як такі не захищаються авторським правом (Париж, 16 лютого 1994 року, PIBD, III, 309). Нещодавно Касаційний суд пояснив, що за відсутності подібності за формою відновлення функціональних можливостей (ідей) каралося на основі паразитичної конкуренції (Civ 1 ère 13 грудня 2005 р., JCP 2006.IV.1092).

Як і в звичайному праві, може існувати кумуляція з паразитичною конкуренцією: таким чином, судили на тій підставі, що підроблене програмне забезпечення було інтегровано в окремий процес комерційної пропозиції: Париж 9 березня 2005 р., GP 15-17 січня 2006 р., С31.

  1. в) Право діяти в порушення:

Коли автор програмного забезпечення надає ліцензію певним користувачам (наприклад, в освітніх цілях) право розповсюдження та/або виготовлення та/або простого використання, необхідно знати, хто, ліцензіар або ліцензіат, порушує дію . Зазвичай в договорі нічого не зазначено, і саме тут кваліфікація стає важливою. Зазвичай це власник, який подає позов про порушення, який, якщо не передбачено інше, не надається ліцензіату (CA Paris 4 th ch. B, 4 лютого 1994 р. JCP ed. E. 1994, I, n ° 357, n ° 4).

Якщо хтось приймає кваліфікацію ліцензії, ліцензіат, в принципі, не має права діяти порушуючи; якщо ми приймемо кваліфікацію договору sui generis або право користування, буде потрібно шукати, часто гадальну операцію, волі сторін.