Pravni aspekti korišćenja open-source koda — ako želite da izbegnete problem pratite ovu check-listu

Zaista je važno da se uvek pročita licenca kada koristite open-source softver.

Tijana Žunić Marić
24/11/2017

I am a lazy person, which is why I like open source, for other people to do work for me.

Linus Torvalds

Bez obzira na to da li ste zaista lenji ili samo želite da se fokusirate na kreiranje nečeg inovativnog uz korišćenje već utabanih prečica, u svakodnevnom radu programera uobičajeno je da razvoj softverskih proizvoda olakšavaju i ubrzavaju opensource biblioteke (od npr. biblioteka za obradu slike, biblioteka za filtriranje podataka, Big Data analize, full-stack frameworka, do mašinskog učenja).

Milioni komponenti opensource koda se skinu svake godine sa interneta kako bi pomogli savremeni razvoj softvera. Dakle, nema nikakve sumnje da je opensource ekosistem daleko odmakao od grupe entuzijasta koji se bore protiv predatorskog zaključavanja komercijalnog softvera i da je za mnoge sada već postao mainstream. Najbolji dokaz za to je činjenica da se neke od najpopularnijih tehnologija današnjice zasnivaju na opensource kodu (IoT, Healthcare, AI, Android).

Ipak, činjenica da je opensource softver (u daljem tekstu: OSS) besplatan, ne znači da njegovo korišćenje ne povlači određenu cenu. Zapravo, ukoliko koristite opensource biblioteke protivno njihovoj licenci, postoji mogućnost da niste platili na mostu, ali da ćete platiti na ćupriji.

Ok, hajde sada da krenemo od početka, kako bismo došli do uputstava koje treba da poštujete.

Koja je razlika između licenci vlasničkog softvera i OSS?

Softver, koji predstavlja „originalnu duhovnu tvorevinu autora”, zaštićen je autorskim pravom. Autor ili nosilac autorskog prava odlučuje o tome ko ima pravo da instalira i kopira računarski program, da ga koristi ili prodaje, da ga javno saopštava, modifikuje i unapređuje. Suštinski, komercijalni softver (softver namenjen za komercijalnu upotrebu kao što je prodaja) može da bude i vlasnički softver i OSS. Ipak, razlike između njih su suštinske.

Kod vlasničkog softvera (na engleskom „proprietary software”), licencom se kupuju određena prava, odnosno definiše se tačno šta je korisniku zabranjeno, a šta dozvoljeno da radi sa softverom. Ona, pre svega, treba da odgovori na pitanje kom kodu korisnik ima pristup – da li ima pristup samo mašinskom kodu (object code) ili ima pristup i izvornom kodu (source code).

Pravilo je da korisnik uvek može da pristupi mašinskom kodu, dok se pristup izvornom kodu posebno ugovara i nije karakterističan za, na primer, Saas (Softver as a Service) ili za programe koji podrazumevaju široku upotrebu i koje sami korisnici mogu prilagoditi potrebama (na primer, Microsoft Office). Osim toga, u ugovoru o licenci je definisano gde korisnik može da instalira softver, koliko puta može da ga instalira, da li može da ga kopira, modifikuje i distribuira.

Ukratko, licenca komercijalnog softvera polazi od zabrana i onda eksplicitno nabraja šta sve možete da radite sa takvim softverom.

Tipičan primer vlasničkog softvera je Microsoft, koji podrazumeva kupovinu više dodatnih softverskih licenci, kao što su Microsoft Windows operativni sistem, IIS web server, Microsoft SQL Server baza podataka i ASP.NET programski jezik.

Kod open-source softvera, autorsko pravo je okrenuto „naglavačke”.

Umesto da licenca nabraja šta vam je dozvoljeno, OSS licence nabrajaju samo ono što vam je zabranjeno. Drugim rečima, polazi se od toga da korisnik ima čitav niz prava, a tačno se definišu samo uslovi pod kojima može ova prava da uživa. U srži open source definicije su sledeće četiri slobode:

Dakle, OSS licenca garantuje ove slobode bez bilo kakve naknade autoru – vlasniku koda. Takođe, za razliku od vlasničke licence OSS licenca nužno podrazumeva pristup izvornom kodu.

Tipičan primer kombinacije OSS tehnologija je Linux operativni sistem, Apache Web server, MySQL baza podataka i i PHP programski jezik.

Ipak, koliko god lepo zvučala činjenica da se ovakve tehnologije mogu dobiti besplatno, u opensource svetu egzistira niz različitih licenci, a samim tim i određeni broj zabrana na koje morate da pazite. Ključ jeste u razumevanju razlika između licenci.

Koje OSS licence postoje?

Svaka OSS licenca ima posebne uslove kako za korišćenje opensource koda, tako i za njegovu modifikaciju.

Organizacija koja nosi ime „Inicijativa za otvoreni kod” (na engleskom Open Source Initiative) sadrži listu OSS licenci, koje moraju proći kroz postupak odobrenja, jer moraju da poštuju sve zahteve open source definicije. Postoji više od 70 OSS licenci, ali 10 najpopularnijih se primenjuju u 90% slučajeva.

Ukoliko bismo hteli maksimalno da pojednostavimo objašnjenje OSS licenci, mogli bismo izvesti njihovu grubu podelu na:

  1. Restriktivne ili zabranjujuće (copyleft) licence, i
  2. Dopuštajuće ili permisivne (non-copyleft) licence.

Restriktivne ili copyleft licence garantuju svim korisnicima prethodno pomenute četiri slobode bez naknade, pod uslovom da taj opensource kod ili bilo koji program koji nastane upotrebom tog opensource koda garantuje iste uslove svojim korisnicima. Drugim rečima, ako je OSS zaštićen restriktivnom licencom, onda ne možete da ograničavate dalje korisnike da koriste taj kod ili njegove modifikacije. Četiri slobode postaju zauvek vezane za taj opensource kod.

Suština restriktivnih licenci je da izvorni kod bude javno dostupan, kako bi drugi programeri mogli da ga proučavaju, modifikuju i unapređuju, te da tako unapređeni softver ostane besplatan i dostupan celom svetu. Kada ne bi bilo copylefta, odnosno kada ne bi postojala zabrana da se takav softver komercijalizuje, vrlo brzo bi derivati tog softvera postali nedostupni svima, a korisnici tih derivata ne bi imali više mogućnost da takav kod slobodno koriste, kopiraju, distribuiraju ili modifikuju.

Namera je da restriktivna licenca motiviše programere, koji nisu orijentisani isključivo ka profitu, da unapređuju razna softverska rešenja. Pojedini važni programi (na primer, GNU C++ compiler) nastali su isključivo zahvaljujući njima.

Najpoznatija restriktivna licenca je GNU Opšta javna licenca (na engleskom: GNU General Public License, GNU GPL ili samo GPL) koju je sačinio Ričard Stolman.

Na primer, operativni sistemi u okviru Linuxa su zasnovani na GPL licenci. Ako biste, na primer, napisali kod i objavili pod GNU GPL licencom, drugi programer koji modifikuje vaš kod i želi da ga distribuira, morao bi da to uradi isključivo pod GNU GPL licencom. Drugim rečima, i originalni i novi kod moraju biti opensource. U suprotnom, drugi programer može da odgovara za kršenje vašeg autorskog prava.

Sa druge strane, dopuštajuće opensource licence korisniku softvera daju neograničenu slobodu da koristi, proučava i menja softver, a sadrže minimalne zahteve vezane za redistibuciju ovog softvera. Ukoliko je OSS koji koristite pod dopuštajućom licencom, izvorni kod možete da koristite i kao deo softvera zatvorenog koda ili softvera zaštićenog vlasničkom softverskom licencom.

Najpopularnije dopuštajuće licence su BSD, MIT i Apache. Na primer, poznati softverski paketi koji koriste jednu od verzija MIT licence uključuju Expat, Ruby on Rails, Node.js, jQuery itd.

Ipak, treba imati u vidu da podela nije potpuno crno-bela. Postoje i licence koje su između restriktivnih i dopuštajućih.

Na primer, GNU Manje opšta javna licenca (na engleskom: Lesser General Public License ili samo LGPL) je u osnovi restriktivna (kao GPL), ali dopušta da opensource kod pod ovom licencom bude vezan za vlasnički softver, što inače ne bi bilo dopušteno pod GPL licencom. Pošto se LGPL najviše koristi za biblioteke, moguće je da vaš kod sadrži opensource biblioteke, a da i sam ne postane opensource.

Ipak, imajte u vidu da to ne važi za samu izmenu biblioteke. Ako postoji njena nova verzija, ona se mora objaviti kao opensource.

U svakom slučaju, zaista je važno da se uvek pročita licenca kada koristite OSS.

Takođe, bez obzira da li se radi o restriktivnoj ili dopuštajućoj licenci bitno je da se ispoštuju zahtevi koji su naznačeni u takvoj licenci. Na primer, licenca može zahtevati da se unese ograničenje odgovornosti, ili da se naznači ime autora, ili da se opišu izmene na kodu pre njegove dalje distribucije i sl.

Poređenja radi, GPL, LGPL, Apache, BSD zahtevaju unošenje organičenja odgovornosti, dok GPL, LGPL, Apache zahtevaju da se opišu izmene na kodu pre njegove dalje distribucije, a što nije slučaj sa BSD.

Koje licence mogu biti problematične?

U načelu, bitno je da svaki programer vodi računa kako prilikom upotrebe OSS, tako prilikom modifikacije OSS, kao i prilikom objave koda pod OSS licencom. Imajući u vidu da neko može da vas tuži samo zato što niste ispoštovali zahteve u opensource licenci i imajući u vidu da bi sud u tom slučaju mogao da utvrdi da je došlo do kršenja autorskog prava, svaka licenca potencijalno može biti problematična.

Ipak, za potrebe ovog teksta fokusiraćemo se na problem koji može da nastane onda kada kombinujete OSS sa vlasničkim softverom. Naime, kada pišete sopstveni kod, ako budete koristili opensource kod ili opensource biblioteke koje su zaštićene restriktivnom licencom, vaš softver možda neće moći da bude vlasnički softver, već će postati OSS.

Drugim rečima, OSS restriktivna licenca može da ga „zarazi”.

Kada se smatra da je vaš kod zaražen OSS licencom?

Da biste znali da li je vaš kod zaražen potrebno je da analizirate na koji način su OSS i vaš kod povezani. U oko 80% slučajeva će odgovor biti očigledan, a u 20% će ovo pitanje bili složenije. Inače, ovo je tehnička stvar i ona bi podrazumevala da vaš programerski tim radi zajedno sa vašim pravničkim timom.

Dakle, nakon što ste identifikovali delove OSS u vašem softveru, uključujući i identifikovanje restriktivnih licenci koje se tako primenjuju, ovo je prvo pitanje koje treba da postavite:

Ako je odgovor odričan, dalje je potrebno postaviti sledeća pitanja:

Grafički prikaz analize:

Imajte u vidu da ako je svrha softvera koji razvijate samo interna, onda niste u opasnosti od kršenja opensource licence. Jedina opasnost za vas postoji ukoliko želite dalje da distribuirate softver kao vlasnički softver svojim klijentima/korisnicima, kada prethodna analiza za vas treba da bude ključna.

To-do-lista za korišćenje OSS

Da biste bili sigurni da ne kršite OSS licencu, te da vas ne može jednog dana iznenaditi tužba za povredu autorskog prava, potrudite se da na sva sledeća pitanja možete da odgovorite potvrdno:

  1. Da li pre korišćenja OSS svaki od programera pročita licencu i ispoštuje njene zahteve?
  2. Da li u firmi/organizaciji imamo predviđene procedure za korišćenje OSS? Da li imamo osobu koja je odgovorna za poštovanje tih procedura? Da li su svi nivoi naše organizacije upoznati sa procedurama?
  3. Da li imamo listu svih OSS biblioteka i listu svih komercijalnih biblioteka koje koristimo? Koliko često ažuriramo tu listu?
  4. Da li objavljujemo opensource sekvence našeg koda u skladu sa zahtevima OSS licence?
  5. Da li šaljemo neophodne licence i fajlove sa obaveštenjima kao što se zahteva u opensource bibliotekama koje koristimo?

Danas postoje automatizovana rešenja za identifikovanje sekvenci opensource softvera u vašem kodu, koja vam mogu značajno uštedeti vreme i smanjiti rizik prilikom korišćenja OSS.

Iako slabosti OSS nisu bile predmet ovog teksta, treba imati u vidu da pojedina istraživanja tvrde da je tokom 2016. godine 58.1 milion opensource komponenti skinuto sa interneta. Imajući u vidu i cirkulaciju ovih komponenti u novim sekvencama koda, nije iznenađujuće da i vaš kod možda ima jedan od identifikovanih nedostataka.

Uvođenje prethodno navedenih procedura, dakle, nije onda bitno samo sa pravnog aspekta, već i sa tehničkog. Ako na pravilan način vodite evidenciju o sekvencama OSS u vašem kodu, to će definitivno smanjiti sve potencijalne rizike i izdvojiti vas na tržištu.

Sada kada imate jasnija uputstva, na vama je da odlučite.

Tijana Žunić Marić

Objavio/la članak.

petak, 24. Novembar, 2017.

IT Industrija

🔥 Najčitanije

Anastasia Stojkovic

petak, 7. Decembar, 2018.

Moje razumevanje ove teme (ispravite me ako grešim – molim vas, značiće mi 😊) jeste da ukoliko je OSS pod restriktivnom licencom (GPL npr.) onda bez obzira da li u naš kod integrišemo ceo OSS ili deo OSS, naš kod pada pod OSS licencu. Isto tako nije važno da li je u pitanju modifikacija OSS ili ne. S tim da ako modifikujemo OSS u obavezi smo da modifikaciju i objavimo kako bi drugi imali prilike da je koriste. S druge strane, kod manje restriktivnih licenci (LGPL), koje se koriste uglavnom za biblioteke, pravi se razlikovanje kod statičkog i dinamičkog linkovanja biblioteka sa našim kodom. Ako je u pitanju statičko linkovanje, onda kod pada pod OSS licencu, a ako je dinamičko onda možda i ne. Opet, akcenat u mom komentaru je na copyleft licencama. Permissive licence su druga priča, imaju mnogo manja ograničenja i mogu se koristiti za komercijalni softver.

Milan Markovic

četvrtak, 6. Decembar, 2018.

Odlican clanak. Medjutim, kao programeru mi nije najjasnije na sta se misli pod "sekvenca OSS ugradjena u kod". Da li to znaci da se delovi OSS bibiloteka ne smeju koristiti unutar sopstvenog koda, dok je koriscenje cele biblioteke kao takve (as is), bez modifikacija, dozvoljeno?