– Oprogramowanie bazujące na otwartym kodzie staje się dojrzalsze zarówno technologicznie, jak i biznesowo. Wystarczy popatrzeć chociażby na sposób jego dystrybucji. Nawet amatorskie projekty zachowują uznane standardy odnośnie do licencjonowania czy wdrażania aplikacji. Przy czym nie jest to zmiana, która nastąpiła nagle. To proces trwający od kilkunastu, a nawet kilkudziesięciu lat – mówi Marcin Kubacki, Chief Software Architect w Storware.

Oprogramowanie open source stanowi podstawę wielu innowacji związanych ze sztuczną inteligencją, chmurą obliczeniową, jak również blockchainem. Na Linuxie opiera się praktycznie cały internet. Systemy operacyjne na licencji otwartej są obecne wszędzie: w biznesie, edukacji, w systemach transakcyjnych, a także w największych projektach naukowych, takich jak chociażby Wielki Zderzacz Hadronów. Inny przykład to rynek smartfonów, gdzie system operacyjny Android, bazujący na jądrze Linuxa, posiada niemal 80 proc. udział w rynku. Jak mówi Jim Zemlin, dyrektor wykonawczy Linux Foundation: „Linux to jedyne oprogramowanie, które zmienia się dziewięć razy na godzinę”. Jednak o ile do dominacji Linuxa w segmencie serwerów czy Androida na rynku smartfonów zdążyli się już wszyscy przyzwyczaić, o tyle w obszarze wirtualizacji następują istotne zmiany – systemy zamknięte tracą przewagę.

– Dekadę temu wybór VMware’a był odpowiedzialną decyzją. Obecnie sytuacja jest całkowicie inna. Mamy nowy trend, jakim jest konteneryzacja wypierająca wirtualizację. Aplikacje w kontenerach dają niespotykane możliwości skalowania, nieosiągalne dla systemów zwirtualizowanych, a także przenoszenia aplikacji, w tym do chmury oraz na brzeg sieci. Do obsługi kontenerów i aplikacji w kontenerach wybierany jest Kubernetes, który, jak powszechnie wiadomo jest projektem open source – tłumaczy Marcin Madey, Country Manager w polskim oddziale SUSE.

Spory potencjał tkwi w rozwiązaniach do przetwarzania brzegowego. Eksperci duże nadzieje pokładają w Embedded Linux, systemie operacyjnym przeznaczonym do obsługi urządzeń Internetu Rzeczy. W sprzedaży znajdują się już wykorzystujące Linuxa „inteligentne” telefony, lodówki czy termostaty w kaloryferach. Natomiast umowa SUSE z Elektrolitem pozwoli na tworzenie nowej generacji systemu operacyjnego opartego na systemie Linux dla autonomicznych pojazdów.

Jak widać, open source zatacza coraz szersze kręgi i już dziś zdecydowana większość firm z listy Fortune 500 korzysta z oprogramowania open source na takim czy innym poziomie. To rewolucja, którą tak do końca ciężko zrozumieć. Jak bowiem wytłumaczyć fakt, że działalność gospodarcza warta biliony dolarów opiera się na wysiłkach stosunkowo niewielkiej społeczności ludzi często wykonujących tę pracę bez bezpośredniego wynagrodzenia?

Liderzy w świecie open source

Rozwiązania open source posiadają ugruntowaną pozycję w wielu segmentach rynku. Oprócz systemów operacyjnych dla serwerów, gdzie prym wiodą komercyjne dystrybucje Red Hat i SUSE, a także smartfonów z Androidem, rozwiązania bazujące na otwartym kodzie szybko zdobywają nowe obszary IT. Od pewnego czasu w świecie nowych technologii toczy się dyskusja, czy konteneryzacja wyprze wirtualizację. Zdania na ten temat są podzielone. Niektórzy uważają, że kontenery i maszyny wirtualne będą się uzupełniać, z czym nie zgadzają się fani konteneryzacji. Jednak nawet uwzględniając dalszą koegzystencję obu technologii, trzeba się liczyć ze słabnącą pozycją wirtualizatorów z zamkniętym kodem źródłowym. Choć VMware vSphere lub Microsoft Hyper V nadal cieszą się popularnością, biznes coraz chętniej sięga po darmowe narzędzia do wirtualizacji serwerów, takie jak Red Hat Virtualization, Proxmox, oVirt, Virtuozzo czy Xen Server. Osobną kwestią jest ofensywa platformy Kubernetes, zyskująca akceptację wśród przedsiębiorców, dostawców usług chmurowych, a także producentów infrastruktury teleinformatycznej.

– W obszarze zarządzania infrastrukturą i oprogramowaniem największym zainteresowaniem cieszą się platformy i narzędzia służące do wdrażania, utrzymania i administracji oraz orkiestracji aplikacji uruchamianych w kontenerach. A zatem projekty takie, jak Kubernetes i jemu podobne, budowane na bazie, bądź jako rozszerzenie funkcjonalności Kubernetesa. Wśród nich znajdziemy na przykład Rancher, OKD czy OpenShift – mówi Adam Sokołowski, Business Development Manager w Simplicity.

Kubernetes jest dzieckiem Google’a. Inżynierowie tego koncernu opracowali go w celu zarządzania klastrami. Kilka lat później platforma trafiła pod skrzydła Cloud Native Computing Foundation. Kubernetes może pracować w środowisku lokalnym i chmurze publicznej. Platforma z poziomu jednej płaszczyzny kontroli wspiera automatyzację wdrożeń, skalowanie aplikacji, zarządzanie kontenerami, monitoruje procesy i zmiany. Przez długi czas bastionem rozwiązań zamkniętych pozostawały pamięci masowe. Jednak również w ich przypadku obserwujemy zachodzące zmiany. Takie programy open source, jak Ceph czy MinIO otwierają szerokie możliwości w zakresie przechowywania danych w postaci obiektów. Nie sposób nie zauważyć ekspansji baz danych open source NoSQL. Nierelacyjne bazy danych – w przeciwieństwie do klasycznych silników – pozwalają na szybką analizę danych nieustrukturyzowanych i badanie korelacji pomiędzy nimi. Wśród baz NoSQL największym powodzeniem cieszą się MongoDB oraz Apache Cassandra. Warto zauważyć, że kapitalizacja rynkowa MongoDB wynosi 25,5 mld dol., podczas gdy wartość Red Hata, kiedy był przejmowany przez IBM-a, wynosiła 20,5 mld dol.

Zdaniem integratora

Artykuł Open source, czyli „przezroczysty koń trojański” pochodzi z serwisu CRN.

Otóż nie i nie. To jedna z pułapek ideologicznego myślenia o open source. Twórcy tych licencji dbają o to, aby twórca opracowania (czyli nasz programista ze spółki A, czy raczej sama spółka) nie „zamknęły” kodu takich opracowań. Ale nie oznacza to, że zmuszają, aby kod zawsze pokazać publicznie, nie oznacza, że świat „zewnętrzny” ma zawsze roszczenia. Open source działa w relacji licencjodawca – licencjobiorca. Jeżeli udzielana jest licencja, licencjobiorca (i tylko on) może żądać dostarczenia kodu źródłowego. Jeżeli żadna ze stron takiej umowy nie jest zainteresowana udostępnieniem kodu źródłowego innym osobom, nie mają takiego obowiązku. Dopiero gdy spółka B rozpowszechni oprogramowanie, które nabyła, będzie musiała udostępnić kod źródłowy każdemu z użytkowników tego oprogramowania.

Mechanizm ten ma szczególną wagę w grupach kapitałowych. Jeżeli jedna ze spółek ma charakter tzw. CUW/Centrum IT i opracowuje rozwiązania dla całej grupy – choćby i tysiąca spółek – to każda z tych spółek ma prawo do otrzymania kodu, ale nie mają obowiązku jego pokazywania na zewnątrz. Mimo objęcia kodu licencją GPL można więc cały czas kontrolować know-how i tajemnice przedsiębiorstwa, jeżeli są zawarte w kodzie.

A teraz druga zagadka: ten sam programista (spółka A) mówi „hola, hola, ale tam jest pełno mojego kodu – udostępnię na licencji GPL tylko to, co jest pierwotnie na GPL, a to co opracowałem, na własnościowej, komercyjnej licencji”. Czy taki „hybrydowy” mechanizm ma szansę zadziałać?

Ma, ale rzadko. Wszystko zależy od tego, co i jak połączył programista. Nie każde użycie kodu open source, nawet na GPL, zaraża. To wyzwanie zarówno od strony prawnej, jak i architektury systemu, ale bywa i tak, że możemy zaprojektować rozwiązanie w ten sposób, by ryzyka zarażenia uniknąć (IP by design). Jednak GPL ma tę cechę, że w zarażaniu jest bardzo skuteczny. Żeby wytłumaczyć, jak ten mechanizm zarażania działa, potrzeba trochę teorii.

Interfejs między prawem autorskim a klauzulą copyleft

Ochrona praw autorskich do utworów nie ogranicza się do ich dosłownej treści. Nie miałaby ona sensu, gdyby po dokonaniu prostych modyfikacji można było korzystać z utworu bez zgody autora. Dlatego też prawo autorskie pozwala autorowi kontrolować również wykorzystanie utworów zależnych (adaptacji, tłumaczeń, aranżacji i innych zmian, określanych łącznie mianem opracowań). Na poziomie międzynarodowym zostało to uregulowane w art. 8 i 12 Konwencji Berneńskiej, a w UE w odniesieniu do programów komputerowych w art. 4 (1) (b) dyrektywy 2009/24/WE. Na poziomie krajowym jest ono traktowane albo jako odrębne prawo (najczęściej określane jako „prawo do adaptacji”) [1], albo jako część szerszego prawa do zwielokrotniania [2]. W każdym przypadku, gdy mamy do czynienia z utworem zależnym (opracowaniem), korzystanie z niego wymaga zgody nie tylko autora utworu zależnego (opracowania), ale także autora utworu pierwotnego (oryginału).

Prawo autorskie nie definiuje, czym jest opracowanie. Najogólniej rzecz ujmując, jego istotą jest „twórcza ingerencja” w dzieło twórcy pierwotnego. Każde opracowanie, w tym opracowanie programu komputerowego, jest więc wynikiem twórczości intelektualnej, w której występują obok siebie elementy twórcze zaczerpnięte z utworu oryginalnego, a także elementy twórcze dodane przez twórcę utworu zależnego. W świecie innym niż rynek oprogramowania to na przykład tłumaczenie „Harry’ego Pottera” czy adaptacja filmowa książek J.K. Rowling. Niby coś innego, literka w literkę nie ma sensu porównywać, ale gdyby nie oryginał, opracowania by też nie było.

Możliwość kontrolowania korzystania z utworów w postaci opracowania zapewnia klauzula copyleft. Z prawnego punktu widzenia, klauzula copyleft to zezwolenie na korzystanie z opracowania programu pierwotnego (oryginału), udzielone przez pierwotnego autora (autorów) pod warunkiem, że opracowanie zostanie również udostępnione na tych samych warunkach. Klasyczny przykład takiej klauzuli znajdziemy w GNU GPL 2.0, która stanowi w paragrafie 2 (b), że: „Musisz spowodować, że jakakolwiek praca, którą rozpowszechniasz lub publikujesz, która w całości lub w części zawiera lub jest pochodną Programu lub jego części, będzie licencjonowana jako całość bez opłat dla wszystkich stron trzecich zgodnie z warunkami niniejszej Licencji”. Na pierwszy rzut oka proste. Jednak trudność tkwi w udzieleniu odpowiedzi na pytanie, kiedy w przypadku software’u dochodzi do powstania opracowania. Spróbujmy przejść przez kilka scenariuszy.

Artykuł Open source: trochę dłuższa analiza (cz. II) pochodzi z serwisu CRN.

Jeden z podstawowych nurtów to fundacja Free Software Foundation, której celem, jak i celem stojącego na jej czele guru R. Stallmana, jest tworzenie i rozpowszechnianie „wolnego” oprogramowania („free software”),  a także prawne zabezpieczanie jego dalszej „wolności”, przy czym angielskie słowo „free” oznacza tu właśnie „wolność”, a nie „darmowość”. Zgodnie z Free Software Definition licencje na „wolne” („wolnodostępne”) oprogramowanie powinny zapewniać każdemu wolność: wykorzystania oprogramowania w dowolnym celu (również „komercyjnym”), badania oprogramowania i dostosowywania go do własnych potrzeb, rozpowszechniania oprogramowania w dowolny sposób, w tym również rozpowszechniania w zmodyfikowanej (dostosowanej, udoskonalonej) postaci. Jednocześnie w ramach FSF silnie akcentuje się ideologiczny sprzeciw środowiska programistów przeciw nadmiernie restrykcyjnym regulacjom prawa autorskiego i dotychczasowym „własnościowym” regułom udostępniania oprogramowania, którym towarzyszy zamiar izolowania poszczególnych użytkowników, ich podporządkowania i uzależnienia od dostawcy.

Jak podkreśla preambuła najbardziej znanej licencji stworzonej przez FSF: „większość licencji na oprogramowanie pomyślana jest po to, aby odebrać użytkownikowi możliwość swobodnego udostępniania innym i zmieniania danego oprogramowania. Natomiast w wypadku GNU General Public License (GNU GPL), celem jest zagwarantowanie użytkownikowi swobody udostępniania i zmieniania tego wolnego oprogramowania, a więc danie pewności, że oprogramowanie jest wolnodostępne dla wszystkich użytkowników”. Celem GNU GPL jest więc przełamanie przywilejów wynikających z praw własności intelektualnej, jakie przyznawane są twórcy w zamian za jego pracę, i zapewnienie swobody przepływu informacji dla dobra publicznego.

W najbardziej radykalnych wypowiedziach R. M. Stallmana i Free Software Foundation spotkać można opinię, że korzyści materialne nie powinny być jedynym czy głównym czynnikiem motywującym programistę do pracy twórczej. Wystarczającą motywacją powinna być sama radość tworzenia, możliwość samorealizacji czy zdobycia uznania. Ponieważ chodzi tu w pewnym sensie o odwrotność „copyright”, używa się tu terminu „copyleft”, a „wolne” oprogramowanie udostępniane na licencjach GNU GPL i zbliżonych, tj. gwarantujących jego „wolność” również w przyszłych wersjach, nazywa się „copylefted software”.

Idealizm Free Software Foundation, ironicznie określany mianem „informatycznego komunizmu”, nie jest podzielany przez wszystkich aktywistów open source. Przeciwnicy podejścia FSF podkreślają, że ruch open source ma znaczenie przede wszystkim jako alternatywa i uzupełnienie komercyjnych produktów informatycznych. Może on sprzyjać wzrostowi konkurencji na rynku, przełamaniu dominacji dużych producentów i promowaniu niezależnych standardów technicznych, w oparciu o które zarówno indywidualni programiści, jak i mali i średni producenci oprogramowania, mogą oferować własne produkty i usługi. Innymi słowy celem ruchu powinna być nie tyle „wolność”, co „otwartość” oprogramowania. Tak też cele open source postrzegane są przez Open Source Initiative (OSI) i drugą z czołowych postaci ruchu – E. S. Raymonda.

Zgodnie z opracowaną przez OSI definicją Open Source Definition program należy do kategorii open source, jeżeli licencja zapewnia: swobodną redystrybucję programu (zwielokrotnianie w celu udostępnienia osobom trzecim i rozpowszechnianie oprogramowania); dostęp do kodu źródłowego; swobodę modyfikowania i dokonywania opracowań; swobodę rozpowszechniania modyfikacji i opracowań programu; brak dyskryminacji jakichkolwiek osób lub grup osób; brak ograniczeń co do sposobu wykorzystania oprogramowania; objęcie licencją open source całości rozpowszechnianego programu, a nie tylko wydzielonej części; zakaz uzależniania udzielenia zezwolenia na korzystanie z programu od uzyskania licencji dotyczącej innego produktu; zakaz wpływania na sposób udostępniania i korzystania z innego oprogramowania (np. poprzez postanowienia umowne, że wszystkie programy rozpowszechniane na jednym nośniku muszą należeć do kategorii open source).

Bardziej pragmatyczne podejście Open Source Initiative jest źródłem rozbieżności pomiędzy FSF a OSI. Z praktycznego punktu widzenia różnice pomiędzy Free Software Definition a Open Source Definition są jednak nie aż tak wielkie. Istnieją licencje spełniające przesłanki Open Source Definition, które z punktu widzenia FSF są zbyt restrykcyjne, jak również takie, które wprawdzie spełniają przesłanki Free Software Definition, jednak nie mogą być uznane za Open Source. Przypadki takie są wprawdzie stosunkowo rzadkie, jednak ideologiczne spory pomiędzy poszczególnymi odłamami ruchu powodują, że w ostatnich latach popularność zdobywa „politycznie poprawny” termin Free, Libre, Open Source Software (FLOSS), obejmujący wszystkie odmiany „niewłasnościowego” oprogramowania. My stosujemy dalej pojęcie „open source”, mając na myśli jak najszerszą kategorię (czyli FLOSS).

Przełamanie przywilejów

Celem licencji open source jest więc przełamanie przywilejów twórcy wynikających z praw własności intelektualnej oraz zapewnienie swobodnego przepływu informacji z korzyścią dla społeczeństwa. Innymi słowy, podstawowym celem licencjonowania open source jest odmówienie komukolwiek prawa do wyłącznego korzystania z utworu. Oprogramowanie komputerowe jest przede wszystkim chronione prawem autorskim (niestety). Dodatkowo, w wielu jurysdykcjach, pewne innowacyjne elementy funkcjonalne oprogramowania mogą być chronione patentami jako tak zwane wynalazki realizowane za pomocą komputera. Przedmiotem patentu może być zarówno produkt (np. standardowy komputer z zainstalowanym innowacyjnym oprogramowaniem wykonującym pewne funkcje), jak i proces (np. pewien przebieg czynności wykonywanej za pomocą programu komputerowego). Ponadto, oprogramowanie może zawierać inne elementy chronione jako własność intelektualna. W szczególności nazwa oprogramowania lub organizacji, która zarządza jego rozwojem może być zarejestrowana jako znak towarowy.

Wszystkie licencje open source uwzględniają wykorzystanie oprogramowania objętego licencją jako przedmiotu prawa autorskiego. Ponadto, niektóre licencje open source zawierają postanowienia zapewniające, że jeśli jakiekolwiek elementy oprogramowania byłyby chronione patentami, zezwolenie zawarte w licencji obejmuje również zezwolenie na korzystanie z wynalazku chronionego tym patentem. Jest to szczególnie prawdziwe w przypadku licencji takich, jak: Academic Free License 3.0, GPL 3.0, AGPL 3.0, Apache 2.0, Eclipse Public License 2.0, Mozilla Public License 2.0.

Inaczej wygląda sytuacja w przypadku znaków towarowych. Wiele licencji zawiera wyraźne ograniczenia dotyczące korzystania z niektórych znaków towarowych. Na przykład licencja Apache 2.0 nie zawiera prawa do używania znaku towarowego licencjodawcy, z wyjątkiem uzasadnionego i zwyczajowego użycia w opisie pochodzenia oprogramowania. Podobne postanowienia można znaleźć w licencjach BSD-3-clause,PHP-3.0 i GNU GPL 3.0. Ze względu na „otwartość” oprogramowania open source, jego elementy nie mogą być także chronione jako nieujawnione know-how lub tajemnica handlowa.

Objęcie oprogramowania licencją open source nie powinno być rozumiane jako zrzeczenie się praw własności intelektualnej lub przekazanie go do domeny publicznej (to bardzo ważne, ponieważ często, a błędnie, właśnie tak podchodzi się do OS). Oprogramowanie open source nadal jest chronione prawem autorskim, a korzystanie z niego wymaga przestrzegania warunków licencji. Nawet najprostsze licencje, takie jak MIT czy BSD-2-clause, nakładają na użytkownika pewne zobowiązania, takie jak obowiązek dostarczenia informacji o używanym oprogramowaniu. Inne często spotykane postanowienia to obowiązek informowania o dokonanych zmianach, udostępniania kodu źródłowego oprogramowania open source w związku z jego rozpowszechnianiem oraz udostępniania kodu źródłowego wszelkich modyfikacji dokonanych w rozpowszechnianej kopii oprogramowania. Licencje GPL to już zestaw bardzo daleko idących wymagań.

Charakter prawny licencji OS

Charakter prawny licencji OS nie jest w pełni jasny. W większości jurysdykcji licencje te są interpretowane jako umowy (np. w Belgii, Chorwacji, Czechach, Francji, Hiszpanii, Holandii, Niemczech, Portugalii, Rumunii, Turcji, na Węgrzech). W niektórych krajach (np. w Grecji) rozważa się również ich kwalifikację jako jednostronnej zgody uprawnionego. Z drugiej strony, w kilku krajach, m.in. ze względu na brak orzecznictwa, sytuacja pozostaje niejasna. Przykładowo w Polsce, w odniesieniu do licencji GNU GPL, rozważano zakwalifikowanie jej częściowo jako umowy (w zakresie zezwolenia na rozpowszechnianie objętego nią oprogramowania), częściowo jako jednostronnej zgody na korzystanie z utworu (w zakresie eksploatacji programu open source przez użytkownika).

Co ważne, w wielu krajach Unii Europejskiej orzeczenia sądów potwierdziły skuteczność licencji open source, w tym charakterystycznych dla licencji GNU GPL klauzul copyleft (o których poniżej). Na przykład we Francji sąd zezwolił nabywcy programu na licencji GPL na wniesienie pozwu przeciwko dystrybutorowi programu na licencji GPL o ujawnienie kodu źródłowego. Podobnie w Niemczech sąd wydał wstępny nakaz przeciwko pozwanemu, który włączył oprogramowanie GPL do swojego oprogramowania własnościowego.

Podsumowując – niezależnie od sporów w literaturze prawniczej dotyczących kwalifikacji licencji open source, warunki określone w tych licencjach należy traktować jako wiążące. Wykorzystanie oprogramowania open source może więc nastąpić tylko na warunkach określonych w tych licencjach.

Open source i Creative Commons

Creative Commons to zbiór licencji opublikowanych po raz pierwszy w 2002 r. przez Creative Commons, amerykańską organizację non-profit założoną w 2001 r. Istnieje kilka rodzajów licencji Creative Commons. Różne wersje licencji narzucają różne prawa. Wszystkie licencje Creative Commons wymagają przypisania autorstwa do twórcy (opisanego elementem „BY”). Twórca może ponadto zastrzec, że licencjobiorcy mogą: (po pierwsze) rozpowszechniać utwory pochodne tylko na licencji identycznej („nie bardziej restrykcyjnej niż”) z licencją, która obowiązuje w stosunku do oryginalnego utworu (SA, Share-Alike element); (po drugie) kopiować, rozpowszechniać, wyświetlać i wykonywać utwór oraz tworzyć na jego podstawie utwory zależne wyłącznie w celach niekomercyjnych (NC, element niekomercyjny); (po trzecie) kopiować, rozpowszechniać, wyświetlać i wykonywać jedynie dosłowne kopie utworu, ale nie utworów pochodnych na nim opartych (ND, No Derivative Works element).

W związku z tym twórca, korzystając z licencji Creative Commons, zawsze zachowuje prawa autorskie, zezwalając jednocześnie innym na kopiowanie i rozpowszechnianie, a także może określić, czy korzystanie z utworu może odbywać się wyłącznie na warunkach niekomercyjnych, czy też ograniczyć tworzenie utworów zależnych. Licencje CC zawsze przyznają „prawa podstawowe”, takie jak prawo do rozpowszechniania utworu chronionego prawem autorskim na całym świecie w celach niekomercyjnych i bez modyfikacji.

Poza licencjami dotyczącymi praw autorskich, Creative Commons oferuje także CC0, czyli narzędzie pozwalające na umieszczanie materiałów w domenie publicznej. CC0 jest narzędziem prawnym, które pozwala twórcom zrzec się jak największej liczby praw. Narzędzie to powstało w związku z pojawiającymi się w wielu systemach prawnych wątpliwościami dotyczącymi zrzekania się praw autorskich przed upływem czasu ochrony.

Licencje Creative Commons oparte są na podobnej koncepcji co open source, ale nie są identyczne. Po pierwsze, są bardziej restrykcyjne w niektórych kombinacjach. Licencje zastrzegające użycie niekomercyjne (NC) i udostępnianie utworów zależnych (ND) nie są zgodne z definicjami wolnego oprogramowania i open source. Po drugie, są one generalnie przeznaczone do dzielenia się utworami innymi niż oprogramowanie i ich użycie w odniesieniu do oprogramowania nie jest zalecane. Ponieważ jednak programy komputerowe są utworami podlegającymi ochronie prawa autorskiego, objęcie ich licencją Creative Commons nie jest niemożliwe. Licencja CC BY-SA 4.0 jest kompatybilna z licencją GPL 3.0.

Standaryzacja open source

Jedną z zalet licencji open source (podobnie jak Creative Commons) jest de facto ich standaryzacja. W przypadku oprogramowania własnościowego istnieje duża różnorodność licencji, zarówno pod względem zakresu udzielanych praw, ograniczeń i warunków stosowanych przy korzystaniu z oprogramowania (tzw. metryk licencyjnych), jak i postanowień dodatkowych (np. zobowiązań dotyczących audytów licencyjnych czy odpowiedzialności). Oznacza to, że licencjobiorca przed podpisaniem umowy musi (a przynajmniej powinien) zapoznać się z bardzo obszernym i skomplikowanym dokumentem prawnym, często podlegającym nieznanemu mu prawu właściwemu (to często kilkaset stron tekstu, jeżeli uwzględnimy warunki kontraktowe publikowane w internecie). Zwiększa to koszty transakcyjne związane z udostępnianiem oprogramowania oraz niepewność prawną. W praktyce to wielkie wyzwanie dla organizacji, połączone z ryzykiem audytu i odszkodowań, ale to temat na inny tekst.

Z kolei w przypadku oprogramowania open source najczęściej stosowane są licencje opracowane przez organizacje popularyzujące ten model dystrybucji oprogramowania (takie jak wspomniana FSF) oraz fundacje zarządzające rozwojem dużych projektów open source (Apache, Mozilla, Eclipse). Dodatkowo, organizacje takie jak FSF czy Open Source Initiative regularnie dokonują przeglądu i oceny zgodności licencji z opracowanymi przez siebie definicjami wolnego i otwartego oprogramowania. W konsekwencji, licencje open source cieszą się dużym zaufaniem deweloperów i użytkowników. Przy czym w przypadku popularnych licencji (takich jak GNU czy Mozilla Public License) korzystanie z oprogramowania powinno być łatwiejsze w ocenie prawnej niż w przypadku licencji „zamkniętych”. Jak się okaże, nie zawsze.

Omawiane korzyści standaryzacji są częściowo ograniczane przez rosnącą liczbę licencji open source. The Open Source Initiative wymienia obecnie ponad 100 licencji spełniających definicję open source. Liczbę kombinacji zwiększają „wyjątki” dodawane przez niektórych deweloperów do danej licencji (np. wyjątek GCC Runtime Library, wyjątek Qt GPL). Wskazuje się, że zjawisko to, ogólnie znane jako „proliferacja” open source, ma kilka negatywnych konsekwencji. Po pierwsze niekompatybilność: przy większej liczbie licencji prawdopodobieństwo połączenia jednego produktu software’owego z innym, udostępnionym na niekompatybilnych warunkach licencyjnych, wzrasta wykładniczo. Po drugie niepewność: im więcej licencji open source jest wykorzystywanych w praktyce, tym mniej prawdopodobne jest, że będą one poddane kontroli sądowej i ocenie ekspertów prawnych. Analizie podlegają tylko popularne, szeroko stosowane licencje. Po trzecie zamieszanie i zwiększone koszty transakcyjne: im więcej licencji dotyczy danego projektu, tym trudniej jest ocenić, czy projekt spełnia warunki każdej z nich lub przewidzieć, jaki będzie prawny rezultat połączenia różnych programów.

Podsumowując, wykorzystanie komponentów na tzw. „permisywnych” licencjach open source (MIT, BSD, Apache) wiąże się najczęściej tylko z podaniem w dokumentacji odpowiedniej informacji o zastosowanym oprogramowaniu i licencji, która je obejmuje. Więcej uwagi należy poświęcić wykorzystaniu oprogramowania open source na licencjach typu copyleft. W tym przypadku istotny staje się sposób połączenia takiego oprogramowania z innymi elementami produktu, opisany poniżej. Ryzykowne może okazać się stosowanie komponentów na „egzotycznych” (rzadko spotykanych) licencjach, zwłaszcza jeśli nie zostały one poddane ocenie przez organizacje takie jak Free Software Foundation czy Open Source Initiative.