07 нояб. 2025 г.·8 мин
Ричард Столлман и свободное ПО: идеи, которые изменили код
Разберём философию Ричарда Столлмана о свободном ПО, проект GNU и GPL — и как эти идеи изменили лицензирование, права разработчиков и экосистему open source.
Разберём философию Ричарда Столлмана о свободном ПО, проект GNU и GPL — и как эти идеи изменили лицензирование, права разработчиков и экосистему open source.
Программное обеспечение — это не только технический продукт, но и набор разрешений. Кто может его запускать, копировать, делиться с другом, исправлять баг или строить что‑то новое поверх него? На эти вопросы чаще отвечает не код, а лицензирование. По мере того как ПО становилось центральным для работы, общения и исследований, правила «что вам разрешено» начали формировать инновации не меньше, чем технические возможности.
Ричард Столлман (часто «RMS») важен потому, что он сделал эти правила невозможно игнорировать. В начале 1980‑х он наблюдал сдвиг: всё больше программ распространялось без исходников, и пользователям всё чаще говорили, что они могут пользоваться ПО лишь на условиях кого‑то другого. Столлман увидел в этом не мелкое неудобство, а утрату свободы пользователей и разработчиков — и ответил набором принципов и юридических инструментов для защиты этих свобод.
Эта статья сосредоточена на идеях Столлмана и их практических последствиях: определение свободного ПО, проект GNU, копилефт и GNU General Public License (GPL) — и на том, как они повлияли на современные экосистемы открытого ПО и нормы лицензирования.
Это не биография и не глубокое техническое руководство по сборке ядер или управлению репозиториями. Вам не нужен опыт программирования, чтобы понимать текст.
Столлман — влиятельная и одновременно спорная фигура. Цель здесь — оставаться фактическим и читабельным: что он отстаивал, какие юридические механизмы появились, как компании и разработчики адаптировались и где сохраняются дебаты — чтобы вы могли увидеть, почему его работа всё ещё влияет на повседневный выбор ПО.
«Свободное ПО» легко неправильно понять, потому что слово свободное звучит как про цену. Ричард Столлман использовал свободное в значении свободы — способности пользователя контролировать ПО, на которое он опирается.
Если программа стоит $0, но вам не позволяют проверить её, изменить или поделиться ею, она может быть «свободной как пиво» и при этом несвободной в смысле, который важен Столлману.
Свободное ПО определяется четырьмя базовыми разрешениями:
Эти свободы про агентность: вы не просто потребитель инструментов — вы можете стать участником, который проверяет, адаптирует и улучшает их.
Свободы 1 и 3 невозможны без доступа к исходному коду — читаемым человеком инструкциям. Без него ПО похоже на запечатанный прибор: вы можете им пользоваться, но не понимаете, что он делает, не можете починить его при поломке и не сможете адаптировать под новые потребности.
Доступ к исходникам важен и для доверия. Он позволяет независимый обзор (для приватности, безопасности и справедливости) и делает поддержание ПО возможным, даже если оригинальный разработчик перестаёт им заниматься.
Подумайте о блюде в ресторане.
Вот суть: свободное ПО даёт пользователям возможности, необходимые для контроля над своей вычислительной средой.
До того как «лицензирование ПО» стало предметом широких споров, много чего в программной культуре — особенно в университетах и исследовательских лабораториях — строилось на допущении: если вы улучшили инструмент, вы делитесь улучшением. Исходники шли вместе с программами, люди учились, читая чужой код, и исправления распространялись неформально.
Такая культура начала меняться по мере коммерциализации ПО. Компании (и некоторые институты) стали рассматривать исходники как конкурентное преимущество. Распространение сопровождалось условиями «без права на обмен», код перестал идти с программами, и договоры о неразглашении стали обычным делом. Для разработчиков, привыкших к коллективному решению задач, это изменение выглядело не просто неудобством, а сменой правил, делающей совместную работу юридически рискованной.
Одна из часто пересказываемых историй — про принтер в AI‑лаборатории MIT. Столлман описывал, как новый принтер пришёл с программой, распространяемой только в бинарном виде, без исходников. Практическая проблема была приземлённой: лаборатории хотелось модифицировать программу, чтобы уведомлять о застреваниях бумаги или лучше маршрутизировать задания. По старым «хакерским» нормам кто‑то бы залатал код и поделился исправлением. Здесь этого нельзя было сделать — потому что исходники были недоступны.
Важно не преувеличивать: не один принтер создал глобальное движение. Это был понятный, наглядный пример более широкой тенденции — инструменты, от которых зависели люди, становились нефункционируемыми для своих пользователей.
Для Столлмана ключевая проблема была не только в техническом доступе, а в потере свободы сотрудничать. Если вы не можете изучить программу, вы не можете её контролировать. Если вы не можете делиться улучшениями, сообщества фрагментируются, и все начинают заново решать те же проблемы в частном порядке.
Эта мотивация сформировала лицензирование: вместо того чтобы полагаться на добрую волю или неформальные нормы, Столлман хотел правила, сохраняющие возможность использовать, изучать, изменять и делиться ПО — чтобы сотрудничество не могло быть отменено, как только программа стала коммерчески ценной.
Главный практический шаг Столлмана был не только в манифесте — он запустил инженерный проект. В 1983 году он объявил о проекте GNU с амбициозной целью: создать полноценную операционную систему, которую любой мог бы использовать, изучать, изменять и распространять, оставаясь совместимой с Unix, чтобы люди могли запускать привычные программы и рабочие процессы.
Операционная система — это не одна программа, а целый стек. GNU ставил цель создать все повседневные компоненты, нужные для полезной работы компьютера, включая:
Проще говоря: GNU строил «трубопровод», провода и переключатели — не один прибор.
К началу 1990‑х GNU дал большую часть «userland», но один критичный кусок отставал: ядро (управляющая часть, работающая с железом). Когда в 1991 году появился Linux, оно заполнило этот пробел.
Именно поэтому многие популярные системы сегодня сочетают компоненты GNU с ядром Linux — часто такие системы называют «GNU/Linux».
GNU сделал идею свободного ПО реальной, создав рабочую базу, на которой другие могли строить. Философия объясняла, почему свобода важна; GNU предоставил инструменты, делавшие свободу практически применимой и масштабируемой.
Копилефт — это стратегия лицензирования, предназначенная сохранить свободу ПО не только в первой версии, но и в будущих. Если вы получаете код под копилефтом, вам разрешено использовать, изучать, изменять и распространять его — но при перераспространении вы обязаны передать те же свободы другим.
Копилефт звучит как «анти‑авторское право», но на самом деле опирается на авторское право. Автор использует своё авторское право, чтобы задать условия разрешений в лицензии: «Вы можете копировать и изменять это, но если вы перераспространяете, вы должны сохранить ту же лицензию». Без авторского права не было бы механизма для принудительного применения этих условий.
Думайте об этом как о правиле, которое следует за кодом:
Цель — предотвратить сценарий, который волновал Столлмана: кто‑то берёт работу сообщества, улучшает её, а затем прячет улучшения.
Разрешительные лицензии (MIT, BSD) в общем позволяют делать с кодом почти всё, включая распространение модифицированных версий под закрытой лицензией. Копилефт‑лицензии (например, GNU GPL) также позволяют широкое использование и модификацию, но требуют, чтобы производные распространялись под теми же условиями — таким образом свобода сохраняется дальше по цепочке.
GNU General Public License (GPL) изменил правила игры, превратив «обмен» в обеспечиваемое правом требование, а не просто добрую практику. До GPL вы могли получить исходники, улучшить их и затем выпустить закрытую версию, которую пользователи не могли изучать. GPL перевернуло эту динамику: она защищает права пользователей, добавляя условия к перераспространению.
На практике GPL даёт пользователям право запускать программу с любой целью, читать и изменять исходники и делиться оригиналом или модификациями.
Если вы распространяете GPL‑ПО (особенно в продукте), вы обязаны передать те же свободы. Это обычно означает:
Обязательства GPL в основном возникают при распределении ПО — отправке бинарников, продаже устройств с ПО или передаче копий клиентам. Если вы модифицируете GPL‑код для внутреннего использования и не распространяете его, как правило, вам не нужно публиковать исходники.
Не нужно погружаться в сложную юридическую теорию, чтобы понять суть: если ваша программа включает GPL‑код так, что получается объединённое произведение (например, линковка в приложение), результат обычно считается производным и должен распространяться под GPL. Простое выполнение GPL‑программы или взаимодействие с ней как с отдельным процессом по стандартным интерфейсам часто рассматривается иначе.
GPLv2 — классическая широко используемая версия. GPLv3 добавляет защиту против патентных соглашений и «tivoization». LGPL предназначена для библиотек: она позволяет линковать из проприетарных программ при соблюдении условий и при этом сохранять библиотеку свободной.
Свободные лицензии (особенно GNU GPL) не просто «разрешают» обмен — они защищают право изучать, изменять и распространять ПО так, чтобы это было трудно отменить позднее. Для разработчиков это значит: ваши улучшения могут оставаться доступными другим под теми же условиями, а не поглощаться закрытым продуктом без отдачи сообществу.
Под GPL вы можете:
Поэтому GPL часто называют «принудительной взаимностью». Если кто‑то распространяет покрытое GPL ПО (или производное), он не может добавлять ограничения, которые блокировали бы downstream‑пользователей от тех же действий.
Эти права идут с обязанностями при распространении ПО:
Эти обязанности — не «ловушки», а механизм, предотвращающий одностороннее извлечение ценности из совместной работы.
Команды должны относиться к соблюдению лицензий как к части релизной дисциплины. Отслеживайте:
Простой SBOM и повторяемый чеклист релизов предотвратят большинство проблем до вмешательства юристов.
На уровне кода «свободное ПО» и «open source» часто описывают одни и те же проекты. Различие в основном в том, почему обмен важен.
Движение Free Software (ассоциируемое с Ричардом Столлманом и Free Software Foundation) рассматривает свободу ПО как этический вопрос: пользователи должны иметь право запускать, изучать, изменять и распространять ПО. Суть — не только в лучшем инженерном решении, а в защите автономии пользователя.
Подход Open Source подчёркивает практические результаты: лучшее сотрудничество, более быстрое развитие, меньше багов и улучшенная безопасность благодаря прозрачности. Он комфортно представляет открытость как превосходную модель разработки, не требуя принятия моральной позиции.
В 1998 году Open Source Initiative популяризировала термин «open source», чтобы сделать идею более дружественной к бизнесу. «Free software» часто неправильно понимали как «бесплатно», и некоторые компании уклонялись от месседжа, сформулированного через права и этику. «Open source» дала возможность говорить «мы работаем так», не звуча идеологично.
Многие проекты, называющие себя open source, используют GNU GPL или другие копилефт‑лицензии, другие выбирают permissive‑лицензии (MIT, Apache). Текст лицензии может быть одинаковым; меняется только рассказ для контрибьюторов, пользователей и клиентов. Одна история — «это защищает ваши свободы», другая — «это снижает трение и улучшает качество».
Если приоритет команды — гарантировать, что downstream‑пользователи сохранят те же свободы, подавайте это как свободное ПО и рассматривайте копилефт.
Если цель — максимально широкое принятие (включая компании, которые не хотят взаимных обязательств), подход open source и permissive‑лицензия могут лучше подойти.
Если вы хотите широкого сотрудничества, но хотите, чтобы улучшения возвращались, используйте открыто‑ориентированный язык для доступности и копилефт для достижения результата.
Свободное ПО не означает «никто не зарабатывает». Это означает, что пользователи имеют свободу запускать, изучать, изменять и распространять код. Многие компании строят здоровую выручку вокруг этой свободы — часто за счёт того, за что организации действительно готовы платить: надёжности, ответственности и экономии времени.
Несколько распространённых моделей:
Современный пример модели управляемого сервиса — платформы, которые быстро генерируют и запускают приложения. Например, Koder.ai — платформа vibe‑coding, помогающая командам строить веб, бэкенд и мобильные приложения через чат, одновременно поддерживая экспорт исходного кода. Такое сочетание (быстрая итерация плюс владение кодом) естественно сочетается со значениями свободного ПО: возможность инспектировать, менять и переносить своё ПО при необходимости.
Выбор лицензии может определить, кто улавливает ценность:
«Коммерческое» описывает способ продажи; «свободное ПО» — права пользователя. Компания может продавать свободное ПО, брать плату за поддержку и при этом уважать свободы пользователей.
Перед тем как принять или полагаться на FOSS‑проект, спросите:
GPL и «FOSS» много обсуждаются, но несколько мифов мешают ясности — особенно у команд, которые просто хотят выпустить продукт, не нарушая лицензий.
Не значит. Публичное достояние означает отсутствие владельца авторских прав и отсутствие условий для использования — любой может использовать работу без ограничений.
GNU GPL — это прямо противоположное «без условий». Автор сохраняет авторские права и предоставляет широкие разрешения на использование, изменение и распространение — но лишь при соблюдении условий GPL (в частности, публикации исходников при распространении бинарников).
Видимость кода может помочь безопасности, но не гарантирует её. Проект может быть открытым и при этом:
Безопасность приходит через активную поддержку, аудиты, ответственное раскрытие и надёжную эксплуатацию — а не через ярлык лицензии.
Часто GPL называют «вирусной», подразумевая, что она распространяется без контроля. Это метафора с нагрузкой.
Обычно имеется в виду копилефт: если вы распространяете производное GPL‑произведение, вы должны предоставить соответствующие исходники под GPL. Это намеренное требование, сохраняющее свободы downstream. Это не «инфекция», а условие, которое вы можете принять или избежать, выбрав другой код.
Правило простое: обязанности в основном срабатывают при распространении.
Когда это важно, получите точную оценку по тому, как код комбинируется и распространяется — а не только исходя из общих предположений.
Ричарда Столлмана критикуют — и это не отменяет факта его влияния. Полезно разделять два разговора: (1) дебаты о Столлмане как личности и участнике сообщества и (2) измеримый вклад принципов свободного ПО, проекта GNU и GPL в лицензирование и права разработчиков. Второй можно обсуждать по первичным источникам (тексты лицензий, истории проектов, практики использования), даже если мнения о первом различаются.
Один из частых критических вопросов касается не лицензирования, а управления проектами: как принимаются решения, кто имеет власть и что происходит, когда основатели, мейнтейнеры и пользователи хотят разного. Свободные сообщества сталкивались с вопросами:
Лицензии дают правовые рамки, но не обеспечивают здоровые процессы принятия решений.
Другой важный дебат — о гостеприимстве и нормах поведения: как проекты устанавливают ожидания по уважительному общению, как разрешают конфликты и насколько они открыты для новичков. Некоторые проекты вводят формальные кодексы поведения; другие предпочитают минимальные правила и неформальную модерацию. Нет универсально «правильного» подхода, но компромиссы реальны и заслуживают обсуждения без персональных нападок.
Если вы оцениваете наследие Столлмана, полезно опираться на проверяемые факты: что требует GPL, как копилефт изменил практики соблюдения и как эти идеи повлияли на последующие лицензии и институты. Можно быть критичным, поддерживать или оставаться в нерешительности — главное стремиться к точности, уважению и ясности в том, что именно критикуется.
Самый практический подарок Столлмана командам — простой вопрос: какие свободы вы хотите гарантировать downstream? Ответ превращает «выбор лицензии» из ощущения в решение.
Если не уверены, решайте по цели: принятие (permissive) против взаимности (copyleft) против дружественного к библиотекам копилефта.
Если вы создаёте продукты с помощью AI‑помощников (включая чат‑платформы типа Koder.ai), этот чек‑лист становится ещё важнее: вы всё равно выпускаете реальные артефакты и несёте реальные лицензионные обязательства. Скорость не снимает ответственности — она лишь делает повторяемые процедуры соответствия более ценными.
Сделайте это скучным и повторяемым:
Для более глубоких сравнений см. /blog/choosing-an-open-source-license и /blog/gpl-vs-mit-vs-apache.
«Свободное ПО» означает свободу, а не цену.
Программа может стоить $0 и при этом быть несвободной, если вы не можете её изучить, изменить или распространять. Свободное ПО сосредоточено на правах запускать, изучать, изменять и распространять программное обеспечение, от которого вы зависите.
Определение строится на четырёх разрешениях:
Если хотя бы одно из этих прав отсутствует, пользователи теряют контроль, и сотрудничество усложняется.
Потому что без исходного кода вы не можете реально изучать или изменять программу.
Доступ к исходникам позволяет:
Копилефт использует авторское право, чтобы требовать «разделяй подобно» при перераспространении.
Вы можете использовать, изменять и даже продавать программу, но если вы распространяете изменённую версию, вы обязаны предоставить получателям те же свободы (обычно — выпустить соответствующий исходный код под той же лицензией).
GPL предоставляет широкие права (использовать, изучать, изменять, распространять) и требует взаимности при распространении.
Если вы распространяете бинарные сборки под GPL, обычно вы должны:
Чаще всего — нет.
Для GPL обязательства обычно вступают в силу при распространении. Если вы модифицируете GPL‑код для внутреннего использования и не передаёте копии за пределы организации, как правило, нет необходимости публиковать изменения.
(Исключения возможны — это обобщённое правило, а не юридическая консультация.)
Это зависит от того, как код объединён.
В общих чертах:
Когда это важно, сопоставьте конкретную схему интеграции перед выпуском.
Они направлены на разные риски:
Выбирайте, исходя из того, хотите ли вы строгую взаимность (GPL) или «дружественную к библиотекам» взаимность (LGPL).
Обычно — нет при стандартном GPL.
Если вы запускаете GPL‑ПО на собственных серверах и пользователи лишь взаимодействуют с ним по сети, это обычно не считается «распространением», так что требования по раскрытию исходников не срабатывают.
Если вы хотите, чтобы сетевое использование влекло за собой обязанность раскрывать код, обратите внимание на AGPL и оцените её применимость к вашей архитектуре.
Да — многие компании зарабатывают на свободном ПО, не нарушая его свобод.
Распространённые модели:
Выбор лицензии влияет на стратегию: permissive ускоряют принятие; copyleft препятствует закрытым форкам и поддерживает модели, основанные на услугах.