chore: licence compliance for published artifacts

[dskarzh]

Attribution hygiene for this fork, along the same lines as thingsboard/tbel#51 and thingsboard/protobuf-dynamic#4.

Targets thingsboard, not master — master here tracks upstream and carries none of the fork's work.

Changes

• Mark the files we have modified. Apache-2.0 §4(b) requires modified files to carry prominent notices stating that they were changed. Five upstream files are altered by this fork and none of them said so: src/core/index.js, src/core/components/responses.jsx, src/core/components/live-response.jsx, src/style/_layout.scss, and dist/swagger-initializer.js.

  Upstream carries no per-file licence headers, so the notice is a plain leading comment and no ThingsBoard copyright header is applied to upstream code — the aim is to state the fact of modification, not to claim authorship. The copyright line inside the notice carries an SPDX-FileCopyrightText tag, so the modification copyright is machine-readable while staying scoped to the modifications; scanners parse it as a copyright statement without any licence detection changing. In src/core/index.js the notice sits below the @prettier docblock, which only takes effect when it is the first comment.

• Declare the licence on the ThingsBoard-authored files. The 11 files under src/core/plugins/http-login-auth/ are the opposite case: new work, not modifications, so no §4(b) notice applies — but they are also the one place where ThingsBoard holds the copyright and can declare the licence in-file. Each now carries the short-form SPDX header (SPDX-FileCopyrightText: Copyright 2024 ThingsBoard, Inc. + SPDX-License-Identifier: Apache-2.0). Scanners resolve every one of them to Apache-2.0 at 100%; before, they carried no licence information at all.

• Replace the README with a fork-descriptive one. Upstream's README documents upstream's npm packages, compatibility matrix and contribution flow, none of which applies here. The replacement states what the fork is, how it is consumed (GitHub archive of a TB-suffixed tag, packaged into the springdoc-swagger-ui webjar), and lists the deltas against upstream 5.21.0. That delta list doubles as the §4(b) modification notice for the changed files that cannot carry one in-file — the JSON manifests and the regenerated dist bundles (see the next section). The License section uses the canonical phrasing that scanners resolve to exactly Apache-2.0.

• Bump the version to 5.21.0TB2 and rebuild the bundles. The tag name is already load-bearing (chore: licence compliance for published artifacts springdoc-openapi#2 pre-bumped <swagger-ui.version> to it), so package.json and package-lock.json are set to match. The dist bundles are rebuilt because webpack bakes PACKAGE_VERSION into them — without a rebuild they would keep self-reporting 5.21.0TB. The rebuild churn is fully attributable: a control rebuild at the previous release commit reproduced the committed bundles byte-for-byte after normalizing the four build stamps (PACKAGE_VERSION, GIT_COMMIT, GIT_DIRTY, BUILD_TIME), so the only changes here are the new stamps in the four bundles and source-map updates whose content change is the header comments added by this PR — plus one one-character drift flagged in review: the tachyons-sass/scss/_clears.scss entry in swagger-ui.css.map's sourcesContent reads *zoom: 1 where the previously committed map had zoom: 1. The rebuilt map is the faithful one — that is what tachyons-sass@4.9.5 ships, and the build's star-hack sed only rewrites dist/swagger-ui.css, never the map — so the old map's copy had been altered by something in the previous build's environment. No effect on the compiled CSS, which is unchanged. (GIT_DIRTY reads true by construction — the stylesheet step writes into dist/ before the bundles compile; the previous release build has the same flag for the same reason.)

• Delete the three stale source maps (dist/swagger-ui-bundle.js.map, dist/swagger-ui-es-bundle.js.map, dist/swagger-ui-standalone-preset.js.map), as flagged in review. They are orphaned: the build does not generate maps for these three bundles (sourcemaps: false in their webpack configs), no bundle carries a sourceMappingURL reference to them — the only mechanism by which anything ever loads a source map — and they were last touched by the 5.12.0TB release, so they no longer described the bundles sitting next to them. Deleting them has no observable effect (nothing could reach them), removes ~4.2 MB of misleading metadata from the webjar's wholesale copy of dist/, and leaves every remaining map both referenced and regenerated by this PR's rebuild. Upstream's 5.21.0 tree does ship its own (current) copies of these files, so the deletion is recorded in the README delta list.

Which of these notices a binary consumer actually sees

dist/swagger-initializer.js is the only file whose notice ships as a first-class comment — the reason it is in this PR. Since the rebuild, the src/ notices also travel inside the maps that embed source text:

	reaches the published webjar	notice
the 4 src/ files	indirectly — three of the shipped source maps (swagger-ui.js.map, swagger-ui-es-bundle-core.js.map, swagger-ui.css.map) embed full source text in sourcesContent, and after the rebuild the notices ride in them; the other three maps carry sources paths only	added, satisfying §4(b) at the file
the 9 dist/ bundles, maps and stylesheets	yes, but regenerated on every build	not annotated in-file; the README delta list covers them
dist/swagger-initializer.js	yes, verbatim	added

dist/swagger-initializer.js is not build output. None of the build* scripts writes it — upstream ships it in dist/ as a hand-editable template — and the fork added SwaggerUIBundle.plugins.HttpLoginAuth to its plugins list. Confirmed byte-identical to the copy inside the published springdoc-swagger-ui-2.8.8TB.jar.

§4(b) is a condition on the files themselves, which this PR satisfies for all five regardless of which ones travel.

Two modified files that cannot carry an in-file notice

package.json and package-lock.json also differ from upstream, in the version field only — 5.21.0 becomes 5.21.0TB2 (once in package.json, twice in the lockfile). Their §4(b) notice is the README's delta list rather than an in-file comment, for three reasons:

• JSON has no comment syntax. A _comment key would be a functional change to a manifest in order to document a licensing fact, which is a worse trade than documenting it in the README.
• package-lock.json is generated. npm rewrites it on install, so any annotation is transient — the same category as the dist/ bundles.
• The version string itself already announces the divergence. The TB suffix exists to say this is not upstream 5.21.0, which is precisely what §4(b) is about.

Neither file ships in the webjar in any case.

Why NOTICE is deliberately untouched

§4(d)'s obligation is to preserve the attribution notices upstream placed in NOTICE — SmartBear's two lines. Adding our own notices there is expressly optional ("You may add Your own attribution notices"), and the modification notices this PR owes live in the files themselves, so NOTICE stays byte-identical to upstream.

The NOTICE problem that does exist is downstream: org.thingsboard:springdoc-swagger-ui builds its webjar by downloading https://github.com/thingsboard/swagger-ui/archive/${swagger-ui.version}.zip, unpacking it, and moving only dist/ into the jar. NOTICE and LICENSE are present in the unpacked archive and are simply not copied — so the published springdoc-swagger-ui-2.8.8TB.jar contains no NOTICE, and SmartBear's attribution does not reach anyone who consumes it. That copy step is fixed in thingsboard/springdoc-openapi#2.

Follow-up needed from someone with write access

The springdoc build fetches by tag, so merging this changes nothing on its own — https://github.com/thingsboard/swagger-ui/archive/5.21.0TB.zip resolves to refs/tags/5.21.0TB and will keep serving the old bytes.

1. Merge this PR
2. Tag the merge commit as 5.21.0TB2. This was originally just a suggestion (existing tags are one per upstream base — 5.12.0TB, 5.21.0TB — so there is no precedent for a second build on the same base, and 5.21.1TB would falsely imply an upstream 5.21.1), but chore: licence compliance for published artifacts springdoc-openapi#2 has since pre-bumped <swagger-ui.version> to 5.21.0TB2, so the name is now load-bearing: if a different tag is chosen here, that property and this repo's package.json version must be adjusted to match (and the bundles rebuilt, since they self-report the version)
3. Update package.json's version to match the chosen tag — pre-bumped to 5.21.0TB2 in this PR (package-lock.json synced), matching the springdoc pre-bump, with the bundles rebuilt to embed it
4. In thingsboard/springdoc-openapi: bump <swagger-ui.version>, copy NOTICE in the springdoc-swagger-ui antrun step — both delivered in chore: licence compliance for published artifacts springdoc-openapi#2; what remains there is cutting a new release (2.8.8TB is on Maven Central and immutable)

One thing worth checking before that release: the webjar path embeds the version (META-INF/resources/webjars/swagger-ui/5.21.0TB/, becoming 5.21.0TB2/), so it is worth grepping consumers for the literal version string in case anything hardcodes the path.

No behaviour changes

Every edit is a comment, the README, or the version bump and its rebuild. No source-logic, build-config or dependency changes. dist/swagger-initializer.js only gained a leading comment — node --check passes. The rebuilt bundles are byte-identical to the previous ones after normalizing the four build stamps, verified against a control rebuild at the previous release commit.

[dskarzh]

Review summary

Reviewed 5 changed files in docs: attribution notices for the ThingsBoard modifications. No inline comments — the changes themselves are sound. Verified against the upstream 5.21.0 base (fceaec60..c324bf6c): the four files marked are exactly the upstream source files the fork modified, the http-login-auth/ files are indeed new work, the @prettier pragma in src/core/index.js stays in the first comment block where it takes effect, the Sass comment in _layout.scss is legally placed before the @use rules, and NOTICE keeps SmartBear's lines first and untouched. One observation about a file outside the diff below.

Per reviewer request, this run covered correctness & safety only; the quality/design pass was skipped.

Additional findings

These observations are about existing code outside the PR's diff — spotted while reading surrounding context.

• dist/swagger-initializer.js:15 — This is also a hand-modified upstream file (the fork added SwaggerUIBundle.plugins.HttpLoginAuth to the plugins list), and unlike the bundles it is not regenerated by the build — nothing in package.json scripts or the webpack configs touches it. It therefore ships verbatim in the springdoc webjar, which makes it the one modified file where a §4(b) notice comment would actually reach the binary distribution — yet it carries none. Was it left out deliberately as part of dist/, or overlooked because the fork-diff was filtered to src/?

---

This review was auto-generated. Findings may contain errors — please verify before applying changes.

[dskarzh]

Verified all three claims — the finding is correct, and I have added the notice in a third commit (0cde2178).

It is a modified upstream file. Against v5.21.0:

-      SwaggerUIBundle.plugins.DownloadUrl
+      SwaggerUIBundle.plugins.DownloadUrl,
+      SwaggerUIBundle.plugins.HttpLoginAuth

It is not build output. All seven build* scripts run webpack against the webpack/*.js configs, producing the bundles and stylesheets. Nothing writes swagger-initializer.js — the only reference to it outside dist/ is a URL inside a docker/configurator error message. Upstream ships it as a hand-editable template that happens to live in dist/.

It ships verbatim. Extracted the published springdoc-swagger-ui-2.8.8TB.jar copy and diffed it against this file: byte-identical, HttpLoginAuth line included.

So the cause was exactly as you guessed — I filtered the fork diff to src/ and treated everything under dist/ as generated without checking which of them were. 12 of the 13 dist files are; this one is not.

That also makes it the only §4(b) notice in this PR that a binary consumer will ever see:

	reaches the jar	notice
4 src/ files	no	added
12 dist/ bundles + maps	yes, but regenerated each build	not meaningful
dist/swagger-initializer.js	yes, verbatim	added in 0cde2178

node --check passes. Wording is kept identical to the other four for consistency; the URL for the modified sources lives in NOTICE, which the same jar will carry once the copy step is fixed in thingsboard/springdoc-openapi.

One cosmetic oddity worth naming: this file is upstream's config template, and springdoc overrides its settings at runtime rather than using the petstore URL in it. A modification notice in a file designed to be replaced reads a little strangely — but as published it is a modified upstream file, so annotating it is right.

The PR description has been updated too — it previously said the notices deliberately do not reach the jar and that dist/ was untouched, both of which this commit invalidates.

[dskarzh]

Re-review summary

Re-reviewed docs: attribution notices for the ThingsBoard modifications — verified 1 finding from previous review.

Status	Count
✅ Resolved	1
💬 Acknowledged	0

All previous findings have been addressed. No new issues in the fix commit: the notice sits above window.onload, and the Docker configurator locates the configuration block by the //<editor-fold> string markers (not line numbers) and preserves everything before the start marker, so the added comment cannot interfere with it.

Finding details

• ✅ dist/swagger-initializer.js:1 — hand-modified upstream file (adds HttpLoginAuth plugin) carried no §4(b) notice — Fixed in code by 0cde2178.

One minor nit, not code: the PR description now trails the change — it still says "Four upstream files are altered" (now five are marked) and that "the per-file notices deliberately do not try to reach the jar", while the dist/swagger-initializer.js notice does ship verbatim in the webjar. Worth updating the description before merge.

Per reviewer request, this run covered correctness & safety only; the quality/design pass was skipped.

---

This re-review was auto-generated. Findings may contain errors — please verify before applying changes.

[dskarzh]

Review summary

Reviewed 6 changed files in docs: attribution notices for the ThingsBoard modifications. Left 0 comments inline. The added notices preserve JavaScript, JSX, and Sass parsing, and the Docker configurator preserves the new leading initializer comment because it only replaces the marker-delimited block. The previously reported dist/swagger-initializer.js omission is resolved and is not repeated here; one new attribution-scope question remains in existing fork changes outside this PR's diff.

Per reviewer request, this run covered correctness and safety only; the quality/design pass was skipped.

Additional findings

These observations are about existing code outside the PR's diff — spotted while reading surrounding context.

• package.json:3; package-lock.json:3,9 — Against upstream 5.21.0, the fork changes these version fields from 5.21.0 to 5.21.0TB, but neither manifest is among the five files marked as modified. Since this PR aims to satisfy Apache-2.0 §4(b), which refers to any modified files, could these two files be included in the compliance treatment, or could the PR document why version-only/generated metadata is outside its scope? JSON's lack of comments may require a different mechanism, but otherwise the source archive still contains two modified files without an in-file change notice.

---

This review was auto-generated. Findings may contain errors — please verify before applying changes.

[dskarzh]

Two things here — one finding I have acted on, one nit that was already stale when the review ran.

package.json / package-lock.json — correct, and now documented

Verified against upstream v5.21.0:

package.json
-  "version": "5.21.0",
+  "version": "5.21.0TB",

package-lock.json  (two occurrences)
-  "version": "5.21.0",
+  "version": "5.21.0TB",

So yes: two modified files with no in-file notice, and §4(b) does say "any modified files".

I have taken the second option you offered — documenting the scope rather than annotating them — and added a section to the PR description. The reasoning, beyond JSON not having comments:

• The version string already is the notice. The only change to package.json is 5.21.0 → 5.21.0TB. That suffix exists to announce that this is not upstream 5.21.0, which is exactly what §4(b) is for. A comment stating the file was modified, sitting next to a version deliberately distinguished from upstream, adds nothing a recipient did not already have.
• package-lock.json is generated. npm rewrites it on install, so any annotation is transient — the same category as the dist/ bundles, which are also modified relative to upstream and also not annotated.
• A _comment key would be a functional change to a manifest in order to record a licensing fact. That seems a worse trade than recording it in the PR.

Neither file ships in the webjar in any case, so nothing turns on this for recipients of the binary.

The description nit was already fixed

The previous re-review (12:16) raised the same point, and the description was updated at 12:11:36 — before that review ran at 12:16:07. The live body has read "Five upstream files" and listed dist/swagger-initializer.js since then, and the "deliberately do not try to reach the jar" and "dist/ is untouched" sentences were removed in the same edit.

Worth flagging in case the tooling is reading a cached snapshot of the PR body rather than fetching it fresh, since it has now reported the same stale text twice.

[dskarzh]

Review summary

Reviewed 26 changed files in chore: licence compliance for published artifacts. Left 1 comment(s) inline.

I verified the mechanical claims rather than taking them on faith: all four rebuilt bundles are byte-identical to the previous release after normalizing the four build stamps (PACKAGE_VERSION, GIT_COMMIT, GIT_DIRTY, BUILD_TIME); the three regenerated source maps have unchanged sources/names, mappings changes that are the expected consequence of the shifted lines, and sourcesContent changes that are exactly the header comments this PR adds — with one exception, noted inline; the stamped GIT_COMMIT (gd2e455bf) resolves to an ancestor of the PR head; the compiled swagger-ui.css is untouched (the SCSS notice is stripped in compressed output); the notice in src/core/index.js sits below the @prettier pragma as described; and the README's LICENSE/NOTICE links resolve. No behaviour changes found.

Additional findings

These observations are about existing files outside the PR's diff — spotted while reading surrounding context.

• dist/swagger-ui-bundle.js.map, dist/swagger-ui-es-bundle.js.map, dist/swagger-ui-standalone-preset.js.map — these three maps were last touched by the 5.12.0TB release and no longer correspond to the bundles sitting next to them. The build never refreshes them (sourcemaps: false in webpack/bundle.js:25, webpack/es-bundle.js:24, webpack/standalone.js:11), and none of the three bundles carries a sourceMappingURL trailer referencing them — they are orphaned 5.12-era files (paths only, no sourcesContent) that still ship in the webjar's wholesale copy of dist/. Pre-existing rather than introduced here, but since this PR is about artifact hygiene: consider deleting them, or adding them to the README delta list as known-stale.

---

This review was auto-generated. Findings may contain errors — please verify before applying changes.

[dskarzh]

Re the stale source maps (review finding): verified and taken the delete option, folded into the amended bump commit (aec91843).

Confirmed all three claims, plus one more data point the review did not have:

• Fork history: all three maps were last touched at the 5.12.0TB release; the 5.21.0 update never refreshed them.
• The build cannot refresh them — sourcemaps: false in webpack/bundle.js, webpack/es-bundle.js, webpack/standalone.js — and none of the three bundles ends with a sourceMappingURL trailer, which is the only mechanism by which anything ever loads a source map. They were unreachable dead weight that misdescribed the 5.21-era bundles next to them, shipping in the webjar's wholesale copy of dist/.
• Upstream's v5.21.0 tree does ship its own copies of these three maps (their release pipeline evidently builds them despite the repo config), so the fork's stale copies were also divergent from upstream — and the deletion is itself a delta, now recorded in the README's list.

Taking upstream's copies instead would not have helped: this fork's bundles are built from modified sources, so upstream's maps would misdescribe them too. After the deletion, every map remaining in dist/ is both referenced by the artifact next to it and regenerated by this PR's rebuild.

The PR description has a new bullet covering this, and the consumer-visibility table's dist-file count is corrected accordingly.

[dskarzh]

Review summary

Reviewed 29 changed files in chore: licence compliance for published artifacts. No correctness or safety issues found. Per reviewer request, the separate quality/design pass was skipped, and topics already covered in the PR discussion were not repeated.

---

This review was auto-generated. Findings may contain errors — please verify before applying changes.