Lisensetterlevelse i M&A: hva due diligence-team faktisk trenger

Lisensrisiko er avtalerisiko. Udeklarert copyleft, manglende attribusjon eller en offentlig side som ikke lenger matcher builden, kan bli holdbacks, prisnedslag eller remediation-programmer etter closing.

Kjøpere spør fordi de arver produktene som leveres og forpliktelsene som følger med. Selgere som allerede vedlikeholder en gjennomgått oversikt, svarer raskere og med færre overraskelser.

• Bekreft hvilke produkter og release-linjer som er i scope for avtalen.
• Identifiser copyleft, nettverks-copyleft og proprietære SDK-vilkår tidlig.
• Skill sikkerhetsfunn fra lisensoffentliggjøring. Due diligence trenger ofte begge, men det er ikke samme leveranse.
• Spør om registreringen er knyttet til det som faktisk leveres, ikke bare et scan av markedsføringssiden.

Due diligence-klart bevis er en gjennomgått oversikt for hvert produkt i scope, frosset ved en kjent publisering, med full lisenstekst og attribusjon der det kreves. En kjøpervendt attesteringsside pluss matchende eksporter er den vanlige formen.

En innlimt lockfil, en ikke-gjennomgått SBOM eller en NOTICE-fil fra for tre år siden er input, ikke bevis. Bevis betyr at noen godkjente fremstillingen før den forlot huset.

• Produktavgrenset oversikt (direkte og transitive etter deres policy).
• Menneskegjennomgåtte lisens-ID-er og vedlagt full tekst.
• En stabil URL eller eksport generert fra samme godkjente snapshot.
• En klar angivelse av hvilken release eller dato registreringen dekker.

De fleste brannslukkinger starter fra de samme hullene. Oppdag dem før data room-forespørselen lander.

Ingen av dem betyr at avtalen faller. De betyr at noen må bygge en forsvarlig registrering på nytt under tidspress.

• Udeklarerte eller uavklarte GPL-, LGPL- eller AGPL-komponenter i builds som leveres.
• Utdaterte NOTICE- eller attribusjonsfiler som ikke matcher gjeldende lockfil.
• En SBOM behandlet som ferdig offentliggjøring, uten gjennomgått lisenstekst.
• Ett regneark som dekker flere produkter uten per-produkt-scope.
• Offentlige sider eller eksporter som ikke kan spores til en publiseringsgodkjenning.

Bygg pakken fra samme løkke dere allerede bør kjøre for kunder: importer det som leveres, gjennomgå det, publiser, og eksporter deretter. Finn ikke opp en parallell due diligence-only-prosess uken før signering.

Når kjøperen ber om både en URL og filer, generer begge fra ett frosset snapshot, så data room ikke inneholder motstridende versjoner.

En vedlikeholdt etterlevelsesside og matchende eksporter er infrastruktur for due diligence, ikke en erstatning for juridisk rådgivning. Høyrisikolisenser, spørsmål om outbound-distribusjon og avtalespesifikke indemnities krever fortsatt juridisk gjennomgang.

SourceTrust hjelper team med å holde den operasjonelle registreringen oppdatert, så advokater argumenterer om de få vanskelige sakene, ikke om manglende oversikt.

Vanligvis ikke alene. En SBOM identifiserer komponenter. Due diligence trenger fortsatt gjennomgåtte lisenser, full tekst og et klart produktomfang. Behandle SBOM-en som importen, og fullfør deretter gjennomgang og publisering før dere deler.

Per produkt: en aktuell gjennomgått oversikt, en attesterings-URL eller tilsvarende offentliggjøring, og eksporter fra samme snapshot. Å vite hvilken release hver fil dekker, sparer dager når data room åpner.

Be om produktavgrenset bevis knyttet til buildene i avtalen: en vedlikeholdt side eller offentliggjøringspakke, matchende SPDX eller CycloneDX hvis påkrevd, og bekreftelse på at copyleft-rader er gjennomgått. Unngå å godta ett udatert regneark som komplett.