Открытые лицензии

7 минут
10.06.2021
Если одна из идей вашего проекта — создание ПО, распространяемого максимально широко, то такой вид лицензий — наиболее подходящая правовая защита для разработчиков.

В чем суть
Открытые лицензии (Свободные лицензии / Free licenses) — правовой инструмент, который защищает разработчика при его желании сделать широкодоступное ПО, доработка которого была бы возможна силами всего сообщества пользователей.

В этом случае лицензии должны делать софт свободным для пользователей, а именно содержать базовые условия о свободе пользователей:

  • реализовывать программу в любых целях;
  • получать доступ к исходному коду ПО;
  • модифицировать ПО;
  • распространять копии ПО и копии модифицированного ПО.
Бесплатность открытой лицензии
Открытые лицензии устроены таким образом, что брать деньги за распространение недопустимо — в противном случае ПО станет несвободным. Однако это не исключает возможность выстраивать бизнес-модель альтернативным образом — например, оказывать платные услуги по техническому сопровождению или адаптации ПО, которое распространяется на условиях свободных лицензий.

Например, дистрибутив Linux — Red Hat Enterprise от компании Red Hat распространяется на платной основе, так как в него входит пакет дополнительных услуг в виде администрирования, службы поддержки и так далее, в то время как программы на основе Linux и само ядро Linux распространяются по модели открытого лицензирования.
Виды открытых лицензий
Открытые лицензии могут быть:

– «взаимными» — обязывают распространять ПО / его модификации на условиях такой же лицензии;

– «разрешительными» — дают полную свободу в выборе условий распространения ПО / его модификаций.

Ниже раскрыты особенности наиболее известных открытых лицензий.
Creative Commons (CC)
Набор открытых лицензий, которые позволяют распространять изображения, музыку, видео и иной подобный контент на различных условиях.

Наиболее популярные виды лицензий Creative Commons:
СС Attribution — требует указания автора при распространении контента («разрешительная» лицензия);
CC Share Alike — производное ПО должно распространяться на условиях этой же лицензии («взаимная» лицензия);
CC Attribution — No Derivative Works — нельзя вносить изменения в ПО и при этом необходимо указывать авторство;
CC Attribution — Noncommercial — переработка ПО возможна только на некоммерческой основе.
GNU General Public License (GNU GPL)
Первая открытая лицензия для распространения ПО, особенностью которой является обязанность разработчиков распространять программу и её модификации исключительно на условиях той же GNU GPL.

Существует и её более мягкая версия — Lesser GNU GPL, которая обязывает распространять на тех же условиях только библиотеки и их модификации, используемые при разработке ПО.
The MIT License
Разрешительная открытая лицензия для ПО, состоящая всего из 167 слов! Условие распространения ПО под этой лицензией — обязанность приложить уведомление об авторском праве и текст этой лицензии к каждому экземпляру ПО.

Приложение текста лицензии не равно распространению итогового ПО на тех же условиях. Разработчик по-прежнему свободен в выборе дополнительных условий для распространения своего ПО.
Совместимость открытых лицензий
В разработке ПО могут быть элементы, которые лицензируются по-разному. Условия разных лицензий могут конфликтовать между собой, совмещение таких элементов будет нарушением лицензии. Для того, чтобы правомерно объединять элементы, нужно удовлетворять условиям всех лицензий сразу.

Пример: в GNU GPLv3 есть условие, запрещающее включение дополнительных условий, ограничивающих пользователя, по сравнению с самой GNU GPL. Из-за этого GNU GPL несовместима с Original BSD License, условия которой обязывают прилагать особое уведомление ко всем рекламным материалам о ПО. Если соединить софт на основе GNU GPL с софтом на основе Original BSD License, это нарушение GNU GPL, которое может привести к спору с правообладателем ПО на основе GNU GPL.

А такие лицензии, как The MIT License или Lesser GPL, совместимы с GNU GPL.

Чтобы минимизировать риски несовместимости, нужно внимательно проверять следующие обстоятельства:

  1. Какие элементы на условиях открытых лицензий вы используете?
  2. Совмещаете ли вы их в одном ПО?
  3. Что предусматривают условия лицензий, каковы их ключевые условия (модификации, совместимость)?

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

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

Важно понимать, что даже за нарушение не обременяющих условий можно понести серьезную ответственность.

Так, в самом известном судебном разбирательстве, связанном с открытыми лицензиями, Jacobsen v. Katzer, американский суд усмотрел нарушение условий открытой Artistic License и взыскал убытки с нарушителя. В итоге дело закончилось мировым соглашением, по которому нарушитель выплатил 100 000 $.

На что обратить внимание
Ниже указаны те условия открытых лицензий, которые важно проверить перед использованием объекта:
Есть ли в открытой лицензии пункт о том, что разработчик должен приложить ее условия к своему продукту либо сослаться на них?
С таким условием при распространении ПО лицензия будет выдаваться самим разработчиком свободного ПО, и если кто-либо нарушит условия лицензии и ему будет запрещено использовать ПО, это не повлияет на остальных пользователей.
Условие распространения «AS IS», которое можно найти в любой открытой лицензии
Это условие ограничивает ответственность разработчика и лишает пользователя любых гарантий. Учитывайте то, что любые риски, связанные с использованием ПО, будут лежать на пользователе.
Проверьте совместимость открытых лицензий, если вы используете в разработке разные компоненты
Для этого мы рекомендуем использовать систему учета:

  1. Составить список используемых вами объектов, которые распространяются на условиях открытой лицензии;
  2. Проверить соблюдение условий этих открытых лицензий;
  3. Устранить нарушение можно заменой конфликтующего элемента в ПО на иной, либо созданием собственного элемента ПО, если это возможно.

Кроме того, для минимизации будущих рисков рекомендуется разработать и регламентировать процесс использования ПО на условиях открытых лицензий. В частности, проработать систему уведомлений и учета об использовании компонентов, распространяемых на условиях открытых лицензий.
ЗАКАЗЧИКИ И ПЛАТФОРМЫ
26.06.2021
читайте также:
Разработка EULA
End-user license agreement (EULA, лицензионное соглашение с конечным пользователем) регулирует...
защита прав на по
27.06.2021
Борьба с распространением нелицензионного ПО
Технические и юридические инструменты борьбы с использованием нелицензионного ПО...
защита прав на по
28.06.2021
Борьба с воровством и переработкой кода
Недобросовестные конкуренты могут скопировать весь код или его часть, чтобы создать похожий функционал...