В статье я рассматриваю вопрос, можно ли считать программу для ЭВМ, которая линкуется динамически с компонентами из библиотек, модификацией этих компонентов (производной от них программой).
Что такое модификация программы для ЭВМ и производное произведение можно прочесть в моем Телеграм-канале «IP – IT право с нуля»
При разработке своей программы для ЭВМ мы можем использовать чужие компоненты (программы), выполняющие те или иные функции.
Как правило, интересующие компоненты содержатся в библиотеках. Их использование возможно на условиях известных лицензий разных версий GNU, Аpache и др.).
Есть общие библиотеки, есть специализированные (например, для графического интерфейса).
Зачем решать какие-то типовые подзадачи, необходимые для выполнения нашей, если они уже кем-то решены. Не нужно изобретать велосипед.
Возьмем простейшие примеры.
1. Программе, которую мы разрабатываем, нужно найти целое от числа или вычислить логарифм.
Есть библиотека в Python для выполнения матфункций:
найти целое от числа - math.trunc(x),
вычислить логарифм - math.log(x[, base]).
Соответственно, мы используем эту библиотеку в своем коде (программе).
Или.
2. Разрабатываем небольшую программу – видеоплеер. Используем библиотеку FFmpeg.
Эта библиотека позволяет обрабатывать и проигрывать видео: склеивать, кодировать, изменять, обрезать видео.
Соответственно, библиотека может быть использована для наших целей.
Поскольку мы предполагаем использование компонентов из библиотек, у нас, естественно, возникает вопрос: а не будет ли наша программа носить производный характер от этих компонентов и являться их модификацией?
Как минимум, от ответа на этот вопрос зависит необходимость получения разрешение (лицензии) на использование библиотек при создании и последующем использовании нашей программы, необходимость уведомления об авторских правах на библиотеки.
🔷Для начала рассмотрим, какие варианты связывания (линковки) с библиотеками существуют.
Это так называемые, статическая и динамическая линковки.
Что это такое и в чем принципиальное отличие.
Статическое связывание
Нужный компонент-программу можно заимствовать, включив его, собственно, в исходный код нашей программы, затем из исходного кода скомпилировать объектный (практически, рабочий) код.
Об объектном и исходном кодах см. Телеграм-канал «IP – IT право с нуля»
При таком подходе можно согласиться, что мы имеем дело с модификацией заимствованных компонентов и в итоге наша программа носит характер производной, поскольку создана с использованием сторонних компонентов.
Хотя, конечно, если мы позаимствовали только математические функции – как-то обидно делать такой вывод, если наша задача решает более глобальные проблемы. Но бывают и библиотеки, выполняющие более сложные задачи.
Другая версия этого же случая (и наиболее распространенная) - это компоновка исполняемого кода на основе объектных кодов заимствованных компонентов и объектного кода нашей программы.
Этот вариант возможен, когда, собственно, итоговый исходный код нашей программы может быть разбит на отдельные компилируемые модули.
Но в любом случае, при статической линковке код библиотеки становится частью исполняемого кода(!).
Динамическая линковка
Цели все те же, но в отличие от статической линковки, модули библиотек не собираются в наш исполняемый файл, а подгружаются на этапе выполнения нашей программы (нашего исполняемого кода).
Для работы нашей программы необходимо, чтобы к используемой библиотеке имел доступ и пользователь. Поскольку, как уже отмечено, в нашей программе нет компонентов из библиотек, есть только ссылка на них(!).
И здесь возникает закономерный вопрос, а будет ли наша программа при таком связывании с библиотекой производной от используемых компонентов?
Ведь компоненты вызываются при работе нашего кода, но не входят в его состав?
Или нашу программу можно рассматривать как самостоятельный объект, при работе которого требуется наличие определенных инструментов у пользователя?
На мой взгляд, различие вариантов линковки хорошо показывает следующий пример.
Допустим, вы занимаетесь разработкой и продажей гамаков.
Вариант 1. Вы можете закупить столбы для крепежа гамака и продать пользователю готовый комплект.
Пользователю не нужно будет заботиться о том, куда бы навесить этот гамак.
Это у нас статическое связывание. Столбы – это компоненты из библиотек. Гамак – наша разработка, но поставляем мы итоговую программу: гамак + столбы.
Вариант 2. Альтернативный вариант.
Вы разрабатываете и продаете пользователю исключительно сам гамак - полотно с крючками и не более. Пользователь же должен позаботиться о наличии у него столбов, на которые он навесит гамак.
Применительно к программам.
По варианту 1 мы предоставляем пользователю исполняемый код, в котором содержится и библиотека. То есть, пользователю не нужно заботиться о библиотеке.
По варианту 2 мы передаем пользователю свою разработку и лицензию на нее, а далее пользователь «собирает» гамак сам. Соответственно, приобретает части, которых у него нет, вступает во взаимоотношения с продавцом (лицензиаром библиотеки).
В процессе работы нашего кода у пользователя «цепляются» нужные компоненты из библиотеки.
При втором варианте в нашу задачу входит: информирование пользователя об условиях, при которых наша программа заработает, о необходимости наличия у пользователя конкретных инструментов – библиотек.
Все это можно прописать в лицензии для нашей программы, документации к ней, повторить информацию, например, при запуске программы.
В принципе, гражданское право допускает возможность получения одного результата для заказчика, но под разными правовыми конструкциями (купля-продажа и подряд, подряд с использованием материалов подрядчика или заказчика и т.п.).
И говорить о том, что наша программа является производной от библиотеки при динамической линковке, на мой взгляд, не совсем корректно.
На этом можно было бы остановиться. Но.
В отличие от гамака, компоненты (библиотеки), используемые при работе нашей программы, предоставляются под лицензиями, как правило открытыми. Да еще с участием в качестве стороны иностранного элемента.
И эти лицензии могут содержать нюансы.
Возьмем, например, лицензию GNU LGPL v3 (под ней распространяется, в частности упомянутая библиотека FFmpeg).
«A "Combined Work" is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the "Linked Version".
По-русски, комбинированная программа – это программа, созданная путем объединения или связывания с библиотекой.
То есть, и динамическая линковка делает нашу программу комбинированной.
Далее, в разделе 4 идет указание на необходимость уведомления об авторских правах, предоставлении копии лицензии LGPL V3 и GNU при распространении как самих библиотек, так и комбинированных работ. И это общие правила, которые не зависят от того, каким способом связываются библиотеки.
Также требуется извещение с каждым экземпляром комбинированной программы об использовании библиотеки на основании данной лицензии.
Данные условия лицензии могут быть истолкованы как восприятие лицензиаром нашей программы в качестве производной (модифицированной) от библиотеки и при динамической линковке.
С другой стороны, «Combined Work» это далеко не производная работа и даже не составная, как мы их понимаем.
Да и до запуска нашей программы нет никакого связывания с библиотекой. Она связывается при работе у пользователя.
И уведомление о правах и лицензии это всего лишь уведомления.
Другой пример. Лицензия Apache 2.0. Ситуация еще интереснее.
«Производное произведение» означает произведение, в форме исходного или объектного кода, которое основано на (или получено из) произведения.
Не включает в себя произведения, которые обособлены от, или только связаны (или связаны по наименованию) с интерфейсами Произведения или его Производных произведений".
Раздел 4, устанавливающий условия распространения, в том числе условия об уведомлениях, регулирует только вопрос самих библиотек или производных работ.
А как отмечено в данной лицензии, динамическая линковка не ведет к возникновению производной работы - Derivative Works.
И данная лицензия как нельзя заманчива для оформления отношений с пользователем по варианту 2 (продажа гамака без столбов).
Тем не менее, хотя формально динамическая линковка может не приводить к созданию "Derivative Work" и, соответственно, требовать выполнения Раздела 4, на практике поступают осторожно и рекомендуют всегда включать уведомления об авторских правах и лицензии библиотеки Apache 2.0 в свой проект.
Считается, что это наиболее безопасный и этичный подход, который поможет избежать потенциальных проблем в будущем.
Но, как уже писала, уведомления – это уведомления.
Таким образом, построение отношений с клиентом по варианту 2 - это вполне приемлемая модель при динамическом связывании с библиотекой. Но целесообразно выполнить все условия об уведомлениях и предоставить копии лицензий, по крайней мере для упомянутых выше.
Учитывая проблемы определения применимого права, в частности, к открытым лицензиям с иностранным элементом, в том числе к используемым терминам, а также отсутствие в российском законодательстве четкого понимания того, что из себя представляет не только программа с динамическим связыванием библиотек, но и собственно, модифицированная программа, возможны недопонимания.
О применимом праве к лицензиям см. Телеграм-канал «IP – IT право с нуля»
Важно читать условия лицензий, под которыми предоставляются компоненты из библиотек, а также понимать существо используемых компонентов.
Ну, и учитываем требования лицензий, уведомляем, как того они требуют.
При использовании в сотрудничестве с пользователем варианта 2 максимально информируем пользователя о зоне его ответственности.
Примечание. В статье я использую термин «производное», а не «составное» произведение, поскольку считаю, что суть составного произведения совершенно в ином. При использовании библиотек, независимо от варианта линковки, составного произведения не возникает.
Если речь о статической библиотеке – можно говорить о возникновении, максимум, сложного объекта, но никак не составного.
Про составное см. Телеграм-канал «IP – IT право с нуля»
О программе, как сложном объекте, можно прочитать в моей статье
Тема не простая. Возможны вопросы.
Связь через телеграм @NataBeres (в том числе по наставничеству).
➡️Получить больше новых знаний можно ознакомившись с другими моими статьями, например:
«Использование Хеш-суммы в качестве доказательства тождественности файлов (РИДы, закупки и др.)»
«Защита сайта через защиту его дизайна. Сначала проверим, внесена ли творческая компонента»
«SaaS – услуга или лицензия на ПО»,
«БАЗА ДАННЫХ- объект авторских и смежных прав. Проблемы защиты и решения»,
«Искусственный интеллект оставили без прав? Или революция отменяется»
а также статьями из подборок:
подборка «Программы для ЭВМ и базы данных»,
подборка "Товарные знаки, изображения, фотографии и др. Как не нарушить права на них",
подборка "Налогообложение в сфере IP/IT".