Lär dig
Den lättbegripliga guiden till efterlevnad av tredjepartslicenser
Vad open source-licenser faktiskt kräver, hur reglerna visar sig i verkliga produkter, och hur du tar fram en redovisning du kan försvara. Skriven för dem som besvarar diligence under tidspress, inte för jurister.
Börja här
“Open source” är inte ett tillstånd att leverera. Det är ett avtal.
Varje bibliotek, typsnitt, ikon och SDK du bundlar kommer med villkor: Meddelande, attribuering, ibland copyleft. De är standardiserade, offentliga och verkställbara, ofta utan att någon i teamet har läst dem. Här är de tre antaganden som kostar team mest.
“Det är open source, vi kan leverera det.”
Permissiva licenser kräver ändå upphovsrätts- och licensmeddelanden i distributioner. Copyleft kan kräva källkodserbjudanden. Aldrig en fotnot på en wiki.
“Vi är SaaS, licenser gäller inte oss.”
Vissa skyldigheter är lättare vid ren nätverksanvändning, men långt ifrån alla. Typsnitt, installationsprogram och medföljande tillgångar bär fortfarande skyldigheter, och köpare frågar fortfarande.
“npm update är bara en patch.”
En versionsuppdatering kan ändra den faktiska licensen eller lägga till copyleft. Rutinuppdateringar är det vanligaste sättet som efterlevnaden brister obemärkt.
01Vilka reglerna är, och var de gäller
Alla ämnen om licensefterlevnadGrunderna
- Vad som faktiskt ackumuleras i en produktHundratals paket, typsnitt, ikoner och SDK:er, och de utlösande faktorer som tvingar team att äntligen ta en titt.
- Meddelande, attribuering och fullständig textTre olika skyldigheter granskare kontrollerar, och den vanligaste luckan på licenssidor.
- Copyleft, utan den juridiska föreläsningenVad GPL, LGPL och AGPL faktiskt kräver att du omsätter i praktiken innan du levererar.
- Vem som äger skyldighetenUtveckling, juridik och produkt, och när licensskyldigheter gäller för din organisation.
- Var skyldigheter dyker uppWebbplatser, mobilappar, skrivbordsinstallerare och inbyggda produkter bär alla olika skyldigheter.
- Vad det kostar verksamhetenFörsenade affärer, oväntade revisioner och falsk trygghet när ingen äger det som levereras.
- Juridiska konsekvenser i praktikenFörelägganden, skadestånd och tvingad redovisning från verkliga rättsfall om licensverkställighet.
- Licenssidan förklaradVad en köparvänd licenssida måste innehålla, och varför ett kalkylblad inte räcker.
02Var efterlevnadsprogram inte räcker hela vägen
Alla regulatoriska ämnenRegelverk och SBOM
- Täcker SOC 2 eller ISO 27001 det här?Nej. Här är det exakta gapet mellan ett säkerhetscertifikat och licensredovisning.
- EU:s cyberresiliensaktVad CRA:s dokumentation kräver jämfört med den licenssida diligence ändå förväntar sig.
- SBOM jämfört med en licenssidaVarför en maskinläsbar komponentlista inte är samma sak som granskad redovisning.
- Licensfrågor i frågeformulärHur du svarar utifrån en granskad, produktavgränsad förteckning, utan att överdriva.
03Steg för steg, när du är under tidspress
Alla guiderGuider
- Checklista för licensefterlevnadVad ni ska verifiera på inventering, text och attribuering innan ni delar en URL.
- Vad inköp faktiskt efterfrågarKontinuerligt bevis, varför exporter blir inaktuella, och hur du svarar när beroenden ändras snabbare än pappersarbetet.
- Granska en förteckning före publiceringEn praktisk ordningsföljd från import till godkänd publicering, utan att hoppa över några grindar.
- Från SBOM till en licenssidaOmvandla CycloneDX eller lockfiles du redan genererar till en granskad redovisning.
- Licensefterlevnad i M&ADue diligence-redo bevis: attestationssida, SPDX, CycloneDX och PDF från en snapshot.
Läser på för att någon bad om bevis?
Hoppa över brandövningen. Importera din förteckning och se var du står, gratis, på minuter.