Open Source
Лицензии: CLA, DCO и совместимость
Ты написал отличный код и хочешь добавить GPL-библиотеку в свой MIT-проект. Можно? Нет - и вот почему это важно понимать до того, как выяснится в суде.
- Google требует ICLA от всех контрибьюторов в Chromium, Android, Go — это даёт право изменить лицензию в будущем
- Linux Kernel застрял на GPL v2 (не v2+) именно потому что нет CLA — нельзя изменить без согласия 15,000+ авторов
- FOSSA обнаружила GPL в зависимостях Netflix production кода — потребовались месяцы аудита и рефакторинга
- Разработчик Oracle vs Google (Android): суд 10 лет решал вопрос fair use Java API — 9B в ставках
CLA vs DCO: зачем и когда
Когда вы отправляете PR в OSS-проект, встаёт юридический вопрос: кто владеет правами на ваш код? Без явного соглашения - сложная ситуация. Два стандарта: **DCO** (простой, git-based) и **CLA** (формальный, юридически сильный).
**Почему Google требует CLA:** Google хочет иметь возможность изменить лицензию проекта (например, с Apache 2.0 на что-то другое) не спрашивая каждого из тысяч контрибьюторов. Без CLA это невозможно - каждый автор сохраняет copyright на свой код.
Linux Kernel использует DCO, а не CLA. Почему это создаёт проблему при желании изменить лицензию с GPL v2?
Совместимость лицензий и «заражение»
Не все лицензии можно комбинировать. **Лицензионная несовместимость** - это когда требования одной лицензии противоречат требованиям другой. Самый частый случай: GPL в MIT-проекте.
**LGPL - компромисс:** GNU Lesser GPL создана специально для библиотек. LGPL-библиотеку можно линковать с проприетарным кодом без заражения - только изменения самой библиотеки должны быть открыты. GNU C Library (glibc) использует LGPL именно поэтому.
Ваш MIT-проект использует Apache 2.0 зависимость. Вы хотите также добавить GPL v2 зависимость. Что произойдёт?
Лицензирование в корпоративном контексте
Работая в компании, вы создаёте код в рабочее время на рабочем железе. По умолчанию во многих юрисдикциях - **этот код принадлежит работодателю**. Контрибьюция в OSS с работы требует явного разрешения.
**FOSSA** - инструмент автоматического license compliance сканирования. Интегрируется в CI, проверяет все зависимости и транзитивные зависимости на соответствие корпоративной политике. Используется в Netflix, Uber, Lyft.
Разработчик написал OSS-библиотеку в личное время дома. Работодатель заявляет права на неё, ссылаясь на IP agreement. В каком случае работодатель ПРАВ?
Ключевые идеи
- DCO (git commit -s) — простая сертификация происхождения, без передачи прав. Linux, CNCF используют DCO
- CLA — юридическое соглашение, даёт maintainer право изменить лицензию. Google, Microsoft требуют CLA
- GPL v2 несовместима с Apache 2.0 — патентная оговорка. GPL v3 + Apache 2.0 совместимы
- LGPL = компромисс: библиотеку можно линковать с проприетарным кодом
- IP agreement при найме: код с работы может принадлежать работодателю — читайте договор
Связанные темы
Лицензии и корпоративный контекст ведут к inner source - применению OSS практик внутри компании.
- Следующий урок: Inner Source — Корпоративная OSS практика требует понимания IP и лицензий
Вопросы для размышления
- Вы хотите принять PR в свой Apache 2.0 проект от разработчика, который работает в Google. Нужен ли CCLA от Google? Что будет если не проверить?
- Ваш стартап использует LGPL библиотеку для работы с PDF. Юрист говорит «динамическое линкование — безопасно, статическое — нет». Что это значит практически для Node.js приложения?