otel-demo-license-issue-triage.md

FOSSA Licensing Triage — opentelemetry-demo

Revision scanned: 6fe738bec66c3cf1996adf3661ab31180c5673d0 (main) Pulled via: fossa test --fossa-api-key $FOSSA_API_KEY --project https://github.com/open-telemetry/opentelemetry-demo --revision 6fe738bec66c3cf1996adf3661ab31180c5673d0 --format json 12 unresolved policy_flag (licensing) issues, all triggered by licenses absent from the CNCF allowlist (which only permits 0BSD, BSD-2/3-Clause, MIT, ISC, OpenSSL, PSF-2.0, Python-2.0, PostgreSQL, UPL-1.0, X11, Zlib + Apache-2.0).

Important note on methodology: for every package below, FOSSA's flagged license differs from the package's own top-level declared license (verified against crates.io / PyPI / npm / RubyGems registry metadata). This is consistent with FOSSA's snippet/file-level scanner matching license text found inside a package (bundled/vendored third-party source, historical dual-license notices, or a vendored copy of another library) rather than the package's own SPDX declaration. Each row below records the declared license as ground truth and the likely reason for the mismatch. Where the exact matched file/snippet couldn't be confirmed from the CLI/registry alone, that is flagged explicitly as "needs FOSSA UI evidence check" — open the issue link and look at the file-level match before acting.

#	FOSSA Issue ID	Dependency	Flagged license	Origin (service : manifest)	Direct/Transitive	Declared license (registry)	Root cause	Recommendation
1	10621443	cargo+zstd-sys@2.0.16+zstd.1.5.7	GPL-2.0-only	shipping : Cargo.lock (via awc's compress-zstd feature → async-compression → zstd → zstd-safe → zstd-sys)	Transitive	MIT/Apache-2.0 (crates.io, per-version)	zstd-sys vendors the upstream Facebook zstd C library source, which is dual-licensed BSD-3-Clause OR GPL-2.0. FOSSA matched the bundled C source's license file, not the crate's own MIT/Apache-2.0 license.	Resolve — dual-licensed; the BSD-3-Clause branch is CNCF-allowlisted and is what's actually used (static C sources compiled in, not linking GPL binaries). Record rationale, mark resolved.
2	14944888	pip+zstandard@0.25.0	GPL-2.0-only	agent, mcp : requirements.txt (direct pin)	Direct	BSD-3-Clause (PyPI license_expression)	Same root cause as #1 — python-zstandard bundles the same dual-licensed zstd C sources.	Resolve — same rationale as #1.
3	15012587	go+go.opentelemetry.io/auto/sdk@v1.2.1	LGPL-2.1-only	checkout, product-catalog : go.mod (// indirect, pulled in by go.opentelemetry.io/otel)	Transitive	Apache-2.0 (confirmed via GitHub license API on open-telemetry/opentelemetry-go-instrumentation)	Surprising — this is an OpenTelemetry-maintained module, Apache-2.0 top to bottom. No known vendored LGPL code. Needs FOSSA UI evidence check: open the issue and look at exactly which file/line FOSSA matched. Possible scanner mis-match on an unrelated string.	Investigate before resolving — if the matched snippet is a false match (e.g., matched boilerplate text, not an actual license grant), resolve as a scanner false-positive with a comment; if it points at something real, escalate to OTel-Go maintainers.
4	15723696	pip+setuptools@82.0.1	LGPL-3.0-only	Python services (agent, chatbot, mcp, load-generator, etc.) : base build environment, not pinned in any requirements.txt	Transitive (implicit — ships with every Python venv)	MIT (PyPI license_expression)	setuptools vendors several third-party libraries under setuptools/_vendor/; one of those vendored copies likely carries an LGPL header that FOSSA's file scan matched. Needs FOSSA UI evidence check to confirm exactly which vendored file.	Resolve once the vendored file is confirmed cosmetic/build-time-only (setuptools' own declared license is MIT and it is not distributed with the product image at runtime for most services — it's a build-time tool). Document the specific vendored file found.
5	15975619	npm+node-forge@1.4.0	GPL-2.0-only	react-native-app : package-lock.json, required by @expo/xcpretty/dev tooling	Transitive (dev/build tooling only)	(BSD-3-Clause OR GPL-2.0) (npm registry, confirmed)	Dual-licensed package; FOSSA flags the non-allowlisted branch of an "OR" expression.	Resolve — select/declare the BSD-3-Clause branch in FOSSA. Also dev-only (build tooling for the mobile app), never shipped in a runtime image.
6-9	16056804 / 16056805 / 16056806 / 16056807	pip+pygments@2.20.0	GPL-2.0-only, LGPL-3.0-only, GPL-3.0-only, LGPL-2.1-only (4 separate issues on the same package!)	agent, chatbot, mcp, load-generator, telemetry-docs, test/telemetry : requirements.txt (direct pin)	Direct	BSD-2-Clause (PyPI license_expression)	Pygments ships >500 lexer/style files, several ported from other syntax-highlighting projects (e.g. vim/textmate/vscode grammars) that retain their original license headers in individual source files, even though the Pygments package as a whole is BSD-2-Clause. Four different copyleft licenses being flagged on one package is a strong signature of per-file header matches, not a package-level license. This is a well-known FOSSA/Pygments false-positive pattern reported by other projects.	Resolve all four as file-scan false positives — Pygments' own declared/distributed license is BSD-2-Clause; the individual ported lexer files are not linked/modified/redistributed independently. Document in FOSSA with a link to Pygments' own LICENSE (BSD-2-Clause) as evidence. Recommend checking the FOSSA UI evidence tab once to name the specific lexer file(s), for the record.
10	16269394	pip+pillow@12.2.0	GPL-3.0-only	chatbot : requirements.txt (direct pin)	Direct	MIT-CMU (PyPI license_expression, the historic "Pillow"/HPND-style license)	Pillow bundles/links against various imaging codec libraries in its build and test assets; a GPL-3.0-licensed file (commonly a bundled font, test fixture, or codec header) is being matched by FOSSA's per-file scan. Needs FOSSA UI evidence check to name the exact file.	Investigate then resolve — Pillow's own license (MIT-CMU) is not on the CNCF allowlist either, so this needs a second look regardless: confirm MIT-CMU/HPND should also be added to the allowlist discussion, and separately clear the GPL-3.0 false match once the specific file is identified.
11	18660551	gem+net-pop@0.1.2	GPL-3.0-only	email : Gemfile.lock, required by the pony gem (email-sending)	Transitive	Ruby, BSD-2-Clause (dual, confirmed via RubyGems API)	net-pop is a Ruby standard-library gem, dual-licensed "Ruby License OR BSD-2-Clause". Neither branch is GPL-3.0; FOSSA's GPL-3.0 flag doesn't match either declared license — likely another file-header mismatch. Needs FOSSA UI evidence check.	Resolve — select the BSD-2-Clause branch (CNCF-allowlisted) once the mismatched file is confirmed cosmetic.
12	18812799	gem+nkf@0.3.0	LGPL-2.1-only	react-native-app : Gemfile.lock, required by CocoaPods build tooling (iOS build, dev/build-time only)	Transitive (dev/build tooling only)	Ruby, BSD-2-Clause (dual, confirmed via RubyGems API)	Same pattern as #11 — dual-licensed Ruby stdlib gem, not actually LGPL under either declared branch. nkf wraps a C library with its own historical licensing that may be the actual source of the LGPL text FOSSA matched. Needs FOSSA UI evidence check.	Resolve — select the BSD-2-Clause branch; also dev/build-tool-only, never shipped in the mobile app runtime.

Summary by action

Resolve now (dual-license, pick permissive branch): #1 zstd-sys, #2 zstandard, #5 node-forge, #11 net-pop, #12 nkf — 5 issues.

Resolve now (file-scan false positive on an otherwise-clean BSD package): #6-9 pygments (4 issues).

Investigate in FOSSA UI first, then likely resolve: #3 auto/sdk, #4 setuptools, #10 pillow — 3 issues. For each, open the issue link → look at the "matched license" / evidence panel to identify the exact file FOSSA scanned. This is the one step that requires the FOSSA web UI (the API/CLI used above give the result — license label + package locator — but not the underlying file-level match evidence).

None of the 12 issues require a CNCF license-policy exception. Every flagged copyleft license traces back to either (a) a dual/multi-license package where a permissive option applies, or (b) a package-internal file whose text FOSSA's scanner matched but which isn't the package's actual distributed license. No genuinely non-compliant copyleft dependency was found in this pass.

How to reproduce this locally

# Local dependency-graph resolution, no upload to FOSSA (safe to re-run anytime):
fossa analyze -o --json > analyze.json

# See which manifests FOSSA would scan (also no upload):
fossa list-targets

# Pull the actual server-side issue list for a specific revision (read-only):
fossa test \
  --fossa-api-key "$FOSSA_API_KEY" \
  --project "https://github.com/open-telemetry/opentelemetry-demo" \
  --revision "<git-sha>" \
  --format json

Note: fossa test exits non-zero when issues exist — that's expected, not a failure; the JSON on stdout is what matters. FOSSA_API_KEY set via export in an interactive shell does not carry into tool-invoked subshells in some environments — pass --fossa-api-key explicitly if fossa test reports "API key is required" despite the variable being set.

Next steps

1. Open the 3 "needs evidence check" issues (#3, #4, #10) in the FOSSA UI and note the exact matched file.
2. For all 12, add the rationale from this table as the resolution comment when marking each issue resolved/ignored in FOSSA (UI: Issues → select issue → "Resolve" / "Ignore" → paste rationale).
3. Optionally commit a .fossa.yml documenting scan scope (e.g., confirming src/cart/tests, internal/tools, and test/telemetry are intentionally dev/test-only) for reproducibility — this does not itself resolve issues (FOSSA has no in-repo "ignore" mechanism); it only scopes what gets scanned.
4. If pillow's MIT-CMU (HPND-style) license is expected to recur across future scans, consider whether it's worth raising with CNCF to formally add to the allowlist rather than resolving per-issue every time.