Food for thought (I haven't yet read the wiki page deeply): JesterJ has a system for generating an aggregate notice file and including copies of dependent licenses (which are a superset of Solr's since solr is a dependency)
https://github.com/nsoft/jesterj/blob/9e9c9443c7877f3398a9b0c945428a3b3e36d00f/code/ingest/gradle/licenseMgmt.gradle#L333 My intent in JesterJ was to ensure compliance with all ASF notions of license categories and explicitly detail how I met the distribution requirements of all dependent library licenses (Since it was ASF 2.0 licensed). That code relies on a carefully maintained directory structure that allows sequestration of the relevant notice file, declaration of where it was found, and an explicit description of how each aspect of a license's requirements is fulfilled. ASL 2.0 example https://github.com/nsoft/jesterj/blob/9e9c9443c7877f3398a9b0c945428a3b3e36d00f/code/ingest/licenses/Apache-2.0/aalto-xml-1.3.2/NOTICE.txt https://github.com/nsoft/jesterj/blob/9e9c9443c7877f3398a9b0c945428a3b3e36d00f/code/ingest/licenses/Apache-2.0/aalto-xml-1.3.2/README.txt mozilla 1.1 example https://github.com/nsoft/jesterj/blob/9e9c9443c7877f3398a9b0c945428a3b3e36d00f/code/ingest/licenses/Mozilla-1.1/juniversalchardet-2.5.0/README.txt The JesterJ build also verifies that corresponding directories and files exist for each dependency, and that all the hyper links in those files have not gone 404 The entire licenses directory is also included directly in the distributed uno-jar for improved clarity beyond the (required) notice file. The system is as automated as I could make it (verifying that licenses used are within the allowed set, <https://github.com/nsoft/jesterj/blob/9e9c9443c7877f3398a9b0c945428a3b3e36d00f/code/ingest/licenses/allowed-licenses.json> etc.), but it also intentionally involves an explicit update of the notice files if any library is upgraded. The upgrade will change the name of the directory where the build looks, and the build will flag it until all transitive dependencies are accounted for (based on what Gradle resolves, thus guaranteeing a match to what actually gets packaged) -Gus On Wed, Sep 2, 2026 at 2:59 PM Jan Høydahl <[email protected]> wrote: > Hi, > > I have an old JIRA SOLR-15929 < > https://issues.apache.org/jira/browse/SOLR-15929> titled "Clean up NOTICE > and LICENSE files for Solr" > > Basically we are shipping LICENSE/NOTICE files that are not aligned with > ASF policy. The shipped files are to reflect what is shipped in each > tarball. > > I have (ok, together with an LLM) written a Confluence page with a > proposed plan for improving this. Simply put, we'll generate these files > from a structured source of truth. > > Read the proposal at > https://cwiki.apache.org/confluence/spaces/SOLR/pages/449282855/SOLR-15929+ASF+compliant+NOTICE+and+LICENSE+files+in+dist > and comment here or in the associated JIRA. > > I have not started implementation, but this is a kind of task that is well > suited for AI assistance once we agree on the design. > > Jan -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
