How Should a Project Document Its License?
From the earlier reference collection. Read the current software blog.
License documentation should identify code and data terms separately, point to the complete legal text, and explain which files each notice covers.
Separate the things being licensed
A project may contain source code, sample data, documentation, images, and generated output. These materials do not automatically share one license. State the license for each category and identify exceptions. For example, a repository might say its application code is under one license while a sample dataset is supplied under different terms. A top-level badge alone cannot communicate that distinction.
Make the scope concrete. Tell readers whether a notice applies to the whole repository, a named directory, or specific files. If the project bundles third-party components, list their licenses or point to a maintained notices file. Do not imply that a dependency’s license is the project’s license, or that data can be reused because the program that reads it is openly licensed.
Link to authoritative terms
Include the full license text in the repository when that is the project’s practice, and link to it from the README or documentation. Use the license’s name and version where applicable, and preserve required notices in distributed copies. If data comes from an external provider, link to the provider’s terms and describe any additional conditions your project has established. Public accessibility is not the same thing as permission to redistribute or adapt.
Avoid substituting an informal summary for the legal terms. A short plain-language explanation can orient readers, but it should not claim to replace the license. When a file has no clear license, say that its reuse status is unspecified and identify who can clarify it, if known. Do not assign a license to third-party work simply to make the repository appear complete.
Make reuse decisions traceable
Help readers determine what they may do by mapping the notices to the material. A small table can list “application code,” “example records,” and “screenshots,” each with a license link or a statement that terms are not established. Record attribution requirements, share-alike conditions, or restrictions that matter to ordinary use, but refer readers to the full text for the binding details.
Consider someone who wants to copy a code example and someone else who wants to republish a downloaded dataset. They need separate answers. Explain whether examples follow the code license and whether data files are excluded. Keep notices beside the relevant files when a repository contains mixed materials, and update the documentation when dependencies or source data change. A clear license page reduces guesswork, helps downstream projects preserve notices, and makes uncertainty visible instead of letting readers infer permission from a download button.