Ты собираешь продукт и находишь на GitHub готовый кусок: библиотеку, шаблон, целый проект, который делает ровно то, что нужно. Claude предлагает подтянуть его к тебе. И тут стопор: код вроде лежит открыто, но можно ли его вообще брать, а тем более продавать продукт, где он стоит внутри? Не прилетит ли потом претензия от автора.
Я разберу это по порядку: почему открытый код на GitHub - это ещё не разрешение, какие лицензии дают брать код и продавать продукт, из-за каких придётся открыть весь свой исходник, и как проверить лицензию за минуту до того, как взял. Без «зависит от ситуации».
В Telegram-канале - что нового в вайб-кодинге: инструменты, находки, ошибки. Подпишись.
Материал справочный, я не юрист. Ниже привожу условия популярных лицензий и нормы со ссылками на первоисточники, но конкретно твой случай сверяй с текстом лицензии и, если продукт коммерческий и крупный, с юристом. Решение ты принимаешь сам.
Правда ли, что раз код лежит на GitHub, его можно брать бесплатно?
Главная ловушка тут в слове «открытый». Видно исходники - кажется, что раз их не спрятали, значит, разрешили брать. Логика неверная. «Открытый для чтения» и «разрешённый к использованию» - это разные вещи.
По умолчанию любая творческая работа, и код в том числе, охраняется авторским правом с момента создания. Пока автор явно не разрешил, использовать его нельзя. Так это описывает GitHub на своей же справочной странице про лицензии.
Когда ты создаёшь творческую работу (а код - это тоже творческая работа), по умолчанию она находится под исключительным авторским правом. Пока ты не приложишь лицензию, которая говорит иначе, никто другой не может копировать, распространять или изменять твою работу, не рискуя нарваться на претензии и суд.
Второй слой - сам GitHub. Люди думают: раз я согласился с правилами GitHub, выложив код, то и брать чужой код оттуда мне тоже можно. Правила говорят ровно обратное. Выкладывая репозиторий в открытый доступ, автор разрешает остальным лишь смотреть его и форкать - то есть делать копию внутри самого GitHub. Использовать код у себя это не разрешает.
Делая репозиторий публичным, ты предоставляешь другим пользователям неисключительную всемирную лицензию использовать, показывать и воспроизводить (путём форка) твои материалы через сервис в пределах функций GitHub. Дополнительные права ты можешь предоставить, приложив лицензию.
Ключевое - в последней фразе: «в пределах функций GitHub» и «дополнительные права даёт лицензия». Форк живёт внутри GitHub. Как только ты хочешь взять код к себе в продукт и тем более продавать его, нужна отдельная лицензия от автора. Нет лицензии - нет права, даже если код лежит на самом виду.
Что вообще решает, можно ли взять чужой код?
Всё упирается в один файл. В нормальном репозитории лежит файл лицензии - чаще всего LICENSE, иногда LICENSE.md или упоминание прямо в README. Это и есть разрешение от автора, где написано, на каких условиях код можно брать. GitHub обычно показывает название лицензии сбоку, на странице репозитория, ещё до того как ты откроешь сам файл.
Чтобы не тонуть в юридическом языке, лицензию удобно читать через три вопроса про твой случай:
- Можно ли использовать этот код в коммерческом продукте, за который берут деньги.
- Можно ли менять код под себя.
- Обязан ли я после этого открыть исходники своего продукта или могу оставить их закрытыми.
Почти вся разница между лицензиями - это разные ответы на третий вопрос. Первые два у популярных открытых лицензий чаще всего «да»: бери, меняй, продавай. А вот заставит ли лицензия открыть твой собственный код - вопрос, на котором и спотыкаются. Дальше разберём главные типы по этим трём вопросам.
Одна взятая библиотека - это ещё не продукт. Дальше начинается то, где вайб-кодеры и вязнут: собрать из кусков систему, которая работает стабильно и которую не страшно продавать. На практикуме за три вечера собираешь всю связку - ИИ-клон + Второй мозг + Контекст-инжиниринг. В том числе как складывать такие проверки в свой Второй мозг, чтобы не держать всё в голове.
Какие лицензии разрешают брать код и продавать продукт?
Начну с хороших новостей. Для того, кто собирает продукт на продажу, лучший вариант - так называемые разрешительные лицензии. Их несколько, но чаще всего встречаются три: MIT, Apache 2.0 и BSD. Все они отвечают «да» на первые два вопроса и разрешают оставить твои исходники закрытыми.
Самая частая и самая простая - MIT. Её текст умещается в один абзац.
Настоящим даётся разрешение любому лицу, получившему копию этого программного обеспечения, безвозмездно использовать его без ограничений, включая права использовать, копировать, изменять, объединять, публиковать, распространять, сублицензировать и продавать копии, при условии, что указанное уведомление об авторском праве и это разрешение будут включены во все копии.
Проще говоря, MIT разрешает делать с кодом почти всё, включая продавать продукт и не открывать свои исходники. Единственная обязанность - оставить внутри текст лицензии и строчку об авторстве. Под MIT выпущены, например, Babel, .NET и Rails, так что код с такой лицензией ты почти наверняка уже используешь.
Apache 2.0 устроена похоже, но добавляет два важных пункта. Первый - явная защита от патентных претензий: авторы кода обещают не судиться с тобой по патентам на этот код. Второй - чуть больше формальностей при использовании.
Ты можешь воспроизводить и распространять копии работы или производных работ на любом носителе, с изменениями или без, при условии, что ты передашь получателям копию этой лицензии, пометишь изменённые файлы, сохранишь уведомления об авторских правах и патентах и приложишь читаемую копию файла NOTICE, если он есть.
BSD (в вариантах на 2 и 3 пункта) по сути близка к MIT: бери, меняй, продавай, сохрани копирайт. Свёл все три в таблицу, чтобы разница была видна сразу.
| Лицензия | Продавать продукт | Держать исходники закрытыми | Что обязан сделать | Защита от патентов |
|---|---|---|---|---|
| MIT | да | да | сохранить копирайт и текст лицензии | нет пункта |
| Apache 2.0 | да | да | копирайт, файл NOTICE, пометить изменения | есть |
| BSD (2 и 3 пункта) | да | да | сохранить копирайт | нет |
Как это читать под себя. Увидел у чужого кода MIT, Apache 2.0 или BSD - выдыхаешь: код можно брать в коммерческий продукт, менять и не показывать свои исходники. От тебя нужно лишь одно - не выкидывать файл лицензии и указание авторства из того куска, что ты взял.
Что за копилефт и почему из-за GPL придётся открыть свой продукт?
А вот тут главная ловушка, в которую и попадают. Есть отдельный тип лицензий - с копилефтом. Самые известные - GPL и AGPL. Они выглядят как открытые и разрешают брать код, но взамен требуют кое-что серьёзное.
Условие GPL такое: если ты берёшь код под этой лицензией и распространяешь свой продукт, ты обязан открыть исходники всего продукта под той же GPL и дать их пользователям. Продавать доступ при этом можно, а вот оставить свой код закрытым - нельзя. Так это формулирует и сам справочник GitHub по выбору лицензии.
GNU GPLv3 тоже разрешает людям делать с твоим проектом почти всё что угодно, кроме одного - распространять его версии с закрытым исходным кодом.
Разберём на примере вайб-кодера. Ты собрал платный веб-сервис и вставил в него одну удобную библиотеку под GPL. Формально ты теперь обязан отдать всем желающим исходники всего своего сервиса под GPL. То есть конкурент может взять твой код целиком. Для закрытого коммерческого продукта это чаще всего неприемлемо, и одна библиотека тянет за собой в открытый доступ весь проект.
AGPL - ещё строже. Обычная GPL срабатывает, когда ты раздаёшь программу файлом. Многие думали, что можно обойти это: не раздавать программу, а просто крутить её на своём сервере и давать людям доступ по сети. AGPL закрывает и эту лазейку: открыть исходники придётся, даже когда ты просто держишь сервис онлайн. Для вайб-кодера, который поднимает именно веб-сервис, это критично.
Отсюда простое правило. Увидел у чужого кода GPL или AGPL и собираешь закрытый коммерческий продукт - либо ищи замену с лицензией MIT или Apache, либо готовься открыть весь свой исходник. Само по себе это не «плохая» лицензия, под ней живут Ansible и uBlock Origin, но её условия несовместимы с закрытым продуктом.
Что делать, если у репозитория нет файла лицензии вообще?
Частая ошибка - решить, что раз лицензии нет, то и ограничений нет, бери свободно. Всё наоборот. Отсутствие лицензии - это не разрешение, а запрет по умолчанию. Код без лицензии остаётся под полным авторским правом автора, и трогать его нельзя.
Тут снова работает то правило, с которого мы начали: по умолчанию код защищён авторским правом, и без явного разрешения его нельзя копировать, менять и распространять. Возможность посмотреть и форкнуть внутри GitHub эту стену не пробивает - она не даёт права использовать код в своём продукте.
Что делать на практике, если код без лицензии, а он очень нужен:
- Написать автору. Прямо в репозитории через раздел обсуждений или на почту: спросить, можно ли использовать код и на каких условиях. Иногда автор просто забыл добавить лицензию и добавит её по просьбе.
- Искать замену. Почти для любой задачи есть второй, третий и десятый похожий репозиторий - среди них найдётся такой же с нормальной лицензией MIT или Apache.
- Не брать. Если разрешения нет и замены нет - код не твой, и ставить его в продукт на продажу нельзя. Соблазн «да кто узнает» плохо кончается ровно в тот момент, когда продукт начинает приносить деньги и становится заметным.
Признаёт ли российский закон эти лицензии?
Резонный вопрос: всё это англоязычные лицензии с зарубежных сайтов, а работает ли это в России. Работает. В Гражданском кодексе есть отдельная статья под такие случаи.
Открытая лицензия на использование произведения науки, литературы или искусства.
По смыслу этой статьи открытая лицензия - это договор, к которому ты присоединяешься самим фактом использования кода. Все условия должны быть доступны тебе до начала использования (у открытых лицензий текст лежит рядом с кодом), и по умолчанию такая лицензия безвозмездная. Для программ она действует, пока действует исключительное право автора. Проще говоря, закон прямо признаёт: взял код по MIT или Apache, соблюдаешь их условия - значит, действуешь легально.
Обратная сторона тоже закреплена в кодексе. Программа для ЭВМ охраняется авторским правом наравне с текстами и книгами, а использование чужого произведения без разрешения правообладателя нарушает его исключительное право. То есть «взял без лицензии» - это полноценное нарушение, за которое по закону можно получить претензию и иск.
А если чужой код в проект вставил сам Claude?
Тут возникает второй слой, и его легко перепутать с первым. Одно дело, когда ты сам зашёл в репозиторий и скопировал оттуда файл: тогда всё, что выше, про лицензию, - твоя прямая обязанность. Другое дело, когда код тебе написал Claude по запросу.
В обычном случае ИИ выдаёт свой текст, собранный под твою задачу, а не копию чужого файла. Тогда вопрос смещается в другую плоскость: он уже про то, кому принадлежит сгенерированный код и можно ли его продавать. Это большая отдельная тема, и я разобрал её в материале про то, кому принадлежит код, написанный ИИ.
Но есть исключение, о котором стоит помнить. Иногда ИИ выдаёт узнаваемый чужой кусок почти дословно - целую функцию из известной библиотеки. В таком случае лицензия этой библиотеки продолжает действовать, кто бы физически ни нажал на клавиши. Поэтому крупные готовые блоки, которые Claude притащил откуда-то целиком, стоит проверять так же, как если бы ты скопировал их сам.
Как проверить лицензию, прежде чем взять код: порядок действий
Сведём всё в короткий чек-лист, по которому проверяешь любой чужой код перед тем, как тащить его к себе. Идёшь сверху вниз.
Найди название лицензии на странице репозитория
Открой репозиторий на GitHub. Название лицензии обычно видно в правой колонке или под списком файлов - например, «MIT License», «Apache-2.0», «GPL-3.0». Если там пусто и файла лицензии нет - это уже красный флаг, к нему вернёшься на последнем шаге.
Открой сам файл лицензии
Найди в списке файлов LICENSE, LICENSE.md или COPYING и открой его. Убедись, что название совпадает с тем, что показано сбоку, и что лицензия относится именно к тому коду, который ты берёшь, а не к отдельной части репозитория.
Определи тип: разрешительная или с копилефтом
MIT, Apache 2.0, BSD - разрешительные, код можно брать в закрытый коммерческий продукт. GPL и AGPL - с копилефтом, они заставят открыть исходники твоего продукта. Само слово в названии лицензии обычно сразу отвечает на вопрос.
Сопоставь со своим случаем
Ответь на три вопроса: продаёшь ли ты продукт, меняешь ли код, хочешь ли держать исходники закрытыми. Для закрытого продукта на продажу подходят MIT, Apache, BSD. GPL и AGPL - только если готов открыть весь свой код.
Нет лицензии - не берёшь
Если файла лицензии нет и в README про разрешение ничего не сказано, код брать нельзя. Напиши автору и попроси разрешение или найди аналог с нормальной лицензией. «Лежит открыто» - это не разрешение.
Эта проверка кажется занудной ровно до первой ситуации, когда продукт вырос, начал приносить деньги, и к нему пришли с вопросом про чужой код внутри. Две минуты на старте дешевле, чем разбирательство потом. А что делать с продуктом дальше, чтобы он не заглох после запуска, я разбираю отдельно - собрал продукт на ИИ, что дальше.
Частые вопросы
Источники
- choosealicense.com - справочный проект GitHub по выбору лицензии
- choosealicense.com - что значит отсутствие лицензии
- GitHub Terms of Service, раздел D (License Grant to Other Users)
- MIT License (opensource.org)
- Apache License 2.0 (apache.org)
- GNU General Public License v3.0 (gnu.org)
- GNU Affero General Public License v3.0 (gnu.org)
- Гражданский кодекс РФ, часть 4, статья 1286.1 «Открытая лицензия»
Полная схема вайб-кодинга за три вечера: ИИ-клон + Второй мозг + Контекст-инжиниринг. Записи эфиров в личном кабинете, доступ 30 дней.
Новые материалы - дайджестом, без спама
Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.
