Forking a repository does not change its license. You inherit the original terms, so keep the license file and copyright notices, mark files you changed where the license asks, and follow any copyleft or notice rules. A repository with no license gives you no right to reuse the code, even if you can fork it on a hosting platform.
Forking on a platform is not a license
GitHub's documentation explains that with no license, default copyright applies and no one may reproduce, distribute or create derivative works. Under GitHub's terms, other users may view and fork a public repository, but that is a platform permission for the site, not a grant to reuse code elsewhere. Making a repository private later does not remove existing forks.
What the common licenses ask of a fork
| License family | Keep notices | Mark changes | Share your changes |
|---|---|---|---|
| MIT style | Yes | No | No |
| Apache 2.0 | Yes, including NOTICE | Yes, prominent notices | No |
| GPL family | Yes | Typically yes | Yes, when you distribute |
| AGPL | Yes | Typically yes | Also for network use in some cases |
For Apache 2.0, section 4 asks for a copy of the license, prominent notices on changed files, retained attribution notices and carried forward NOTICE content. For copyleft licenses the bigger question is what happens when you distribute the fork. See the AGPL network clause.
Checklist before you fork and diverge
- Open the license file and confirm it exists and matches the package metadata.
- Note the license in your inventory with the upstream commit you forked from.
- Keep upstream copyright and license text intact in the fork.
- Add change notices where the license requires them.
- Decide whether the fork will be distributed, run internally, or offered as a service.
- Plan how you will track upstream security fixes, since a fork stops receiving them automatically.
Security angle
A fork is a new dependency that you now maintain. Pull in upstream patches on a schedule, and record the fork's origin so advisories for the original can be matched to your copy.
A common slip is deleting the upstream README or license file during a rename or cleanup. Treat those files as protected. Another is copying a fork into a private repository and forgetting that its terms still travel with the code. Put the upstream license check into the same ticket that creates the fork, and keep a link to the original project so reviewers can find it years later.
Safeguard scans dependencies and builds SBOMs, and a free scan helps you see what a repository contains.
Quick check
Can I fork a repo that has no license?
You can use the platform's fork feature, but you have no stated right to reuse or distribute the code beyond that.
Do I need to rename my fork?
Licenses do not generally require it, but trademarks and some font or brand terms can. Check the project's policy.
Sources
- GitHub Docs, Licensing a repository: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository
- Apache License, Version 2.0: https://www.apache.org/licenses/LICENSE-2.0.txt
Last reviewed: 19 October 2026.
