Open Source
Licenses: CLA, DCO and Compatibility
You've written great code and want to add a GPL library to your MIT project. Can you? No - and here's why you need to understand this before finding out in court.
- Google requires an ICLA from all Chromium, Android, and Go contributors - this gives them the right to relicense in the future
- The Linux Kernel is stuck on GPL v2 (not v2+) precisely because there's no CLA - changing it requires consent from 15,000+ authors
- FOSSA discovered GPL code in Netflix production dependencies - months of auditing and refactoring followed
- Oracle vs Google (Android): courts spent 10 years deciding fair use of the Java API - $9B at stake
CLA vs DCO: why and when
When you send a PR to an OSS project, a legal question arises: who owns the rights to your code? Without an explicit agreement - it gets complicated. Two standards: **DCO** (simple, git-based) and **CLA** (formal, legally stronger).
**Why Google requires a CLA:** Google wants the ability to change the project's license (e.g., from Apache 2.0 to something else) without asking every single one of thousands of contributors. Without a CLA this is impossible - each author retains copyright over their own code.
The Linux Kernel uses DCO, not CLA. Why does this create a problem when wanting to change the license from GPL v2?
License compatibility and copyleft "infection"
Not all licenses can be combined. **License incompatibility** happens when the requirements of one license contradict another. The most common case: GPL inside a MIT project.
**LGPL - the compromise:** GNU Lesser GPL was created specifically for libraries. An LGPL library can be linked with proprietary code without infection - only changes to the library itself need to stay open. The GNU C Library (glibc) uses LGPL for exactly this reason.
Your MIT project uses an Apache 2.0 dependency. You want to also add a GPL v2 dependency. What happens?
Licensing in a corporate context
When you work at a company, you write code on company time using company equipment. By default in many jurisdictions - **that code belongs to the employer**. Contributing to OSS from work requires explicit permission.
**FOSSA** is an automated license compliance scanning tool. It integrates into CI, checks all dependencies and transitive dependencies against a corporate policy. Used at Netflix, Uber, and Lyft.
A developer wrote an OSS library in their personal time at home. The employer claims ownership, citing the IP agreement. In which case is the employer CORRECT?
Key takeaways
- DCO (git commit -s) - simple origin certification, no rights transfer. Linux and CNCF use DCO
- CLA - legal agreement giving the maintainer the right to relicense. Google and Microsoft require CLAs
- GPL v2 is incompatible with Apache 2.0 - patent clause conflict. GPL v3 + Apache 2.0 are compatible
- LGPL = the compromise: a library can be linked with proprietary code
- IP agreement on hire: code from work may belong to the employer - read your contract
Related topics
Licenses and corporate context lead naturally to inner source - applying OSS practices inside a company.
- Next lesson: Inner Source — Corporate OSS practice requires understanding IP and licenses
Вопросы для размышления
- You want to accept a PR into your Apache 2.0 project from a developer who works at Google. Do you need a CCLA from Google? What happens if you don't check?
- Your startup uses an LGPL library for PDF processing. Your lawyer says 'dynamic linking is safe, static linking is not.' What does that mean practically for a Node.js application?