Open Source в контексте ИИ

Open Source (open source) в контексте ИИ — это не просто «модель можно скачать» или «веса выложены публично». В трактовке Open Source Initiative (OSI) open source AI сохраняет свободы использовать, изучать, модифицировать и делиться, а для систем машинного обучения требует форму релиза, пригодную для внесения изменений: не только параметры или веса, но и код и данные, использованные для получения этих параметров.

Практически это означает следующее: если вам показывают только веса, такой релиз ещё нельзя автоматически называть open source AI в смысле OSI. Проверять нужно и лицензию, и набор опубликованных артефактов.

Английские термины: open source, open source AI. Также встречается: «открытый исходный код», «open-source AI». Важно не путать это с «open weights» и более расплывчатыми маркетинговыми формулами вроде open или openly available.

Редакционная оговорка: ниже используется рамка OSI, актуальная по указанным источникам на 2026-08-13. В индустрии слово open часто употребляют шире, чем это допускают официальные определения и лицензии.

Простыми словами

Грубо говоря, open source AI можно представить как кухонный набор для повторения и изменения блюда. Вам отдают не только готовое блюдо, но и рецепт, список ингредиентов и то, как они были использованы, чтобы вы могли приготовить то же самое, изменить рецепт и передать его дальше.

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

Как это работает

На стороне классического ПО OSI по-прежнему опирается на Open Source Definition: open source — это не просто доступ к исходникам, а наличие исходного кода под open-source лицензией. В FAQ OSI отдельно сказано, что open source software можно свободно использовать, изменять и распространять, что free software и open source software — это два термина для одного и того же, и что маркировать ПО как open source следует только при OSI-approved Open Source license.

Для ИИ OSI расширяет эту логику на AI-систему в формулировке, согласованной с обновлённым определением OECD. При этом один и тот же тест применяется не только к исходному коду, но и к системе, модели, весам и параметрам.

Ключевая идея для ML-систем — preferred form for making modifications, то есть предпочтительная форма для внесения изменений. Если релиз действительно должен быть модифицируемым, одних опубликованных весов недостаточно: OSI связывает такую форму с кодом и данными, использованными для получения параметров, вместе с самими параметрами.

Четыре свободы OSI
использовать → изучать → модифицировать → делиться
                 ↓
Проверяем объект релиза:
AI-система / модель / веса / параметры
                 ↓
Для ML нужны артефакты, пригодные для изменений:
параметры(веса) + код + данные, использованные для их получения
                 ↓
Смотрим лицензию и дополнительные ограничения
                 ↓
Вывод: open source AI / open weights / source-available

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

Где применяется

• Выбор модели для доработки внутри компании. Если вам нужна не просто инференс-эксплуатация, а реальная возможность менять поведение системы, проверка на open source AI важнее, чем красивая пометка open в анонсе.
• Юридическая и закупочная проверка. Для команд procurement, compliance и security важно отличать open source от source-available релизов с дополнительными ограничениями.
• Образование и воспроизводимость. Когда вы хотите не только запускать модель, но и изучать, как были получены её параметры, рамка OSI даёт более строгий критерий, чем просто публикация весов.
• Выбор инфраструктуры для развёртывания. При планировании собственного стека или использовании облачных обёрток полезно заранее понимать, даёт ли релиз право и техническую возможность на модификацию, а не только на запуск.

Практический пример

Ниже — короткий сценарий проверки релиза модели перед интеграцией в продукт.

1. Посмотрите, что именно опубликовано. Только веса? Только код? Или есть и веса, и код, и данные, использованные для получения параметров?
2. Проверьте, можно ли реально изучать и изменять систему. Если отсутствует значимая часть артефактов для модификации, термин open source AI уже под вопросом.
3. Прочитайте лицензию целиком. Наличие accept-terms, acceptable-use policy, обязательной атрибуции или порога по масштабу коммерческого использования — это сигнал, что релиз может быть source-available, а не open source в смысле OSI.
4. Сверьте релиз с логикой OSI, а не с маркетингом. OSI отдельно пишет, что open weights сами по себе недостаточны, потому что без них скрыты процесс обучения, код и полные сведения о данных.
5. Используйте checklist OSI как учебный инструмент, а не как финальный юридический вердикт. Сама OSI предупреждает, что checklist ориентирован на generative AI, не является operating manual и допускает разные интерпретации.

Практический вердикт: если вы выбираете модель для форка, кастомизации или внутреннего аудита, не ориентируйтесь на слово open в пресс-релизе. Сначала проверьте артефакты и лицензионные ограничения.

Показательный контраст — Llama 2 Community License Agreement. По источникам OSI и самой лицензии, такой релиз содержит принятие условий, acceptable-use policy, атрибуцию и ограничение, связанное с масштабом коммерческого использования. В терминологии OSI это пример source-available релиза, а не open source.

Чем отличается от…

Если вам нужен более широкий контекст стратегий релиза, полезно отдельно сравнить open-source и closed модели. Но именно в узком словарном смысле OSI главный водораздел проходит не по громкости анонса, а по свободам и набору доступных артефактов.

Ограничения и заблуждения

• Заблуждение: «если веса открыты, модель open source». По OSI это неверно. Open weights — не то же самое, что open source AI.
• Заблуждение: «если код лежит в репозитории, вопрос закрыт». Для ML-систем одного репозитория тоже недостаточно, если нет данных и кода, использованных для получения параметров.
• Заблуждение: «open — это просто про доступ». Базовое определение OSI для ПО прямо говорит, что open source — не только доступ к исходникам, а открытость под соответствующей лицензией.
• Заблуждение: «один чеклист даст окончательный ответ во всех случаях». Сама OSI предупреждает, что её checklist — учебный инструмент, привязанный к generative AI, и не operating manual.
• Ограничение рамки. Пограничные случаи придётся оценивать отдельно: терминология поставщиков, состав артефактов и условия лицензии нужно проверять по конкретному релизу.
• Отдельный слой риска. Даже открытый релиз не снимает автоматически вопросы смещений, происхождения данных и приватности; это отдельные проверки, а не следствие одного ярлыка open source.

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

Связанные термины и инструменты

• Open Weights (открытые веса)
• Open-source vs closed модели
• Генеративный ИИ
• Приватность данных в ИИ
• Replicate — облачный API для запуска open-source ИИ-моделей

Источники

• The Open Source AI Definition – 1.0 – Open Source Initiative
• Frequently Asked Questions – Open Source Initiative
• The Open Source Definition – Open Source Initiative
• Open Weights: not quite what you’ve been told – Open Source Initiative
• Checklist to evaluate machine learning systems – Open Source Initiative
• Explanatory memorandum on the updated OECD definition of an AI system | OECD
• Llama 2 Community License Agreement – Meta AI

Вопросы и ответы

Open source AI и open weights — это одно и то же?

Нет. OSI отдельно подчёркивает, что открытые веса сами по себе недостаточны для open source AI, потому что без кода и данных, использованных для получения параметров, система не находится в предпочтительной форме для модификации.

Можно ли назвать модель open source, если открыт только код?

Для обычного ПО открытый код под open-source лицензией — базовый критерий. Но для ML-систем OSI добавляет требование к артефактам, нужным для внесения изменений: одного кода без параметров и без данных, использованных для их получения, обычно недостаточно.

Почему некоторые модели называют open source, хотя OSI с этим не согласна?

Потому что в маркетинге термин open часто используют шире. Если лицензия добавляет принятие условий, acceptable-use policy, атрибуцию или ограничения коммерческого использования, OSI предлагает относить такой релиз к source-available, а не к open source.

Достаточно ли checklist OSI для финальной оценки релиза?

Нет. OSI сама пишет, что checklist — это учебный инструмент, а не operating manual; он ориентирован на generative AI и допускает разные интерпретации. Для спорных случаев нужна отдельная проверка конкретной лицензии и набора опубликованных артефактов.