Should every repository include a LICENSE file?

If you want others to understand how your project may be used, a dedicated LICENSE file is the standard approach. Many repository hosting platforms also detect licences automatically when they're stored in the project root.

What's the difference between a license and a copyright notice?

A copyright notice identifies who owns the work. A licence explains what others are allowed to do with that work, such as using, modifying, or distributing it.

Can documentation have a different license from the source code?

Yes. Many projects license documentation, code, and creative assets separately. If different licences apply, explain this clearly in your documentation so readers understand which terms apply to each type of content.

Where should I mention the project license?

The full licence is typically stored in a LICENSE file. It's also common to include a short licence section in the README and, for larger projects, on documentation websites.

Should I modify the text of a standard open-source license?

Standard licences are designed to be used in their published form. If your project requires different legal terms, it's generally better to choose a licence that already matches your needs or obtain legal advice before making changes.

Markdown License Examples

Search documentation

A licence explains how others can use, modify, and distribute your work. While the legal licence itself is usually a standard document, Markdown makes it easy to present licence information clearly in repositories, documentation, and project websites.

The examples below show common ways to document licensing information without replacing the official licence text.

Open Source • Copyright Notices • Attribution • Dual Licensing • Documentation • Copy Ready

Open Editor Download PDF

What Is a Markdown License File?

Most software projects include a LICENSE file in the root of the repository. This file contains the project's licence, while other Markdown documents—such as a README or documentation site—often link to it or summarise its purpose.

A good licence page should help readers answer questions like:

Is this project open source?
Where can I find the full licence?
Does the documentation use the same licence?
Are third-party assets included?
Who owns the copyright?

The examples below focus on organising this information in a clear and maintainable way.

Example 1: Repository License Page

Most repositories include a short licence page that points readers to the official licence file.

# License

This project is distributed under the MIT License.

See the [LICENSE](LICENSE) file in the repository for the complete license text.

Best for

GitHub repositories
Open-source projects
Public code repositories

Why this structure works

Readers immediately know which licence applies and where to find the complete legal text.

Example 2: README License Section

Many projects include a short licence section near the end of the README.

## License

This project is available under the Apache License 2.0.

For the complete terms and conditions, see the LICENSE file included with this repository.

This allows readers to confirm the project's licence without leaving the README.

Example 3: Documentation License Notice

Documentation sometimes uses a different licence from the software itself.

# Documentation License

Unless otherwise noted, all documentation is licensed separately from the project source code.

Refer to the LICENSE file for complete licensing information.

Best for

Documentation websites
Knowledge bases
User guides

Example 4: Copyright Notice

A copyright notice identifies who owns the work.

# Copyright

Copyright © 2026 Example Company.

All rights reserved.

This example is commonly included in documentation, reports, websites, and proprietary projects.

Example 5: Third-Party Attribution

Many projects include external libraries, fonts, icons, or other assets that require attribution.

# Third-Party Software

This project includes third-party components.

## Included Libraries

- Library A
- Library B

Refer to each project's official license for additional information.

Best for

Software projects
Documentation sites
Commercial applications

Example 6: Asset Attribution Page

Creative assets often require acknowledgement even when they're free to use.

# Asset Attribution

## Icons

Provided by the original icon creator.

## Illustrations

Used under the applicable license.

## Fonts

Included according to their respective licensing terms.

Keeping attribution in one location makes it easier to review and update as the project evolves.

Example 7: Internal Project Notice

Internal documentation can still benefit from a clear ownership notice.

# Internal Use Only

This documentation is intended for employees and authorised contractors.

Do not distribute without permission.

Best for

Company wikis
Internal documentation
Private knowledge bases

Example 8: Documentation Copyright Page

Larger documentation projects often dedicate a page to ownership and usage information.

# Documentation Copyright

Copyright © 2026 Example Company.

Documentation may not be reproduced or redistributed without permission unless otherwise stated.

Separating documentation ownership from software licensing helps readers understand which content the notice applies to.

Example 9: Dual Licensing Overview

Some projects are available under more than one licence.

# Licensing

This project offers multiple licensing options.

- Open-source license for community use.
- Commercial license for organisations requiring alternative terms.

See the LICENSE file for complete details.

Why this structure works

A short overview introduces the available options without repeating the legal wording contained in the official licence documents.

Good License Documentation Builds Trust

Licensing information is often one of the first things developers, contributors, and organisations check before using a project.

Clear documentation doesn't replace legal licence text—it helps readers understand where that information lives, what applies to the project, and where to learn more.

Keeping licence information organised and easy to find makes repositories and documentation more professional and easier to maintain.

Document License Information Clearly

Adding a licence to your project is only part of the process. People should also be able to find and understand it without searching through the repository.

A few simple documentation practices can make licensing information much easier to discover.

Keep the LICENSE File in a Standard Location#

For most projects, place the LICENSE file in the root of the repository.

A typical project structure looks like this:

project/

├── LICENSE
├── README.md
├── CONTRIBUTING.md
├── CHANGELOG.md
└── docs/

Using the standard location helps repository hosting platforms recognise the licence automatically and makes it familiar for contributors.

Link to Your License from the README#

Many visitors read the README before exploring the rest of the repository.

Including a short licence section helps them understand the project's licensing without searching for additional files.

For example:

## License

This project is licensed under the MIT License.

For the complete license text, see the [LICENSE](LICENSE) file.

A simple link is usually all that's needed.

Separate Code and Documentation Licensing#

Not every project uses the same licence for every type of content.

For example:

Source code
Documentation
Images
Icons
Logos
Sample datasets

may each have different licensing requirements.

If different licences apply, document them clearly so contributors and users know which terms apply to each resource.

Credit Third-Party Content#

Projects often include software, fonts, icons, images, or documentation created by others.

Instead of mixing attribution throughout the project, keep it organised on a dedicated page or section.

A simple attribution list can include:

Resource name
Original author
Applicable licence
Link to the original project

This makes future updates much easier.

Keep Copyright Information Current#

Review copyright notices whenever ownership or publication years change.

For example:

Copyright © 2024–2026 Example Company.

Keeping this information up to date improves clarity and presents a more actively maintained project.

Be Consistent Across Your Documentation#

Your README, documentation site, repository, and project website should all refer to the same licensing information.

Conflicting licence notices can confuse users and contributors.

If the project licence changes, update every location that references it.

Common Mistakes

Hiding License Information#

Visitors shouldn't have to search through multiple folders to discover how a project is licensed.

Keep the licence in a predictable location and reference it from important documentation pages.

Copying License Text into Multiple Files#

Maintaining multiple copies of the same licence increases the chance of inconsistencies.

Instead, store the official licence in a single LICENSE file and link to it where appropriate.

Forgetting Third-Party Attribution#

Open-source libraries, icons, fonts, and media often require attribution or have their own licence terms.

Documenting these resources helps maintain compliance and transparency.

Mixing Different License Statements#

If your README says one thing while your documentation says another, users won't know which information is correct.

Review licensing information whenever you update the project.

Editing Standard Open-Source Licenses Without Understanding the Impact#

Well-known licences such as MIT, Apache 2.0, or GPL are intended to be used as published.

If you need different terms, seek appropriate legal guidance rather than modifying a standard licence yourself.

Frequently Asked Questions

1
Should every repository include a LICENSE file?
If you want others to understand how your project may be used, a dedicated LICENSE file is the standard approach. Many repository hosting platforms also detect licences automatically when they're stored in the project root.
2
What's the difference between a license and a copyright notice?
A copyright notice identifies who owns the work. A licence explains what others are allowed to do with that work, such as using, modifying, or distributing it.
3
Can documentation have a different license from the source code?
Yes. Many projects license documentation, code, and creative assets separately. If different licences apply, explain this clearly in your documentation so readers understand which terms apply to each type of content.
4
Where should I mention the project license?
The full licence is typically stored in a LICENSE file. It's also common to include a short licence section in the README and, for larger projects, on documentation websites.
5
Should I modify the text of a standard open-source license?
Standard licences are designed to be used in their published form. If your project requires different legal terms, it's generally better to choose a licence that already matches your needs or obtain legal advice before making changes.