Your GitHub PR Can Land You in Legal Trouble: The Contributor License Agreement Nobody Reads (But Everyone Needs)
You just submitted a clean PR. Tests pass, code reviews are green, and the maintainer is about to merge. Then—*”Please sign our CLA before we can proceed.”*
You click the link. Scan it. Sign it. Move on.
Stop Reviewing Code Like It’s 2019: Why Your Team Needs AI Code Review Automation Tools Now
TL;DR: Manual code review is slow, inconsistent, and expensive. Modern AI code review automation tools catch bugs 40%… ...
Honestly, I did the exact same thing for years. Until one afternoon in Ho Chi Minh City, sitting with a legal advisor from one of our client’s enterprise teams, I realized how risky that behavior actually is.
Most developers sign CLAs without understanding what they’re agreeing to. I’m including myself in that statement.
From Monolith to Event Stream: How We Helped a Fintech Startup Migrate 200 APIs in 8 Weeks with a Vietnamese AI-Augmented Team
From Monolith to Event Stream: How We Helped a Fintech Startup Migrate 200 APIs in 8 Weeks with… ...
Let’s fix that.
The Real Problem: Your Code Isn’t Actually Yours After You Press “Merge”
Here’s the uncomfortable truth most open source contributors don’t want to hear:
When you contribute to a project under a Contributor License Agreement (CLA), you’re either:
- Giving the project a perpetual license to use your code (Apache-style ICLA)
- Assigning copyright to the project entirely (Fiduciary License Agreement)
Most people think they’re doing option A. But plenty of projects use option B.
I maintain a moderately popular library (around 2,800 stars on GitHub), and when I added a CLA requirement last year, three contributors pushed back. Hard. One of them was a contractor working for a Fortune 500 company. His employer’s legal team flagged it immediately.
He couldn’t assign copyright to my project. Company policy.
The Two Main Approaches (And Why It Matters Which One You Pick)
There are two standards for handling contributor rights on GitHub. You need to understand both.
1. The Apache CLA (Individual Contributor License Agreement)
This is the lightest touch. You grant the project a perpetual, irrevocable license to use your contribution. You keep copyright. You can still use your code elsewhere.
When to use it: Most open source projects. It’s what Apache Software Foundation uses.
2. The DCO (Developer Certificate of Origin)
This is simpler. No lengthy document to sign. You just add a `Signed-off-by` line to your commit message.
It was pioneered by the Linux Kernel project. Linus Torvalds trusts it. That’s a solid endorsement.
Here’s what the sign-off looks like in practice:
bash
git commit -s -m "Fix race condition in connection pool
The existing implementation didn't handle concurrent access properly
when multiple goroutines tried to acquire connections simultaneously.
Signed-off-by: Nguyen Minh Anh " The `-s` flag adds that signature automatically. The message certifies you wrote the code or have permission to submit it.
When to use it: Projects that want to avoid CLA bureaucracy. It’s the default for many CNCF projects now.
3. The Fiduciary License Agreement (What Big Corp Actually Wants)
This is the heavy one. You transfer copyright to the project maintainer entirely.
When to use it: Almost never for community projects. Some foundations require it.
What I Learned from Reviewing 200+ Open Source CLAs for Our Remote Team
At ECOA AI, our developers in Vietnam contribute to open source projects regularly. It’s part of our training pipeline. But I discovered something alarming:
Most of our junior engineers didn’t know they couldn’t assign copyright without approval.
Our clients in the US and Europe often have strict IP policies. If one of our developers signs a CLA that transfers copyright, they’re technically violating their contract with the client.
We had to implement a simple policy: *No developer signs a CLA without ticket approval from their lead engineer.*
It’s saved us from at least two legal headaches in the past six months.
The Growing Trend: Why Projects Are Moving to DCO
Here’s what I’m seeing across the GitHub ecosystem in 2025:
More projects are migrating from Apache-style CLAs to DCOs.
Why?
Softer wall for contributors. A DCO requires one line in a commit message. A CLA requires signing up for a service, clicking through a document, and waiting for verification. That friction kills contributions.
Lower legal overhead. You don’t need a lawyer to draft a DCO. The template is right there on the Linux Foundation’s website.
Same legal protection. The DCO is a legally recognized certificate of origin. It provides the same protections for the project.
But—and this is important—DCOs don’t help if you need to enforce patent grants or relicense the project. That’s where a full CLA still wins.
How to Set Up Contribution Agreements on GitHub (Without Driving Contributors Away)
If you’re a maintainer reading this, here’s my practical advice after running a 5K-star project:
- Start with a DCO. Use `Probot: DCO` or integrate it with your CI. It’s a single check that verifies the sign-off exists.
- If you need a CLA, make it frictionless. Use CLA Assistant (the GitHub app) or EasyCLA. The approval should take under two minutes.
- Explicitly state your stance in CONTRIBUTING.md. Don’t bury it. I put it right at the top:
## Legal Stuff
By submitting a PR, you agree to the terms of our DCO.
Every commit must include a Signed-off-by line.
See our full policy in LICENSE-dco.md.- Know your endgame. Do you want to relicense later? Sell commercial licenses? Then you need a more formal agreement. If you’re just building a community tool, stick with the DCO.
The Corporate Reality: What Your Employer Actually Allows
Let’s get real for a moment.
If you work at a company with serious IP protections, you probably can’t assign copyright to an open source project without running it through legal.
I’ve seen this trap catch developers repeatedly. They contribute code, sign a CLA, and suddenly their employer’s legal team is in a tussle with the open source foundation.
The fix: Check your employment agreement. Most companies have a clause about open source contributions. Some require you to get pre-approval. Others block you entirely.
Actually, one of our clients (a SaaS company in Austin) has a policy that all external contributions go through a weekly review board. It sounds bureaucratic, but it’s saved them from accidental IP leakage twice.
What This Means for Vietnamese Developers and Offshore Teams
Look, I’m biased. I run a company that places Vietnamese engineers with international clients. But here’s the reality I’ve seen firsthand:
Vietnamese developers often work on multiple projects simultaneously. They might be contributing to open source for one client and building a proprietary product for another.
That’s a recipe for legal disaster if they sign the wrong CLA.
Our solution
Related reading: Outsourcing Software in 2025: The Strategic Playbook for CTOs and Founders
Related reading: Hire Vietnamese Developers: The Strategic Advantage for Modern Tech Teams
