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

Короткий ответ: лицензия отвечает на три твоих вопроса

Файл с разрешением от автора лежит в проекте и называется LICENSE, иногда COPYING или LICENSE.md. Это и есть ответ. Читать его целиком не нужно, нужно найти в нём ответы на три вопроса про тебя

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

Первые два почти у всех известных лицензий - «да». Вся разница в третьем, и именно на нём люди попадают

Что это тебе даёт: слова MIT, Apache или BSD в файле закрывают вопрос - бери и не думай дальше. GPL и AGPL для закрытого продукта на продажу не подходят, там придётся искать замену. А LGPL разобрана отдельным разделом ниже: это не «нет», это «да, но»

Проверка за две минуты: пять шагов сверху вниз

Порядок один и не меняется от проекта к проекту. Забрать сам проект - отдельная задача, шесть способов скачать с GitHub разобраны у меня в отдельном разборе, здесь речь только про разрешение

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

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

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

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

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

Четвёртый шаг - поиск по этому списку. Ищешь три вещи: буквы GPL, буквы LGPL и строки, где лицензия вообще не указана. Всё остальное можно пролистать: MIT, ISC, BSD и Apache вопросов не создают

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

Мой замер: одна строка привела 54 чужих автора

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

В первом проекте я вписал ровно одну строку - библиотеку для веб-сервера. Ко мне приехало 65 чужих кусочков кода от разных людей. Все с разрешительными лицензиями: 60 под MIT, 4 под ISC, один под BSD. Тут повезло

Во втором проекте я вписал три строки. Приехало 54 кусочка, и вот их разбор

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

Где это ломается на практике: у самой библиотеки для картинок на её странице честно написано Apache 2.0, и по первому шагу проверки она зелёная. А внутрь моего продукта вместе с ней приехал отдельный кусок с лицензией LGPL. На карточке этого не видно, потому что это другой автор и другой проект

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

Что это тебе даёт: правило «посмотри лицензию проекта» верное, но недостаточное. Смотреть надо весь список, и делается это одной командой в том же окне, где ты ставил библиотеку. Если ты собираешь продукт в связке с ИИ, проверка кода от нейросети - это соседняя привычка из того же ряда

LGPL внутри: не «нельзя», а «можно с условиями»

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

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

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

Если библиотеку в проект подтянул помощник в редакторе - хоть GitHub Copilot, хоть Cursor - список всё равно смотришь ты, инструмент про лицензии не спрашивает

Первые три - это буквально текстовый файл и пара строк в разделе «о программе». Четвёртое - причина, по которой LGPL-библиотеку подключают отдельным куском, а не вплавляют внутрь своего кода

Что это тебе даёт: увидел LGPL в списке - это не стоп-кран. Это три текстовых пункта работы и одно техническое решение. А вот полноценная GPL в том же месте - действительно стоп: там условие не «сообщи», а «открой весь свой исходник»

Ложная тревога: поле пустое, а разрешение лежит рядом

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

Я открыл сам каталог этого кусочка. Внутри лежит файл LICENSE, и в нём обычная лицензия MIT с именем автора и годом. Автор просто не продублировал название в служебной карточке пакета

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

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

«Other» на карточке: три проекта, которые выглядят открытыми

7 сентября я прогнал через официальный запрос к GitHub одиннадцать известных проектов и посмотрел, что он отвечает про каждый. Шесть ответили «MIT», два ответили «GPL-3.0», а три ответили странное: «Other», без названия

Я открыл файлы лицензий у всех трёх

• у поисковой системы Elasticsearch в файле лежат сразу три лицензии одновременно, и по умолчанию действуют все три: AGPL, отдельная лицензия сервера и собственная лицензия компании
• у базы MongoDB - собственная лицензия сервера версии 1 от 16 октября 2018 года
• у сервиса автоматизации n8n - лицензия с названием «Sustainable Use License». В том же файле написано ещё две вещи: содержимое всех веток, кроме главной, «не лицензировано» вовсе, а файлы с определённой пометкой в имени требуют платной корпоративной лицензии

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

Честная поправка к моему же сайту: в разборе десяти открытых проектов вместо платных сервисов n8n стоит как замена платному сервису. Для себя - да, ставь и пользуйся. Как кирпич в продукт на продажу - это другой вопрос и другой ответ

Что это тебе даёт: слово «Other» в карточке - это не «мы не разобрались», это сигнал открыть файл руками. За ним почти всегда стоит лицензия с ограничением на коммерцию

Почему карточка GitHub вообще не гарантия

Тут стоит понять, откуда GitHub берёт название лицензии. Он не читает файл как юрист. Он сравнивает текст файла с коротким списком известных лицензий и, если совпало, показывает название. Не совпало - показывает «Other»

Сам GitHub пишет об этом в своей же справке прямым текстом, и это, пожалуй, главная цитата всей статьи

«we're not lawyers and that we make mistakes like everyone else. For that reason, GitHub provides the information on an "as-is" basis and makes no warranties regarding any information or licenses provided on or through it» - дословно из справки GitHub про лицензирование проекта, раздел Disclaimer, прочитано 07.09.2026. По-русски: мы не юристы и ошибаемся, как все остальные, поэтому информация даётся «как есть» и без гарантий

Что это тебе даёт: карточка справа - это подсказка, а не документ. Документ - файл. Разница между ними стоит ровно один клик, и этот клик и есть второй шаг проверки

Нет файла лицензии - значит брать нельзя

Самая частая ошибка новичка звучит так: раз лицензии нет, значит и ограничений нет, бери свободно. Всё наоборот

По умолчанию любая работа человека, включая код, защищена авторским правом с момента, как он её сделал. Пока автор явно не разрешил - разрешения нет. Отсутствие файла это не «бери», это «нельзя»

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

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

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

Что говорит российский закон

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

В ней написано так

«Лицензионный договор, по которому автором или иным правообладателем (лицензиаром) предоставляется лицензиату простая (неисключительная) лицензия на использование произведения науки, литературы или искусства, может быть заключен в упрощенном порядке (открытая лицензия)» - Гражданский кодекс РФ, часть 4, статья 1286.1, пункт 1, прочитано 07.09.2026

И там же условие, из-за которого вся конструкция и работает

«Открытая лицензия является договором присоединения. Все ее условия должны быть доступны неопределенному кругу лиц и размещены таким образом, чтобы лицензиат ознакомился с ними перед началом использования соответствующего произведения» - там же, пункт 1

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

А если чужой код вставил не ты, а нейросеть

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

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

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

Отдельно про права на результаты сервисов - картинки, музыку, голос: это снова другая тема, она в разборе про авторское право и ИИ

Что положить в свой продукт: один файл на всё

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

Ответ простой: один текстовый файл рядом с продуктом. Обычно его называют словами «сторонние компоненты» или NOTICE. В нём по одному блоку на каждую чужую часть

• название чужой части и её версия
• имя автора и год из его строки авторства
• название лицензии
• сам текст лицензии или ссылка на него

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

Собирается он не руками. Тот же список, по которому ты смотрел лицензии на третьем шаге проверки, отдаёт эти данные готовыми. У Apache 2.0 есть дополнительное правило: если у автора рядом лежал файл NOTICE, его содержимое надо донести до твоих пользователей, а не просто упомянуть

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

Что теперь делать: порядок на сегодня

Порядок не зависит от того, что ты собираешь - лендинг, сервис или инструмент для себя

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

Что это тебе даёт: ты перестаёшь решать вопрос «а вдруг» и начинаешь решать вопрос «что конкретно у меня внутри». Первое тревожит бесконечно, второе закрывается за один вечер

Отдельная привычка - смотреть, сколько кода вообще пишет помощник и что из этого чужое. Начать с языка можно с Python с нуля, а выбрать инструмент - по разбору лучших для вайбкодинга

Если ты только подступаешься к сборке своими руками, начать стоит с разбора вайбкодинга, а инструменты сравнить в разборе Cursor и Claude Code. Чужие проекты для учёбы, у которых с лицензиями всё в порядке, собраны в подборке семи открытых проектов на GitHub

Где чаще всего спотыкаются

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

Мой опыт с Claude Code говорит ровно одно: чем раньше проверка встроена в привычку, тем дешевле она стоит. Проверка на старте - две минуты. Проверка на продукте, который уже продаётся, - это переписывание куска и разговор с человеком, который тебе написал

Источники

Все страницы открыты живьём 7 сентября 2026 года, цитаты сняты с самих страниц. Замеры лицензий и списка чужих частей сделаны в тот же день на моей машине, их полные выводы лежат рядом со статьёй в каталоге прогонов

• Правила GitHub, раздел про то, какие права даёт публикация проекта: смотреть и делать копию внутри сервиса, дополнительные права даёт приложенная лицензия - docs.github.com, Terms of Service
• Справка GitHub про лицензирование проекта: как определяется название лицензии сравнением со списком известных, и дословный дисклеймер «мы не юристы и ошибаемся, как все остальные» - docs.github.com, Licensing a repository
• Справочный проект GitHub про отсутствие лицензии: что это значит и три варианта действий - choosealicense.com, No License
• Полный текст лицензии MIT: разрешение и единственная обязанность про строку авторства - opensource.org, MIT License
• Полный текст Apache License 2.0, раздел 4 про условия распространения, пометку изменённых файлов и файл NOTICE - apache.org, Apache License 2.0
• Полный текст GNU GPL v3 - gnu.org, GPL-3.0
• Полный текст GNU LGPL v3, раздел 4 «Combined Works» с четырьмя условиями для продукта с библиотекой внутри - gnu.org, LGPL-3.0
• Гражданский кодекс РФ, часть 4, статья 1286.1 «Открытая лицензия на использование произведения науки, литературы или искусства» - zakonrf.info, статья 1286.1 ГК РФ

Памятка: чужой код в своём продукте

Восемь строк, по которым вопрос закрывается без юриста

Частые вопросы