Ричард Столлман и свободное ПО: идеи, которые изменили код

Почему Ричард Столлман по‑прежнему важен

Программное обеспечение — это не только технический продукт, но и набор разрешений. Кто может его запускать, копировать, делиться с другом, исправлять баг или строить что‑то новое поверх него? На эти вопросы чаще отвечает не код, а лицензирование. По мере того как ПО становилось центральным для работы, общения и исследований, правила «что вам разрешено» начали формировать инновации не меньше, чем технические возможности.

Ричард Столлман (часто «RMS») важен потому, что он сделал эти правила невозможно игнорировать. В начале 1980‑х он наблюдал сдвиг: всё больше программ распространялось без исходников, и пользователям всё чаще говорили, что они могут пользоваться ПО лишь на условиях кого‑то другого. Столлман увидел в этом не мелкое неудобство, а утрату свободы пользователей и разработчиков — и ответил набором принципов и юридических инструментов для защиты этих свобод.

Что это за статья (и что нет)

Эта статья сосредоточена на идеях Столлмана и их практических последствиях: определение свободного ПО, проект GNU, копилефт и GNU General Public License (GPL) — и на том, как они повлияли на современные экосистемы открытого ПО и нормы лицензирования.

Это не биография и не глубокое техническое руководство по сборке ядер или управлению репозиториями. Вам не нужен опыт программирования, чтобы понимать текст.

Взвешенный и доступный взгляд

Столлман — влиятельная и одновременно спорная фигура. Цель здесь — оставаться фактическим и читабельным: что он отстаивал, какие юридические механизмы появились, как компании и разработчики адаптировались и где сохраняются дебаты — чтобы вы могли увидеть, почему его работа всё ещё влияет на повседневный выбор ПО.

Что на самом деле значит «свободное ПО»

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

Если программа стоит $0, но вам не позволяют проверить её, изменить или поделиться ею, она может быть «свободной как пиво» и при этом несвободной в смысле, который важен Столлману.

Четыре основных свободы

Свободное ПО определяется четырьмя базовыми разрешениями:

• Свобода 0: запускать программу для любых целей.
• Свобода 1: изучать, как программа работает, и изменять её, чтобы она делала то, что вам нужно.
• Свобода 2: распространять копии, чтобы помочь другим.
• Свобода 3: публиковать свои модифицированные версии, чтобы сообщество могло от них выиграть.

Эти свободы про агентность: вы не просто потребитель инструментов — вы можете стать участником, который проверяет, адаптирует и улучшает их.

Почему доступ к исходникам — не предмет обсуждения

Свободы 1 и 3 невозможны без доступа к исходному коду — читаемым человеком инструкциям. Без него ПО похоже на запечатанный прибор: вы можете им пользоваться, но не понимаете, что он делает, не можете починить его при поломке и не сможете адаптировать под новые потребности.

Доступ к исходникам важен и для доверия. Он позволяет независимый обзор (для приватности, безопасности и справедливости) и делает поддержание ПО возможным, даже если оригинальный разработчик перестаёт им заниматься.

Простая аналогия: рецепты против запечатанной еды

Подумайте о блюде в ресторане.

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

Вот суть: свободное ПО даёт пользователям возможности, необходимые для контроля над своей вычислительной средой.

Проблема, на которую реагировал Столлман

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

От норм обмена к закрытому ПО

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

История с принтером (пример, а не миф)

Одна из часто пересказываемых историй — про принтер в AI‑лаборатории MIT. Столлман описывал, как новый принтер пришёл с программой, распространяемой только в бинарном виде, без исходников. Практическая проблема была приземлённой: лаборатории хотелось модифицировать программу, чтобы уведомлять о застреваниях бумаги или лучше маршрутизировать задания. По старым «хакерским» нормам кто‑то бы залатал код и поделился исправлением. Здесь этого нельзя было сделать — потому что исходники были недоступны.

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

Почему это привело к идеям по лицензированию

Для Столлмана ключевая проблема была не только в техническом доступе, а в потере свободы сотрудничать. Если вы не можете изучить программу, вы не можете её контролировать. Если вы не можете делиться улучшениями, сообщества фрагментируются, и все начинают заново решать те же проблемы в частном порядке.

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

Проект GNU: создание свободной ОС

Главный практический шаг Столлмана был не только в манифесте — он запустил инженерный проект. В 1983 году он объявил о проекте GNU с амбициозной целью: создать полноценную операционную систему, которую любой мог бы использовать, изучать, изменять и распространять, оставаясь совместимой с Unix, чтобы люди могли запускать привычные программы и рабочие процессы.

Не один инструмент, а целая система

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

• Компиляторы (самый известный — GCC), чтобы превращать код в программы
• Базовые утилиты командной строки (инструменты для копирования файлов, поиска текста, управления процессами)
• Библиотеки и инструменты для разработчиков для создания ПО
• Оболочки и редакторы, чтобы работать с машиной в повседневной работе

Проще говоря: GNU строил «трубопровод», провода и переключатели — не один прибор.

GNU + Linux: как большинство людей с ним столкнулось

К началу 1990‑х GNU дал большую часть «userland», но один критичный кусок отставал: ядро (управляющая часть, работающая с железом). Когда в 1991 году появился Linux, оно заполнило этот пробел.

Именно поэтому многие популярные системы сегодня сочетают компоненты GNU с ядром Linux — часто такие системы называют «GNU/Linux».

Инфраструктура важнее идеалов

GNU сделал идею свободного ПО реальной, создав рабочую базу, на которой другие могли строить. Философия объясняла, почему свобода важна; GNU предоставил инструменты, делавшие свободу практически применимой и масштабируемой.

Копилефт простыми словами

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

Юридический инструмент на базе авторского права

Копилефт звучит как «анти‑авторское право», но на самом деле опирается на авторское право. Автор использует своё авторское право, чтобы задать условия разрешений в лицензии: «Вы можете копировать и изменять это, но если вы перераспространяете, вы должны сохранить ту же лицензию». Без авторского права не было бы механизма для принудительного применения этих условий.

Идея «share alike» (с простыми примерами)

Думайте об этом как о правиле, которое следует за кодом:

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

Цель — предотвратить сценарий, который волновал Столлмана: кто‑то берёт работу сообщества, улучшает её, а затем прячет улучшения.

Копилефт против разрешительных лицензий

Разрешительные лицензии (MIT, BSD) в общем позволяют делать с кодом почти всё, включая распространение модифицированных версий под закрытой лицензией. Копилефт‑лицензии (например, GNU GPL) также позволяют широкое использование и модификацию, но требуют, чтобы производные распространялись под теми же условиями — таким образом свобода сохраняется дальше по цепочке.

Как GNU GPL изменил лицензирование

GNU General Public License (GPL) изменил правила игры, превратив «обмен» в обеспечиваемое правом требование, а не просто добрую практику. До GPL вы могли получить исходники, улучшить их и затем выпустить закрытую версию, которую пользователи не могли изучать. GPL перевернуло эту динамику: она защищает права пользователей, добавляя условия к перераспространению.

Что даёт GPL — и что требует взамен

На практике GPL даёт пользователям право запускать программу с любой целью, читать и изменять исходники и делиться оригиналом или модификациями.

Если вы распространяете GPL‑ПО (особенно в продукте), вы обязаны передать те же свободы. Это обычно означает:

• предоставить исходники (или корректный способ их получения) получателям
• включить текст лицензии и сохранить уведомления об авторских правах
• лицензировать ваши модификации под GPL, чтобы downstream‑пользователи не были «отключены» от прав

Обязанности по передаче исходников (когда они действуют)

Обязательства GPL в основном возникают при распределении ПО — отправке бинарников, продаже устройств с ПО или передаче копий клиентам. Если вы модифицируете GPL‑код для внутреннего использования и не распространяете его, как правило, вам не нужно публиковать исходники.

Что такое «производное произведение» простыми словами

Не нужно погружаться в сложную юридическую теорию, чтобы понять суть: если ваша программа включает GPL‑код так, что получается объединённое произведение (например, линковка в приложение), результат обычно считается производным и должен распространяться под GPL. Простое выполнение GPL‑программы или взаимодействие с ней как с отдельным процессом по стандартным интерфейсам часто рассматривается иначе.

Варианты GPL: v2, v3 и LGPL

GPLv2 — классическая широко используемая версия. GPLv3 добавляет защиту против патентных соглашений и «tivoization». LGPL предназначена для библиотек: она позволяет линковать из проприетарных программ при соблюдении условий и при этом сохранять библиотеку свободной.

Права и обязанности разработчиков при свободных лицензиях

Свободные лицензии (особенно GNU GPL) не просто «разрешают» обмен — они защищают право изучать, изменять и распространять ПО так, чтобы это было трудно отменить позднее. Для разработчиков это значит: ваши улучшения могут оставаться доступными другим под теми же условиями, а не поглощаться закрытым продуктом без отдачи сообществу.

Какие права вы приобретаете

Под GPL вы можете:

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

Поэтому GPL часто называют «принудительной взаимностью». Если кто‑то распространяет покрытое GPL ПО (или производное), он не может добавлять ограничения, которые блокировали бы downstream‑пользователей от тех же действий.

Какие обязанности вы берёте на себя

Эти права идут с обязанностями при распространении ПО:

• сохранять уведомления об авторских правах и текст лицензии
• предоставлять (или предлагать) соответствующие исходники, когда GPL требует этого
• не менять лицензию так, чтобы лишить получателей их прав

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

Практическая заметка о соблюдении

Команды должны относиться к соблюдению лицензий как к части релизной дисциплины. Отслеживайте:

• какие open‑source компоненты вы отправляете
• их версии и лицензии
• где вы предоставляете исходники (или письменные предложения)
• и какие изменения вы вносили

Простой SBOM и повторяемый чеклист релизов предотвратят большинство проблем до вмешательства юристов.

Свободное ПО vs Open Source: раскол ценностей

На уровне кода «свободное ПО» и «open source» часто описывают одни и те же проекты. Различие в основном в том, почему обмен важен.

Разные приоритеты: свобода против принятия

Движение Free Software (ассоциируемое с Ричардом Столлманом и Free Software Foundation) рассматривает свободу ПО как этический вопрос: пользователи должны иметь право запускать, изучать, изменять и распространять ПО. Суть — не только в лучшем инженерном решении, а в защите автономии пользователя.

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

Почему «open source» прижился

В 1998 году Open Source Initiative популяризировала термин «open source», чтобы сделать идею более дружественной к бизнесу. «Free software» часто неправильно понимали как «бесплатно», и некоторые компании уклонялись от месседжа, сформулированного через права и этику. «Open source» дала возможность говорить «мы работаем так», не звуча идеологично.

Те же лицензии, разная подача

Многие проекты, называющие себя open source, используют GNU GPL или другие копилефт‑лицензии, другие выбирают permissive‑лицензии (MIT, Apache). Текст лицензии может быть одинаковым; меняется только рассказ для контрибьюторов, пользователей и клиентов. Одна история — «это защищает ваши свободы», другая — «это снижает трение и улучшает качество».

Простое руководство по решению

Если приоритет команды — гарантировать, что downstream‑пользователи сохранят те же свободы, подавайте это как свободное ПО и рассматривайте копилефт.

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

Если вы хотите широкого сотрудничества, но хотите, чтобы улучшения возвращались, используйте открыто‑ориентированный язык для доступности и копилефт для достижения результата.

Бизнес‑модели и реальные стимулы

Свободное ПО не означает «никто не зарабатывает». Это означает, что пользователи имеют свободу запускать, изучать, изменять и распространять код. Многие компании строят здоровую выручку вокруг этой свободы — часто за счёт того, за что организации действительно готовы платить: надёжности, ответственности и экономии времени.

Как компании зарабатывают на FOSS

Несколько распространённых моделей:

• Поддержка и сервисы: платные службы поддержки, SLA, обучение, аудиты, кастомные фичи и миграции.
• Хостинг и управляемые сервисы: продажа хостинговой версии, где клиенты платят за удобство, масштабирование, бэкапы и комплаенс.
• Двойное лицензирование: та же программа под бесплатной лицензией и также под платной коммерческой лицензией.
• Open core (с осторожностью): действительно свободная база и приватные дополнения. Это может работать, но подрывать доверие сообщества, если «free» часть выглядит намеренно урезанной.

Современный пример модели управляемого сервиса — платформы, которые быстро генерируют и запускают приложения. Например, Koder.ai — платформа vibe‑coding, помогающая командам строить веб, бэкенд и мобильные приложения через чат, одновременно поддерживая экспорт исходного кода. Такое сочетание (быстрая итерация плюс владение кодом) естественно сочетается со значениями свободного ПО: возможность инспектировать, менять и переносить своё ПО при необходимости.

Почему выбор permissive или copyleft влияет на стратегию

Выбор лицензии может определить, кто улавливает ценность:

• Permissive (MIT/Apache): упрощают повторное использование, включая крупные вендоры; это может ускорить принятие, но снизить возможности монетизации эксклюзивности.
• Copyleft (GPL): требуют, чтобы downstream‑распространители делились модификациями под теми же условиями; это может отпугнуть закрытые форки и поддержать модели, основанные на услугах, сертифицированных дистрибуциях или двойном лицензировании.

«Коммерческое» и «свободное ПО» — не противоположности

«Коммерческое» описывает способ продажи; «свободное ПО» — права пользователя. Компания может продавать свободное ПО, брать плату за поддержку и при этом уважать свободы пользователей.

Чек‑лист устойчивости

Перед тем как принять или полагаться на FOSS‑проект, спросите:

• Активно ли сообщество (issues, релизы, ревью)?
• Чёткое ли управление (кто решает, как решаются конфликты)?
• Видимо ли финансирование (спонсоры, поддержка компаний, фонд)?
• Устойчиво ли распределение обязанностей поддержания (bus factor, признаки выгорания)?
• Документированы ли практики безопасности (частота патчей, уведомления)?

Распространённые заблуждения о GPL и FOSS

GPL и «FOSS» много обсуждаются, но несколько мифов мешают ясности — особенно у команд, которые просто хотят выпустить продукт, не нарушая лицензий.

«GPL значит общественное достояние»

Не значит. Публичное достояние означает отсутствие владельца авторских прав и отсутствие условий для использования — любой может использовать работу без ограничений.

GNU GPL — это прямо противоположное «без условий». Автор сохраняет авторские права и предоставляет широкие разрешения на использование, изменение и распространение — но лишь при соблюдении условий GPL (в частности, публикации исходников при распространении бинарников).

«Открытый код всегда безопасен»

Видимость кода может помочь безопасности, но не гарантирует её. Проект может быть открытым и при этом:

• необслуживаемым,
• плохо проверенным,
• уязвимым годами прежде, чем кто‑то заметит.

Безопасность приходит через активную поддержку, аудиты, ответственное раскрытие и надёжную эксплуатацию — а не через ярлык лицензии.

Миф о «вирусной лицензии»

Часто GPL называют «вирусной», подразумевая, что она распространяется без контроля. Это метафора с нагрузкой.

Обычно имеется в виду копилефт: если вы распространяете производное GPL‑произведение, вы должны предоставить соответствующие исходники под GPL. Это намеренное требование, сохраняющее свободы downstream. Это не «инфекция», а условие, которое вы можете принять или избежать, выбрав другой код.

«Могу ли я использовать GPL‑код в своём приложении или сервисе?» (в общих чертах)

Правило простое: обязанности в основном срабатывают при распространении.

• Внутреннее использование: использование GPL внутри компании обычно не требует публикации изменений.
• Отгрузка приложения/устройства: если вы распространяете программу под GPL (или производное), обычно нужно предоставить исходники и уведомления.
• SaaS/веб‑сервисы: запуск GPL‑ПО на серверах обычно не обязывает публиковать код пользователям; для этого создана AGPL.

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

Критика, споры и продолжающиеся дебаты

Ричарда Столлмана критикуют — и это не отменяет факта его влияния. Полезно разделять два разговора: (1) дебаты о Столлмане как личности и участнике сообщества и (2) измеримый вклад принципов свободного ПО, проекта GNU и GPL в лицензирование и права разработчиков. Второй можно обсуждать по первичным источникам (тексты лицензий, истории проектов, практики использования), даже если мнения о первом различаются.

Управление и «кто решает?»

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

• Как выбирать или заменять лидерство?
• Должны ли фонды управляться членами, советом или мейнтейнерами?
• Когда «свобода» мейнтейнера конфликтует с потребностями контрибьюторов?

Лицензии дают правовые рамки, но не обеспечивают здоровые процессы принятия решений.

Инклюзивность, поведение и стандарты сообщества

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

Держать разговор предметным

Если вы оцениваете наследие Столлмана, полезно опираться на проверяемые факты: что требует GPL, как копилефт изменил практики соблюдения и как эти идеи повлияли на последующие лицензии и институты. Можно быть критичным, поддерживать или оставаться в нерешительности — главное стремиться к точности, уважению и ясности в том, что именно критикуется.

Практические выводы: выбор лицензии и вклад

Самый практический подарок Столлмана командам — простой вопрос: какие свободы вы хотите гарантировать downstream? Ответ превращает «выбор лицензии» из ощущения в решение.

Простое дерево принятия решений

• Хотите, чтобы другие (включая конкурентов) могли повторно использовать ваш код с минимальными условиями? Выбирайте permissive (например, MIT, Apache‑2.0).
• Хотите, чтобы улучшения вашего кода оставались доступными при перераспространении? Выбирайте строгий копилефт (например, GNU GPL).
• Хотите, чтобы обязательства касались только модификаций библиотеки, позволяя проприетарным приложениям ссылаться на неё? Выбирайте слабый копилефт (например, LGPL, MPL).

Если не уверены, решайте по цели: принятие (permissive) против взаимности (copyleft) против дружественного к библиотекам копилефта.

Практические шаги для ответственной поставки ПО

1. Выберите одну лицензию для проекта и явно укажите её в README.
2. Добавьте файл LICENSE в корень репозитория (полный текст лицензии).
3. Добавьте заголовки об авторских правах, если это требует ваша организация.
4. Документируйте зависимости (прямые и важные транзитивные) и их лицензии.
5. Если распространяете бинарники, подготовьте необходимые уведомления, предложения исходников (если нужно) и атрибуцию.

Если вы создаёте продукты с помощью AI‑помощников (включая чат‑платформы типа Koder.ai), этот чек‑лист становится ещё важнее: вы всё равно выпускаете реальные артефакты и несёте реальные лицензионные обязательства. Скорость не снимает ответственности — она лишь делает повторяемые процедуры соответствия более ценными.

Внедрите лёгкую внутреннюю практику соответствия

Сделайте это скучным и повторяемым:

• Генерируйте SBOM при сборках.
• Держите шаблон файла notices и обновляйте его при изменении зависимостей.
• Добавьте контроль лицензий в чек‑поинт PR/релиза (даже 10‑минутный чек‑лист).

Для более глубоких сравнений см. /blog/choosing-an-open-source-license и /blog/gpl-vs-mit-vs-apache.