Provjera open-source komponenti kod kupovine društva: popis licenci, SBOM, obim copyleft obaveza, sanacija prije closinga i zaštita u SPA ugovoru.
BRANDAUER Rechtsanwälte
Salzburška kancelarija za gospodarsko, kompanijsko i transakcijsko pravo
Iza svake transakcije stoji uigran tim odvjetnika, pravnika i stručnjaka. Pitanja vezana za kupnju poduzeća zajedno gledamo kroz strukturu, ugovor, poreze i odgovornost.
Nepotpun popis open-source komponenti u tehnološkoj transakciji može biti više od nedostatka u dokumentaciji. Može utjecati na prava na proizvod, obaveze u vezi s izvornim kodom i pregovaračku poziciju kupca kod kupovine društva.
Zato nije dovoljna samo automatska lista paketa. Kupac treba spojiti korištene verzije, stvarne tekstove licenci, tehničko uklapanje i način distribucije ili dostupnosti proizvoda. Tek se iz tog spoja može procijeniti copyleft rizik.
Ovaj tekst produbljuje širi pregled kupovine software ili SaaS firme i odvaja provjeru licenci od opće IP i IT dubinske analize.
SBOM je početna tačka. Provjerite tekst licence, verziju, način uklapanja, distribuciju i planirano korištenje nakon closinga.
Već znate da želite poslati upit? Idite direktno na obrazac za upit.
SBOM je početna tačka. Provjerite tekst licence, verziju, način uklapanja, distribuciju i planirano korištenje nakon closinga.
Sačuvajte provjereni popis komponenti kao prilog data roomu i u SPA ugovoru odredite koje licence, napomene i ponude izvornog koda moraju biti dostupne do closinga. Za svaku copyleft komponentu ponovo provjerite da li konkretno korištenje i distribucija odgovaraju tekstu licence.
Ne pokrivajte neizvjesnost općim jamstvom. Napravite verzionirani popis, sačuvajte tekstove licenci i provjerite pogođene komponente i njihovo uklapanje. Zavisno od rezultata, mjere mogu biti zamjena, odvajanje, dodatna licenca ili dokumentovana ponuda izvornog koda.
Koristan popis sadrži najmanje paket, tačnu verziju, porijeklo, SPDX oznaku, datoteku licence, napomene o autorskim pravima, zavisnosti i upotrebu u proizvodu. SBOM može pripremiti te podatke, ali ne zamjenjuje provjeru artefakta koji se stvarno isporučuje.
Uporedite manifest datoteke, lockfileove, build slike, containere, plugine, vendorizovane biblioteke i izvorne repozitorije. Ako tekst licence nedostaje ili se isporučena verzija razlikuje od popisa, taj nedostatak treba jasno evidentirati u data roomu.
MIT licenca u pravilu dopušta korištenje, izmjene i distribuciju uz očuvanje napomene o autorskim pravima i teksta licence. Apache licenca 2.0 također daje široka prava, ali sadrži zahtjeve za tekst licence, napomene o izmjenama, autorska prava i NOTICE informacije te posebno formuliranu patentnu licencu. Te obaveze moraju ostati dostupne u proizvodu i materijalima za distribuciju.
GPL 2.0 dodatne zahtjeve veže uz kopiranje, izmjenu i distribuciju programa ili djela zasnovanog na njemu. Kod distribucije objektnog koda u pravilu traži odgovarajući mašinski čitljiv izvorni kod ili dopuštenu alternativu. AGPL 3.0 dodaje pravila za izmijenjene programe s kojima korisnici komuniciraju putem mreže. Primjena zavisi od stvarnog teksta licence, izmjene i tehničke isporuke. Sam naziv licence nije dovoljan za opći zaključak.
Za svaku označenu komponentu treba utvrditi da li se koristi neizmijenjena ili izmijenjena, da li je statički ili dinamički povezana, da li radi kao odvojeni servis ili se distribuira zajedno s proizvodom. Naziv biblioteke ili microservicea ne rješava pitanje. Potrebno je tehnički i autorskopravno procijeniti način komunikacije i eventualno jedinstveno djelo.
Kod SaaS poslovanja treba razlikovati rad programa na serveru od distribucije korisnicima. Kod AGPL komponenti posebno provjerite situaciju u kojoj korisnici mrežom komuniciraju s izmijenjenim programom. Direktiva 2009/24/EZ i austrijsko autorsko pravo čine okvir zaštite računarskih programa, dok konkretne obaveze projekta i dalje proizlaze iz primjenjivog teksta licence i stvarnog korištenja.
Ne traži svako odstupanje istu reakciju. Moguće mjere su uklanjanje ili zamjena komponente, nadogradnja na odgovarajuću verziju, odvajanje servisa, ispunjenje obaveza u vezi s napomenama i izvornim kodom ili pribavljanje dodatne komercijalne licence. Tehničku odluku treba uskladiti s planom proizvoda, release planom i obavezama podrške.
Za svaku otvorenu komponentu kupac treba zabilježiti odgovornu osobu, trud, zavisnosti, rok i dokaz izvršenja. Rizik koji se može riješiti tek nakon closinga treba imati preciznu obavezu predaje i ne treba ga skrivati iza neodređenog jamstva. Provjera praznina dubinske analize pomaže da se urede nedostajući dokumenti i odgovornosti.
Katalog jamstava ne treba samo potvrditi da društvo ima prava na izvorni kod. Treba obuhvatiti popis komponenti, poznata kršenja, otvorene obaveze u vezi s napomenama ili izvornim kodom, zahtjeve trećih i promjene između signinga i closinga. Disclosure treba označiti pogođenu komponentu i vezu s dokazima.
Zavisno od nalaza, stranke mogu koristiti sanaciju kao uslov closinga, zadržavanje dijela kupoprodajne cijene, posebno obeštećenje, escrow ili obavezu otklanjanja nakon closinga. Opći katalog jamstava u SPA ugovoru i closing uslovi moraju odgovarati tehničkom planu mjera.
Bez općeg jamstva za open source: Izjava da su sve licence poštovane slabo štiti ako je popis nepotpun. Najprije osigurajte komponente, tekstove licenci i plan sanacije. Pretplatite se na pravne vijesti za nove tekstove i pravne informacije kancelarije.
Rizik najčešće nastaje iz spoja teksta, koda, arhitekture i transakcijskog ugovora, a ne samo iz naziva licence.
| Nivo | Pitanje provjere | Moguća posljedica za deal |
|---|---|---|
| Popis Koje se komponente i verzije stvarno koriste? | Usporediti SBOM, lockfileove i build artefakte | Dopuniti prilog data rooma |
| Licenca Koji puni tekst licence važi za ovu verziju? | SPDX podatke usporediti s LICENSE i NOTICE datotekama | Dostaviti napomene, tekst licence ili izvorni kod |
| Arhitektura Kako se komponenta uklapa ili pruža? | Procijeniti povezivanje, izmjene, granicu servisa i mrežni pristup | Sanacija, odvajanje ili dublja pravna provjera |
| Sanacija Šta mora biti završeno prije izdanja ili closinga? | Odrediti odgovornost, trošak i dokaz | Closing dokument, zadržavanje cijene ili obeštećenje |
| Ugovor Kako rasporediti preostali rizik? | Uskladiti jamstvo, disclosure i mehanizam zahtjeva | Posebno obeštećenje, escrow ili obaveza otklanjanja |
Procjena zavisi od primjenjive verzije licence, programa i načina korištenja. Automatska lista licenci ne zamjenjuje provjeru koda i ugovora.
Ne. SBOM je važna početna tačka, ali treba ga provjeriti prema stvarno isporučenim verzijama, punim tekstovima licenci, napomenama o autorskim pravima i NOTICE informacijama te tehničkom uklapanju.
Ne. Posljedice zavise, između ostalog, od izmjene, povezivanja i distribucije. Relevantni GPL tekst treba primijeniti na konkretan program i način isporuke.
AGPL sadrži dodatna pravila za izmijenjene programe s kojima korisnici komuniciraju putem mreže. Zato posebno provjerite rad servera, izmjene, interakciju korisnika i ponudu izvornog koda.
Treba zatražiti najmanje SBOM ili sličan popis, repozitorije, manifeste i lockfileove, LICENSE i NOTICE datoteke, release artefakte, interne potvrde te popis poznatih izuzetaka i otvorenih mjera sanacije.
Zavisno od nalaza mogu se koristiti disclosure, posebna jamstva, sanacija prije closinga, posebno obeštećenje, zadržavanje dijela kupoprodajne cijene ili obaveza otklanjanja. Klauzula treba označiti komponentu i potrebni dokaz.
Izvorni kod, ugovori, podaci i poslovanje u pregledu.
Provjera prava, licenci i promjene kontrole.
Obaveze proizvoda i sigurnosni procesi u transakciji.
Nalaze dubinske analize pretvoriti u ugovornu zaštitu.
Kod kupnje poduzeća odlučuju struktura, provjera i ugovor. Nazovite nas direktno ili nam pišite, povratni poziv u roku od jednog radnog dana.
Adresa
BRANDAUER Rechtsanwälte GmbH Giselakai 51 5020 Salzburg
Telefon
+43 662 6280000