Looking at the wiki page, I see at least one bit of wishful thinking (I expect it comes from your LLM)... spdx license identifiers are nice, but a LOT of dependencies do not provide such, so you will be in the business of creating them. And there's fun stuff like modified BSDs https://github.com/nsoft/jesterj/blob/9e9c9443c7877f3398a9b0c945428a3b3e36d00f/code/ingest/licenses/BSD-3-Clause-Nuclear/BSD-3-Clause-Nuclear.txt
Also attempts to de-dupe the multiple copies of licenses means somehow verifying that there are *actually* no modifications in the license files (but white space doesn't matter, and that windows encoded file is a pain to compare with all the other UTF-8 ones...), and then aggregating the names of the libraries to associate them with the deduped licenses. My guess is it's just not worth the effort to deduplicate. Another thing, not clearly defended (unless I'm missing something) by the idea in the wiki is *where* we got the notion that the notice we supply really is associated with the library we claim it is. I found that when I forced myself to write that down in each README.txt file in my /licenses/ directory for JesterJ, it uncovered a host of mistakes. "Generated, never hand edited" sounds good, but at least at the time I was working on this for JesterJ I found that th best I could actually achieve was generation from a hand-curated and build-verified directory structure. On Wed, Sep 2, 2026 at 5:27 PM Gus Heck <[email protected]> wrote: > 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) > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
