История открытого программного обеспечения

Что такое открытое программное обеспечение и откуда оно появилось

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

Это краткая версия. Длинная версия важна, потому что программное обеспечение, которое вы запускаете на сервере сегодня, до сих пор несет на себе отпечаток тех решений. Некоторые из них были приняты в 1983 году. Некоторые были приняты в прошлом году, и именно они являются причиной того, что некоторые приложения в наших руководствах по self-hosting теперь поставляются в двух версиях с разными названиями.

Программное обеспечение распространялось до начала его продаж

В 1950-х и 1960-х годах программное обеспечение поставлялось вместе с оборудованием. IBM выпускала исходный код вместе со своими системами, а группы пользователей, такие как SHARE, основанная в 1955 году, обменивались программами на магнитных лентах. Этому положили конец два события. В 1969 году IBM объявила, что будет продавать программное обеспечение отдельно от оборудования, что создало самостоятельный рынок ПО. Затем изменилось законодательство. Закон об авторском праве на компьютерные программы 1980 года (Computer Software Copyright Act of 1980) подтвердил, что программы в США являются объектами авторского права. После 1980 года код, написанный не вами, по умолчанию стал закрытым, поэтому для его распространения требовалось письменное разрешение автора.

Homebrew Computer Club и «Открытое письмо любителям»

Первая встреча Homebrew Computer Club состоялась в марте 1975 года в гараже в Менло-Парке, Калифорния. Участники приносили оборудование и перфоленты, а копирование было неотъемлемой частью встреч. Altair BASIC, написанный Биллом Гейтсом и Полом Алленом, распространялся по залу на скопированных лентах. В феврале 1976 года Гейтс ответил на это в новостной рассылке клуба «Открытым письмом любителям».

Как должно быть известно большинству любителей, большинство из вас воруют программное обеспечение.

Он писал, что менее одного из десяти владельцев Altair заплатили за BASIC, и что машинное время, затраченное на его написание, стоило более 40,000 долларов. В этом письме уже содержится вся суть современного спора. Копирование программного обеспечения ничего не стоит и помогает каждому, кто его копирует. Однако его написание всё равно стоило кому-то года жизни. Каждая лицензия, описанная ниже, является попыткой учесть оба этих факта одновременно.

GNU в 1983 году и GPL как юридическое изобретение

Ричард Столлман анонсировал проект GNU в сентябре 1983 года в Usenet — сети групп новостей, которую использовали до появления веба. GNU расшифровывается как "GNU's Not Unix". План состоял в создании полноценной Unix-совместимой системы, которую любой мог бы копировать и изменять.

Свободный Unix! Начиная с этого Дня благодарения, я собираюсь написать полную Unix-совместимую программную систему под названием GNU (от Gnu's Not Unix) и бесплатно раздать её всем, кто сможет ею воспользоваться.

Free Software Foundation (FSF) была основана в 1985 году. Её определение свободного программного обеспечения перечисляет четыре свободы, пронумерованные с нуля: запускать программу для любых целей, изучать и изменять её, распространять копии и распространять изменённые версии. Свобода 1 требует наличия исходного кода, так как изучать бинарный файл практически невозможно. "Свободное" (free) здесь означает свободу, а не цену. Сама FSF использует фразу: "свобода как в свободе слова, а не как в бесплатном пиве".

Манифест не был изобретением. Им стала лицензия. GNU General Public License (GPL) использует авторское право, чтобы требовать обмена кодом, а не запрещать его. Вы получаете четыре свободы при одном условии: любой, кому вы передаёте программное обеспечение, также получает их вместе с исходным кодом. Столлман назвал это copyleft. Лицензия впервые поставлялась с GNU Emacs в 1985 году, стала GPL версии 1 в 1989 году и версии 2 в июне 1991 года.

GPL работает, потому что она опирается на закон об авторском праве, а не противоречит ему. Без лицензии у вас вообще нет права распространять чужой код. GPL предоставляет это право и накладывает на него условия. Поэтому поставщик, который поставляет модифицированный код под GPL внутри маршрутизатора и отказывается предоставить исходный код, не просто нарушает обещание. Он нарушает авторские права, что позволяет правообладателю обратиться в суд. Именно поэтому принудительное исполнение лицензии возможно — от дел gpl-violations.org Харальда Вельте в 2000-х годах до иска Software Freedom Conservancy против Vizio, поданного в 2021 году, в котором утверждается, что человек, купивший телевизор, также может потребовать исходный код.

Завершение создания системы Linux

К 1991 году проект GNU уже располагал компилятором, библиотекой языка C, командной оболочкой и большинством необходимых инструментов. Рабочего ядра не было, так как разработка собственного ядра GNU, Hurd, заняла гораздо больше времени, чем планировалось. В августе 1991 года студент из Хельсинки опубликовал сообщение в группе новостей comp.os.minix:

Я создаю (бесплатную) операционную систему (просто хобби, она не будет такой большой и профессиональной, как gnu) для клонов 386(486) AT.

Linux 0.01 появился в сентябре 1991 года под лицензией, которую Линус Торвальдс написал самостоятельно и которая запрещала продажу системы. В начале 1992 года он заменил её на GPLv2 и впоследствии неоднократно называл это решение одним из лучших. Именно лицензия сделала вклад корпораций безопасным: компания могла выделить инженеров для работы над ядром, будучи уверенной, что конкурент не сможет сделать эти улучшения закрытыми.

Бесплатная версия Unix уже существовала в Беркли. Причина, по которой именно Linux, а не BSD (Berkeley Software Distribution), стал стандартом бесплатной Unix, отчасти кроется в судебном процессе. В 1992 году Unix System Laboratories подала иск против Berkeley Software Design, и дело рассматривалось до начала 1994 года. В течение этих двух лет системы BSD несли юридические риски, в то время как Linux — нет, и именно в этот период приток пользователей стал массовым. FSF просит называть объединенную систему GNU/Linux, поскольку Linux является ядром, а большинство окружающих его инструментов относятся к GNU. Большинство людей говорят Linux. Оба названия указывают на один и тот же набор программного обеспечения.

1998 год: ребрендинг open source и раскол, который так и не был преодолен

В январе 1998 года компания Netscape объявила о публикации исходного кода своего браузера. Это была крупнейшая на тот момент компания, решившаяся на такой шаг, и это выявило практическую проблему. Фраза "free software" в английском языке воспринимается как "бесплатное программное обеспечение", и именно так ее поняли руководители бизнеса. В феврале 1998 года в Пало-Альто собралась группа людей, чтобы найти более удачный термин, и Кристин Петерсон предложила "open source". Через несколько недель Эрик Реймонд и Брюс Перенс основали организацию Open Source Initiative (OSI). Она приняла определение Open Source Definition, адаптированное из Debian Free Software Guidelines, которые Перенс написал в 1997 году.

Определение Open Source Definition содержит десять критериев. Два из них определяют суть большинства современных споров: исходный код должен быть доступен, а лицензия не должна ограничивать круг лиц, использующих программу, или цели ее использования. Лицензия, содержащая условие "вы не можете предлагать это как коммерческий сервис", не проходит проверку, независимо от того, что она разрешает в остальном. Запомните это утверждение. Именно эту черту переходят современные лицензии типа source-available.

Раскол, возникший в 1998 году, касается причин, а не того, какие лицензии являются приемлемыми. Позиция FSF этична: пользователь, который не может изменить программу, не контролирует свой собственный компьютер. Позиция OSI, представленная бизнесу в эссе Реймонда "Собор и базар", практична: открытая разработка создает более качественное программное обеспечение, и компания может извлечь из этого выгоду. Ответ Столлмана "Почему Open Source упускает суть свободного ПО" до сих пор опубликован на gnu.org, и он никогда не принимал новый термин. Перенс, который помогал его создавать, ушел из совета директоров OSI в 1999 году, заявив, что движение отошло от идей свободного программного обеспечения.

Стоит уточнить, насколько невелик практический разрыв. Список свободных лицензий FSF и список одобренных лицензий OSI почти полностью совпадают, включая GPL, MIT, Apache 2.0 и BSD. Авторы, которым нужно охватить оба значения сразу, используют аббревиатуры FOSS (free and open source software) или FLOSS (free/libre and open source software).

Как компании научились выпускать код

Выход Red Hat на фондовый рынок в 1999 году показал, что прибыль приносит поддержка и упаковка ПО, а не продажа копий. В 2001 году IBM инвестировала миллиард долларов в Linux. В том же 2001 году генеральный директор Microsoft назвал Linux «раком», однако в 2016 году эта же компания вступила в Linux Foundation в качестве платинового участника, а в 2018 году приобрела GitHub за 7.5 миллиарда долларов акциями. В 2019 году IBM купила Red Hat за 34 миллиарда долларов. Это не было изменением отношения к лицензиям. Это было изменение того, где именно сосредоточены деньги. Когда операционная система становится общим активом, содержание собственной версии обходится дорого, и каждый вендор предпочитает конкурировать на уровне выше.

Корпоративное владение работает и в обратную сторону. Когда Oracle купила Sun в 2010 году, она получила MySQL и OpenOffice.org, после чего оба сообщества покинули проект. MariaDB выросла из MySQL, а LibreOffice был форкнут из OpenOffice.org в сентябре 2010 года. Форк — это единственный реальный голос, которым обладает сообщество пользователей, и именно лицензия делает этот голос возможным.

Почему у некоторых приложений, которые вы размещаете самостоятельно, появились форки

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

• MongoDB приняла лицензию Server Side Public License (SSPL) в октябре 2018 года. SSPL гласит: если вы предлагаете ПО другим пользователям как сервис, вы обязаны опубликовать исходный код всего, что используете для предоставления этого сервиса. Организация OSI не признала её открытой лицензией, и в 2019 году MongoDB отозвала её с рассмотрения.
• Redis добавила ограничения на использование некоторых модулей в 2018 и 2019 годах, а затем в марте 2024 года с выходом версии 7.4 перевела основной сервер на двойные условия с доступным исходным кодом. Спустя несколько дней появился форк последнего релиза под лицензией BSD — Valkey. Он находится под управлением Linux Foundation и поддерживается, в частности, Amazon, Google и Oracle. В мае 2025 года Redis добавила лицензию Affero General Public License version 3 (AGPLv3), одобренную OSI, в качестве третьего варианта для Redis 8.
• Elastic перевела Elasticsearch и Kibana с лицензии Apache 2.0 на двойные условия SSPL и Elastic License в январе 2021 года. Amazon создала форк OpenSearch. В августе 2024 года Elastic добавила AGPLv3 как третий вариант, а в сентябре 2024 года проект OpenSearch был передан в Linux Foundation как OpenSearch Software Foundation.
• HashiCorp перевела Terraform и другие свои инструменты на лицензию Business Source License (BUSL) в августе 2023 года. BUSL не является лицензией с открытым исходным кодом, пока она действует, так как запрещает конкурентное использование в производственных целях. Каждый релиз переходит на открытую лицензию в фиксированную дату, для Terraform этот срок составляет четыре года. Форк OpenTofu появился в течение нескольких недель и теперь также находится под управлением Linux Foundation.

У обеих сторон есть веские аргументы, и никто не действует недобросовестно. Компания, оплачивающая труд пятидесяти сотрудников, сталкивается с проблемой, когда гораздо более крупная фирма перепродает её работу, и одной лишь доброй волей это не исправить. Пользователь, который строил инфраструктуру на условиях Apache 2.0 и внезапно оказался в новых правовых рамках, также сталкивается с проблемой, причём его мнения никто не спрашивал. Обратите внимание на то, что произошло далее в двух из этих случаев. После того как форки закрепились, Elastic и Redis вернули строгий копилефт. Копилефт решил исходную претензию, так как AGPLv3 требует от провайдера сервиса публиковать изменения, которые он использует. По состоянию на август 2026 года оба проекта и оба форка продолжают активно развиваться, что является результатом, для которого и были созданы данные лицензии.

Кто имеет право изменить лицензию

Проект может быть перелицензирован только в том случае, если одна сторона владеет авторскими правами на весь его код. Компании получают такой контроль одним из двух способов. Соглашение о передаче авторских прав (copyright assignment) переносит право собственности на каждый вклад в пользу компании. Соглашение с участником (CLA) оставляет право собственности за вами, но предоставляет компании права, достаточные для изменения лицензии на вашу работу. Любой из этих документов обычно подписывается путем перехода по ссылке, которую бот публикует в вашем первом pull request.

В Linux нет CLA. Вклады принимаются на условиях GPLv2 с использованием Developer Certificate of Origin, а авторские права распределены между тысячами людей и компаний. Никто не может изменить лицензию Linux, так как невозможно собрать все необходимые подписи. Такая же защита действует для любого проекта с множеством независимых правообладателей, и это более надежная защита, чем просто обещание, так как она основана на факте владения правами.

Поэтому при выборе программного обеспечения, от которого вы планируете зависеть, следует задавать вопрос не о том, является ли оно открытым сегодня. Важно понимать, кто может изменить условия лицензирования и может ли этот субъект сделать это в одностороннем порядке.

Что на самом деле дает фонд

Фонд удерживает активы и устанавливает правила принятия решений. Apache Software Foundation, Linux Foundation, входящий в него Cloud Native Computing Foundation и Software Freedom Conservancy выполняют эту задачу каждый по-своему. Фонд не становится нейтральным магическим образом. Участники платят за свои места, а большинство людей, работающих полный рабочий день над крупными проектами фонда, получают зарплату от компаний-участников. То, что вы получаете, имеет более узкие рамки, но все еще представляет большую ценность: товарный знак и процесс выпуска релизов не принадлежат одному вендору, поэтому ни одна компания не может сделать проект закрытым.

Товарный знак — это то, что люди часто упускают из виду. Код распространяется по лицензии. Название является товарным знаком, а товарный знак не подпадает под действие лицензии на код. Вы всегда можете сделать форк кода. Но вы, как правило, не можете оставить за собой название. Именно поэтому форки в этой истории называются Valkey, OpenSearch, OpenTofu и Forgejo.

Проблема сопровождения

Современная инфраструктура опирается на проекты, которые поддерживают один или два энтузиаста без оплаты, и сбои делают это очевидным. Уязвимость Heartbleed в OpenSSL в 2014 году затронула библиотеку, через которую проходила значительная часть зашифрованного веб-трафика, а сопровождалась она горсткой людей практически без финансирования. Инцидент Log4Shell в декабре 2021 года заставил службы реагирования по всему миру взаимодействовать с небольшой командой волонтеров проекта Apache Log4j.

Бэкдор в XZ Utils, обнаруженный в марте 2024 года, является наиболее ярким примером, так как атака была направлена на сопровождающего, а не на код. Учетная запись около двух лет вносила действительно полезные правки в библиотеку сжатия, используемую во всех дистрибутивах Linux. Другие учетные записи оказывали давление на измотанного единственного сопровождающего, чтобы тот принял помощь. Новый со-сопровождающий затем внедрил бэкдор в архивы релизов, нацеленный на системы, где демон SSH (secure shell) слинкован с liblzma. Разработчик обнаружил это, исследуя, почему вход в систему занимал примерно на полсекунды больше времени, чем ожидалось. Это было везением, и все участники событий публично это признали.

Финансирование начало поступать: GitHub Sponsors с 2019 года, Open Collective, немецкий Sovereign Tech Fund с 2022 года и проект Alpha-Omega от OpenSSF. Оно распределяется неравномерно и чаще достается проектам, которые уже получили известность. Регулирование также вступает в силу. Акт о киберустойчивости (Cyber Resilience Act) Европейского союза вступил в силу в декабре 2024 года, при этом большинство его требований станут обязательными с декабря 2027 года. Ранние черновики возлагали ответственность производителя на неоплачиваемых волонтеров, поэтому итоговый текст, после длительного лоббирования со стороны фондов и дистрибутивов, вводит более мягкую категорию под названием «управляющий программным обеспечением с открытым исходным кодом» (open source software steward).

Что история открытого ПО означает для программ на вашем VPS

Каждое приложение в наших руководствах по self-hosting является следствием этих решений. Nextcloud существует благодаря форку: в 2016 году основатель ownCloud и значительная часть команды покинули проект и перезапустили его под лицензией AGPLv3, с тех пор оба продукта развиваются параллельно. Эта история — контекст для альтернатив Nextcloud, заслуживающих внимания и self-hosted альтернатив Dropbox, которые конкурируют с ними обоими.

Та же модель прослеживается в хостинге Git. Сам Gitea начался в 2016 году как форк Gogs. В конце 2022 года торговая марка и домены проекта перешли к компании, в декабре того же года Codeberg создал форк Forgejo, а с выходом версии 9 в 2024 году Forgejo перешел с MIT на GPLv3. Оба варианта рассмотрены в вариантах self-hosted Git-серверов, и разница в лицензиях — одна из главных причин их дальнейшего расхождения. В то же время большая часть свободного ПО разрабатывается на GitHub, закрытой платформе, принадлежащей Microsoft, что является старым спором с весомыми аргументами с обеих сторон: см. чем на самом деле является GitHub.

Прежде чем выделять сервер под проект, стоит потратить десять минут на четыре проверки.

• Прочитайте файл LICENSE в репозитории, а не на маркетинговой странице. Страницы могут называть проект «open source» еще долго после того, как содержимое файла перестало этому соответствовать.
• Проверьте наличие CLA или соглашения о передаче авторских прав. Если они есть, единственный владелец может изменить условия будущих релизов.
• Выясните, кто владеет авторскими правами: одна компания, множество участников или фонд.
• Посчитайте активных мейнтейнеров. Проект с одним мейнтейнером — это риск как для этого человека, так и для вас.

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

Часть этой истории можно прочитать на машине перед вами. Каждый пакет в системе Debian или Ubuntu поставляется со своими условиями:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

Первое число показывает, сколько установленных пакетов содержат файл авторских прав (copyright), обычно на небольшом VPS их несколько сотен. Вторая команда выводит начало такого файла для bash, где указана лицензия GNU General Public License version 3. Отсутствие файла означает, что пакет был собран не по правилам Debian; это редкость, и такой пакет стоит изучить внимательнее, прежде чем доверять ему.

FAQ

В чем разница между свободным ПО и ПО с открытым исходным кодом?

Они охватывают практически один и тот же набор лицензий, но расходятся в вопросе о том, почему эти лицензии важны. «Свободное ПО» — более старый термин, предложенный Free Software Foundation в 1985 году, и его аргументация носит этический характер: пользователь, который не может изменить программу, не контролирует свой компьютер. Термин «открытый исходный код» был придуман в феврале 1998 года, чтобы сделать те же лицензии более понятными для компаний, и его аргументация носит практический характер. Лицензии GPL, MIT, BSD и Apache 2.0 входят в оба официальных списка. Авторы, которые хотят объединить оба понятия, используют аббревиатуры FOSS или FLOSS.

Является ли ПО с доступным исходным кодом тем же самым, что и ПО с открытым исходным кодом?

Нет. «Доступный исходный код» (source-available) означает, что вы можете прочитать код. «Открытый исходный код» (open source), согласно определению Open Source Definition, также означает, что лицензия не может ограничивать круг лиц, использующих ПО, или цели его использования. Лицензии SSPL и Business Source License ограничивают коммерческое использование конкурентами, поэтому ни одна из них не является открытым исходным кодом по данному определению, несмотря на то, что исходный код публикуется. Если вы используете ПО только для себя, эти ограничения могут вас никогда не коснуться. Если вы планируете строить на его основе продукт, сначала внимательно изучите текст лицензии.

Может ли компания отозвать лицензию на ПО с открытым кодом, которую она уже предоставила?

Не для того кода, который она уже выпустила. Эта версия остается под той лицензией, с которой она была выпущена; именно поэтому форки, такие как Valkey и OpenTofu, смогли начаться с последнего коммита, выпущенного под разрешительной лицензией. Что компания может сделать, так это перевести будущие версии на новые условия, и она может это сделать только в том случае, если контролирует авторские права на весь проект через передачу прав или соглашение с участниками (contributor licence agreement). Проекты со множеством независимых правообладателей, включая Linux, не могут быть перелицензированы кем-либо в одностороннем порядке.

Какую лицензию стоит искать в ПО для self-hosted решений?

Для ПО, которое вы запускаете самостоятельно и не перепродаете, любая лицензия, одобренная OSI, такая как GPL, AGPL, MIT или Apache 2.0, предоставляет всё необходимое. Более важным критерием является то, кто владеет авторскими правами, так как это определяет, могут ли условия измениться в будущем. Проект, принадлежащий фонду или множеству независимых участников, не может быть перелицензирован вопреки воле пользователей. Проект от одного вендора с соглашением о передаче прав (contributor licence agreement) — может. Оба варианта могут быть качественным ПО. Но только один из них может изменить правила игры в одностороннем порядке.