Open Source звучит как магия: бери готовый код, собирай продукт, экономь месяцы разработки. Но на практике открытые лицензии — это поле, где легко подорваться, если не знать правил. В этой статье разберёмся, как устроены авторские права, чем отличается GPL от MIT, какие подводные камни ждут в России и странах СНГ, и как стартапу избежать юридического фейспалма.

Почему стартапы любят Open Source

Если у вас есть ограниченный бюджет и сроки поджимают, соблазн использовать чужие библиотеки неизбежен. Вместо того, чтобы писать свой веб-сервер, можно взять Nginx; вместо своего ORM — SQLAlchemy или TypeORM.
Но вот парадокс: чем глубже проект погружается в Open Source, тем выше риски. Один неправильный выбор лицензии — и ваш потенциальный инвестор может от вас шарахнуться, как от кода без тестов.

Авторское право в коде: это реально работает

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

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

# simple_logger.py
import datetime

def log(message: str) -> None:
    print(f"[{datetime.datetime.now()}] {message}")

if __name__ == "__main__":
    log("Hello, Habr!")

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

MIT vs GPL: свобода и вирусность

Наиболее частая путаница у разработчиков в СНГ — это различие между «свободными» MIT-подобными лицензиями и «копилефтными» GPL.

• MIT License — берите код, делайте что хотите, только оставьте копирайт. Для стартапа это часто спасение: легко интегрировать, можно закрыть свой продукт.

• GNU GPL v3 — открытый код заразен. Если вы его используете, вы обязаны открыть и свой проект.

Пример:

• MIT библиотека в вашем мобильном приложении → всё ок.

• GPL библиотека в вашем SaaS-продукте → инвесторы могут начать паниковать: придётся выложить весь код.

Российская специфика: как суды смотрят на код

В России мало прецедентов, связанных с open source, но они есть. Проблема в том, что не все юристы и даже судьи понимают разницу между MIT и GPL. Часто применяется общее авторское право, а не логика лицензий.

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

• Apache 2.0 — лицензия с патентными оговорками, часто выбирается крупными компаниями.

• BSD 3-Clause — простая и гибкая альтернатива MIT.

Казус без лицензии

Ситуация: стартап взял библиотеку без лицензии. Код работает, продукт растёт. Через два года появляется автор и требует убрать его код или выплатить компенсацию.
Юридически — он прав. Без лицензии вы ничего не могли использовать.

Поэтому правило №1: никогда не используйте код без лицензии, даже если он лежит на GitHub и выглядит «общедоступным».

Примеры с GitHub Actions

Представим, вы пишете свой CI/CD пайплайн и используете чужие GitHub Actions. Они тоже под лицензией.

name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install deps
        run: pip install -r requirements.txt
      - name: Run tests
        run: pytest

Даже actions/checkout имеет лицензию (MIT). Это значит, что вы можете использовать его без проблем, но обязаны оставить упоминание об авторстве.

Как стартапу минимизировать риски

1. Завести внутреннюю базу зависимостей с лицензиями.

2. Использовать SPDX-идентификаторы (MIT, GPL-3.0-only и т.д.) в документации.

3. Добавить шаг в CI: проверка лицензий зависимостей (например, через license-checker в Node.js).

4. Для ключевых библиотек — написать юристу, даже если кажется, что всё просто.

Будущее: что делать с российскими законами

Пока что в России нет отдельного закона «Об Open Source». Всё держится на международных нормах и практике. Но если появятся местные инициативы, они могут внести хаос.

Поэтому стартапам лучше играть по международным правилам:

• MIT — безопасно для коммерческих продуктов.

• Apache 2.0 — если нужен патентный щит.

• LGPL — для библиотек, которые подключаются динамически.

• GPL — только если вы точно понимаете последствия.

Немного личного опыта

Я однажды участвовал в стартапе, где мы по наивности подключили GPL-библиотеку для обработки PDF. Через пару месяцев инвестор (внимательный дядя с юристами) задал вопрос: «А что это у вас GPL делает внутри продукта?».
В итоге пришлось переписывать модуль заново на MIT-аналогах. Затянуло релиз на месяц и обошлось дорого. Так что на грабли лучше наступать на чужие, а не свои.

Выводы

Open Source — не бесплатный шведский стол. Это скорее общий гараж, где у каждого инструмента есть владелец и правила пользования. Игнорировать их можно, но последствия будут неприятными.
Если вы стартапер в России или СНГ — начинайте думать о лицензиях с первой строки кода. Это скучно, но дешевле, чем потом объяснять инвестору, почему ваш бизнес принадлежит сообществу GPL.