Привет! Я Олег Макаров, ведущий юрист ispmanager. Эта статья будет полезна всем, кто зарабатывает на ПО с открытым кодом. Расскажу, как безопасно работать с лицензиями Open source и что бывает с нарушителями — а уже попадались D-Link и Cisco Systems. Российский разработчик Антон Мамичев выиграл дело о нарушении его авторских прав на открытый код у Veeam Software, дочерней компании Amazon.

Больше всего рискуют разработчики коммерческого кода — умные конкуренты обязательно сделают ревизию кода. Если найдут копилефтную часть, то могут потребовать раскрыть код и сделать его доступным всем. И по закону будут правы. Пострадают все — собственники бизнеса,  разработчики, продакты и юристы. 

Что такое копилефт, как его безопасно использовать, какие еще бывают лицензии и каковы условия их использования — ниже подробно обо всем. 

Какие вообще бывают лицензии для открытого кода и чем отличаются 

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

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

«Взял код — поделись со всеми результатом» — копилефтные лицензии. Название произошло от игры слов и противопоставления разрешительным: Copyright — Copyleft. Они требуют распространять измененное ПО под той же лицензией, что и у оригинального кода. Образно говоря — заражают необходимостью использовать такую же лицензию.  Поэтому еще их называют вирусными.

Дальше расскажу о самых распростаненных лицензиях и условиях их использования. Данные о долях лицензий на рынке я привел по данным рейтинга Statista.com. 

Разрешительные лицензии, их отличия, условия использования и последствия нарушений

Чаще всего на рынке используют три вида разрешительных лицензий:

MIT, «Massachusetts Institute of Technology» — дает возможность свободно использовать, менять и распространять взятое ПО. В 2021 году лицензия MIT занимала самую большую долю рынка Open source — 26%.

Условия использования. Условия обязательные, если взяли код в чистом виде, без переработок. Если вы внесли изменения в Open source компонент кода — укажите в коде, что лицензия и уведомление о правах распространяются только на заимствованную часть.

Нужно включить уведомление об авторском праве и текст лицензии на английском языке:

• в код — если разделяем свой код и заимствованный;

• в интерфейс исполняемого файла или файла license в репозитории.

Уведомление об авторском праве выглядит так: Copyright (c) <год> <владельцы прав>

BSD, «Berkeley Software Distribution» — разрешает использовать, менять и распространять взятый код, если вы указываете его авторство. У BSD есть разные виды — например, FreeBSD, OpenBSD, BSD 1-4. Рассмотрю наиболее распространенные — BSD 2 и BSD 3. Они занимают около 7% всех Open source проектов.

Условия использования:

• Включить информацию об авторском праве в уведомления в интерфейсе исполняемого файла или файла license в репозитории, если код используется в чистом виде. 

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

• Указать в коде, что лицензия и уведомление о правах распространяются только на заимствованную часть кода — как и в лицензии MIT. 

• Только для BSD 3: не использовать имена авторов ПО и разработчиков, если планируете продвигать ПО в коммерческих целях. 

Apache. Разработчик лицензии — Apache Software Foundation. В России Apache считается самой безопасной лицензией — никто не сможет подать в суд, если в коде оригинала окажется запатентованный компонент, потому что по российским законам код не патентуется по п. 5 ст. 1350 ГК РФ.

Рассмотрю версию Apache 2.0 — она занимает 22% всех Open source компонентов.

Условия использования:

• Вставить текст лицензии на английском языке в дистрибутив или иное заметное пользователю место — например, в репозиторий, UI или в исходный код. Требование нужно выполнить независимо от того, переработали ли вы оригинал или взяли код в чистом виде — в отличие от MIT и BSD.

• Отметить любыми доступными средствами кусок оригинального кода, в котором были изменения — например, в комментариях к исходному коду.

• Включить информацию об авторском праве, праве на патенты и товарные знаки в уведомления в интерфейсе исполняемого файла или файла license в репозитории. 

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

• Вписать текст файла Notice.txt, документа для информации или уведомлений в ПО, в одно из мест: в дистрибутив / в исходный код / в специальную вкладку «О программе» на экране ПО или в другое предназначенное для этого место. Текст файла Notice.txt нужно обязательно включить в ПО, если файл сопровождал исходный код — даже если вы добавили текст лицензии на английском языке в дистрибутив или другое место.

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

Копилефтные лицензии — когда подойдут, условия использования, последствия нарушений

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

Чаще всего на рынке используют 6 видов копилефтных лицензий:

GNU GPL v3 (General Public License) — разрешает свободно использовать, менять и распространять ПО. Модифицированное ПО можно свободно распространять только под лицензией GPL v3. Условие — ваш продукт с заимствованным кодом должен быть под лицензией оригинала кода — GNU GPL v3. Занимает 16% всех Open source проектов.

Лицензию написали юристы — в GPL v3 подробно «разжевали» терминологию, учли проблему патентов, тивоизации и добавили информацию о последствиях нарушения условий. 

Условия использования:

• Включить в UI и в код уведомление об авторском праве, праве на патенты и товарные знаки. Условие актуально, даже если заимствованный код не менялся. 

• Включить текст лицензии на английском языке в уведомления в интерфейсе исполняемого файла, в файл license в репозитории. А еще — ссылку на текст лицензии, если в ПО не менялся исходный код.

• Указать в исходном коде, в какую часть внесли изменения, кто их автор и когда поменяли оригинал. 

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

• Предоставить неограниченному кругу лиц права на использование патента, если он есть в производном ПО.

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

GPL v2 — похожа на GPL v3, но в GPL v2 не учтена проблема тивоизации и патентов. Лицензия писалась разработчиком для разработчиков, поэтому ее текст более понятный и простой. Занимает 10% рынка Open source.

Условия использования: 

• Включить в UI и в код уведомление об авторском праве.

• Добавить текст лицензии на английском языке в уведомления в интерфейсе исполняемого файла, в файл license в репозитории. А еще — ссылку на текст лицензии, если в ПО не менялся исходный код.

• Указать в исходном коде, в какую часть внесли изменения, кто их автор и когда поменяли оригинал. 

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

LGPL v2.1 (Lesser GPL), применяется только для лицензирования библиотек и дополняет GPL v2. Доля среди всех Open source проектов — 6%.

Условия использования:

• Отметить измененную часть кода, если была модификации библиотеки, указать авторов и дату изменений.

• Дать пользователю вашего ПО инструменты модификации «втянутой» библиотеки. Запрещено ограничивать право на модификацию соглашением с пользователем (EULA). Это требование касается только статического линкования — «втягивания» кода библиотеки в ваше ПО. Для динамического линкования, когда библиотека не «втягивается» в код, ограничений нет.

AGPL (Affero General Public License) — содержит такие же положения, как GPL v3 и GPL v2. Единственное отличие — лицензия касается и SaaS решений, когда производное ПО распространяется в облачном формате, без физического устройства. 

Условия использования — те же, что для GPL v3 и GPL v2.

Microsoft Public License (Ms-PL) — лицензия Microsoft для распространения исходного кода своих проектов. Не вынуждает раскрывать исходный код программы — достаточно распространять производный код под лицензией MPL. Используется в 3% всех Open source проектов.

Условия использования:

• Распространять ПО с MPL-компонентами в исходном коде только под этой же лицензией.

• Распространять ПО с компонентами под MPL в объектном коде можно только с лицензией, по условиям которой не нужно раскрывать исходный код ПО.

  Невозможно не противоречить MPL с классической проприетарной лицензией, потому что она предполагает сокрытие кода исходного и распространяется только в обьектном. Как вариант, можно разделить в коде условия для «своего» и свободного ПО.

• Предоставить неограниченному кругу лиц права на использование патента, если он есть в производном ПО.

• Не использовать товарные знаки и имена авторов в производном ПО.

Eclipse Public License v.1 — единственная лицензия, которая прямо разрешает коммерческое использование в определенных случаях. Используется для продуктов компании Eclipse Foundation — разработчика одноименной среды разработки IDE. Занимает всего 1% сферы Open source.

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

Что будет, если нарушить требования копилефтных лицензий. Как я уже писал выше — через суд вынудят раскрыть исходный код всей программы и сделать его общедоступным. Обычно вопрос решается в досудебном порядке, но бывают и громкие разбирательства.

 Вот несколько примеров из судебной практики.

Германия. Юрист-программист Харальд Велте в проекте gpl-violations.org успешно засуживал компании, которые попадались на нарушении условий GPL. Например, программист подал иск на D-Link — в сентябре 2006 года Мюнхенский суд подтвердил, что компания нарушила условия GPL и обязал D-Link предоставить исходный код и покрыть судебные издержки. 

США. Free Software Foundation и Artiflex удалось через суд принудить Cisco Systems, Palm, Inc., раскрыть исходный код их ПО с GPL-компонентами кода.

Россия — дело Антона Мамичева против Veeam Software. Компания удалила его имя из программного кода и использовала программу в коммерческих целях. В ответ в ходе судебных разбирательств Антона обвинили, что он нарушил условия лицензии GNU GPL v2 и поэтому не имеет право защищать свои авторские права. После 7-летних разбирательств Антону удалось доказать, что даже если нарушены условия копилефтной GPL-лицензии, разработчик не теряет права на защиту своего ПО. 

Вот некоторые выводы, которые Антон Мамичев сформулировал из своего опыта судебных разбирательств:

• Копилефтные лицензии очень опасны для проприетарных продуктов, даже не подпадающих под ограничения.

• Решения судов полностью непредсказуемы, поэтому нужно избегать самого предмета спора.

• Десять раз подумайте об использовании копилефтных лицензий наподобие GNU GPL.

Все самое важное о лицензиях Open source коротко

Подойдут для коммерческих целей все разрешительные лицензии— например, MIT, BSD, Apache. Они позволяют распространять ПО как угодно — нужно только указать в коде информацию о лицензии и разделить, какой кусок кода скопировали, а какой написали самостоятельно. Самая безопасная для РФ разрешительная лицензия — Apache, защищает от судебных исков, если в коде был запатентованный компонент. 

Не подойдут для коммерческих целей большиство копилефтных лицензий  — по их условиям нужно распространять модифицированное ПО. Важно, чтобы ваши наработки были открытые и бесплатные для других пользователей. Единственная копилефтная лицензия, которую можно использовать в коммерческих целях — Eclipse Public License v.1. Важно — на все претензии к ПО с такой лицензией придется отвечать самостоятельно. 

Три главных мысли на тему Open source:

Первоначально статья опубликована в блоге ispmanager

Другие мои статьи, как соблюдать законы в IT 

Как хостерам попасть в реестр РКН, зачем его придумали и что будет, если этого не сделать

Новый закон для хостинг-провайдеров: как попасть в реестр Роскомнадзора и удержаться