Права на программы: договорная цепочка, лицензии и аудит open source

1. Составьте карту продукта и авторов

Работающее приложение не является единым однородным правовым активом. Оно содержит собственный код, библиотеки, документацию, графику, интерфейс, базы данных и внешние сервисы. У каждого элемента могут быть другой автор и договорное основание. Сначала определяют версию продукта, репозитории, историю вкладов, создателей и организацию, планирующую развитие, распространение или продажу. Доступ к репозиторию сам по себе не доказывает приобретения авторских прав. ^{[1] [2]}

Практическая единица аудита — модуль, связанный с автором, датой создания, условиями сотрудничества и документом о передаче прав либо лицензии. Счет за разработку подтверждает оплату, но автоматически не решает вопросы способов использования, изменений и дальнейшего лицензирования. В отчете отделяют документированные права от устных заверений и пробелов. Включают также вклады учредителей, созданные до регистрации компании.

2. Работник и подрядчик имеют разные правовые основания

Статья 74 часть 3 польского Закона об авторском праве по общему правилу относит имущественные права на программу, созданную работником при исполнении трудовых обязанностей, к работодателю, если договор не устанавливает иного. Необходимо подтвердить трудовые отношения и связь программы с обязанностями. Специальное правило нельзя автоматически переносить на любую графику или частный проект человека, работающего в компании. ^[1]

При B2B проверяют договор, права исполнителя от субподрядчиков и обязательную форму. Передача имущественных авторских прав требует письменной формы под угрозой недействительности; письменная форма необходима и для исключительной лицензии. Договор должен прямо охватывать согласованные способы использования. Скан подписи, электронное письмо и квалифицированная электронная подпись — разные юридические категории; способ заключения конкретного соглашения проверяют самостоятельно. ^[1]

3. Сопоставьте договор с бизнес-моделью

Для программы важны воспроизведение, перевод, адаптация, иные изменения и распространение. Проверьте, может ли заказчик поддерживать систему, передать развитие новому поставщику, использовать решение в группе компаний и предлагать его другим пользователям. Отдельно исследуют операционный доступ: исходный код, инструкции сборки, конфигурацию, домен, аккаунты и ключи. Право использования ограниченно полезно, если актуальную версию невозможно собрать или развернуть. ^{[1] [2]}

Гипотетический пример: компания приобрела приложение, но важный модуль написал субподрядчик, не охваченный договорами. Заверение главного исполнителя о полных правах само по себе не исправляет отсутствующее звено. Установите автора и разрешение, получите нужные права либо замените модуль. Проблема может иметь значение при инвестиции или продаже продукта, даже если приложение годами работало без претензий.

4. SAS Institute: функциональность и охраняемая форма

В SAS Institute, C-406/10, Суд ЕС указал, что функциональность программы, язык программирования и форматы файлов для реализации ее функций сами по себе не являются формой выражения, охраняемой директивой о программах. Это разграничение идей и принципов работы с конкретным выражением кода. Оно не создает общего разрешения копировать чужие материалы или документацию. ^[3]

Элементы, выражающие собственное интеллектуальное творчество автора, могут охраняться, включая соответствующую документацию. Законный пользователь вправе наблюдать, изучать и тестировать работу в предусмотренных пределах; декомпиляция для совместимости имеет отдельные строгие условия. Проект совместимого инструмента должен документировать законные источники информации и метод разработки. Конфиденциальность, договоры, данные и иные права могут требовать самостоятельной оценки. ^{[2] [3]}

5. UsedSoft: перепродажа требует истории приобретения

UsedSoft, C-128/11, касалось исчерпания права распространения загруженной копии при определенной модели: бессрочное право использования, плата, соответствующая экономической стоимости копии, и первый выпуск в оборот в ЕС с согласия правообладателя. Суд анализировал загрузку и предоставление лицензии совместно. Одно название договора не определяет правовые последствия и не заменяет исследования экономического содержания сделки. ^[4]

При перепродаже первый покупатель должен сделать свою копию непригодной для использования; решение также ограничивает разделение лицензионных пакетов. Из него не следует автоматическая передаваемость каждой подписки, облачной услуги или цифрового произведения. Для аудита нужны документы первоначального приобретения, объем разрешения, цепочка передач и подтверждение прекращения использования. Отсутствующая история происхождения представляет конкретный доказательственный риск, который общее заверение продавца не обязательно устраняет. ^[4]

6. Open source: проверяйте версию и распространение

Перечень зависимостей должен фиксировать название, версию, источник, лицензию, изменения и модель распространения. SPDX помогает обмениваться сведениями о компонентах и лицензировании; автоматический отчет сам по себе не подтверждает выполнение всех условий. Проверяют лицензионные файлы, исключения, двойное лицензирование и транзитивные зависимости. Внутреннее использование, передачу копий и сетевой доступ отражают отдельно: последствия зависят от конкретного текста лицензии. ^[5]

Например, GPLv3 устанавливает условия передачи объектного кода, включая соответствующий исходный код и лицензионную информацию. Не все open-source библиотеки имеют одинаковую модель, и не каждое использование автоматически требует публикации всего продукта. Исследуют реальное сочетание и распространение. Аудит должен завершаться действиями: исправить notices, предоставить исходный код, заменить зависимость либо получить иную лицензию, с ответственным лицом и сроком исполнения. ^[6]

Источники и дальнейшее чтение

1. 1
   Польский Закон об авторском праве ↗

   Dz. U. 2025 poz. 24 ze zm.; art. 41,53,67,74–77

   Официальная страница с актуализированным текстом; трудовые программы и форма договоров.

2. 2
   Директива о правовой охране программ ↗

   Dyrektywa 2009/24/WE; art. 1–6,9

   Объем охраны, законные приобретатели и совместимость.

3. 3
   Суд ЕС: SAS Institute против World Programming ↗

   C-406/10, 2.05.2012, ECLI:EU:C:2012:259, pkt 39–46,54–61,66–70

   Функциональность, язык, форматы и документация требуют разных оценок.

4. 4
   Суд ЕС: UsedSoft против Oracle ↗

   C-128/11, 3.07.2012, ECLI:EU:C:2012:407, pkt 42–49,69–71,78–88

   Условия исчерпания и пределы перепродажи копий программ.

5. 5
   SPDX — спецификации ↗

   SPDX: Software Package Data Exchange; specyfikacje projektu Linux Foundation

   Документирование компонентов и лицензий не заменяет правовой анализ.

6. 6
   GNU GPLv3 — официальный текст в документации GCC ↗

   GNU General Public License, version 3, 29.06.2007; sekcje 4–6

   Условия конкретной лицензии, а не законодательный акт.