АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Лицензия open source

Лице́нзия open source (лицензия с открытым исходным кодом) — лицензия на программное обеспечение, которая предоставляет пользователям права на использование, изучение, изменение и распространение программного обеспечения (включая его исходный код). Эти лицензии способствуют разработке свободного и открытого программного обеспечения (FOSS).

Законы об интеллектуальной собственности (ИС) ограничивают изменение и распространение творческих работ. Лицензии с открытым исходным кодом используют эти существующие правовые механизмы для обратных целей. Они предоставляют получателю права использовать программное обеспечение, изучать исходный код, изменять его и распространять модификации. Эти критерии изложены в определении открытого исходного кода.

A pie chart displays the most commonly used open source license as Apache at 30 %, MIT at 26 %, GPL at 18 %, BSD at 8 %, LGPL at 3 %, MPL at 2 %, and remaining 13 % as licenses with below 1 % market share each.

После 1980 года в США программное обеспечение стало рассматриваться как литературное произведение, подпадающее под действие авторского права. Ричард Столлман основал движение за свободное программное обеспечение в ответ на рост популярности проприетарного программного обеспечения. Термин «открытый исходный код» использовался организацией Open Source Initiative (OSI), основанной разработчиками свободного программного обеспечения Брюсом Перенсом и Эриком С. Рэймондом. Термин «открытый исходный код» подчёркивает преимущества модели открытой разработки, а не свободу программного обеспечения. Хотя цели, стоящие за этими терминами, различны, лицензии с открытым исходным кодом и лицензии свободного программного обеспечения описывают один и тот же тип лицензий[1].

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

История

Интеллектуальная собственность и авторское право

Интеллектуальная собственность (ИС) — это правовая категория, которая рассматривает творческий продукт как собственность, аналогичную частной собственности[2]. Правовые системы предоставляют владельцу ИС право ограничивать доступ во многих аспектах[3]. Владелец может продавать, сдавать в аренду, дарить или лицензировать свою собственность. Существует несколько типов законов об ИС, охватывающих программное обеспечение, включая товарные знаки, патенты и авторские права[4].

Большинство стран создали законы об авторском праве в соответствии с Бернской конвенцией с небольшими изменениями[5]. Согласно этим законам создатель оригинального произведения или его работодатель владеет авторским правом на эту работу и, следовательно, имеет исключительное право делать копии, выпускать модифицированные версии, распространять копии, публично исполнять или демонстрировать работу публично. Модифицированная версия оригинальной работы называется производным произведением[6]. Если оригинальная работа не находилась в общественном достоянии, производная работа может распространяться только с разрешения владельца авторского права[7].

Движение за свободное программное обеспечение

В 1980 году в США после внесения правительством поправок в закон программное обеспечение стало рассматриваться как литературное произведение и ограничивалось законами об интеллектуальной собственности[8].

Американский активист и программист Ричард Столлман основал движение за свободное программное обеспечение как протест против тенденций распространения проприетарного программного обеспечения и закрытых моделей разработки[9]. В течение 1980-х годов он начал проект GNU по созданию свободной операционной системы, написал эссе о свободе, основал Фонд свободного программного обеспечения (FSF) и написал несколько лицензий свободного программного обеспечения[10]. При этом FSF использовал существующие законы об интеллектуальной собственности для противоположных целей: вместо наложения ограничений, свободное программное обеспечение предоставляло свободы получателю[11].

Инициатива открытого исходного кода

Термин «открытый исходный код» появился в 1990-х годах как альтернативное обозначение свободного программного обеспечения; были установлены конкретные критерии для определения того, какие лицензии охватывают свободное и открытое программное обеспечение[12][13]. Активные члены сообщества свободного программного обеспечения, Брюс Перенс и Эрик С. Реймонд, основали Инициативу открытого исходного кода (OSI)[14].

Эрик С. Реймонд был сторонником использования термина «открытый исходный код» вместо «свободного программного обеспечения», так как считал, что открытый исходный код более привлекателен для бизнеса и лучше отражает ощутимые преимущества разработки свободного и открытого программного обеспечения (FOSS).

Одна из целей Реймонда заключалась в расширении существующего сообщества хакеров за счёт включения крупных коммерческих разработчиков[15]. В книге «Собор и базар» Реймонд сравнил разработку с открытым исходным кодом с базаром — открытым общественным рынком. Он утверждал, что помимо этических принципов, открытая модель предоставляет преимущества, которые не может воспроизвести проприетарное программное обеспечение[16][17]. Реймонд уделял большое внимание обратной связи, тестированию и отчётам об ошибках[18]. Он противопоставлял проприетарную модель, где небольшие группы секретных сотрудников выполняли эту работу, разработке Linux, где группа тестировщиков потенциально включала весь мир[19]. OSI удалось предоставить возможность разработки программного обеспечения с открытым исходным кодом крупнейшим корпоративным разработчикам, включая Sun Microsystems, IBM, Netscape, Mozilla, Apache, Apple Inc., Microsoft и Nokia. Эти компании выпустили код под существующим лицензиям и разработали собственные проекты для одобрения OSI[20][21].

Создание стандартов

Для проекта Debian Брюс Перенс предложил Критерии Debian по определению свободного программного обеспечения (DFSG)[22], которые были разработаны с целью предоставить более конкретный и объективный стандарт для свободного и открытого программного обеспечения (FOSS), который Debian будет размещать в своих репозиториях[23]. OSI принял DSFG и использовал их в качестве основы для своего Определения открытого исходного кода[24].

Photograph of Bruce Perens at a conference

Фонд свободного программного обеспечения поддерживает конкурирующий набор критериев — Определение свободного программного обеспечения[25].

Исторически эти организации и их наборы критериев были признанными авторитетами в определении того, распространяется ли лицензия на свободное и открытое программное обеспечение[26]. Несмотря на значительное разнообразие отдельных лицензий, конкурирующие определения мало различаются[13]; каждое из них требует, чтобы тот, кто получает лицензированное программное обеспечение, имел возможность использовать, изменять и распространять лицензированную работу[27].

Типы лицензий

Лицензии с открытым исходным кодом подразделяются на 2 основных типа[28][29]:

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

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

Лицензии open source основаны на законе об авторском праве, но на открытый код распространяются и другие формы интеллектуальной собственности[30]. 

Патент

Основные лицензии с открытым исходным кодом, выданные с конца 1990-х годов, содержат патентные разрешения, и распространяются на патенты, принадлежащие разработчикам[31].

Патенты на программное обеспечение защищают идеи и, вместо конкретной реализации, охватывают любую реализацию формулы изобретения, а также дают владельцу право исключать других из создания, использования, продажи или импорта продуктов, основанных на идее. Поскольку патенты предоставляют право исключать, а не право создавать, можно иметь патент на идею, но все равно не иметь возможности законно реализовать её, если изобретение основано на другой запатентованной идее. Таким образом, патентные разрешения с открытым исходным кодом могут предоставлять разрешение только на защищённые патенты. Они не могут гарантировать, что третья сторона не запатентовала какие-либо концепции, воплощённые в коде[30].

Более ранние разрешительные лицензии не содержат прямого упоминания о патентах и предусматривают только косвенное предоставление патента в своих предложениях об использовании или продаже защищённых материалов[32].

Более новые копилефт-лицензии и лицензия Apache 2004 года (Apache License 2.0) предоставляют явные патентные гарантии и ограниченную защиту от судебных разбирательств по патентным спорам[33]. Эти положения об ответных мерах в отношении патентов (англ. Patent retaliation) защищают разработчиков, прекращая действие лицензий для любой стороны, которая инициирует патентный иск в отношении защищённого программного обеспечения[33].

Товарный знак

Товарный знак — единственная форма интеллектуальной собственности, не являющаяся общей для свободного программного обеспечения (FOSS) и программного обеспечения с открытым исходным кодом. Товарные знаки на FOSS функционируют так же, как и любые другие торговые знаки[34].

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

Отказ от контроля над товарным знаком приведёт к потере этого товарного знака. Таким образом, ни одна лицензия на программное обеспечение с открытым исходным кодом не предусматривает свободного использования товарного знака[36].

Ограничения на использование товарных знаков могут перекрывать авторские права и влиять на материалы, которые обычно находятся в свободном доступе[37].

Дублирование товарных знаков может сделать проекты с открытым исходным кодом и бесплатным контентом уязвимыми для враждебного поглощения, если сторонние лица подадут заявку на регистрацию товарных знаков для производных работ[38]. Один из примеров — дело Андрея Дуксина о регистрации проекта ARTSCP (производной работы SCP Foundation) как товарного знака[39].

Разрешительная лицензия

Разрешительные лицензии (также известные как академические лицензии[40]), позволяют получателям использовать, изменять и распространять программное обеспечение без обязательств предоставлять исходный код. Организации создали эти лицензии для общественного распространения своих разработок[40]. Разрешительные лицензии обычно короткие, часто меньше страницы текста, с небольшим набором условий. Большинство из них включают отказ от гарантий и обязательств перед авторами. Некоторые из них содержат чёткие положения о патентах, товарных знаках и других формах интеллектуальной собственности[41].

Лицензия BSD

Первую лицензию с открытым исходным кодом разработал Калифорнийский университет в Беркли для распространения своей операционной системы Berkeley Software Distribution (BSD). Лицензия BSD и её более поздние варианты разрешают модификацию и распространение подпадающего под действие лицензии программного обеспечения[42][43].

Лицензия MIT

Массачусетский технологический институт (MIT) разработал академическую лицензию, основанную на оригинальной лицензии BSD. Лицензия MIT уточнила условия, сделав их более чёткими[44]. Например, лицензия MIT описывает право на сублицензирование[45].

M I T campus at night

Одной из сильных сторон разработки ПО с открытым исходным кодом является непрерывный процесс, в рамках которого разработчики могут опираться на производные работы друг друга и объединять свои проекты в коллективные работы. Явное предоставление сублицензий на защищённый код обеспечивает юридическое преимущество при отслеживании цепочки авторства[44].

BSD и MIT являются шаблонами, которые могут быть адаптированы к любому проекту. Они широко адаптированы и используются многими проектами FOSS[42].

Лицензия Apache

Лицензия Apache является более всеобъемлющей и понятной. Фонд Apache Software Foundation разработал её для своего HTTP-сервера Apache HTTP Server.

Версия 2, опубликованная в 2004 году, предоставляет юридические преимущества по сравнению с простыми лицензиями и предоставляет аналогичные права[46]. В то время как лицензии BSD и MIT предполагают неявное предоставление патента[47], лицензия Apache включает раздел о патентах с явным предоставлением от авторов[48].

Кроме того, это одна из немногих разрешительных лицензий с пунктами о об ответных мерах в случае нарушения патента (англ. Patent retaliation)[49], которые вступают в силу, если лицензиат инициирует судебный процесс о нарушении патентных прав в отношении защищённого кода. В такой ситуации патентные права аннулируются. Эти пункты защищают от патентного троллинга[50].

Копилефт-лицензии

Подробнее
Копилефт

Копилефт-лицензии требуют, чтобы исходный код распространялся вместе с программным обеспечением, и чтобы код был доступен по аналогичной лицензии[51][52]. Как и разрешительные лицензии, большинство копилефт-лицензий требуют указания авторства[53] и отказываются от подразумеваемых гарантий[54]. Копилефт использует ограничения законов об интеллектуальной собственности — вопреки их обычному назначению — чтобы обеспечить открытость кода[55].

A sticker reads, «Copyleft circled letter L».

Термин копилефт и связанный с ним слоган «Все права отменены» (англ. All rights reversed) ранее использовались в шутливой форме в Principia Discordia и Tiny BASIC. Современное использование этого термина началось с усилий Ричарда Столлмана по созданию свободной операционной системы. В 1984 году программист Дон Хопкинс отправил по почте Столлману письмо с мануалом, на конверте была наклейка «Copyleft Ⓛ». Столлман, работавший в этот период над операционной системой GNU, начал использовать этот термин[56]. Ранняя версия лицензирования копилефт использовалась для выпуска GNU Emacs в 1985 году[11][57]. Этот термин стал ассоциироваться с более поздними взаимными лицензиями фонда FSF, в частности, с GNU General Public License (GPL)[58].

Ричард Столлман заявил, что «основная идея копилефта заключается в в том, чтобы использовать закон об авторском праве, но перевернуть его так, чтобы он служил противоположному назначению: вместо средства приватизации программного обеспечения становится средством сохранения свободы программного обеспечения»[59].

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

Сильные и слабые копилефт-лицензии

Лицензии с копилефтом в свою очередь можно разделить на «сильные» и «слабые» в зависимости от определения в лицензии производной работы[51].

«Сильный копилефт» (англ. strong copyleft) — это принцип лицензирования программного обеспечения, при котором все производные работы обязаны распространяться на тех же условиях, что и оригинал, с полным раскрытием исходного кода (GPL, AGPL).

Слабый копилефт (англ. weak copyleft) — это подход в лицензировании свободного ПО, при котором требования по открытости кода распространяются не на весь проект, а лишь на изменённые части исходного (лицензированного) кода (LGPL, MPL).

GNU General Public License (GPL) v2.0 и 3.0

Лицензия GPL, опубликованная фондом Free Software Foundation (FSF), является одной из первых копилефт-лицензий общего назначения.

GPL 3.0, запущенная в 2007 году, занимает третье место (по состоянию на 2 квартал 2025 года) по популярности среди open source-лицензий, согласно данным GitHub[60]. В неё добавлены положения о патентах, улучшена совместимость с другими лицензиями и запрещена тивоизация (Tivoization) — использование механизмов DRM для ограничения установки модифицированных версий ПО.

Среди известных проектов, использующих GPL, можно отметить WordPress, который распространяется под лицензией GPL 2.0.

Linux, в свою очередь, является одним из самых успешных open source-проектов всех времён, используемым на серверах, в облачной инфраструктуре, встроенных системах и даже в Android[61]. Однако основное ядро Linux доступно только под лицензией GPL 2.0, поскольку создатель Linux Линус Торвальдс не согласен с рядом положений, добавленных в версию 3.0, включая пункт о тивоизации[29].

Викиверситет использует лицензию GNU Free Documentation License (GFDL)[62].

Основные применяемые лицензии

  1. GNU Free Documentation License (GFDL) версии 1.2 или новее
    • Позволяет свободно копировать, распространять и изменять материал.
    • Требует сохранения указания авторства
    • Запрещает неизменяемые разделы, текст первой и последней обложки (в контексте Викиверситета)
    • Ссылка на текст лицензии: http://www.gnu.org/copyleft/fdl.html

GNU Affero General Public License (AGPL) 3.0

Лицензия Affero General Public License (AGPL) похожа на GPL 3.0 и является «сильной» копилефт-лицензией, направленной на продвижение свободы программного обеспечения и сохранение модификаций в открытом доступе. Её ключевое отличие заключается в том, что она ориентирована на веб-сервисы и приложения, где программное обеспечение работает на серверах, а не распространяется в виде исполняемых файлов.

Опубликованная в 2007 году фондом FSF, AGPL 3.0 стала популярной благодаря росту облачных вычислений и программного обеспечения как услуги (SaaS), и по состоянию на 2025 год — это пятая по популярности open source-лицензия[29].

GNU Lesser General Public License (LGPL)

LGPL, также разработанная фондом FSF, является «слабой» копилефт-лицензией. Она менее строгая по сравнению с GPL, что делает её более удобной для бизнеса. LGPL обычно используется для библиотек, где авторы хотят поощрять вклад сообщества, но при этом позволяют проприетарному ПО подключаться к библиотекам без необходимости раскрывать весь исходный код. Если кто-то изменяет саму открытую библиотеку, изменения должны быть опубликованы под лицензией LGPL, но это не касается всей программы, которая использует библиотеку[29].

Mozilla Public License 2.0

Portrait of Mitchell Baker

Опубликованная фондом Mozilla Foundation в 2012 году, Mozilla Public License (MPL) 2.0 занимает десятое место по популярности среди open source-лицензий, согласно метрике GitHub. MPL — это «слабый» копилефт, предназначенный для защиты проприетарного кода, одновременно позволяя разработчикам пользоваться преимуществами открытого ПО. В отличие от LGPL, ориентированной на библиотеки, и GPL, применимой на уровне проектов, MPL действует на уровне отдельных файлов, требуя от пользователей делиться только ограниченным набором кода[29].

Другие виды копилефт-лицензий

Практические преимущества копилефт-лицензий привлекли коммерческих разработчиков. Корпорации использовали и написали взаимные лицензии с более узкой областью применения, чем GPL[64].

Например, Netscape разработала собственные условия копилефт после отклонения разрешительных лицензий для проекта Mozilla[21].

IBM разработала Common Public License (CPL) и позже приняла Eclipse Public License (EPL).

Сравнение лицензий open source и свободных

Лицензии на свободное ПО также являются лицензиями на ПО с открытым исходным кодом[65].

Отдельные термины «свободное ПО» и «ПО с открытым исходным кодом» отражают разные ценности, а не юридическое различие[66].

Оба движения (FSF и OSI) и их формальные определения требуют, чтобы защищённая работа была доступна с исходным кодом и с разрешением на изменение и распространение[13].

Иногда возникают ситуации, когда лицензия принимается только одной организацией, но наиболее популярные лицензии свободного программного обеспечения являются лицензиями с открытым исходным кодом, включая GPL[67].

  • Если программа свободная, она почти всегда открытая (соответствует и FSF, и OSI);
  • если программа открытая, она не обязательно свободная (может не давать всех четырёх свобод FSF).

Примеры совпадений: GPL, MIT, Apache — одобрены обеими организациями.

Пример расхождения: NASA Open Source Agreement — признана OSI, но отвергается FSF как слишком ограничительная.

Хотя на практике эти понятия (лицензия open source и свободная лицензия) часто пересекаются и могут считаться синонимами, между ними есть философские и юридические различия[68][69][70]:

Свободное ПО ПО с открытым исходным кодом
Различия в приоритетах Фокус на правах пользователя:
  • свобода запускать программу для любых целей;
  • свобода изучать и изменять код (обязателен доступ к исходникам);
  • свобода распространять копии;
  • свобода улучшать программу и публиковать изменения.

Акцент: этический — право человека на контроль над технологиями.

Фокус на практических преимуществах открытого кода:
  • улучшение качества и безопасности за счёт коллективного участия;
  • ускорение разработки;
  • гибкость адаптации.

Акцент: прагматичный — эффективность модели разработки.

Подход к лицензированию Требует, чтобы все производные продукты тоже распространялись под свободной лицензией (принцип копилефт, например, GPL). Это гарантирует сохранение свобод для конечных пользователей. Допускает более гибкие условия:
  • могут использоваться разрешительные лицензии (MIT, BSD, Apache), которые позволяют включать открытый код в проприетарные продукты;
  • не всегда требуют, чтобы модификации оставались открытыми.
Отношение к коммерческому использованию Не запрещает коммерцию, но ставит во главу угла сохранение свобод. Например, GPL разрешает продавать ПО, но с условием предоставления исходного кода и тех же прав покупателям. Чаще допускает интеграцию в коммерческие продукты без обязательного открытия кода производных решений (в зависимости от лицензии).
Критерии соответствия Оценивается по четырём свободам FSF. Лицензия должна гарантировать все из них без исключений. Соответствует 10 принципам OSI (например, свободное распространение, доступность исходного кода, отсутствие дискриминации).

Для избегания споров используются такие названия:

  • FOSS (Free and Open Source Software) — объединяет оба подхода;
  • FLOSS (Free/Libre and Open Source Software) — подчёркивает «свободу» (libre) в значении FSF.

Совместимость лицензий

Совместимость лицензий определяет возможность объединения исходных кодов разных лицензий в целях создания нового программного обеспечения.

Chart of license compatibility, full details in section.

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

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

При объединении кодовых баз исходные лицензии могут быть сохранены для отдельных компонентов, а более крупная работа выпущена под совместимой лицензией[73].

Разрешительные лицензии могут использоваться в работах с копилефтом, но этот материал не может быть выпущен под разрешительной лицензией. Некоторые слабые лицензии с копилефтом могут использоваться под GPL и считаются GPL-совместимыми. Программное обеспечение с GPL может использоваться только под GPL или AGPL[71]. Разрешительные лицензии широко совместимы, поскольку они могут охватывать отдельные части проекта.

Несколько лицензий, включая GPL и Apache License, были пересмотрены для улучшения совместимости[74].

Правоприменительная практика

Лицензии на свободное и открытое программное обеспечение успешно применяются в гражданских судах с середины 2000-х годов[75].

Portrait of Harald Welte

Мировая практика

В двух ранних судебных процессах — Якобсен против Катцера (Jacobsen v. Katzer) в США и Вельте против Сайткома (Welte v. Sitecom) в Германии — ответчики утверждали, что лицензии на открытое программное обеспечение недействительны[77][78] и не имеют законной силы. Суды США и Германии отклонили эти иски. Они постановили, что ответчики не могли законно распространять программное обеспечение, если лицензии не имели законной силы[75][76].

Суды установили, что распространение программного обеспечения означает согласие с условиями лицензии[79].

При выпуске программного обеспечения на физических носителях пользователь может получить согласие с уведомлениями, размещёнными на термоусадочной плёнке. При распространении в Интернете может использоваться согласие по клику (англ. clickwrap), цифровой эквивалент, при котором пользователь должен нажать кнопку, чтобы принять условия[80].

Программное обеспечение с открытым исходным кодом имеет дополнительный механизм принятия. Закон запрещает распространение без разрешения правообладателя[81]. Поэтому суды рассматривают распространение как принятие условий лицензии. Они могут включать положения об авторском праве или положения об исходном коде для лицензий с копилефтом[82][83].

Долго обсуждаемый вопрос в сообществе FOSS заключается в том, являются ли лицензии с открытым исходным кодом «простыми лицензиями» (англ. bare licenses) или контрактами[84]. Простая лицензия — это набор условий, при которых действия, иначе ограниченные законами об ИС, разрешены[75]. Согласно интерпретации простой лицензии, отстаиваемой FSF, дело в суд подаётся держателем авторского права как нарушение авторского права[75]. Согласно интерпретации как договора, дело может быть подано в суд любой заинтересованной стороной как нарушение договора[85].

В России

В судебной практике Суда по интеллектуальным правам (СИП) РФ решения, непосредственно связанные с открытыми лицензиями на ПО, встречаются редко. Это связано с тем, что споры в этой сфере часто касаются вопросов соблюдения условий лицензий, раскрытия исходного кода и ответственности за нарушения, которые не всегда доходят до судебного разбирательства в СИП. Судебная практика СИП по открытым лицензиям на ПО в России ограничена, и большинство дел касаются общих вопросов защиты авторских прав на код.

В зарубежных судах (например, в США) рассматриваются дела о нарушении открытых лицензий, где суды привлекают к ответственности за несоблюдение условий (например, отсутствие раскрытия исходного кода). В России подобная практика пока не получила широкого распространения.

Однако можно выделить несколько общих тенденций, затрагивающих открытые лицензии:

  • Защита авторских прав на исходный код. Код программы признаётся объектом авторского права и защищается как литературное произведение. Разработчик считается автором, если он создал код своим творческим трудом. Возникновение авторского права не требует регистрации, но его можно подтвердить различными способами, например, указанием автора в исходном коде, размещением в публичных репозиториях (GitHub) или регистрацией в Роспатенте[86].
  • Ответственность за нарушение условий лицензии. Несоблюдение условий открытой лицензии влечёт ответственность за нарушение исключительного права автора. Правообладатель может использовать меры защиты, предусмотренные ст. 1252 ГК РФ, включая запрет использования ПО, изъятие контрафактных экземпляров и взыскание компенсации.
  • Роль экспертиз. В спорах о нарушении прав на ПО ключевую роль играют компьютерно-технические экспертизы, которые сравнивают исходный код программ и устанавливают факт заимствования[87][88].

Примеры дел, косвенно связанных с открытыми лицензиями

  • Дело А. Мамичева. Упоминается как знаковый спор, связанный с open source. Хотя детали дела не раскрываются, отмечается, что суды самостоятельно констатировали нарушение условий GPL v2 и отказали Мамичеву в защите его прав на ПО. Этот случай может указывать на то, что суды признают действительность открытых лицензий, но не всегда защищают права их авторов[89].
  • Споры о переработке и производности программ. В делах, где рассматривается вопрос о том, является ли программа производной от другой, суды учитывают степень заимствования кода. Это актуально и для открытых лицензий, где условия часто требуют раскрытия исходного кода или указания авторства[87].
  • Дела о нарушении исключительных прав. В некоторых случаях суды рассматривают споры о неправомерном использовании кода, что может включать и ситуации с открытыми лицензиями. Например, в деле «Инлайн-Про» против «Барсум» экспертиза установила заимствование кода, что привело к нарушению прав истца[88].

Особенности открытых лицензий в российском праве

  • Принцип исчерпания прав. Для открытого ПО он фактически не действует, так как экземпляры должны распространяться на условиях открытой лицензии даже после правомерного введения в оборот[89].
  • Двойное лицензирование. Многие open source продукты распространяются под двумя лицензиями: бесплатной (с ограничениями) и коммерческой (с более либеральными условиями). Это позволяет разработчикам монетизировать проект[89].
  • Защита прав конечных пользователей. В России третьи лица (например, конечные пользователи) не вправе предъявлять иски о нарушении открытых лицензий, что ограничивает возможности защиты их интересов[89].

Программное обеспечение в общественном достоянии

Хотя open source-лицензии предоставляют определённые права, они всегда содержат оговорки.

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

Просто опубликовать программное обеспечение без лицензии недостаточно, так как по умолчанию на большинство творческих работ, включая программное обеспечение, распространяется действие закона об авторских правах. Здесь помогают инструменты «передачи в общественное достояние» (public domain dedication).

Для программного обеспечения существует Unlicense — девятая по популярности лицензия на GitHub (хотя её статус как лицензии вызывает споры).

Creative Commons предлагает схожий инструмент — CC0 1.0, который фокусируется на творческих работах в целом. CC0 использует более ясный юридический язык, соответствующий международному праву, но не предоставляет патентных прав. Стоит отметить, что в 2012 году Creative Commons подала заявку на одобрение CC0 1.0 в качестве open source-лицензии, но отозвала её после того, как OSI выразила обеспокоенность тем, что она явно исключает выдачу патентов[29].

Использование в проприетарном программном обеспечении

Использование лицензий Open-source в проприетарном программном обеспечении требует внимательного изучения условий лицензий.

  • Для проприетарных проектов предпочтительны разрешительные лицензии (MIT, Apache 2.0, BSD), так как они накладывают минимум ограничений и позволяют свободно интегрировать код без раскрытия собственных разработок[29].
  • При использовании слабого копилефта (LGPL, MPL, EPL) важно чётко разграничивать компоненты: открытый код должен оставаться под соответствующей лицензией, а проприетарные части могут быть закрытыми. Необходимо соблюдать условия лицензий, например, публиковать изменения в открытых компонентах[90].
  • Сильный копилефт (GPL, AGPL) не рекомендуется для проприетарных проектов, так как требует раскрытия всего исходного кода производного продукта.

Ссылки

  1. ↑ Byfield, 2008.
  2. ↑ Rosen, 2005, p. 22.
  3. ↑ Rosen, 2005, pp. 22—23.
  4. ↑ Rosen, 2005, p. 15.
  5. ↑ Smith, 2022, sec. 3.1.2.
  6. ↑ Rosen, 2005, pp. 27—28.
  7. ↑ Rosen, 2005, p. 28.
  8. ↑ Oman, 2018, pp. 641—642.
  9. ↑ Williams, 2002, ch. 1.
  10. ↑ Williams, 2002, ch. 7.
  11. ↑ 1 2 Williams, 2002, ch. 9.
  12. ↑ Greenbaum, 2016, sec. I.A.
  13. ↑ 1 2 3 Maracke, 2019, sec. 2.2.
  14. ↑ Carver, 2005, pp. 448–450.
  15. ↑ Raymond, 1999, "Memes and Mythmaking".
  16. ↑ Raymond, 2001, "The Cathedral and the Bazaar".
  17. ↑ Brock, 2022, sec. 16.3.4.
  18. ↑ Raymond, 2001.
  19. ↑ Raymond, 2001, "The Social Context of Open-Source Software".
  20. ↑ Onetti, Verma, 2009, p. 69.
  21. ↑ 1 2 Hammerly, Paquin, Walton, 1999.
  22. ↑ Perens, 1999.
  23. ↑ Greenbaum, 2016, pp. 1302–1303.
  24. ↑ Greenbaum, 2016, pp. 1304—1305.
  25. ↑ Greenbaum, 2016, p. 1305.
  26. ↑ Fontana, 2010, p. 2.
  27. ↑ Coleman, 2004, "Political Agnosticism".
  28. ↑ Smith, 2022, sec. 3.2.
  29. ↑ 1 2 3 4 5 6 7 8 Open Source лицензии: полное руководство по выбору и применению. www.securitylab.ru (17 января, 2025). Дата обращения: 7 ноября 2025.
  30. ↑ 1 2 Rosen, 2005, pp. 22—24.
  31. ↑ Bain, Smith, 2022, sec. 10.4.3.
  32. ↑ Bain, Smith, 2022, sec. 10.4.2.
  33. ↑ 1 2 Bain, Smith, 2022, sec. 10.4.4.
  34. ↑ Chestek, 2022, p. 30.
  35. ↑ Chestek, 2022, pp. 184—185.
  36. ↑ Rosen, 2005, p. 38.
  37. ↑ Joy, 2022, p. 986.
  38. ↑ Joy, 2022, pp. 1004–1006.
  39. ↑ Joy, 2022, pp. 979, 1002.
  40. ↑ 1 2 Rosen, 2005, p. 69.
  41. ↑ Rosen, 2005, pp. 101—102.
  42. ↑ 1 2 Smith, 2022, sec. 3.2.1.1.
  43. ↑ OSI, 2023.
  44. ↑ 1 2 Rosen, 2005, pp. 73—90.
  45. ↑ OSI, 2023, "The MIT License".
  46. ↑ Smith, 2022, sec. 3.2.1.2.
  47. ↑ Bain, Smith, 2022, sec. 10.4.2.
  48. ↑ OSI, 2023, "Apache License, Version 2.0".
  49. ↑ Bain, Smith, 2022, ch. 10.
  50. ↑ Bain, Smith, 2022, sec. 10.4.4.
  51. ↑ 1 2 Sen, Subramaniam, Nelson, 2008, pp. 211—212.
  52. ↑ St. Laurent, 2004, pp. 38—39.
  53. ↑ Ballhausen, 2019, p. 86.
  54. ↑ Rosen, 2005, p. 135.
  55. ↑ Rosen, 2005, pp. 103—106.
  56. ↑ Keats, 2010, p. 64.
  57. ↑ Full Text of GNU Emacs Copying Permission Notice (1985).
  58. ↑ Keats, 2010, pp. 63—67.
  59. ↑ Joy, 2022, pp. 990—992.
  60. ↑ License Rankings Globally (англ.). innovationgraph.github.com. Дата обращения: 7 ноября 2025.
  61. ↑ LINUX.ORG.RU. https://www.linux.org.ru/. Дата обращения: 25 ноября 2025.
  62. ↑ Викиверситет: Получение разрешений. ru.wikiversity.org. Дата обращения: 25 ноября 2025.
  63. ↑ St. Laurent, 2004, pp. 68, 75.
  64. ↑ Tsai, 2008, pp. 564—570.
  65. ↑ Onetti, Verma, 2009, p. 71.
  66. ↑ St. Laurent, 2004, pp. 81—83, 114.
  67. ↑ Ballhausen, 2019, p. 82.
  68. ↑ Open source (свободное по). blog.skillfactory.ru (27 марта 2023). Дата обращения: 7 ноября 2025.
  69. ↑ Свободное и открытое программное обеспечение: в чем разница? www.8host.com (29 ноября, 2017). Дата обращения: 7 ноября 2025.
  70. ↑ Open source: что это, в чем преимущества и недостатки. getcompass.ru (4 апреля 2024). Дата обращения: 7 ноября 2025.
  71. ↑ 1 2 Smith, 2022, sec. 3.3.
  72. ↑ Rosen, 2005, pp. 243—247.
  73. ↑ St. Laurent, 2004, pp. 159—163.
  74. ↑ See Smith, 2022, p. 102 for: Apache License version 2.0 in 2004, GPL version 3 in 2007, LGPL version 3 in 2007, and AGPL version 3 in 2007. See Smith, 2022, pp. 95–101 for: MPL version 2.0 in 2012 and EPL version 2 in 2017.
  75. ↑ 1 2 3 4 Smith, 2022, sec. 3.4.1.
  76. ↑ 1 2 Ballhausen, 2022, sec. 5.3.
  77. ↑ Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008).
  78. ↑ Welte v. Sitecom (District Court of Munich 2004). Text
  79. ↑ Smith, 2022, p. 106.
  80. ↑ Rosen, 2005, p. 137.
  81. ↑ Rosen, 2005, p. 138.
  82. ↑ Rosen, 2005, ch. 6.
  83. ↑ Meeker, 2020, 17:04.
  84. ↑ Walden, 2022, sec. 1.1.
  85. ↑ Smith, 2022, sec. 3.4.2.
  86. ↑ Алина Сундетова. Как защитить права на проект с открытым кодом. runetlex.ru. Дата обращения: 27 ноября 2025.
  87. ↑ 1 2 Защита авторских прав на программы на ЭВМ: судебная практика и тенденция регулирования. rtmtech.ru. Дата обращения: 27 ноября 2025.
  88. ↑ 1 2 Евгения Ефименко. Верховный суд разрешил спор о компьютерной программе. pravo.ru (29 ноября 2022). Дата обращения: 27 ноября 2025.
  89. ↑ 1 2 3 4 Сафьянников А.В. Правовые проблемы использования открытого программного обеспечения (open source). ipcmagazine.garant.ru (20 июня 2022). Дата обращения: 27 ноября 2025.
  90. ↑ Сравнение лицензий с открытым исходным кодом. worksolutions.ru. Дата обращения: 8 ноября 2025.

Примечания

Дополнительно по теме

Категории