Что такое open source: открытый исходный код, лицензии и примеры

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

Ниже — чем open source отличается от свободного ПО и от «просто открытого» кода, какие лицензии встречаются чаще всего и что они требуют, реальные плюсы и минусы, примеры проектов и как сделать первый вклад.

Три понятия, которые путают

Бесплатность и открытость — разные вещи. Open source-программу можно продавать, а бесплатная программа может быть проприетарной (закрытой).

Откуда взялся термин

В 1983 году Ричард Столлман объявил о проекте GNU — свободной UNIX-совместимой операционной системе, а в 1985 году основал Free Software Foundation (FSF). FSF называет программу свободной, если она дает четыре свободы: запускать ее для любых целей; изучать и менять (для этого нужен исходный код); распространять копии; распространять измененные версии.

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

Эта двусмысленность мешала продвигать идею в бизнесе. В 1998 году появился термин «open source» и организация Open Source Initiative (OSI). Она опубликовала Open Source Definition — 10 критериев лицензии, выросших из принципов Debian. Среди них — свободное распространение, доступность исходного кода, разрешение производных работ, отсутствие дискриминации людей и сфер применения.

На практике почти все популярные лицензии признаны и OSI, и FSF. Различие скорее в акцентах: FSF говорит об этике и правах пользователя, OSI — о практической пользе открытой разработки.

Лицензии open source: какие бывают и что требуют

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

• Разрешительные (permissive): MIT, BSD, Apache 2.0. Код можно встроить даже в закрытый продукт. Обычно достаточно сохранить уведомление об авторском праве и текст лицензии.
• Копилефт (copyleft): GPL, LGPL, AGPL, MPL. Если вы распространяете производную работу, ее нужно распространять под той же лицензией с исходным кодом. Название — игра слов на copyright.
• Передача в общественное достояние: CC0, Unlicense. Автор отказывается от прав, насколько это позволяет законодательство конкретной страны.

Важная граница: требования GPL срабатывают при распространении программы. Если компания изменила GPL-код и использует его только внутри себя, публиковать изменения GPL ее не обязывает. AGPL закрывает этот сценарий для сервисов, с которыми пользователи работают по сети.

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

Как узнать лицензию проекта

Лицензию ищут в файле LICENSE или COPYING в корне репозитория и в метаданных пакета. Современные пакеты указывают ее SPDX-идентификатором — стандартным коротким именем вроде MIT или Apache-2.0. Скрипт ниже выводит лицензии всех установленных Python-пакетов:

from importlib.metadata import distributions

for dist in sorted(distributions(), key=lambda d: d.metadata["Name"].lower()):
    meta = dist.metadata
    # Новый способ (PEP 639): SPDX-выражение в поле License-Expression
    license = meta.get("License-Expression")
    if not license:
        # Старый способ: свободный текст в поле License или классификаторы
        classifiers = [c for c in (meta.get_all("Classifier") or [])
                       if c.startswith("License ::")]
        license = meta.get("License") or "; ".join(classifiers) or "не указано"
    print(f'{meta["Name"]:<20} {dist.version:<10} {license.splitlines()[0][:60]}')

Результат в чистом окружении Python 3.14.7 после pip install requests==2.34.2 (актуальная версия на сентябрь 2026; версии зависимостей у вас могут отличаться):

certifi              2026.7.22  MPL-2.0
charset-normalizer   3.5.1      MIT
idna                 3.20       BSD-3-Clause
pip                  26.2.1     MIT
requests             2.34.2     Apache-2.0
urllib3              2.8.0      MIT

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

Плюсы и минусы открытого ПО

Плюсы, которые реально работают:

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

Минусы и риски:

• Нет гарантий по умолчанию. Почти все лицензии поставляют ПО «как есть». Гарантированную поддержку дает коммерческий договор, например подписка на Red Hat Enterprise Linux.
• Выгорание и нехватка мейнтейнеров. Критичные библиотеки нередко держатся на одном-двух людях.
• Смена лицензии. Компания может перевести следующие версии под source-available лицензию. Так было с Terraform в 2023 году; сообщество ответило форком OpenTofu.
• Атаки на цепочку поставок. В 2024 году в архиватор xz-utils внедрили бэкдор (CVE-2024-3094) через многолетнее «доверие» к новому мейнтейнеру.
• Юридические обязательства. Нарушение копилефта в продукте грозит претензиями.

Открытый код сам по себе не делает программу ни безопаснее, ни опаснее закрытой. Он дает возможность аудита, но кто-то должен его провести. Уязвимость Log4Shell (CVE-2021-44228) годами жила в популярной открытой библиотеке Log4j.

Примеры open source-проектов

Не все знакомое «открыто» целиком. Исходники редактора VS Code опубликованы под MIT (репозиторий Code — OSS), но сборка, которую скачивают с сайта Microsoft, распространяется под собственной лицензией Microsoft.

Как начать контрибьютить в open source

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

1. Выберите проект, которым пользуетесь сами: так проще понять, что улучшать.
2. Прочитайте README, CONTRIBUTING.md и CODE_OF_CONDUCT.md. В них описаны правила оформления, тесты и требования к коммитам.
3. Найдите задачу с меткой good first issue или help wanted и напишите в ней, что беретесь.
4. Сделайте форк, отдельную ветку под задачу, коммит и откройте pull request (merge request).
5. Отвечайте на ревью и правьте код в той же ветке.

Шаг 4 можно отрепетировать без GitHub: роль сервера сыграют локальные «голые» репозитории. Стенд ниже проверен в bash на Git 2.43 (Ubuntu 24.04) и Git 2.50 (macOS). Запускайте его в пустой временной папке:

set -e
# 1. "Чужой" проект: bare-репозиторий вместо GitHub
git init -q --bare -b main upstream.git
git clone -q upstream.git author && cd author
git config user.name "Author"; git config user.email "author@example.com"
echo "# demo" > README.md && git add README.md && git commit -q -m "Initial commit"
git push -q origin main && cd ..

# 2. Форк = своя копия; клонируем ее и подключаем оригинал как upstream
git clone -q --bare upstream.git fork.git
git clone -q fork.git work && cd work
git config user.name "Contributor"; git config user.email "you@example.com"
git remote add upstream ../upstream.git

# 3. Отдельная ветка под одну задачу, коммит с подписью DCO
git switch -q -c fix-readme-typo
echo "Demo project for first contribution." >> README.md
git commit -q -s -am "docs: describe project in README"
git push -q -u origin fix-readme-typo
git log -1 --format='%s%n%n%b'
git remote -v

Вывод (путь к fork.git будет вашим):

warning: You appear to have cloned an empty repository.
docs: describe project in README

Signed-off-by: Contributor <you@example.com>

origin  /tmp/fork.git (fetch)
origin  /tmp/fork.git (push)
upstream    ../upstream.git (fetch)
upstream    ../upstream.git (push)

Предупреждение в первой строке ожидаемо: автор клонирует пустой репозиторий, еще до первого коммита. Флаг -s добавляет строку Signed-off-by — так автор подтверждает Developer Certificate of Origin (DCO), право отдать этот код проекту. Некоторые проекты вместо DCO просят подписать соглашение контрибьютора (CLA). В реальном проекте после git push вы откроете pull request из своей ветки в ветку main оригинала.

Если не получилось

• Pull request закрыли без слияния. Чаще всего задачу не согласовали заранее или нарушили правила из CONTRIBUTING.md. Сначала обсуждайте изменение в issue.
• Проверка CI упала на DCO. В коммите нет строки Signed-off-by: исправьте последний коммит через git commit --amend -s --no-edit и отправьте ветку с git push --force-with-lease.
• Форк отстал от оригинала. Выполните git fetch upstream и перенесите ветку на свежий upstream/main через git rebase.
• Долго нет ответа. У мейнтейнеров нет обязательств по срокам. Вежливо напомните через неделю-две или выберите более активный проект.

Выводы

• Open source — это код под лицензией, которая разрешает изучать, менять и распространять его; просто опубликованный код без лицензии открытым не является.
• Свободное ПО (FSF, 1985) и open source (OSI, 1998) в основном совпадают по лицензиям, но отличаются акцентами; бесплатность и открытость — разные свойства.
• Разрешительные лицензии (MIT, BSD, Apache 2.0) позволяют встраивать код в закрытые продукты, копилефт (GPL, AGPL, MPL) требует открывать производные работы при распространении.
• Открытость дает прозрачность и независимость от вендора, но не гарантирует безопасность и поддержку.
• Первый вклад проще начать с документации и задач good first issue, по правилам из CONTRIBUTING.md.

Где применяется / связь с практикой

FAQ

Можно ли использовать open source в коммерческом продукте?
Да, лицензии OSD не запрещают коммерческое использование. Но нужно выполнить условия лицензии: для MIT сохранить уведомление, для GPL при распространении открыть исходный код производной программы.

Что будет, если в репозитории нет файла лицензии?
Такой код формально остается под авторским правом автора: читать его можно, а копировать и распространять без разрешения нельзя. Лучше попросить автора добавить лицензию.

Open source и открытое API — одно и то же?
Нет. Открытое API — публичный интерфейс сервиса, код которого может быть полностью закрыт. Open source касается исходного кода и прав на него.