Можно ли брать чужой код из GitHub в свой продукт и продавать его в 2026

Ты собираешь продукт и находишь на GitHub готовый кусок: библиотеку, шаблон, целый проект, который делает ровно то, что нужно. Claude предлагает подтянуть его к тебе. И тут стопор: код вроде лежит открыто, но можно ли его вообще брать, а тем более продавать продукт, где он стоит внутри? Не прилетит ли потом претензия от автора.

Я разберу это по порядку: почему открытый код на GitHub - это ещё не разрешение, какие лицензии дают брать код и продавать продукт, из-за каких придётся открыть весь свой исходник, и как проверить лицензию за минуту до того, как взял. Без «зависит от ситуации».

В Telegram-канале - что нового в вайб-кодинге: инструменты, находки, ошибки. Подпишись.

Правда ли, что раз код лежит на GitHub, его можно брать бесплатно?

Главная ловушка тут в слове «открытый». Видно исходники - кажется, что раз их не спрятали, значит, разрешили брать. Логика неверная. «Открытый для чтения» и «разрешённый к использованию» - это разные вещи.

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

Второй слой - сам GitHub. Люди думают: раз я согласился с правилами GitHub, выложив код, то и брать чужой код оттуда мне тоже можно. Правила говорят ровно обратное. Выкладывая репозиторий в открытый доступ, автор разрешает остальным лишь смотреть его и форкать - то есть делать копию внутри самого GitHub. Использовать код у себя это не разрешает.

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

Что вообще решает, можно ли взять чужой код?

Всё упирается в один файл. В нормальном репозитории лежит файл лицензии - чаще всего LICENSE, иногда LICENSE.md или упоминание прямо в README. Это и есть разрешение от автора, где написано, на каких условиях код можно брать. GitHub обычно показывает название лицензии сбоку, на странице репозитория, ещё до того как ты откроешь сам файл.

Чтобы не тонуть в юридическом языке, лицензию удобно читать через три вопроса про твой случай:

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

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

Одна взятая библиотека - это ещё не продукт. Дальше начинается то, где вайб-кодеры и вязнут: собрать из кусков систему, которая работает стабильно и которую не страшно продавать. На практикуме за три вечера собираешь всю связку - ИИ-клон + Второй мозг + Контекст-инжиниринг. В том числе как складывать такие проверки в свой Второй мозг, чтобы не держать всё в голове.

Какие лицензии разрешают брать код и продавать продукт?

Начну с хороших новостей. Для того, кто собирает продукт на продажу, лучший вариант - так называемые разрешительные лицензии. Их несколько, но чаще всего встречаются три: MIT, Apache 2.0 и BSD. Все они отвечают «да» на первые два вопроса и разрешают оставить твои исходники закрытыми.

Самая частая и самая простая - MIT. Её текст умещается в один абзац.

Проще говоря, MIT разрешает делать с кодом почти всё, включая продавать продукт и не открывать свои исходники. Единственная обязанность - оставить внутри текст лицензии и строчку об авторстве. Под MIT выпущены, например, Babel, .NET и Rails, так что код с такой лицензией ты почти наверняка уже используешь.

Apache 2.0 устроена похоже, но добавляет два важных пункта. Первый - явная защита от патентных претензий: авторы кода обещают не судиться с тобой по патентам на этот код. Второй - чуть больше формальностей при использовании.

BSD (в вариантах на 2 и 3 пункта) по сути близка к MIT: бери, меняй, продавай, сохрани копирайт. Свёл все три в таблицу, чтобы разница была видна сразу.

Как это читать под себя. Увидел у чужого кода MIT, Apache 2.0 или BSD - выдыхаешь: код можно брать в коммерческий продукт, менять и не показывать свои исходники. От тебя нужно лишь одно - не выкидывать файл лицензии и указание авторства из того куска, что ты взял.

Что за копилефт и почему из-за GPL придётся открыть свой продукт?

А вот тут главная ловушка, в которую и попадают. Есть отдельный тип лицензий - с копилефтом. Самые известные - GPL и AGPL. Они выглядят как открытые и разрешают брать код, но взамен требуют кое-что серьёзное.

Условие GPL такое: если ты берёшь код под этой лицензией и распространяешь свой продукт, ты обязан открыть исходники всего продукта под той же GPL и дать их пользователям. Продавать доступ при этом можно, а вот оставить свой код закрытым - нельзя. Так это формулирует и сам справочник GitHub по выбору лицензии.

Разберём на примере вайб-кодера. Ты собрал платный веб-сервис и вставил в него одну удобную библиотеку под GPL. Формально ты теперь обязан отдать всем желающим исходники всего своего сервиса под GPL. То есть конкурент может взять твой код целиком. Для закрытого коммерческого продукта это чаще всего неприемлемо, и одна библиотека тянет за собой в открытый доступ весь проект.

AGPL - ещё строже. Обычная GPL срабатывает, когда ты раздаёшь программу файлом. Многие думали, что можно обойти это: не раздавать программу, а просто крутить её на своём сервере и давать людям доступ по сети. AGPL закрывает и эту лазейку: открыть исходники придётся, даже когда ты просто держишь сервис онлайн. Для вайб-кодера, который поднимает именно веб-сервис, это критично.

Отсюда простое правило. Увидел у чужого кода GPL или AGPL и собираешь закрытый коммерческий продукт - либо ищи замену с лицензией MIT или Apache, либо готовься открыть весь свой исходник. Само по себе это не «плохая» лицензия, под ней живут Ansible и uBlock Origin, но её условия несовместимы с закрытым продуктом.

Что делать, если у репозитория нет файла лицензии вообще?

Частая ошибка - решить, что раз лицензии нет, то и ограничений нет, бери свободно. Всё наоборот. Отсутствие лицензии - это не разрешение, а запрет по умолчанию. Код без лицензии остаётся под полным авторским правом автора, и трогать его нельзя.

Тут снова работает то правило, с которого мы начали: по умолчанию код защищён авторским правом, и без явного разрешения его нельзя копировать, менять и распространять. Возможность посмотреть и форкнуть внутри GitHub эту стену не пробивает - она не даёт права использовать код в своём продукте.

Что делать на практике, если код без лицензии, а он очень нужен:

1. Написать автору. Прямо в репозитории через раздел обсуждений или на почту: спросить, можно ли использовать код и на каких условиях. Иногда автор просто забыл добавить лицензию и добавит её по просьбе.
2. Искать замену. Почти для любой задачи есть второй, третий и десятый похожий репозиторий - среди них найдётся такой же с нормальной лицензией MIT или Apache.
3. Не брать. Если разрешения нет и замены нет - код не твой, и ставить его в продукт на продажу нельзя. Соблазн «да кто узнает» плохо кончается ровно в тот момент, когда продукт начинает приносить деньги и становится заметным.

Признаёт ли российский закон эти лицензии?

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

По смыслу этой статьи открытая лицензия - это договор, к которому ты присоединяешься самим фактом использования кода. Все условия должны быть доступны тебе до начала использования (у открытых лицензий текст лежит рядом с кодом), и по умолчанию такая лицензия безвозмездная. Для программ она действует, пока действует исключительное право автора. Проще говоря, закон прямо признаёт: взял код по MIT или Apache, соблюдаешь их условия - значит, действуешь легально.

Обратная сторона тоже закреплена в кодексе. Программа для ЭВМ охраняется авторским правом наравне с текстами и книгами, а использование чужого произведения без разрешения правообладателя нарушает его исключительное право. То есть «взял без лицензии» - это полноценное нарушение, за которое по закону можно получить претензию и иск.

А если чужой код в проект вставил сам Claude?

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

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

Но есть исключение, о котором стоит помнить. Иногда ИИ выдаёт узнаваемый чужой кусок почти дословно - целую функцию из известной библиотеки. В таком случае лицензия этой библиотеки продолжает действовать, кто бы физически ни нажал на клавиши. Поэтому крупные готовые блоки, которые Claude притащил откуда-то целиком, стоит проверять так же, как если бы ты скопировал их сам.

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

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

1. Найди название лицензии на странице репозитория

   Открой репозиторий на GitHub. Название лицензии обычно видно в правой колонке или под списком файлов - например, «MIT License», «Apache-2.0», «GPL-3.0». Если там пусто и файла лицензии нет - это уже красный флаг, к нему вернёшься на последнем шаге.

2. Открой сам файл лицензии

   Найди в списке файлов LICENSE, LICENSE.md или COPYING и открой его. Убедись, что название совпадает с тем, что показано сбоку, и что лицензия относится именно к тому коду, который ты берёшь, а не к отдельной части репозитория.

3. Определи тип: разрешительная или с копилефтом

   MIT, Apache 2.0, BSD - разрешительные, код можно брать в закрытый коммерческий продукт. GPL и AGPL - с копилефтом, они заставят открыть исходники твоего продукта. Само слово в названии лицензии обычно сразу отвечает на вопрос.

4. Сопоставь со своим случаем

   Ответь на три вопроса: продаёшь ли ты продукт, меняешь ли код, хочешь ли держать исходники закрытыми. Для закрытого продукта на продажу подходят MIT, Apache, BSD. GPL и AGPL - только если готов открыть весь свой код.

5. Нет лицензии - не берёшь

   Если файла лицензии нет и в README про разрешение ничего не сказано, код брать нельзя. Напиши автору и попроси разрешение или найди аналог с нормальной лицензией. «Лежит открыто» - это не разрешение.

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

Полная схема вайб-кодинга за три вечера: ИИ-клон + Второй мозг + Контекст-инжиниринг. Записи эфиров в личном кабинете, доступ 30 дней.