Members: @Maccabee Levine (chair), @Olamide Kolawole, @Kevin Day , @Peter Murray (representing CC)
Slack: #folio-tc-license-evaluation
Initial Meeting Time: Thursday 8/21, 3pm - 4pm ET
Zoom Meeting ID: TBD after first meeting (link sent directly)

Agenda and Minutes

2025-11-18

Attendees: @Peter Murray @Kevin Day @Maccabee Levine @Olamide Kolawole

Feedback from TC review last week
- Edit PR #109 (offering the tool) to add a link to the FAQ page, and merge.
  - Done
- Reconsider not scanning all modules at this time?
  - TC can consider that as a council. Subgroup not going to.
  - @Maccabee Levine Report on that to TC @Peter Murray & CC.
- Configure any automatic running of the tool.
  - It was suggested at TC to scan on any PRs that change the dependencies.
  - Like above, TC can consider that as a council.
- Implement communications plan?
  - Once per flower release, but also once ASAP to get the community informed.
  - Group agrees that the existing comm plan text is ok, no need for an “introductory” edit.
  - @Olamide Kolawole will talk to Jenn about posting to those channels.
- Work with RSMG to add to calendar? Or wait until we do PR#110 making it required?
  - Better to get it on the calendar sooner than later. Work with RSMG to add it now.
  - Date: same as the RFC notification, grouped together
  - Title: Verify third-party dependency licensing using the TC Module Evaluation tool
  - Description: link to repo? Or link to criteria explaining optional now but required later?
    - Link directly to how to run it via the GHA UI: https://github.com/folio-org/tc-module-eval?tab=readme-ov-file#web-interface-github-actions
  - @Maccabee Levine start thread in #rsmg channel, tag Olamide
Open GitHub issue to add Go server support to TC Module Eval tool. @Maccabee Levine
No meeting needed next week but we’ll coordinating finishing the above tasks in the slack channel, and then officially close the subgroup and delete the recurring calendar event!

2025-11-13

Attendees: @Peter Murray @Maccabee Levine

Feedback from TC review yesterady
- Merge Q&A page PR (#111)
  - Done
- Edit PR #109 (offering the tool) to add a link to the FAQ page, and merge.
- Reconsider not scanning all modules at this time?
- Configure any automatic running of the tool.
We postponed the rest of the agenda since no one else could make it.

2025-11-06

Attendees: @Kevin Day @Maccabee Levine @Peter Murray

Review comments on PR #111.
Timeline for demos to TC / requesting for approval
- Demo of the tool itself (not for approval, but discussion)
- TC Module Eval PR #3 on how the lists of licenses should be managed.
  - It’s already been merged, but should still get approval and/or any changes.
- PR #109 recommending the tool for use during a trial period
- PR #110 requiring the tool’s use. For TC review / approval next April/May, but initial discussion now on the plan.
- PR #111 on how to deal with certain third-party dependency license issues that we may run into while we wait for CC’s legal responses.
Timeline for Recurring Calendar items.
@Peter Murray will (still!) send the updated questions from Kevin to CC/legal.
@Maccabee Levine Draft message to send per-release cycle about licensing.
Keep Thursday meetings on the calendar for the moment, but go/no-go based on what happens at the Wednesday TC meeting discussion.

2025-10-30

Attendees: @Peter Murray @Maccabee Levine

Pass updated questions document to CC.
- @Peter Murray will pass the updated doc to CC. To his knowledge, CC hasn’t done anything yet with the original document. Peter needs to talk to Tom, including about other OLF projects having similar questions.
With no one else able to make it, we postponed the rest of the agenda to next week.

2025-10-23

Attendees: @Kevin Day @Maccabee Levine @Olamide Kolawole

Language resolution (and action items from it) if still open
- Consensus to treat first/third party as FOLIO/non-FOLIO.
- @Kevin Day will review the language (uses of third-party/nested to transitive) on the wiki page, and the questions to CC/legal.
Any final changes to the three questions in PR #111 we're asking TC approval on.
- Consensus: approved. The part about requiring CC to approve modules with already-used problem dependencies is really tough, no one likes it but we can’t come up with a better option.
Any final changes to the Q&A wiki page that will be our work product.
- Consensus it’s good, other than any language edits per above.
Review of the two features Olamide planned to have by this meeting (if they’re ready), to complete the MVP:
- JS modules. Will handle the multi-license case if available in package.json.
  - This is working now.
  - Handles the multi-license case, based on SPDX standard. Probably some edge cases missed, can fix as we find them.
  - Currently looking at direct dependencies also. JS eval doesn’t have automatic capability to do transitive; you’d have to walk the tree. Had a branch using some tools do that, but heavyweight and took ~10 minutes to run.
- GitHub Action integration to run it. Pointing at a specific tag/commit specified in the module evaluation template.
  - Olamide has this working. Report is an artifact under the action summary.
  - Actions > Folio Module Evaluation > Run Workflow > URL/branch of repo to eval, output format, etc. Takes ~1-2 minutes to run based on caching.
- Looks good!
Does the tool need to scan transitive dependencies as well?
- This subgroup was partially driven by Julian’s tool finding problem transitive dependencies of a maven module, even though the direct dependencies were fine. Dev team added some notes in the readme; the dependencies either were dual-licensed, or were acceptable but required a note in the README.
- Weird that we would enforce on module evaluation, even though after that date, a dependency might pull in its own (transitive to us) dependencies that violate our policies, and we have no knowledge of that risk. Also we don’t know when transitive dependencies might go in and of the direct dependency. Semgrep etc. scans every source file for license text, serious check.
  - This may be handled by the process we have now/soon about reviewing existing modules. But would not catch it until we did that evaluation, might have to scan continuously. Or might be ok to do a reasonable effort periodically.
- Can we just look at license file & metadata for transitive deps? Not every file? (I.e. copyrights on documentation shouldn’t matter as we don’t include that…opportunities for false-positive / irrelevant licenses.) TC hasn’t done that level of investigation in the past.
- Maven makes the transitive check easy, but we have multiple languages, and not as easy to find the transitive for Go, Groovy, Node, etc. In-depth scan for transitive deps. Can turn on the flag for maven, but the others would not be adequate.
- We asked CC for final answer on this (from legal). So looking for interim answer recommendation.
- Important to bring this up for new languages as we bring them in – is there a way to vet the licenses via their package management services.
- Consensus:
  - Turn the maven side now to include transitive dependencies.
  - Need longer-term strategy how to do this “right”, with CC/legal advice. May need to pay for third-party services, or build other tools etc. But ok waiting for CC input on that.

2025-10-16

Attendees: @Kevin Day @Maccabee Levine @Peter Murray

Olamide will be absent today.
On the Licensing Questions & Answers doc:
- Review @Maccabee Levine 's work on the Process section.
  - For the last two process questions about evaluating existing modules, subgroup agrees we should wait for the legal analysis so that we don’t raise issues across many repos & dependencies that turn out to be moot. And also if it turns out from legal that we do need to consider transitive dependencies, then that will be a larger conversation and it’s best not to start it with the wrong scope.
  - Move this as the the following question into the tech council repo Licensing: Questions / Answers / Deliverables | How should the evaluator handle a license that doesn’t appear at all on the ASF... as part of another short-term PR.
  - By EOD Tuesday
- Review @Kevin Day and @Peter Murray 's cleanup of the “on person assignments and other distractions”.
  - Is it ok to delete some of the older conversation, that doesn’t reflect the subgroup’s conclusions? Yes. Older thoughts will be retained in the wiki history. A new person reading at the first time would not be overwhelmed by everything on the page.
  - In a footnote to the page as a whole, we can provide a link to the historical version of the page i.e. “if you are looking for more information”.
  - @Kevin Day and @Peter Murray will do that cleanup (whole document, including under Process) ahead of next week’s meeting. – by EOD Tuesday.
  - Related Google doc cleanup
    - @Kevin Day exporting LGPL docs to PDF on wiki
Review @Peter Murray ‘s “Why ASF” answer for inclusion in the FOLIO Module Evaluation tool’s documentation.
- @Peter Murray will post that Slack canvas to CC as FYI, as outcome from WOLFcon meeting.
- Include this as part of the same short-term PR I’m creating for the other two moved questions above.
On Wednesday, everyone @Kevin Day @Peter Murray @Olamide Kolawole read that Q&A one last time for final edits, for approval Thursday.

2025-10-09

Attendees: @Maccabee Levine @Peter Murray @Olamide Kolawole @Kevin Day

Review updates to Olamide’s tool. What else needs to be added for MVP / completing the subgroup?
- Multi-licensed dependencies? This is handled already in Maven.
- JS modules? Olamide expects by the group’s next meeting (although he will be absent that week). Will handle the multi-license case if available in package.json.
- Other backend languages? (Or for MVP, should we list these as exceptions to requiring the tool for now?) Group agrees.
- GitHub Action integration to run it. Pointing at a specific tag/commit specified in the module evaluation template. Olamide expects this by the next meeting he’s available (10/23).
- That should do it for MVP!
Review license list management PR and decide how to schedule it on the recurring calendar.
- Consensus: good to merge.
Review short-term TCR PR to prohibit any more LGPL dependencies for now.
- Consensus: looks good. Someone will approve and I will merge. Need TC approval first.
Review second TCR PR to reference and require the TC Module Eval tool.
- Consensus to flip the change, make the tool optional (for supported languages) for 6m. Then to required.
Review our original deliverable list of Q&As. How do we wrap that up as a deliverable?
- Maccabee wants to complete some items in the process section now that we have one. @Maccabee Levine
- Clean out some of the notes on person assignments, and other distraction. @Kevin Day will take a crack at this with @Peter Murray 's assistance.
- Consensus to deliver the document as the result of the subgroup’s process, but not to ask TC approval and make it an official doc unless they ask for that.
- Exception: The part about “Why ASF”.
  - Copy out of the working document into the process doc itself, possibly distill down, but still explain a) why we care about what ASF says at all, and b) if so, why make an external copy. @Peter Murray
How do we distill and/or preserve the LGPL documents for CC/legal?
- Export the two docs and add them to this wiki space under Licensing Subgroup. “3rd Part Dependencies Using LGPL 2.1 in FOLIO” and “Questions Regarding LGPL 2.1 in FOLIO“. @Kevin Day

2025-10-02

Attendees:

Review Olamide’s tool: https://github.com/folio-org/tech-council/pull/105
- Great tool!
- GHA – are there limits for the folio-org? No, no charges on open projects.
  - You would go to the Actions tab of this repo, enter the URL of the repo you want to evaluate. Would show the output files in the artifacts section within GHA.
- Olamide will move it to a separate repo.
- Kevin: convert from npm to yarn?
- Olamide will build in the front-end module evaluation also.
- Maccabee will rewrite process doc to reference this tool.
  - PR to the tech council eval template to reference the tool, or a doc on how to use the tool
  - Turn the process for maintaining the list of licenses into a TC Decision Record.
    - Add to the DR the point about no more exceptions until after CC / legal eval.
WOLFcon discussion with CC / next steps.
- CC had good comprehension of the concerns.
- CC did vote to endorse recommendation to TC not to add new LGPL dependencies.
  - The Community Council endorses a recommendation to Technical Council not to add new LGPL dependencies. CC will contact OLF to obtain legal counsel on this topic (see Questions Regarding LGPL 2.1 document).
  - CC recommends that the Foundation review this issue with member projects and coordinate the need for legal representation.
- One CC member was concerned about any public statement for/against a license exception. No legal claims/opinions, no public decisions until we get legal advice.
- How do week keep this legal consult issue in front of TC after the subgroup?
  - Add something to the TC recurring calendar!
Julian mentioned at TC that Hibernate now supports Apache license in newest versions. That was the biggest exception issue.
Upcoming meetings:
- October 9: All available.
- October 16th? Olamide will be out. The rest of us available.
- October 23: All available.

2025-09-18

Attendees: @Maccabee Levine @Peter Murray @Olamide Kolawole

Do we have consensus based on Kevin’s LGPL doc, that the exceptions are reasonably justified for the short term (until CC or legal weighs in).
- Some think yes, we think existing three exceptions are defensible (until we have legal guidance).
- Others think maybe, depending how the project actually uses the modules.
- Others think not justified, but project has no other choice at the moment, needs CC to decide on risk vs engineering effort to find alternatives (if that’s even possible).
- But any way around it: consensus that we don’t want to expand the exceptions further until that legal consult.
Can CC, with Peter’s leadership, discuss this constructively at WOLFcon breakout on Friday?
- Peter will lead this!
- If we allow the LGPL exceptions, what forces would push on the other side of that? What are the risks, and to whom – project, hosting providers, etc.?
Fork in the road: Do we keep trying semgrep (beta for server access, JS discussion for FE modules)? Or pivot to Olamide’s tool and pause subgroup until it’s available for eval?
- TC would need policies that all projects would need lock files. i.e. also for Go (and JS), and a big discussion.
- Olamide believes his tool would cover what we need. (Also trying to automate parts of the module eval.) Rewriting it in typescript. Will be added to the tech-council repo where we have the criteria today. May be able to run as a GHA instead of Jenkins. Can slap a front end in front of it for non-technical folks to run.
  - Tool does: What license are allowed or not, and what are the exceptions.
  - Can tool look at nested dependencies? Depends on the language. Maven has tools to do, Gradle also. With JS, just looks at top-level dependencies, but can invoke tools to do that also.
  - Can the tool include or exclude the peer and dev dependencies? Yes, right now ignoring both.
  - We could document based on language X what the tool does as-is, or whether additional work is needed by the reviewer.
    - But ideally the tool should take care of nested dependencies in any language, if those are needed.
  - Olamide will build this “FOLIO Module-Eval” tool, whether or not it’s used for license part, because of other purposes.
  - We could recommend (not mandate) this tool. BUT if someone used a different tool or did so manually, it would need to use the same list of allowed/disallowed licenses.
    - So we’d need a list of those allowed/disallowed licenses – either as part of the tool or separately – just in case someone uses another tool.
- Consensus to pause (not end) semgrep investigation for licenses, until we can evaluate Olamide’s tool when it’s available. (And eventually the beta will end, and may expand to include other languages.)
Review semgrep management proposal. Most could be applied to Olamide’s tool as well.
Meeting calendar going forward?
- By two weeks from now (which is our next subgroup meeting), Olamide believes he will have something to show by then.

2025-09-11

Attendees: @Maccabee Levine @Kevin Day @Peter Murray @Olamide Kolawole

Report back from CC re: LGPL. Timing of those answers? Is it necessary or possible to (partially?) separate LGPL-specific issues from our larger subgroup goals / timeframe?
- CC scheduling some time at WOLFcon Friday meeting to discuss.
- Timing of LGPL answers? Process to get answers remains to be seen, unknown to us so far, legal council or ?.
- Can we decide on the exceptions at least as part of this subgroup? We may have enough to have reasonable justification at this point, pending the clarification. Some concerns, but nothing outright saying we’re contrary to FOLIO’s defined values.
  - Consensus provisionally agrees, but we’ll all read again before next week to see if we agree.
  - What if new exceptions are requested in the meantime? Lean against approving, so we have less remediation to do later if it’s a problem. Hold off on this pending the above question.
Report back from Security Team about semgrep.
- Based on the answers, we had consensus that semgrep would be a good solution if we can get it to work across all folio-org repositories, not the ~40 repositories it reports on currently. Per Julian’s explanation, the issue is likely lock files: “The current configuration of the supply chain analysis requires that the module has a lock file committed to the GitHub repository. We haven’t enabled the beta feature that allows Java, C#, Kotlin, and Python code without a lock file.”
- @Maccabee Levine will continue to work on determining if semgrep can work for us.
- @Olamide Kolawole will work on connecting his tool to a jenkins workflow, so it can be run without developer skillset. (Not something that will be accomplished in the next two weeks.) This should be a good alternative solution.
- Everyone will review the draft process to use and manage semgrep.

2025-09-04

Attendees: @Maccabee Levine @Olamide Kolawole @Kevin Day @Peter Murray

Review questions for CC/legal
Review semgrep questions to Security Team
Questions re: other tools

2025-08-28