When your code package includes someone else's code or assets, identify them in
THIRD_PARTY_NOTICES.md and include the license texts and notices their terms require. This guide
takes you from an inventory of what you ship to a notices file you can check against the final
package. Each component's license sets the exact obligations.
Start with the source, dependency manifests and lockfiles, built files, and assets for the release you intend to sell. Keep the original downloads or source links so you can recover each component's license and notices.
The Kurodyne Commercial License covers seller-owned material. Third-party components keep their own terms, including any additional rights those terms give buyers. You don't need to bundle a Kurodyne license file, and your notices can't add restrictions to the license buyers accept at checkout.
Work through the files buyers receive, including:
- Dependencies you include directly and the dependencies they bring with them
- Code copied into your source tree, such as utilities, components, snippets, and starter files
- Code incorporated into bundles, compiled programs, plugins, or generated files
- Fonts, icons, images, audio, sample data, and documentation from other creators
Use your package manager's dependency tree or a license inventory tool as a starting list, then compare it with the package. A tool that reads package metadata can miss copied code and assets. Check what your agent added too; its description of a dependency's license isn't the license.
A development dependency may contribute code or assets to your output. Check the output before excluding it from the inventory. Conversely, a tool used only to build your code doesn't belong in the list of bundled components just because it appears in your development environment.
Record software buyers install separately as requirements, and distinguish it from material inside the package. Check its terms for the use you promise. Leaving a dependency out of the package doesn't by itself resolve licensing requirements for a combined program.
Read the license from the exact version or revision you use. Check its LICENSE, COPYING,
NOTICE, asset-specific terms, and file headers. A repository's current license can differ from
the release in your package, and individual files can have separate terms.
For every component, establish that you may distribute it in this product and that buyers may use it as your listing promises. If there are multiple license options, record the option you use and any exception or separate permission that matters.
Record the matching identifier from the SPDX License List(opens in a new tab), such as MIT, BSD-3-Clause, or Apache-2.0. If the terms have no SPDX identifier, record their exact name and keep the text or permission you rely on. Don't substitute a similar license.
Use the permissive-license requirements to identify the notices and license copies required for those components, and the font and asset license requirements for CC-BY-4.0 and OFL-1.1 material. Record the required files and notices in your inventory.
If a component's terms are missing or don't allow the uses you promise, obtain the permission you need or remove and replace the component before packaging it. Which dependencies and files should I check? covers code without a license and licenses that prohibit commercial use.
A notices file can't satisfy a requirement to provide source code, offer relinking, preserve redistribution rights, or obtain permission for commercial use. Check the exact license and how your code uses the component before packaging it.
For copyleft components, use the copyleft requirements and Commercial License compatibility explanation to check the arrangement. Include services buyers will host as well as files you distribute. Record how you will fulfill any source, relinking, or other delivery requirement.
For fonts, images, and other assets, check the asset license requirements, including permission to redistribute editable files. If the terms don't fit the uses you promise, resolve the conflict before submitting the product.
Put THIRD_PARTY_NOTICES.md at the top level of the ZIP file. For each component, record its name,
version or revision, source, included paths, license, copyright holders, modifications, and buyer
obligations. If an asset has no version, use its original filename and a source reference that
identifies the copy you used.
Include required texts in the notices file or in clearly linked files inside the package, as the
component's terms allow. Preserve required notices in source files too. Use a directory such as
licenses/<component-name>/ to keep upstream files together. Copy the actual upstream texts;
replacing their copyright holders with your name or linking only to a website loses required
information.
This example describes a fictional product called Filter Panel. It assumes the seller includes an
unchanged copy of the
clsx 2.1.1 source(opens in a new tab)
as vendor/clsx.mjs. Copy the complete
clsx 2.1.1 license file(opens in a new tab)
into licenses/clsx-2.1.1/LICENSE.txt. That file contains the original copyright notice, permission
text, and disclaimer.
The example paths describe the fictional package; this article doesn't supply its product code.
Adapt the entry to your verified files and repeat it for every included component. Save the
following text as THIRD_PARTY_NOTICES.md:
The example relies on the accompanying license file. The short entry isn't a substitute for it.
If another component supplies a NOTICE file or needs a modification notice in its source, include
those too. State where buyers can find any required source code or source offer and fulfill the
applicable license's delivery requirements.
In the Product Editor's Public requirements, disclose material third-party obligations, such as attribution, source availability, separate licenses, or required paid accounts. Explain which component they affect and what the buyer must do. Keep those statements consistent with your README, notices, and promised commercial uses.
Link the notices file from your README using its path within the package. The README template includes a section for this. The top-level README is public before purchase, so keep purchase-only access details in the release's Private usage instructions or the Key value field.
For a product with no package, identify the third-party components and obligations in the listing. Supply any required texts through the delivered material or private usage instructions in a way the component's license permits. A listing summary doesn't replace a license's required delivery.
Build the package, then check the copy buyers will receive:
- Extract the final ZIP file into a new folder. Open
THIRD_PARTY_NOTICES.mdand every local file it links. Check that the license and notice files are present and readable without network access. - Compare the contents with your inventory. Include copied snippets, assets, dependencies inside bundles, and any additional versions of a component. Remove entries only when their material is no longer included or required.
- Check original notices, required modification statements, and any attribution that must appear in the running product. Inspect built and minified files as well as readable source.
- Confirm that required source, source access, or other obligations are fulfilled. A readable source file alone may not be all the corresponding source a license requires.
- Match the public requirements and README to the package. Remove unfilled placeholders and make sure each entry identifies the release you actually include.
- Upload the package in the Product Editor's Files section. The Package checklist reports the license and notice files it finds; finding a file doesn't establish license compliance.
If a license file is missing after packaging, add it to the package input and rebuild the ZIP file. If a build removes required notices, configure the build to retain them or include them in another location the license allows. If you can't identify a component's source or permission, resolve that before submitting the release.
Repeat the check when dependencies, assets, build output, or component licenses change. Keep each release's notices with that release, and follow Updating a Product You Sell when preparing an update.
Follow
the packaging steps in Publish Your First Product
to create your ZIP file. Keep README.md and THIRD_PARTY_NOTICES.md at the ZIP file's top level.
Continue with Publish Your First Product to complete the listing
and submit it for review, or start selling on Kurodyne to set up your store.