Security Scan (SIAX Cloud) / security (push) Successful in 15s
CI (SIAX Cloud) / security (pull_request) Successful in 16s
Security Scan (SIAX Cloud) / security (pull_request) Successful in 20s
CI (SIAX Cloud) / security (push) Successful in 29s
CI (SIAX Cloud) / quality (push) Successful in 36s
CI (SIAX Cloud) / integration (pull_request) Successful in 37s
CI (SIAX Cloud) / integration (push) Successful in 49s
CI (SIAX Cloud) / quality (pull_request) Successful in 51s
Certifieringslanan (BI-P147) hittade det; jag verifierade det oberoende mot LICENSE-filen vid respektive git-tagg 2026-09-07: v0.208.1 Business Source License 1.1 — source-available, INTE öppen källkod v0.209.0 Apache License 2.0 dbt Labs licensierade om MetricFlow vid 0.209.0. Den gamla pinnen låg alltså exakt en patch under gränsen. För en självhostad plattform vars hela premiss är att inte ha ett proprietärt runtime-beroende är det en licensdefekt, inte en smaksak: BUSL begränsar produktionsanvändning fram till sitt change date. Notera metodpunkten: PyPI redovisar INGET licensfält för någondera versionen, så en metadatakontroll hade inte hittat något. Skillnaden syns bara i LICENSE-filen vid taggen. Ny grind: `tests/unit/metricflow-licence.test.ts` asserterar att pinnen ligger på eller över `METRICFLOW_FIRST_OPEN_SOURCE_VERSION`, och — som negativ kontroll — att alla tre kända BUSL-versionerna (0.207.3, 0.208.0, 0.208.1) faktiskt förkastas av samma jämförelse. Utan den andra assertionen hade den första kunnat passera med en jämförelse som inte diskriminerar. Detta gör INTE MetricFlow verifierad: `providerReadiness()` returnerar fortfarande `verified: false`, ingen supply-chain-granskning är gjord och providern har aldrig körts (ingen Python-runtime är provisionerad). Att laga licensen är inte samma sak som att bevisa komponenten. typecheck rent, 2/2 tester gröna. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>