Лига Сисадминов

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

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

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

«Взял код — поделись со всеми результатом» — копилефтные лицензии. Название произошло от игры слов и противопоставления разрешительным: 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 подробно «разжевали» терминологию, учли проблему патентов, тивоизации и добавили информацию о последствиях нарушения условий.

→ Тивоизация — ситуация, когда разработчик технически запрещает пользователям менять установленное на устройстве ПО. Например, из-за тивоизации нельзя дорабатывать программы на iPhone — можно использовать только ПО из App Store. Термин назвали в честь цифрового видеоплеера Tivo, который запрещал модифицировать установленное на нем ПО. Лицензия 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:

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

Штрафы, иски, потеря прав на ПО — возможные последствия нарушения условий лицензий. Сумма компенсаций зависит от того, насколько крупная компания, права которой вы нарушили.

Если нужно запретить пользователям менять ПО на устройстве, то подойдут копилефтные лицензии GPL v2, LGLP v2.1 и AGPL».

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