Open source: как безопасно использовать открытый код и не лишиться прав на ПО

Привет! Я Олег Макаров, ведущий юрист 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 подробно «разжевали» терминологию, учли проблему патентов, тивоизации и добавили информацию о последствиях нарушения условий.

Тивоизация — ситуация, когда разработчик технически запрещает пользователям менять установленное на устройстве ПО. Например, из-за тивоизации нельзя дорабатывать программы на 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 v.2. Доля среди всех Open source проектов — 6%.

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

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

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

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

Microsoft Public License (MPL) — лицензия 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. Важно — на все претензии к ПО с такой лицензией придется отвечать самостоятельно.

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

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

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

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

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

1010
Начать дискуссию