Repository navigation
List the bundled dependencies' licenses, with their texts and notices - #57
Merged
Merged
Conversation
The license-maven-plugin, in the build: - add-third-party writes THIRD-PARTY.txt, the dependencies the CLI jar bundles and their licenses, and fails the build on one under a license that isn't allowed (Apache-2.0 and MIT, for now) or without one. - download-licenses keeps each license's text in src/license/texts, and which dependency each is for in src/license/licenses-resolved.xml, both committed. A build reads them rather than downloads them, offline too; it downloads only what it hasn't seen, and deletes nothing. Whatever changes shows in git, and CI and the release fail until it's reviewed and committed. - src/license/licenses.xml corrects what the POMs say, for the versions reviewed: jSerialComm and JNA are taken under Apache-2.0, of their dual licenses; the MIT texts come from the projects' tagged LICENSE files, with their copyright lines; and jSerialComm's and Scala's NOTICE files, which aren't in their jars, come from their tagged sources. Each download is named and checked against a checksum. An upgraded dependency gets the license its POM gives until its entry is updated. The list, the texts and the mapping go in META-INF/third-party in the jars and in third-party in the CLI zip. The shade plugin merges the NOTICE files inside the dependencies' jars into the runnable jar's, and leaves out their LICENSE files, which overwrote each other there.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The runnable jar and the CLI zip bundle dnp3c's dependencies, but they didn't carry those dependencies' licenses. This PR has the build produce and check them with the license-maven-plugin (2.7.1).
What ships
META-INF/third-party/in the jars, andthird-party/in the CLI zip:THIRD-PARTY.txt: each bundled dependency and its licenses;licenses-resolved.xml: which file goes with which dependency.META-INF/NOTICEmerges the NOTICE files found inside the dependencies' jars; for now that's only commons-cli's. TheirLICENSEfiles used to overwrite each other there, and are now left out.How it's kept correct
src/license. A build reads them rather than downloading them, including offline. It downloads only what it hasn't seen and never deletes anything, so any change shows in git. CI and the release workflow both fail until that change is reviewed and committed.src/license/licenses.xmlfixes what the POMs say, for the versions reviewed:LICENSEfiles, which carry their copyright lines, instead of a generic page;src/license. That fails the guard until the entry is reviewed and updated.Checked locally: an offline build changes nothing, a deleted text is restored unchanged, and a version that no longer matches its correction changes
src/license.CLAUDE.md describes the process.