chore: licence compliance for published artifacts

[dskarzh]

License hygiene for the published artifacts, along the same lines as thingsboard/tbel#51.

Changes

• Ship the license text. The jar, sources jar and javadoc jar carried no copy of the Apache License, though LICENSE was in the repository — so anyone receiving a binary got no license text with it. A <resources> entry now copies it into META-INF. maven-javadoc-plugin does not package project resources, so maven-resources-plugin stages the file into the javadoc output directory at prepare-package, before javadoc:jar runs. LICENSE itself is replaced with the text from apache.org, with the two http:// URLs it contains changed to https:// — see the note below.

• Restore EnumDefinition to the upstream formatting. Its only difference from upstream was brace placement and indentation; there was no code change at all. Reverting it leaves the file byte-identical to upstream, so it is not a modified file and needs no change notice.

• Mark the files we have modified. DynamicSchema (+69/-26 ignoring reformatting), MessageDefinition (+30/-23) and DynamicSchemaTest carry real changes from the upstream os72 sources, and none of them said so. Each now carries a short notice below the existing upstream header, which is left untouched. The notice points at the Git history rather than describing individual changes, so it needs no maintenance.

• Replace the README. It was upstream's, and instructed readers to depend on com.github.os72:protobuf-dynamic:1.0.1, which is not this artifact. The replacement says what this fork is and how it is licensed.

• Drop two upstream files. RELEASE_NOTES.md stops at 1.0.1 and documents none of the versions published from here. .github/FUNDING.yml solicited donations for the original author from a ThingsBoard repository.

• Fix the pom urls. The project <url> pointed at the upstream repository, so the homepage shown for this artifact sent readers somewhere that does not carry it — and it contradicted <scm>, which already named this one. <scm><url> held the SSH clone string where a browsable address belongs, and <connection>, the read-only anonymous connection, was SSH and unusable without a key. The license url now uses https.

• Name the license in full, and make the spelling consistent. The README said "licensed under the Apache License 2.0 — see LICENSE". That reads fine but is imprecise on both halves: the license's own name is "Apache License, Version 2.0", and a bare pointer to a file names no license at all. It now reads protobuf-dynamic is licensed under the Apache License, Version 2.0. See LICENSE for the full license text. This is not cosmetic — with the old wording a ScanCode run over this repository reported the project as Apache-2.0 AND MIT AND NOASSERTION: "licensed under the Apache License 2.0" covers 80% of a rule written for dual MIT/Apache notices, and "see LICENSE" is an exact match for a rule meaning a reference to a license that cannot be identified here. There is no MIT anywhere in the repository. With the wording above the same scan reports Apache-2.0 alone, every match at 100%. Separately, the pom comments and one plugin execution id used the British "licence"; they now use "license", so the spelling is consistent across the repository. The pom also declares the license by its SPDX name: <name> moves from the legacy Sonatype string The Apache Software License, Version 2.0 to SPDX's canonical Apache License 2.0 (identifier Apache-2.0). Maven has no field for the identifier itself, so the canonical name is the whole of what alignment means here, and aggregators match it more reliably than the legacy phrasing. Verified: the declared license still resolves to Apache-2.0 with nothing unmapped.

• Publish releases to the ThingsBoard repository. <distributionManagement> pointed at the OSSRH staging endpoints, which Sonatype decommissioned in 2025 — mvn deploy had no working target at all. It now points at repo.thingsboard.io/artifactory/libs-release-public, the same publishing setup as other ThingsBoard-hosted libraries and the same change as chore: licence compliance for published artifacts springdoc-openapi#2 and Update distribution management to publish to repo.thingsboard.io tbel#49. The snapshot repository entry is dropped since only releases are published. The org.sonatype.oss:oss-parent parent pom goes with it: it existed solely to wire projects into OSSRH (the repository endpoints, the sonatype-oss-release profile, 2012-era plugin pins — all inside that profile, none used by regular builds) and has been deprecated since 2015. Everything this build uses is declared locally, verified by a clean rebuild: all three jars produced, each carrying META-INF/LICENSE. The deploying machine needs a thingsboard-public-repo server entry in settings.xml; the gpg-sign profile is unchanged.

<developers> is deliberately unchanged. The upstream entry is inherited from the original pom and is an attribution notice, which derivative works are required to preserve.

Note on the LICENSE text

It is not byte-identical to apache.org/licenses/LICENSE-2.0.txt: two lines carry https:// where the canonical file still has http://. That is deliberate and matches thingsboard/tbel#51. Every operative term is untouched, so recipients still receive a copy of the License; the only cost is that a scanner matching license texts by checksum may not recognise it as verbatim Apache-2.0. Rule-based detection is unaffected: ScanCode matches this LICENSE as Apache-2.0 at 100%.

Why the javadoc plugin version is now pinned

Staging the license into the javadoc output directory is path-based, and that directory moved between plugin versions — 3.5.0 writes to target/apidocs, 3.12.0 to target/reports/apidocs. The version was previously unpinned and inherited from oss-parent, so the two could drift apart, and the symptom is silent: the build stays green and the javadoc jar simply ships without the license. Pinning the version keeps the staging path correct, and there are comments on both plugins recording that they are coupled.

Verified

From a clean build, all three artifacts carry META-INF/LICENSE byte-identical to the repository file, the sources jar carries the modification notices with the upstream copyright headers still above them, and the javadoc HTML is intact.

Not addressed here

• No version bump. Now included: the final commit bumps the version to 1.0.5TB (1.0.4TB is on Maven Central and immutable, so releasing this needs a new version anyway) — merging and deploying is all that is left.

• The build does not pass on a current JDK, and did not before this branch. mvn package fails compiling the test: lombok 1.18.8 no longer runs its annotation processor on recent JDKs, so @Slf4j's log field is never generated. Verified against pristine master, which fails identically. The verification above therefore used -Dmaven.test.skip=true, so the test suite has not been run. Bumping lombok would fix it, but that is a different change and I have left it alone.

No source behaviour changes — every edit is a comment, a metadata field, whitespace, or build configuration.

[dskarzh]

Review summary

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

The pom resource configuration and the javadoc licence-staging coupling look correct — the ordering (prepare-package before javadoc:jar at package) holds, the deliberately pinned plugin versions are documented, and the nonexistent src/main/resources directory in the restated default resource is silently skipped by Maven, so it is harmless. The modification notices are comment-only insertions between the upstream header and the package statement, so no behaviour changes. Both inline comments are about factual accuracy of the licence text and the modification-notice claims, not about anything broken.

Note: per the requester's instruction, this run covered the correctness & safety lens only — the quality & design pass was skipped.

---

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

[dskarzh]

Re-review summary

Re-reviewed chore: licence compliance for published artifacts — verified 2 finding(s) from previous review.

Status	Count
✅ Resolved	1
💬 Acknowledged	1

All previous findings have been addressed. The fix commits were also reviewed for new issues: the only content change since the previous review is the EnumDefinition formatting revert, which I verified leaves the file byte-identical to upstream os72/protobuf-dynamic as claimed — no new issues found. As with the previous review, the quality & design pass was skipped at the requester's instruction.

Finding details

• ✅ src/main/java/com/github/os72/protobuf/dynamic/EnumDefinition.java — modification notice on a file that differed from upstream only by reformatting — Fixed in code: the file was reverted to the upstream formatting (byte-identical, verified) and the notice removed; the PR description was corrected accordingly.
• 💬 LICENSE:4 — text not byte-identical to canonical apache.org LICENSE-2.0.txt (two http:// → https:// substitutions) despite the PR description claiming canonical text — Developer: "deliberate, matches thingsboard/tbel#51; every operative term is untouched" — the PR description now documents the deviation explicitly instead of claiming canonical text.

---

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

[dskarzh]

Review summary

Reviewed 9 changed files in chore: licence compliance for published artifacts. No issues found.

The correctness and safety pass confirmed that the Java changes do not alter runtime behavior. A clean mvn -Dmaven.test.skip=true clean package succeeded, and the main, sources, and javadoc jars each contain META-INF/LICENSE byte-identical to the repository file. Existing resolved or acknowledged review threads were excluded, and the quality/design pass was skipped as requested.

---

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