LICENSE: project license

When you publish code on GitHub without a LICENSE file it remains legally "all rights reserved" for the author. Anyone can view the code in a browser and fork it within GitHub (GitHub Terms of Service permit this as a condition of using the platform), but without an explicit license the user has no right to:

• copy it to their machine for use in their own project,
• modify and distribute it,
• embed it in their product.

This contradicts the intuition that "published on GitHub means open source." Code becomes open source when a license explicitly grants those permissions.

Every public project should have a LICENSE file in the root. Without one, the code is legally useless to anyone else.

Common licenses

MIT

The shortest and most permissive license. You can do almost anything: use it in commercial products, modify it, close your fork. The only requirement is to preserve the copyright notice.

MIT License

Copyright (c) 2026 Your Name

Permission is hereby granted, free of charge, to any person obtaining

a copy of this software ...

Choose MIT when:

• Your goal is maximum distribution.
• You do not mind someone closing your code in a proprietary product.
• Simplicity matters more than legal nuance.

Apache-2.0

Similar to MIT but longer, with two important additions:

• Patent grant: explicitly licenses any patents related to the code to users.
• NOTICE file: lets the author specify additional information that forks must preserve.

Choose Apache-2.0 when:

• The project may carry patent risk.
• Your target users are companies (legal teams tend to prefer Apache-2.0 over MIT because of the explicit patent grant).

GPL (v2, v3)

Copyleft: derivative works must also be under GPL. If you use GPL code in your product, your product becomes GPL too. This is a "viral" license, and that is by design.

Choose GPL when:

• Your goal is to guarantee that the code stays open in all forks.
• You are comfortable with commercial companies being unable to use it without disclosing their own code.

The Linux kernel is GPL v2. Most GNU tools are GPL v3.

LGPL (Lesser GPL)

GPL for libraries: you can link the library into a proprietary product without the "viral" effect (when linked dynamically). Modifications to the library itself must be kept open.

AGPL (Affero GPL)

GPL with a service-side clause: even a SaaS that uses AGPL code must disclose modifications to users of the service, not only to those who download the binary. This closes the "web service loophole."

BSD (2-clause, 3-clause)

Permissive, very similar to MIT. The difference is in the details: 3-clause prohibits using the author's name to endorse derivative products. In practice, BSD and MIT are interchangeable.

How to choose

• Maximum distribution, do not care if someone closes the code → MIT.
• Same, plus patent risk, plus corporate-friendly → Apache-2.0.
• Want everything to stay open → GPL.
• It is a web service, not a library → AGPL.
• Not sure and do not want to research it → MIT (the default on GitHub).

The site https://choosealicense.com (by GitHub) walks you through a decision tree. Use it when you are uncertain.

Technical details

• LICENSE file in the root. GitHub detects the license automatically when the file is named LICENSE or LICENSE.md (without prefixes such as MY-LICENSE).
• Year and author. The MIT template requires a year and author name (Copyright (c) 2026 Your Name).
• Header in source files. Some licenses (Apache-2.0) call for a short header in each source file. It is not strictly required, but it is the convention.
• Changing a license retroactively is hard. If the repository has had contributors, their work legally remains under the original license; changing it requires consent from each of them. Choose carefully, because the decision is long-term.

Pitfalls

• "No license" is legally all rights reserved. Do not say "I have no license, it's open source."
• License compatibility matters. A GPL project cannot directly use Apache-2.0 code (there are nuances depending on the GPL version). BSD is compatible with MIT and Apache-2.0. Think about this when you add third-party code to your project.
  • A binary shipped without a LICENSE file is technically a violation of some licenses. Distribution generally implies delivering the LICENSE file alongside the binary.