OSS Attribution

If you ship JavaScript or Python to end users, you have an obligation to surface the licenses of the open-source code you depend on. Attestly generates that file for you.

What gets included

• A summary paragraph noting the dominant license profile and any risks.
• A license breakdown table — count per SPDX id with each entry tiered as permissive, weak copyleft, strong copyleft, network copyleft, or proprietary/unknown.
• A packages requiring legal review section — every weak/strong/network copyleft and unknown-license dependency, with plain-English context for what the obligation means for a closed-source SaaS.
• A full inventory of every package in every supported lockfile (npm, pnpm, yarn, pip, poetry, go, cargo).
• Each package's SPDX license identifier, source URL, and NOTICE file when present.
• A SHA-256 of the rendered output, for reproducibility.

License-policy enforcement

You can set a license allowlist under Settings → OSS Policy. Common configurations:

Policy	Allowed
Permissive only	MIT, Apache-2.0, BSD-2/3, ISC, 0BSD, Unlicense
Permissive + LGPL	Permissive + LGPL-2.1, LGPL-3.0
Custom	Any list you define

When the scanner finds a package outside the allowlist, the dashboard surfaces a warning and the drift bot blocks the next PR until either the package is removed or the policy is updated.

Output formats

The OSS Attribution document is available in three formats from your trust center:

• Markdown — for embedding in your app or docs.
• HTML — pre-styled, ready to drop into a Settings → About screen.
• JSON — machine-readable, for SBOM tools.

Edge cases

• Dual-licensed packages — we display the license you've selected in your policy, falling back to the most permissive if no policy match exists.
• Packages with no license — surfaced as a hard error. This is genuinely dangerous; we don't paper over it.
• Vendored code — if you've copied source from another project into your own repo, our scanner can't see the license. Add a .attestly/vendor.toml declaring it.