| | | |
|---|
1 min | Scribe | | @Kevin Day followed by @Maccabee Levine Reminder: Please copy/paste the Zoom chat into the notes. If you miss it, this is saved along with the meeting recording, but having it here has benefits. |
| Licensing Subgroup | @Maccabee Levine | Subgroup has documented the use of Olamide’s FOLIO Module Evaluator tool. TC Module Eval PR #3 on how the list of licenses should be managed. PR #109 recommending the tool for use during a trial period PR #110 requiring the tool’s use (for TC review next April/May).
|
| Meeting Notes | | Trickier aspects of this are passed to the legal council. Olamide wrote a tool that is demonstrated during the meeting. https://github.com/folio-org/tc-module-eval The goal of the tool is to automate the parts of the module evaluation that are not practical to do by hand. Ideal future situation is to have a Jenkins job, or something like that, to run this across modules after evaluation has passed. This is intended to provide information to assist module developers and does not block anything. The runtime speed is approximately 2 minutes.
There are different ASF categories of licenses that can change at any time (TC Module Eval PR #3). The bulk of category B are weak copyleft licenses that are okay but must be documented in the README. We are cloning those categories, so we need to maintain a process of staying up to date with the ASF categories. The ASF utilizes Git, which helps make detecting changes to their policy easier. Where would the last review date be stored?
The trial period and PR #109 . After the trial period and PR #110 . The Q&A/FAQ page for third-party dependencies (PR #111). The Recurring calendar describes a date to periodically check with the CC about whether or not they received a response from the legal advisors. How often are 3rd-parties changing their licenses (particularly when they may change to an incompatible license)? This does not happen too often (tends to be rare). The licenses are generally tied to specific versions. Kevin points out that we had the opposite where an incompatible license change to compatible (Hibernate going from LGPL to Apache2). Julian points out that a third party dependency might switch their dependencies (a transitive dependency from our perspective). We as a project should do a complete scan of all components before an official release to ensure that everything has been checked at least once before a release. Maccabee points out that the license subcommittee agreed with this but we were not certain as to how often this must happen. In the short term, the transitive (nested) dependencies are enabled. If we did this across all existing modules, but the transitive dependencies might reveal a lot of problems (that might potentially be false positives). What is the likelyhood of a development teams to do this scan periodically? This lack of centralized scanning could lead to weak enforcement. Zak points out that it would be too big of an ask to review every one of these on every single PR. It might be a waste of time if not everything is relevant. Changing a package.json or yarn.lock might help us identify (help trigger) and handle these cases with less effort. This would be straight-forward. Olamide points out that up until now the 3rd-party licenses has not been enforced. We need action items to help us fix these as they come up. There is a good chance of push back from the teams if they are told they must rewrite their code to remove disallowed 3rd-party dependencies.
The license sub-committee will meet again to handle any action items that came out of this meeting.
|
NA | Zoom Chat | | Craig McNally 10:23 AM (Edited)
I figured I'd share this as it gives some perspective on scope. Snyk is reporting > 50k dependencies
Shelley Doljack 10:23 AM
I need to step away for a bit.
I’m back now. |