Licensing: Questions / Answers / Deliverables
The subgroup has documented answers to the questions below, with contributions from additional TC members. These questions and answers helped us
to understand the various permutations of our dependencies' licenses and use within FOLIO,
to raise specific questions to Community Council for some definitive legal advice,
and to define a process and build a tool to conduct our third-party license evaluations more consistently and efficiently.
The TC will consider recommendations from the subgroup in the form of several PRs to the tech-council repo (#108, #109, #110, #111) that would affect the module evaluation process. Some of these questions involve process decisions that are considered in those PRs. The remaining questions and answers are just work product of the subgroup, and have been condensed for readability. Of course the edit history of this page is always available, and v. 23 has the version just before condensing.
- 1 Goals: What are the project’s goals re: dependency licensing? Document so we can all – TC, CC, developers, etc. – be on the same page.
- 1.1 What is the specific problem that the community is/was trying to address with this value (“Module license is compatible with the FOLIO Project“)? What does “compatible with the FOLIO Project“ mean?
- 1.2 Why is our specific evaluation criterion (“Inclusion of third party dependencies complies with ASF 3rd Party License Policy (2)“) expected to address that value?
- 1.3 There are currently three dependencies listed as exceptions. Are these exceptions to the criterion that still respect the value or do they conflict with the value as well?
- 1.4 What risks does the project incur when we include modules that do not meet the criterion or value? What benefits do we get by including those modules? How do these balance out? Who should be making that call?
- 1.5 Are source-code hosting providers (i.e. GitHub) affected by license violations?
- 2 Process
- 2.1 What specific process should TC evaluators use to check licenses for FE modules? BE modules? Document so that all TC members, including those who are not developers or sysops, can do this evaluation step.
- 2.2 Identify / document existing tools to do (parts of?) this third-party license evaluation step of the evaluation process. I.e. Julian’s tool, and existing npx tools that have been used before.
- 2.3 Identify / define additional tools that we would like to exist to fill gaps in the third-party license evaluation process.
- 2.4 Do tools handle dual-licensed modules, where one license is acceptable, in a useful manner?
- 2.5 What differs if a dependency is used for testing but not in deployment? (Other variations?)
- 2.6 What differs if a dependency’s source code is bundled / binary code? (Do we bundle any?)
- 2.7 How should the evaluator handle a license that doesn’t appear at all on the ASF page?
- 2.8 What should we do when a new module includes a problem dependency that is already included in existing modules (that went through TCR, or pre-dated it)?
- 2.9 What (if anything) should the project do about existing modules with problem licensed dependencies? (Other than the existing module evaluation process that we are developing.)
- 2.10 What licenses do we have among dependencies in the FOLIO project today? (Could there be a catastrophic license added recently, that we don’t even know about?)
Goals: What are the project’s goals re: dependency licensing? Document so we can all – TC, CC, developers, etc. – be on the same page.
What is the specific problem that the community is/was trying to address with this value (“Module license is compatible with the FOLIO Project“)? What does “compatible with the FOLIO Project“ mean?
Compatible with Apache 2.0 license used for FOLIO’s source code. For runtime dependencies this means a permissive software license, or a compatible copyleft license and a warning/notice so that users are not surprised that FOLIO, a permissive licensed project, comes with a copyleft dependency.
Why is our specific evaluation criterion (“Inclusion of third party dependencies complies with ASF 3rd Party License Policy (2)“) expected to address that value?
See Third Party Dependencies (after PR #111 is merged).
From initial research & discussion
The ASF 3rd Party License Policy requirement is to provide a clear list of licenses that have already been vetted by a notable entity, such as the Apache Software Foundation. This reduces the burden on the FOLIO community and its resources.
Why reference a list of licenses?
Before referencing this policy, the criterion stated “Third party dependencies use an Apache 2.0 compatible license.” This was not directly actionable, because there was no list of allowed licenses to consult. See PR 79. Providing a list of compatible licenses makes the criterion actionable without independent “legal research” by TC members, who are not qualified to do so.
Why ASF’s list in particular?
ASF’s policy’s criteria for inclusion of a particular license is that it’s open source and that “as applied in practice, [it] must not impose significant restrictions beyond those imposed by the Apache License 2.0.” This falls in line with the values of FOLIO.
If ASF’s policy is stricter than ours, then licenses they list in Category A or B should provide a list of licenses that we may want to further investigate with reason to suspect that it might be acceptable.
ASF’s list is actively managed, discussed and updated, i.e. to categorize new licenses, by ASF’s Legal Affairs Committee, which includes actual legal council. Some other commonly used lists/tools are not clearly vetted that way.
FOLIO should be able to automatically monitor this due to the files being hostend on GitHub at resolved.md.
There are currently three dependencies listed as exceptions. Are these exceptions to the criterion that still respect the value or do they conflict with the value as well?
The subgroup has determined that this question is best answered following legal consultation. Consult the following documents regarding this:
The three exceptions are LGPL 2.1. This license is on ASF’s Category X, not allowed for ASF projects.
The
org.z3950.zing:cql-java, specifically, this is from Index Data:The
org.marc4j:marc4jexception is under GPL2 and we have no known alternatives at this time.The
org.hibernate.*(Hibernate) exception has recently changed its license to use the Apache 2.0 License. We still have to determine how to handle old LGPL2 Hibernate dependencies.As of Mar 14, 2025 “A first release of ORM 7.0 covered under the Apache 2.0 License will be released early next week!”.
The Hibernate license change from LGPL2 to Apache 2.0 will only be applicable to versions moving forward from 7.0.0.Beta4. They will not be backporting any relicensing to any 6.x, 5.x, etc branches.
Additional note, there are “transitive” and “direct” dependencies. A third party dependency may create a combined work within its own scope if its dependency is a “compile” dependency sub-type. However, Java JAR/WAR files are not executables because a JAR/WAR has to be executed via “java -jar”. Bundling a servlet into the JAR/WAR file might make that file an executable and might change the stipulations regarding the use of that dependency under the LGPL2.1 license.
See official response regarding Java and LGPL.
”If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application.”
”When you distribute the library with your application (or on its own), you need to include source code for the library. But if your application instead requires users to obtain the library on their own, you don't need to provide source code for the library.”
What risks does the project incur when we include modules that do not meet the criterion or value? What benefits do we get by including those modules? How do these balance out? Who should be making that call?
The risks depend on the license.
The ASF 3rd Party License Policy explains why licenses have been put into the Category X section.
Rejecting a license is better than accepting a license with unknown risks.
Are source-code hosting providers (i.e. GitHub) affected by license violations?
Yes, if the license doesn’t allow publishing the source code.
Yes, if the license doesn’t allow executing the software but it runs in a CI pipeline like GitHub Actions.
The terms of source-code hosting providers require idemnification, for example GitHub: https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#p-release-and-indemnification
Process
What specific process should TC evaluators use to check licenses for FE modules? BE modules? Document so that all TC members, including those who are not developers or sysops, can do this evaluation step.
TC members should use the FOLIO Module Evaluator tool to check third-party licenses for both FE and BE modules.
This is intended initially as a recommendation, and later as a requirement.
The easiest way to run the FOLIO Module Evaluator is web-based, simply invoking a GitHub action on the tool’s repository. This capability (and specific instructions) is expected by the end of October 2025.
The tool can also be locally installed and run via CLI, as documented in the readme.
Identify / document existing tools to do (parts of?) this third-party license evaluation step of the evaluation process. I.e. Julian’s tool, and existing npx tools that have been used before.
Several tools have been used ad-hoc on individual module evaluations.
folio-dependencies tool for maven-based modules
npm license-checker
None of the above tools currently
cover the gamut of languages supported in FOLIO
provide web front ends
support a process where the FOLIO community can manage the list(s) of licenses in each ASF category
The subgroup gave strong consideration to Semgrep, with very helpful input (in these attached questions and afterwards) from the FOLIO Security Team based on their (evaluation of) using it for the project’s security vulnerability monitoring.
Ultimately we decided that Semgrep would not be our best option at this time for license evaluation. Factors included
Problems with the GitHub integration to grant admin access to team members, despite several attempts.
Inability to scan modules without a lock file, which excludes nearly all FOLIO modules. There is a by-request beta program to scan Java modules without lock files, but even if we were accepted to the beta (at no cost), we would still need a separate solution for front end (and non-Java back end) modules. Or alternatively, would need an initiative to add lock files to all modules, but that has its own considerations, including on front-end modules where the lock files are effectively ignored by the bundling process and create their own confusion.
Inability to distinguish Categories A and B, unless we turned on PR monitoring (to which there was an objection earlier).
Poor handling of multi-licensed modules.
Some also felt that to consider other tools, those tools themselves would need to also have compatible licenses.
Identify / define additional tools that we would like to exist to fill gaps in the third-party license evaluation process.
After identifying the gaps (above) in existing tools, Olamide defined and then built a tool to address them.
provides a modular, extensible framework for automatically evaluating FOLIO modules against acceptance criteria. It currently supports Java modules with a pluggable architecture for adding support for additional programming languages.
To meet the TC’s needs, the tool:
Evaluates Java modules (maven or gradle).
Evaluates JS modules (expected by the end of November 2025).
Provides a web-front end via GitHub Actions (expected by end of November 2025).
Does not require lock files.
Categorizes licenses.
Based on the ASF categorization.
But in a way that allows for FOLIO-specific handling, such as instructions on how to deal with attribution on our project, or exceptions as FOLIO deployment scenarios may differ from ASF’s needs.
And with a process to keep the lists of licenses up to date.
Handles multi-licensed modules intelligently.
Can grow to automate other parts of the TC module evaluation, if the council decides to do so.
Olamide expects to be able to expand the tool to handle all currently OST languages ahead of making the tool a formal requirement for evaluations.
Do tools handle dual-licensed modules, where one license is acceptable, in a useful manner?
The FOLIO Module Eval tool does handle dual-licensed modules intelligently.
From our initial investigation of existing tools:
The semgrep.dev’s license scanner doesn’t handle this automatically but allows to manual assign it to Allowed, Comment, or Blocked, see Semgrep license exceptions .
See Multiple License Types Semgrep docs:
“Semgrep treats packages with multiple licenses as if all licenses apply and behaves according to the strictest policy.”
This is a known issue. The Semgrep implementation is wrong. This is clearly documented on Multiple License Types.
Semgrep supports manual exemptions to fix the result of the wrong implementation, and other wrong violation reports.
mvn project-info-reports:dependencies(used on https://julianladisch.github.io/folio-dependencies/) shows licenses combined withORnext to each other making it easy to check.The
mvn dependency:treeshows a tree view of the dependencies.We can add a pom tweak to control generation of selective reports.
What differs if a dependency is used for testing but not in deployment? (Other variations?)
Community Council is working to get legal advice on how these considerations affect FOLIO’s development and deployment scenarios.
From initial research and discussion:
This depends on the specific license in question.
For licenses like LGPL2.1, this makes a big difference. If using the source for testing does not result in a combined work and is also not being distributed, then this might not be a concern. For example, if the docker image were to download some sources that are used by a dependency under LGPL2.1 but do not combine with that dependency, then there is likely no violation. See highlight note below regarding LGPL2.1 and combined works.
For testing it might be that a library/tool being used does not form a combined work with FOLIO’s (runtime or testing) source code.
Some licenses, like the AGPL impose broader restictions.
A build pipeline may keep the combined work (of runtime code, test code and testing software library) for a few days (for example in the Artifacts download area of the GitHub Actions run) to help with debugging.
For details see
ASF 3rd Party License Policy - Including build tools in ASF products
“Note that the tool must not affect the licensing of the project source code.”
ASF 3rd Party License Policy - They may not distributed category X licensed components but may be used at build time.
“For example, using a GPL'ed tool during the build is okay, but including GPL'ed source code is not.”
LGPL2.1 Specific Note on Combined Works: Based on the investigation into LGPL2.1 from several sections above, there might not be any combined work concerns based on how Java and others utilize the library. Specifically see license text regarding “work that uses a library“.
What differs if a dependency’s source code is bundled / binary code? (Do we bundle any?)
Community Council is working to get legal advice on how these considerations affect FOLIO’s deployment scenarios (which may differ on front-end and back-end, and by language).
From initial research and discussion:
This is explained in ASF 3rd Party License Policy. Category B licensed libraries may only be bundled as binary code, not as source code.
The ASF 3rd Party License appears to take a more opinionated stance that is not consistent with some licenses. Most notably LGPL2.1. The difference between a bundled code and a combined work is not as clear. The LGPL2.1 license focuses on “executable” rather than “combined work” and uses “derivative work” based on binaries being combined. There is a specific distinction between “linking” and “derivative” work. A combined package, like with a WAR/JAR file might itself not be a “derivative” even if they are in binary form. Therefore, some licenses may not impose as many restrictions or any restrictions. This is described in further details in sections above.
FOLIO does distribute JAR files inside of the docker images. These JAR files are a bundling in the most basic sense. However, as noted above, the definition of “bundling” may be different from license to license. Therefore, each bundling/binary situation must be clarified for each distrinct license type.
FOLIO does build and distribute binaries when it comes to the GOLang. Languages like GOLang, being compiled languages, might require more stringent rules that other languages might not require as a result.
GoLang builds are executables; therefore, in cases like LGPL2.1, would potentially be classified as a “derivative” work depending on the details of the individual projects. We should take special care to see when/where we perform go build inside of Docker images.
How should the evaluator handle a license that doesn’t appear at all on the ASF page?
See Third Party Dependencies (after PR #111 is merged).
From initial research and discussion:
It fails the criterion. It’s too risky for hosters. Legal advice is likely more expensive than replacing the library, and it may not give a clear answer.
What should we do when a new module includes a problem dependency that is already included in existing modules (that went through TCR, or pre-dated it)?
See Third Party Dependencies (after PR #111 is merged).
What (if anything) should the project do about existing modules with problem licensed dependencies? (Other than the existing module evaluation process that we are developing.)
The subgroup concluded that this question, and a process for dealing with these modules, should be deferred until after CC receives the requested legal analysis, because the number of problem dependencies (and risk to our project) may be lower than expected. For example, we may be legally advised that
our project’s specific dependency bundling / linking methods reduce the risks from particular dependencies' licenses
transitive dependency checking may not be necessary in some circumstances
Either of these results could significantly change the scope of our project-wide dependency review, which would reduce confidence in the process.
From initial research and discussion, which may be useful after we receive that legal advice:
Pushback would be expected on those findings. How to handle that? (Pushback would happen after the subgroup completes. But what path forward should TC suggest as guidance?)
It may be the case that this question is moot – after doing the evaluation in the question below, there may not be any problem licenses. This relies also on the exceptions being ok, which will be answered by a question above. And it depends on the answer to the risk question above. For draft purposes I’m assuming that there are indeed problem licenses in the project now, and that they are a problem risk.
Work to communicate the problem and find a solution:
Notify the relevant POs and dev leads of the findings, including the legal advice relevant to the problem licenses – what risks it presents to the project. Notify hosting providers of the risk as well.
For each of the problem dependencies, bring together a group of stakeholders (members of dev teams using the dependency? members of hosting providers? others?) to identify a solution and a plan/timeline for implementation.
Is it just a matter of attribution, or another simple Category B resolution? If so, remediate.
Can the FOLIO project decide to actually comply with whatever the additional terms are of the license? If that’s what the group wants to do, make that case to CC/legal.
If it’s actually necessary to replace the dependency, determine the plan / timeline to do so.
Alternatively, we could defer dealing with existing modules until they come up in the TC’s existing module evaluation process. TC should reject this approach because:
It ignores even considering how to deal with a known risk, let alone addressing it.
It puts the focus on a single dev team whose module we happen to be evaluating, as opposed to others using the same dependency.
It would discourage teams from participating with the existing module evaluation process.
What licenses do we have among dependencies in the FOLIO project today? (Could there be a catastrophic license added recently, that we don’t even know about?)
The subgroup concluded that this question, and a full analysis of existing modules, should be deferred until after CC receives the requested legal analysis, for the same reasons as in the previous question.
From initial research and discussion
Olamide’s Tool
Olamide wrote a python script to report on current licenses on mod-* and ui-* modules. Lists a lot of licenses. Some existing licenses are not compliant (see below). There are 509 unknown licenses. Intends to package something like this with a TCR evaluation. Did not modify codebase. (Julian’s
project-info-reportstool also doesn’t require a modification of the codebase, but if different spellings of the same license should be merged the plugin configuration needs to be added to the pom.xml.) Gradle, Maven, Go have plug-ins. Javascript modules included. (Julian’s tool is also specifically for Maven.)Would create a jenkins job to run the report, so no code knowledge needed.
If Semgrep is available to use by the community, we’d choose Semgrep. If it’s only for the security team, then no. (Unless Jenkins can output that particular report without providing access to the security vulnerabilities.)
Existing License Problems per Olamide’s Python Tool
This is not an exhaustive list.
Only one or two modules were selected as an example.
See for a complete list.
mod-agreements: ASF Category B, ASF Category X, and even some unknowns.ch.qos.logback: LGPL.com.h2database: MPL 2.0 (This H2 is in lots of projects and not justmod-agreements).javax.activation: CDDL 1.0 (several dependencies using this).javax.persistence: EPL 1.0.org.bouncycastle: Bouncy Castle License (this is an unknown).org.glassfish: Dual licensed of CDDL 2.0 / GPL 2.org.hibernate: LGPL 2.1.org.javassist: MPL 1.1.org.junit.jupiter: EPL 2.0.org.z3950.zing: LGPL 2.1.
mod-circulation: ASF Category B, ASF Category X, and even some unknowns.io.github.x-stream: Indiana University Extreme! Lab Software License (this is an unknown).com.google.re2j: Go license (this is an unknown).junit: EPL 1.0.org.aspectj: EPL 2.0.org.json:json1: The JSON License, explicitly prohibted by the ASF Category X.org.z3950.zing: LGPL 2.1.