Free Online Software License Notice Generator
Generate third-party license attribution notices.
Project and dependencies
This produces an attribution template, not a license grant or legal clearance. Keep the complete license text for every dependency in your distribution and verify the declared licenses yourself.
About the Software License Notice Generator
Most open-source licenses require you to preserve attribution when you redistribute code. A NOTICE or third-party attribution file collects those acknowledgements in one place, which makes it easier to satisfy notice requirements and easier for recipients to see what is included. This generator takes a project name, version, and a list of dependencies with their versions, licenses, and source URLs. It then formats a clean notice that you can commit to a repository, ship beside a binary, or include in an installer or documentation bundle.
The output is deliberately plain text. Plain text is portable, diffs well in version control, and can be read
without tools. Dependencies are listed alphabetically and summarised by license so a reviewer can quickly see
whether a copyleft component has appeared. Empty rows are ignored, duplicate names are kept because two
packages can share a name, and a missing URL is shown as a placeholder rather than silently dropped. The
notice updates as you type, and you can copy it or download it as NOTICE.txt.
What a good notice includes
- Project identification: the product name and version the notice belongs to.
- Component list: each dependency name, version, and the license it is distributed under.
- Source location: a repository or homepage URL so recipients can find the original code.
- License summary: a count by license, which helps spot copyleft or unknown licenses.
- Full texts: the complete license text for each component, usually kept in a separate LICENSES directory.
Where notices go wrong
The most common mistake is treating a generated list as a substitute for the license text. Attribution does not replace the full grant, and some licenses also require a NOTICE file, a copy of the license, or a description of modifications. A second mistake is using an inaccurate license label from a package manager without checking the actual package. Metadata can be wrong, dual-licensed packages can offer a choice, and a bundled dependency can carry a different license from its wrapper. A third mistake is failing to update the notice when dependencies change. Generate it as part of the release process, not once at the start of the project.
This tool does not scan a lockfile, resolve transitive dependencies, download license texts, or decide whether a license is compatible with your project. It formats the information you provide. For a real release, combine it with a software composition analysis step, keep the full license texts, and have a qualified reviewer check anything unusual. The result is an informational template, not legal advice.
Frequently asked questions
Does this replace the actual license files?
No. Keep the complete text of every license with your distribution. The notice is an attribution index, and several licenses require both the notice and the full license text.
Should transitive dependencies be listed?
Usually yes. If a bundled library includes another library, the end distribution may need to acknowledge both. Generate the list from your lockfile and check bundled or vendored code separately.
What if I do not know a dependency's license?
Do not guess. Mark it as unknown, inspect the package metadata and repository, and resolve it before release. An unknown license is a distribution risk, not a formatting problem.