Разбираемся в ограничениях на использование опенсорса
В 2021 году компания Elastic сменила лицензию поисковой системы Elasticsearch и веб-интерфейса Kibana с открытой Apache 2.0 на несвободную SSPL 1.0. Поводом стало то, что крупные технологические компании и провайдеры облачных сервисов пользовались продуктами Elastic, не покупая коммерческой лицензии. Исходный код остался доступным, однако не считается «открытым» в соответствии с принципами OSI (Open Source Initiative), потому что сторонние разработчики не могут использовать его бесплатно.
В ответ компании начали создавать форки и использовать открытый код Elastic для развития собственных продуктов, а разработчики, которые вносили свой вклад в развитие программ, осудили решение правообладателя. Подобные случаи показывают, что выбор лицензии может существенно повлиять на коммерческое развитие опенсорс-проекта и сообщество разработчиков. Рассказываем о тонкостях лицензирования ПО с открытым кодом и о том, почему лицензиями не стоит пренебрегать.
Этим материалом мы продолжаем проект «Исходный код», посвященный опенсорсу: его истории, философии, ключевым принципам, самым известным и важным разработкам, а также законодательству и лицензированию. Проект подготовлен при поддержке высокопроизводительного и масштабируемого российского веб-сервера Angie.
Хотя компоненты программ с открытым исходным кодом по определению доступны всем, некоторые правообладатели не хотят, чтобы продукт, зачастую созданный на бескорыстной основе, бесконтрольно использовался и продавался. Поэтому они запрещают использовать открытый код в проприетарном ПО и даже требуют выпускать продукт, созданный на основе опенсорса, в открытый доступ. Впрочем, это не означает, что опенсорсные решения нельзя использовать в коммерческих целях. Существуют, например, платные версии Linux, владельцы которых зарабатывают на продаже лицензий дистрибутивов и поддержке клиентов. Допустимые сценарии использования софта, определенные правообладателем, описываются в лицензии.
Опенсорсные лицензии можно условно разделить на две категории: пермиссивные (разрешительные) и копилефтные (вирусные). Первые позволяют использовать исходный код в любых проектах, в том числе и проприетарных. Вторые требуют, чтобы производный софт распространялся по той же лицензии, что исходный. Иначе говоря, исходный код всегда должен быть открытым и распространяться также на условиях копилефтной лицензии.
Фонд свободного программного обеспечения (Free Software Foundation) разделяет копилефтные лицензии на две категории: с сильным и слабым копилефтом. Сильный копилефт не подразумевает условий, при которых производный софт можно распространять под любой другой лицензией, кроме той, что используется в исходном коде. Слабый копилефт, напротив, предусматривает такие условия. Например, лицензия EPL (Eclipse Public License), разработанная на базе Common Public License, общественной лицензии IBM, позволяет использовать исходный код в проприетарных программах. Главное условие — его нужно вынести в отдельный файл программы.
Большие проекты зачастую используют сразу несколько опенсорсных компонентов. И перед тем, как отправлять их в Продакшн — это финальный этап разработки, на котором версия ПО протестирована, исправлена, готова к работе и продаже, либо обновлению уже существующей версии.
С пермиссивными лицензиями все просто: большинство из них совместимы между собой, с другими свободными и даже с проприетарными лицензиями. Фрагменты исходного кода останутся под собственными лицензиями, а новый проект может существовать под любой другой. Копилефтные лицензии, напротив, не только несовместимы с пермиссивными и проприетарными, но могут быть несовместимы даже друг с другом. Так, например, GPLv2 несовместима с GPLv3. Хотя FSF позволяет использовать в рамках одного проекта продукты с этими лицензиями, но только при одном условии: разработчик должен указать, что «программа выпускается под GNU GPL версии N или более поздней».
Ряд копилефтных лицензий все-таки совместимы друг с другом. К их числу относятся, к примеру, GPLv3 и EUPL 1.2. В крайних случаях можно перелицензировать продукт целиком. Иначе говоря, попросить всех правообладателей согласиться с заменой лицензии. Такую процедуру провела компания Mozilla Foundation для браузера Mozilla Firefox.
Некоторые продукты выпускаются с двойным или даже мультилицензированием — ПО может иметь несколько лицензий, причем как открытых, так и проприетарных. Проприетарная лицензия может подразумевать оказание платной технической поддержки и ряд дополнительных возможностей, которых нет в ПО с открытой лицензией. В таком случае, если кто-то хочет использовать код в некоммерческих целях, он может делать это под опенсорс-лицензией и соблюдать ее условия (например, открыть модифицированный код исходной программы). Если же пользователь хочет использовать ПО с открытым кодом, но скрыть код своего ПО, то он может использовать коммерческую лицензию и делать что угодно. Это одна из распространенных бизнес-моделей в опенсорсе.
Лицензию на опенсорс можно написать самостоятельно, например отредактировав MIT или Apache. Однако следует позаботиться о том, чтобы ею могли воспользоваться люди, которые не разбираются в юридических тонкостях. Такого принципа придерживается Open Source Initiative (OSI) — организация, которая с 1998 года продвигает открытое ПО и претендует на звание главного верификатора открытых лицензий.
К сегодняшнему дню OSI одобрила более 100 лицензий. Среди разработчиков опенсорс-продуктов существует негласная договоренность: если лицензия не получила одобрения OSI, значит, она не соответствует «духу опенсорса» и использовать ее нежелательно.
Изучение самописных лицензий может потребовать дополнительных усилий. Крупные компании, привыкшие внимательно следить за юридическими нюансами, вероятно, вовсе не станут использовать продукты с самописными лицензиями. А для широкого круга пользователей намного удобнее, когда лицензия проверена авторитетной организацией и одобрена как опенсорсная. Это облегчает им жизнь, избавляя от необходимости вчитываться в каждое слово.
Проверкой лицензий также занимается Фонд свободного программного обеспечения (Free Software Foundation), основанный Ричардом Столлманом. Фонд разработал и написал текст лицензии GPL и выносит определение о совместимости с ней других лицензий. Со списком проверенных лицензий можно ознакомиться здесь. Важно отметить, что многие лицензии, которые считаются опенсорными, FSF не признает по собственным критериям и относит к категории несвободных. В России пока не существует организаций, которые занимаются проверкой опенсорсных лицензий.
Полагаю, что такие организации в России не нужны. Во-первых, свободные лицензии по самой своей сути носят международный характер и не требуют национального одобрения. Во-вторых, одобрение со стороны FSF и OSI нужно в связи с тем, что ряд свободных лицензий налагает ограничения на лицензии совместно используемых продуктов, ссылаясь на FSF и OSI.
Алексей Смирнов, генеральный директор компании BaseALT
Однако в будущем ситуация может измениться благодаря распространению опенсорсных операционных систем и другого ПО. Например, в России уже есть собственная открытая лицензия версии 1.1. Ее текст выложен в репозитории государственного проекта «Витрины данных НСУД».
Открытая государственная лицензия принята в рамках постановления Правительства РФ от 10.10.2022 № 1804 об эксперименте по предоставлению права использования программ для ЭВМ, алгоритмов, баз данных и документации к ним (в том числе принадлежащих государству) на условиях открытой лицензии и по созданию условий для использования открытого программного обеспечения. Это уже не проект, а полноценный, готовый к использованию текст лицензии (шаблон). Отмечу, что обязательное использование этого текста лицензионного договора относится только к участникам, прямо указанным в упомянутом постановлении. Иные участники рынка открытого и свободного ПО вольны выбирать любую лицензию, которая кажется им подходящей (при условии соблюдения прав использования включенных в продукт компонент). Подробнее о важности выбора лицензии — в нашем аналитическом материале на сайте (russiaos.ru). Открытая государственная лицензия (ОГЛ) составлена на основе тех же принципов, что и международная лицензия Apache, и потому можно говорить о ее условной (но не официальной) совместимости с такими лицензиями.
Надежда Кострюкова, и. о. директора АНО «Открытый код»
Прежде всего необходимо проверить лицензии продуктов, которые планируется включить в проект. Если они пермиссивные, их можно использовать в любом проекте — и открытом, и закрытом. Если лицензии копилефтные, значит, придется открыть исходный код.
Исключением будут только библиотеки для разработки с лицензией LGPL: их можно использовать в проприетарных продуктах. При этом необходимо явно сообщить об использовании библиотеки с LGPL. Кроме того, могут возникнуть ограничения при включении в текст программы свободного кода или при Процесс объединения файлов программы в один исполняемый файл (или библиотеку) во время компиляции.
На GitHub проект может быть открытым, но не иметь никакой лицензии. В таком случае он подчиняется условиям использования GitHub. Это означает, что, даже если GitHub позволяет просматривать код, его нельзя использовать, распространять и модифицировать в собственном продукте, если автор явно не даст на это разрешение.
Проект может иметь несколько лицензий, в том числе проприетарные для платного использования. В таком случае необходимо выбрать лицензию, которая будет совместима с продуктом. Из-за ошибки в выборе лицензии компания Hancom в 2017 году получила иск от Artifex Software, которой принадлежал набор программ Ghostscript, позволяющий интерпретировать язык PostScript и документы PDF и распространяющийся по двум лицензиям: коммерческой и открытой. Hancom пользовалась открытой лицензией и должна была открыть код офисного пакета, но не сделала этого. Компании урегулировали спор до суда, так и не огласив подробности.
При этом лицензии не имеют ограничений в зависимости от страны разработки продукта.
Большинство опенсорсных продуктов распространяются на условиях лицензий, в тексте которых не указана разрешенная территория использования. В соответствии с российскими коллизионными нормами Гражданского кодекса РФ при наличии иностранного элемента (иностранного правообладателя) в отношении лицензионного договора (лицензии), должно применяться право страны, на территории которой лицензиату разрешается использование результата интеллектуальной деятельности. Если же такое использование разрешается на территориях одновременно нескольких стран, то подлежит применению право страны, где находится место жительства или основное место деятельности лицензиара (п. 8 ст. 1211 ГК РФ).
Александр Журавлев, управляющий партнер юридической компании ЭБР, председатель комиссии по правовому обеспечению цифровой экономики Московского отделения Ассоциации юристов России, сооснователь образовательной платформы Moscow Digital School
Однако для большинства проектов, поддерживаемых и развиваемых независимыми разработчиками, определить страну проживания или местонахождения лицензиара практически невозможно. При этом, если основная ветка проекта поддерживается и развивается иностранной некоммерческой организацией, например The Linux Foundation, лицензиаром в таком случае будет именно она, поскольку ее разработчики будут получать контрибьюты и вносить в них изменения для объединения с другими компонентами. Чаще всего это означает создание производного произведения, права на которое будут принадлежать иностранной организации, местонахождение которой определяется в соответствии с учредительными документами.
Вендоры ПО с открытым кодом нередко сталкиваются с проблемами лицензирования, пытаясь коммерциализировать собственные продукты. Например, в августе 2023 года компания HashiCorp объявила о замене лицензии в продуктах Terraform, Packer, Vault, Boundary и других с открытой MPL на BSL 1.1 (Business Source License). BSL позволяет использовать открытый код в некоммерческих целях, а для коммерческих требует разрешения правообладателя. Однако некоторые компании, использовавшие исходный код продуктов HashiCorp, сделали форк исходного кода и объявили о развитии форков под открытыми лицензиями.
Если вы используете в софте исходный код продуктов, которые сменили лицензию, возможно, стоит поискать аналогичные форки с открытой лицензией. С другой стороны, если вы сами выводите продукт в открытый доступ, имейте в виду, что вне зависимости от лицензии это подразумевает использование продукта другими разработчиками, пусть даже им придется делать это через форк.
Если разработчики хотят сделать продукт доступным для использования без ограничений, следует выбрать одну из пермиссивных лицензий: MIT, BSD или Apache. Продукт с такой лицензией будет популярнее, чем с GPL, поскольку его можно будет использовать в любых опенсорсных и проприетарных решениях.
Если компания выбирает лицензию GPL или ее аналоги, любые производные продукта смогут выходить только под лицензией GPL. При этом проекты под копилефтными лицензиями развиваются динамичнее, поскольку код всех участников тоже открытый и «возвращается» в проект. Это делает сотрудничество более эффективным.
Сегодня выводить продукты в опенсорс крупным компаниям помогают внутренние команды, так называемые Open Source Program Office. Они объединяют сотрудников с различными компетенциями и координируют процессы, поэтому разработчикам не нужно искать юристов, безопасников и других специалистов. Кроме того, существуют ресурсы, такие как choosealicense, которые помогают подобрать лицензию.
Наконец, при выводе в опенсорс необходимо учитывать зависимости между лицензиями продуктов, которые содержатся в коде. Вам потребуется указать авторов, правообладателей, торговые марки и многое другое. Особых требований к опенсорсным лицензиям в России нет, поэтому использовать можно любую распространенную лицензию.
При разработке текста собственной лицензии также следует учитывать нормы ст. 1286.1. ГК РФ. Так, например, если в тексте вашей лицензии не указан срок действия, то будет считаться, что лицензия на ПО представлена на весь срок действия исключительного права. А в отношении других видов произведений (например, если вы делаете отдельную лицензию на документацию) право использования этой документации будет считаться предоставленным на пять лет. Если же в тексте вашей лицензии не будет указана территория, на которой допускается использование соответствующего произведения, то такое использование будет считаться предоставленным на территории всего мира (п. 3 ст. 1286.1 ГК РФ).
Пока в России еще не было ситуаций, при которых возникали бы юридические проблемы из-за использования опенсорс-лицензий в программных продуктах. При этом мы не можем исключать таких проблем в будущем при эскалации взаимоотношений с США. Два совета, на что нужно обращать внимание при использовании зарубежного опенсорсного продукта.
Во-первых, проверьте правообладателя опенсорса. Все корпорации, такие как Microsoft, IBM, Google, очень активно и много участвуют в создании опенсорс ПО. И надо понимать, что иностранные правообладатели при введении законодательством США экспортных ограничений на распространение опенсорс-технологий в Россию будут предпринимать меры по ограничению доступа технологий в Россию.
Во-вторых, необходимо смотреть на наличие оговорок об экспортных ограничениях в тексте лицензии. Есть ряд опенсорс-лицензий, которые уже сейчас такие оговорки содержат, например Android Software Development Kit License Agreement.
Александр Журавлев, управляющий партнер юридической компании ЭБР, председатель комиссии по правовому обеспечению цифровой экономики Московского отделения Ассоциации юристов России, сооснователь образовательной платформы Moscow Digital School
Нет в России и отдельного закона о регулировании использования опенсорса. Однако с ним связана статья 1286.1 в Гражданском кодексе. Согласно ей, неправомерное использование произведения на основе открытой лицензии влечет для нарушителя компенсацию убытков или взыскание компенсации. К такому лицу также может быть предъявлено требование о публикации решения суда с указанием действительного правообладателя.
Наибольшее количество судов, связанных с использованием опенсорса, происходит в США. В октябре 2021 года фонд Software Freedom Conservancy (SFC) обвинил производителя электроники Vizio в нарушении использования своих продуктов, поскольку компания не открыла исходный код продукта в соответствии с лицензией GPL. Спор примечателен тем, что SFC не был владельцем исходных продуктов с лицензией GPL, но подал в суд от лица покупателя продукции Vizio.
В России судов, связанных с использованием опенсорса, практически нет.
Можно назвать только одно такое громкое дело — противостояние Nginx и Рамблер, начавшееся 12 декабря 2019 года. Суть его заключалась в претензии Rambler по статье 146 УК РФ «Нарушение авторских и смежных прав» к Игорю Сысоеву, который начал разрабатывать один из самых популярных в мире веб-серверов Nginx (распространяется по 2-пунктной лицензии BSD, есть производные проприетарные продукты), работая в Рамблере. Тогда в поддержку Сысоева выступили даже российские технологические гиганты: Яндекс, VK, Озон, МТС. В итоге претензия успехом не увенчалась, 18 мая 2020 года дело было прекращено.
Дмитрий Винокуров, Performance QA Engineer в Miro
Нет в России и отдельного закона о регулировании использования опенсорса. Однако с ним связана статья 1286.1 в Гражданском кодексе. Согласно ей, неправомерное использование открытого кода, например, за пределами условий лицензии или в результате нарушения личных неимущественных прав влечет внедоговорную ответственность.
В России были сложности с особенностями российского законодательства: в случаях, если в лицензионном договоре не указывались территория и срок действия, то территория ограничивалась Россией, а срок — 5 годами. После введения в ГК РФ понятия «открытая лицензия» эта проблема была решена.
Тут важно уточнить терминологию. Англоязычный термин Free Software означает «свободное ПО», и приходится постоянно указывать, что имеется в виду именно свободное, а не бесплатное. С русским термином «свободное» такой неоднозначности нет. Зато термин «открытый код» крайне неоднозначен, потому что опенсорс подразумевает не только доступность исходников, но и передачу определенного набора прав.
Алексей Смирнов, генеральный директор компании BaseALT
Популярные опенсорсные лицензии не содержат географических ограничений, поэтому при выборе зарубежных продуктов лицензия не играет важной роли.
По вопросу допустимых для использования в РФ опенсорсных лицензий можно ознакомиться с методическими Рекомендации ЦКИТ (Центр компетенций по импортозамещению в сфере информационно-коммуникационных технологий) применяются только в контексте включения ПО в реестр и соответствия СПО, распространяемых на условиях открытых или свободных лицензий в составе ПО. Если разработчик не планирует включать свое ПО в реестр, он может использовать любое СПО, распространяемое на условиях любых открытых лицензий.
Дмитрий Винокуров, Performance QA Engineer в Miro
С самого начала опенсорс подразумевал свободу использования ПО. Однако единого мнения о том, как должна выглядеть эта свобода, так и не появилось. Ричард Столлман и FSF считают, что производное ПО обязательно должно быть свободным, а авторы лицензий BSD, MIT и других — что нельзя ограничивать свободу производного ПО и оно может быть любым, в том числе и проприетарным.
Если не учитывать особенности лицензии, использование опенсорса может привести к претензиям со стороны правообладателей. В России таких прецедентов практически нет. Однако софт с открытым кодом становится популярнее, а законодательство совершенствуется, поэтому это, скорее всего, дело времени.
При использовании в России стоит сейчас обращать внимание не только на содержание лицензии, но и на то, кто является правообладателем. Если это большое сообщество разработчиков, неблагоприятное изменение лицензионных условий на новые версии ПО практически невозможно, но если правообладателем является корпорация, то это реально.
Алексей Смирнов, генеральный директор компании BaseALT
Реклама: ООО «Веб-Сервер», ИНН 9704151517, 2SDnjeg12wJ
Что такое опенсорс и почему он важен для IT-индустрии
Наверняка вам доводилось слышать выражение «опенсорс». Может быть, вы даже понимаете, что под этим термином скрывается «программное обеспечение с открытым исходным кодом». Но какие возможности такая открытость дает разработчикам и почему может быть выгодна обыкновенным пользователям? Рассказываем о разработке и значимости опенсорс-проектов.