License fixes

A license finding is answered by approving the license, by allowing it in one product with a reason, or package by package: replacing one and keeping another. License fixes let Taiga do the replacing, and take care of an obligation the approved licenses still carry. Both end in an initiative in the product’s backlog, which Taiga plans and builds like any other. A person reviews the plan before anything is built, and the change lands as a pull request.

Decide one package at a time

The packages under one license rarely want the same answer. A direct dependency that ships to your users can be replaced, while one a framework brings in at build time is better kept. On a license’s page, each package has its own controls while the license needs a decision and you can change the product. The page lists every package the license decides, one row each, however many versions or lockfiles hold it. A package licensed under an expression that includes the license, such as MIT AND MPL-2.0 when MIT is approved, is listed on the page of MPL-2.0, with the same controls.

• Replace raises an initiative for that package alone, one for each repository that holds it, and opens it. The initiative leaves the license’s other packages as they are, so several can run side by side. The license stays open, and the row links the fix.
• Allow this package, in the row’s menu, keeps the package in this product with a reason you give. Who allowed it, when and why stay in the license’s activity and the audit log. Undo allow on the same row brings the question back.

Allowing a package holds for that product and that license only. The license stays off your approved list, the other products using it are not affected, and a new package under it in this product is still raised.

A fix is judged by the inventory, not by the merge. After the pull request merges, the row waits for a sweep of the default branch. When the package is gone, the row goes with it. When a newer sweep still lists it, the row says so and offers Replace again.

The page says how many packages are left to decide. Once every package left under the license is allowed, it no longer needs a decision, and its finding closes as allowed.

Replace every package under a license

On a license’s page, the menu beside Allow in this product holds Replace all, with the number of packages it takes. It appears while more than one package is left and one of the license’s findings in the product is open. A package you allowed is not among them, and while one package has its own fix under way, replace the others from their rows.

One click raises an initiative for each repository that holds an open finding of the license, queues it, and opens it when there is one. The findings move to being fixed, and the initiative carries them from there. While it does, the Licenses tab and the license’s page show the fix under way and link its initiative, and the license is not counted among those to decide.

The initiative states what must be true when it is done:

• The packages Taiga reports under that license are no longer installed in the repository. A package you allowed stays. Each one is replaced by another package, or another version of it, or removed where the product no longer needs it.
• The replacement’s license, and the licenses of what it brings in, are all on your approved list. A permissive package that pulls in the same copyleft one fixes nothing.
• Nothing is copied or rewritten from the replaced package’s source, because code derived from it keeps its license.

It lists the packages under the license with their versions, where each is declared, and the package that brings it in when the repository does not declare it directly, together with your approved list. The plan says what the code uses from each package and which alternatives it compared, and you review it before the build starts. The approved list itself is never changed: approving a license stays a decision a person makes on the Licenses page.

When only build tools carry the license

When every package under the license is a build or test tool, nothing under it reaches your users, and allowing it in the product is often the better answer. A replacement then has to be a maintained package that does the same job; code written over another package’s internals does not count. When none does the same job with about the same API, the plan takes the closest one and says what changes for the product. The plan’s first step says that only build tools carry the license, so you can weigh the replacement against allowing the license when you review it. To allow it instead, cancel the initiative and choose Allow in this product on the license’s page.

When the finding closes

Merging the pull request does not close the finding. It goes back to open, and the next sweep of the default branch decides: the finding is resolved when no package under the license is left, and stays open when one is. A merged change cannot mark a license as gone that is still installed.

Ship notices with a web frontend

Licenses such as MIT, BSD, ISC and Apache-2.0 ask for their copyright notice and license text to go with the code. A web frontend sends its dependencies to every visitor’s browser, and minifiers drop license comments unless told to keep them.

The Licenses tab of Maintaining offers Ship notices where Taiga’s inventory finds Vite declared in one of the product’s repositories, and that repository does not already declare a notices collector. Taiga knows rollup-plugin-license, vite-plugin-license and rollup-license-plugin. A collector declared says the tool is there, not that the notices page is, so nothing in Taiga calls the notices shipped. One click creates an initiative, queues it and opens it. While one is open, the button opens that one instead of creating another. When it is built, every production build of the web app:

• writes a notices file for every bundle it serves to the browser, listing each third-party package in it with the LICENSE and NOTICE files the package ships, as a maintained collector writes them (rollup-plugin-license with Vite),
• lists a package that ships no license file with the license it declares, its author and its repository,
• copies, unchanged, the notices a package keeps for the projects it bundles in a file of its own (such as ThirdPartyNotices.txt),
• keeps the bundle’s license comments in the minified code,
• and shows the notices on an Open source licenses page at /legal/open-source, linked from the footer.

Nothing in the build fails or warns because of a package’s license, whatever the package declares.

Build tooling and test tools that stay out of the bundle, and packages marked private, are not listed, and server-side code is left alone. A development dependency whose code is bundled reaches the browser, so it is listed. The initiative adds no license check, copy of your approved list or SBOM to the repository: Taiga keeps the approved list, checks every package against it, and produces the SBOM. Anything already in place stays; the initiative changes only what is missing.

From an AI tool

These are available through the Taiga MCP server:

• taiga_fix_finding on a license finding the row marks fixable replaces the packages under its license in that finding’s repository. The row’s fixNote says why one is not fixable: a fix already under way, or a finding that is not open.
• taiga_replace_license_package replaces one package under a license, and hands back a fix already under way (raised: 0).
• taiga_allow_license_package allows one package in the product with a reason, or undoes that (action: undo). taiga_list_packages says on each row whether the package is allowed and how its fix stands. With licensePage, it lists every package the license decides, including those under an expression that includes it. Both are in the setup toolset.
• taiga_ship_notices raises the notices initiative for a product, for a key that may change the product and its backlog, and hands back the open one when there is one (created: false). It is in the setup toolset.

They raise the same initiatives as the buttons, and their plans wait for review the same way.