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.

Rodzaje licencji OS – copyleft vs non-copyleft

Jednym z najpowszechniej przyjętych kryteriów klasyfikacji licencji open source jest rozróżnienie między licencjami typu copyleft i non-copyleft. Rozróżnienie to odnosi się do kwestii, czy wyniki dalszego rozwoju i modyfikacji programu muszą być udostępniane na tej samej lub „kompatybilnej” licencji, co oryginalny program. Ogólnie rzecz biorąc, licencje typu copyleft wymagają, aby wyniki dalszego rozwoju i modyfikacji programu były udostępniane na tych samych warunkach, co program oryginalny. Decydując się na wykorzystanie kodu objętego copyleft, korzystający (programista) „zaraża” swoje rozwiązanie (swój kod) tą licencją. Jego program, do którego użył komponentów copyleft, powinien być objęty warunkami pierwotnej licencji copyleft. Ten szczególny efekt (tzw. „wirus copyleft”) ma na celu zabezpieczenie „otwartości” danego programu i zapobieżenie jego „uprzywilejowaniu”, nawet jeśli jest on używany w dziełach pochodnych.

Powyższa konsekwencja ma duże znaczenie praktyczne. W wielu środowiskach open source traktowany jest jako darmowa „baza kodu” do swobodnego wykorzystania. Twórcy copyleft wprowadzili jednak przebiegły i bardzo skuteczny mechanizm – możesz z naszego rozwiązania skorzystać, ale wtedy twoje rozwiązanie będzie dalej dystrybuowane na naszych licencyjnych warunkach. O konsekwencjach opowiemy w dalszych częściach, ale to oznacza, że jak użyjemy copyleft, to nie będziemy mogli żądać opłat licencyjnych za nasze rozwiązanie czy też będziemy zobowiązani do ujawnienia kodu źródłowego całości rozwiązania (w tym naszej, autorskiej części).

Rozróżnia się dwa rodzaje klauzul typu copyleft. Pierwszą jest tzw. silny copyleft. W tym przypadku warunki licencji muszą być zachowane dla każdej pracy pochodnej. Jakbyśmy nie używali oprogramowania, „wirus” działa. Najbardziej znanymi przykładami są wszystkie wersje GNU GPL i GNU AGPL. Drugi typ to tzw. słaby copyleft. W tym przypadku warunki licencji muszą być zachowane dla określonych dzieł pochodnych. Czyli może okazać się, że mimo użycia oprogramowania copyleft, do „zarażenia” nie doszło. Licencje takie są najczęściej stosowane w przypadku bibliotek oprogramowania. Dzięki temu biblioteki te mogą być używane – pod pewnymi dodatkowymi warunkami – w produktach wydanych na innych licencjach i samo ich użycie nie prowadzi do „efektu wirusa”. Licencje, które wykorzystują „słabą” klauzulę copyleft to m. in. GNU Lesser General Public License (LGPL) oraz Mozilla Public License. W praktyce (czytaj: upraszczając) oznacza to, że korzystając z kodu z „silną” licencją prawie na pewno „zarazimy” nasz kod warunkami takiej licencji. W przypadku „słabej” licencji standardowe zastosowanie danego komponentu (np. odwołania do biblioteki na LGPL) nie stwarza takiego ryzyka.

Żeby było jeszcze trudniej – w niektórych przypadkach spotyka się także tak zwane „częściowe” klauzule copyleft. Częściowe licencje typu copyleft mają podobny skutek jak słabe klauzule copyleft. Częściowy copyleft zwalnia niektóre części utworu z copyleft, zezwala na rozpowszechnianie niektórych części utworu lub jego modyfikacji na warunkach innych niż licencja copyleft lub w inny sposób nie nakłada warunków copyleft na cały utwór. Przykładem częściowego copyleftu jest wyjątek GPL dotyczący linkowania, który zwalnia z copyleftu pliki nagłówkowe bibliotek oprogramowania i pozwala na dynamiczne linkowanie oprogramowania komercyjnego (np. wyjątek GCC Runtime Library). Skutek podobny do LGPL, ale diabeł tkwi, oczywiście, w szczegółach.

Zazwyczaj klauzula copyleft jest połączona ze zobowiązaniem do udostępnienia kodu źródłowego oprogramowania objętego licencją copyleft. Dzieje się tak dlatego, że licencja ta ma zapewnić użytkownikom możliwość czytania kodu, poprawiania go i dzielenia się swoimi zmianami. Skuteczne korzystanie z tych praw wymaga dostępu do kodu źródłowego.

Licencje „non-copyleft” (znane również jako „permisywne”) nie mają podobnych ograniczeń. Z reguły nie ma więc przeciwwskazań do łączenia rozwiązań „własnościowych” i „otwartych”, w tym udostępniania rozwoju „otwartego” programu na licencji „zamkniętej”. Najpopularniejsze przykłady to MIT, BSD (wszystkie wersje) oraz Apache. Licencje te nie nakładają obowiązku udostępniania kodu źródłowego. Oznacza to, że program objęty taką licencją może być udostępniony zarówno w postaci binarnej, jak i źródłowej, niezależnie od tego, czy został zmodyfikowany, czy nie.

Autorzy są Partnerami w kancelarii Maruta Wachta.

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

Tomasz Buk, Interim Manager w DXC pyta: „Wypłata w kryptowalutach za pracę na etacie – czy to jest możliwe? Na podstawie przepisów takie świadczenie ma charakter niepieniężny, czyli zalicza się do płatności w naturze. (…) Wynagrodzenie w naturze możemy otrzymać tylko za część zmienną wynagrodzenia, np. premie, dodatki, ryczałty, diety itd. Możliwość taka musi być zawarta w regulaminie pracy (w małych firmach do 20 osób) lub w układzie zbiorowym w większych firmach. Opodatkowanie tej części przebiega na zasadach ogólnych (17 proc. lub 32 proc.). I tutaj jeden <<myk>> dla tych, którzy chcieliby skorzystać z takiej możliwości. W zależności od tego jaką mamy podpisaną umowę z pracodawcą przy sprzedaży waluty wirtualnej będziemy mogli sobie ją wliczyć w koszt uzyskania dochodu albo nie. Zamiast otrzymywać wypłatę na podstawie tej samej umowy o pracę, lepiej zawrzeć z pracodawcą dodatkową umowę o kupno waluty wirtualnej w kwocie netto należnych dodatków i najlepiej od razu o możliwości potrącenia tej kwoty z wypłaty. Różnica jest taka, że można wykazać ten <<koszt zakupu>> waluty i obniżyć należny podatek”. Można? Można!

Marcin Fidler, Partner w Stilo Energy, w ramach cyklu „Najwięksi polscy wynalazcy”, przypomniał postać Jacka Trzmiela „urodzonego w 1928 r. w Łodzi, który po wojnie wyemigrował do USA i wstąpił do armii, a jego zadaniem było naprawianie sprzętu biurowego. Po kilku latach założył własną firmę Commodore Portable Typewriter, zajmującą się naprawą maszyn do pisania. Potem założył nową spółkę, która wprowadziła na rynek pierwsze kalkulatory Commodore. Następnie Trzmiel zbudował urządzenie, które stworzyło podwaliny dla rynku komputerów osobistych. Commodore 64 wszedł na rynek w 1982 r., okazał się hitem na niespotykaną skalę. Sprzedany w 22 milionach egzemplarzy do dziś uważany jest za najpopularniejszy w dziejach komputer domowy. <<Dla mas, a nie klas>> – tak mawiał o urządzeniu jego twórca. Ówczesna konkurencja nie była w stanie zaoferować lepszego sprzętu w porównywalnej cenie. W 1984 r. Trzmiel odszedł z firmy w wyniku konfliktu z udziałowcami. Kupił konkurencyjną grupę Atari i w kolejnych latach obie strony prowadziły wyniszczającą wojnę rynkową. Niestety, poległy na niej obie. W latach 90. najpierw zbankrutowało Commodore International, a później Atari Corporation”. Niemniej, naszym zdaniem, ich wysiłek, aby wprowadzić komputery pod strzechy jednak się udał.

Kiedyś Microsoft przygotował miły gadżet upominkowy w postaci grilla z napisem: „Grilluj, byle nie nas ”. Zdaje się, że albo Piotr Marciniak, CEO TPnets.com tego prezentu nie dostał, ewentualnie nie zastosował się do prośby. O czym świadczy następujący, pełen goryczy wpis: „Jak Microsoft zabiera mi czas na pisanie doktoratu i ma błędną komunikację telefoniczno-webową. Od jakiegoś czasu piszę w wolnym czasie doktorat wykorzystując do tego mój domowy 10-letni komputer i zainstalowany na nim ówcześnie Office 2010 z adekwatną do tego celu domowo-studencką licencją. Kilka dni temu po jakiejś kolejnej aktualizacji systemu padło mi menu start, choć sam Win10 działał nadal. Żadne sugerowane magiczne rozwiązania od powershell po rejestr nie pomogły. Zostało, zgodnie z poradnikiem Microsoftu, nadrzucenie systemu. Wykonałem. Problem pozostał nierozwiązany. Więc sięgnąłem po Classic Start Menu, bo pracować dalej trzeba. Po tej operacji przy próbie uruchomienia Worda do dalszej pracy nad doktoratem zaskoczył mnie komunikat, że muszę ponownie aktywować Office’a. Opcja internetowa nie działa. Telefoniczna dla Polski również, ale na www Microsoft wskazuje dla Polski numer: (48) (22) 594 19 99. Po wdzwonieniu się i wyklikaniu szeregu czasochłonnych opcji usłyszałem, że wsparcie przeniesiono do sieci pod adres: help.microsoft.com, na którym jednak aktywacji wykonać nie mogę, bo powinienem ją zrealizować telefonicznie pod w/w numerem. Błędne koło. Ani telefon, ani www nie oferują żadnej pomocy żywego człowieka. Gratulacje Microsoft. Straciłem 2 dni próbując odzyskać pełną sprawność Win10. Co się nie udało. W nagrodę Wasz Office przestał również działać. A ja zamiast pisać pracę naukową – tracę czas. Zapewne Legalna Marta wyjaśni mi, że powinienem przejść na #Office365. Tylko, że to byłoby zarówno kompletnie zbędne, jak i biznesowo nieetyczne”.

Mirosław Burnejko, prezes Transparent World, zwrócił uwagę na ciekawe wydarzenie, jakie miało miejsce w Salwadorze: „Salwador przyjął ustawę wprowadzającą Bitcoin jako prawny środek płatniczy (62 głosy z 84 w kongresie). Dziś z rana słuchałem rozmowy z prezydentem Salwadoru na Twitter Spaces (było ponad 20,000 ludzi LIVE). Oto kilka ciekawych rzeczy z rozmowy: Bitcoin stał się prawnym środkiem płatniczym. Sprzedawcy MUSZĄ akceptować BTC. Podatki z transakcji w BTC mają być płacone w BTC. Rząd ułatwia wymiany (wymiana po kursie transakcji). Obywatel może mieć dowolny portfel. Chcą wprowadzić możliwość otrzymania obywatelstwa, gdy ktoś zainwestuje 3 BTC (nie USD) w Salwadorze. Ta rozmowa brzmiała jak lekkie Sci-Fi, ale faktycznie dzieje się coś ciekawego w tym naszym wspaniałym świecie”. Podpisujemy się pod tym stwierdzeniem.

Z kolei Marcin Babiak podniósł kwestię związaną z tym, że „firmy nigdy nie zatrudniały tak często, jak obecnie. Nigdy nie wydały na to tyle pieniędzy. I nigdy nie szło im to tak źle”. Zdaniem właściciela Kordo Edukacja „główne przyczyny tego zjawiska to łatwość, z jaką pracownik może dziś zmienić pracę oraz problem ze znalezieniem odpowiedniego kandydata na jego miejsce. Jeśli jesteś szefem małej organizacji (firmy, działu), a przed tobą wyzwanie szybkiego wzrostu, może zdarzyć się, że nie docenisz ilości czasu, jaką zajmie ci rekrutacja. Jeśli twój zespół liczy 5 specjalistów, a za 3 lata przewidujesz 15 osób, to oznacza, że musisz co 2 miesiące zatrudnić nową osobę. Przy założeniu 20 proc. rotacji. Czy to dużo?”. No właśnie, czy to dużo? Odpowiedź na to pytanie, wraz z uzasadnieniem, znajdziecie w całym wpisie Marcina Babiaka. Polecamy.

Artykuł LinkedIn Park pochodzi z serwisu CRN.

„Najgorsze doświadczenie zakupów online. Zwycięzcą tej kategorii jest Empik Group… i jednocześnie wielkim przegranym, bo gdy firma doprowadzi Cię do sytuacji, że chcesz wszystkim swoim znajomym powiedzieć – unikajcie tej firmy jak ognia to znaczy, że naprawdę wszystko było nie tak” – tak zaczyna swój wpis Piotr Płóciennik, CEO Salesberry. A dalej wyjaśnia: „Miesiąc temu zamówiłem kamerkę internetową na empik.com. Kamerka przyszła po dwóch dniach, ale nie ta. (…) Zadzwoniłem, odesłałem i poprosiłem, by przysłać mi właściwą. Mijają kolejne dni. Kamerki nie ma. Panie na infolinii są miłe i zapisują nasze rozmowy w systemie. Efektu brak. W końcu informacja: mamy czternaście dni na rozpatrzenie reklamacji. Hej – to nie jest reklamacja! Po prostu wyślijcie mi właściwy towar. Czekam na niego. Mijają kolejne dni. Kolejne miłe Pani odpowiadają, że oddzwonią i cisza. W końcu nie ma wyjścia – wysyłam ostateczne, przedsądowe wezwanie do wydania towaru i informuję Empik, że zawiadomię policję o możliwości popełnienia przestępstwa (próba wyłudzenia, kradzieży). W końcu po 25 dniach dostaję informację, że Empik nie zrealizuje zamówienia i odeśle mi pieniądze. Sprawdzam kilka razy maila z tą informacją. Nie ma tam słowa <<przepraszamy>>”. Bez komentarza.

Wielu z nas do dzisiaj pamięta wdrażanie procedur narzuconych przez RODO, a niejeden dostawca IT na tym nieźle zarobił. Co nie zmienia faktu, że w dobie pandemii przepisy te stały się częściowo fikcyjne. Kwestię tę poruszyła niedawno Anna Streżyńska, CEO MC2 Innovations, zwracając uwagę, że „przyjęte we współczesnym świecie decyzje regulacyjne rozdęły RODO do nieprzytomności, nieproporcjonalnie do zapewnianej ochrony, uniemożliwiając normalne prowadzenie biznesu – co wie każdy, kto musi wypełniać kilka rejestrów i pozostałe wymagania. Jednocześnie, gdy rząd musi wykonać jakieś zadanie to albo z niskich pobudek łamie ustanowione przez siebie zasady, jak w przypadku wyborów i lekko rozdysponowuje dane bez zgody zainteresowanych, albo niepotrzebnie narusza prywatność dla tzw. wyższego dobra (jak w przypadku apki COVID-owej monitorującej przemieszczanie). W ten sposób resztki zaufania do państwa ulegają destrukcji”. Krótko mówiąc: co wolno wojewodzie, to nie tobie… obywatelu.

Dlaczego transformacje zwinne i cyfrowe często się nie udają? – to z kolei pytanie, jakie zadał Adrian Sasin, założyciel Szkoły Kierowników IT, od razu udzielając odpowiedzi: „bo zarządzający firmą traktują to jak każdy inny projekt – <<weźcie, zróbcie i powiedzcie, gdy będzie już gotowe>>”. Podkreślił przy tym, że transformacja to sprawa całej firmy, a nie jednej osoby czy jednego działu. Jeśli transformacja ma się udać, zarządzający i decydenci muszą zmienić swoje spojrzenie na biznes i otoczenie, swój sposób myślenia, czyli zmienić siebie. „Budżet przydzielany raz w roku na konkretne projekty? Czas to zmienić i podejmować decyzje w każdym miesiącu – gdzie inwestujemy, gdzie wprowadzamy zmiany, co jednak trzeba przerwać”. Takie czasy…

„Dlaczego mam skok ciśnienia, gdy przetarg wygrywa jakaś bliska konkurencja. Im bliższa, tym większy skok. I dlaczego wygrali?” Takim dylematem podzielił się na LinkedIn Marcin Maruta, Partner w kancelarii Maruta Wachta. Ciekawe są dalsze wnioski: „Odpowiedź jest często zaskakująco prosta – bo mieli lepsze oferty. Lepszą wartość dla klienta. A skąd ciśnienie? Bo to suma moich strachów, mają zrobione coś lepiej, mają argumenty, których mi brak. To takie <<lustereczko powiedz przecie>>. Warto przyjrzeć się ich ofertom, sprzedaży, nawet www. Im lepiej ich znamy, tym sprawniej pójdzie nam SWOT. To źródło i inspiracji, i darmowego konsultingu”. Nam pozostaje się zgodzić i dodać, że dotyczy to każdej branży.

Resort cyfryzacji zajął się w ostatnim czasie nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa. Łukasz Nowatkowski, CTO&CMO w G Data Software  zwrócił uwagę na zapis, który pozwala wydać premierowi nakaz odłączenia dostępu online dla połączeń z określonymi adresami IP lub stronami WWW. Resort zapewnia, że takie kroki będą konieczne tylko „w przypadku wystąpienia incydentu krytycznego”, przy czym mają być opatrzone klauzulą natychmiastowej wykonalności i będą mogły obowiązywać przez okres dwóch lat. Ponadto projekt pozwala wydać je bez uzasadnienia „jeżeli wymagają tego względy obronności lub bezpieczeństwa państwa lub bezpieczeństwa i porządku publicznego”. Czy jednoosobowe podejmowanie tak strategicznych decyzji może być bezpieczne dla nas wszystkich? Co z naszą wolnością? – pyta Łukasz Nowatkowski. A my razem z nim…

Marcowy pożar w OVH wywołał lawinę komentarzy, czemu trudno się dziwić, biorąc pod uwagę skalę zniszczeń i liczbę poszkodowanych klientów. W tym kontekście Andy Brandt, założyciel Code Sprinters, zwrócił uwagę, że „to pokazuje zagrożenia wynikające z postępującej centralizacji Internetu. Był on oryginalnie projektowany jako sieć rozproszona, a więc przez to odporna na awarie i ataki. I takim był do mniej więcej 2010 roku, kiedy to <<chmura>> z jednej a scentralizowane serwisy, takie jak Facebook czy LinkedIn, zaczęły zmieniać ten obraz. W efekcie znikają niezależne serwery, na których stoją niezależne aplikacje czy fora. Po dekadzie tego procesu z jednej strony możliwa jest centralna cenzura (która jest smutną realnością naszych czasów – sieć, która miała być miejscem wolności staje się miejscem tępienia <<nieprawomyślnych>>), ale jest też drugie zagrożenie: coraz większe uzależnienie od niewielkiej liczby krytycznych lokalizacji. (…) Dlatego warto mieć kopie <<u siebie>>. To staromodne, ale jednak…” Krótko mówiąc: przezorny zawsze ubezpieczony.

Artykuł LinkedIn Park pochodzi z serwisu CRN.

CRN „No to TSUE dał (prawniczego) czadu. Dużo do przemyślenia. Privacy Shield is dead” – tak skomentował Pan wyrok w sprawie Schrems II. Pojawiły się też głosy o delegalizacji chmury czy też zakazie używania Google Analytics… Sprawa wydaje się więc poważna, ale nie wiemy, jak bardzo. A zatem?

Marcin Maruta  Bardzo. Zacznijmy od tego, że jakikolwiek transfer danych osobowych poza Europejski Obszar Gospodarczy wymaga podstawy prawnej. W relacjach między Unią a USA jedną z pierwszych i najważniejszych podstaw był program Safe Harbour. Jednak wyrok TSUE z 2015 roku w sprawie Schrems I zakwestionował jego sens. I trudno się dziwić, bo liberalne prawo amerykańskie dotyczące ochrony danych nijak się ma do europejskiego, które jest bardziej restrykcyjne i ideologicznie inaczej skonstruowane. Założenia programu nie miały więc odzwierciedlenia w rzeczywistości, poza tym, że firmy działające po obu stronach Atlantyku zabezpieczały się klauzulą, w której powoływały się na Safe Harbour. W ten sposób miały poczucie, że działają zgodnie z prawem. Safe Harbour został zastąpiony Privacy Shield, co z kolei zostało unieważnione najnowszym wyrokiem, a więc Schrems II. Szczerze mówiąc, to nie było wielkie zaskoczenie dla prawników, którzy zajmują się ochroną danych osobowych. Można się było tego spodziewać z tych samych powodów, co w przypadku Safe Harbour.

Dotychczasowe umowy, w których powoływano się na Privacy Shield, są więc już nieważne?

Kilka słów, aby uporządkować obraz sytuacji. Jak wspomniałem, do transferu danych potrzebujemy podstawy prawnej. Jest ich kilka, od porozumień międzynarodowych w rodzaju Privacy Shield, po zgody osób fizycznych. Wyrok TSUE dotyczył dwóch podstaw, najczęściej stosowanych – Privacy Shield i tzw. standardowych klauzul umownych. Privacy Shield została unieważniona, więc ta podstawa znika. Jeżeli na niej opieraliśmy transfer, to musimy albo go zaprzestać, albo znaleźć inną podstawę. Standardowe klauzule umowne to wzorcowe umowy zawierane między przedsiębiorcami z Unii i spoza Unii, a właściwie Europejskiego Obszaru Gospodarczego. One, jako mechanizm, przetrwały, ale na podmioty, które dokonują transferu danych nałożono obowiązek badania, czy kraj, do którego dane są przekazywane, zapewnia odpowiednią ochronę. I tu wpadamy w pułapkę, ponieważ Trybunał stwierdził, że w USA takiej ochrony nie ma, więc stosowanie klauzul na potrzeby transferu do tego kraju jest co najmniej wątpliwe.

Niemniej wyrok dotyczy wszystkich krajów?

Wyrok w zakresie standardowych klauzul dotyczy całego świata, niemniej faktycznie kluczowy w tym kontekście jest transfer danych osobowych w obrocie ze Stanami Zjednoczonymi, bo to dostawcy amerykańscy zdominowali rynek IT, w tym sektor chmurowy. Wiele amerykańskich firm szukało przy tym podstawy prawnej do transferu danych swoich klientów z terenu UE na teren USA, i w tym celu korzystało z zapisów Privacy Shield. Chodzi przede wszystkim o usługodawców, którzy nie mieli rozbudowanych przedstawicielstw czy centrów danych w Europie. A teraz ich tutejsi klienci mają problem. Taki problem mają też podmioty transferujące dane w oparciu o klauzule, choć tutaj mogą wystąpić przypadki, kiedy transfer da się obronić. W przypadku Tarczy – nie ma już takiej możliwości. 

Z tego wynika, że potrzebna jest nowa umowa pomiędzy UE a USA. Czy jest na to szansa i kiedy może to nastąpić?

Już dwie umowy nie wytrzymały próby czasu, a szanse na stworzenie trzeciej uważam za nikłe, bo podejście do tematu danych osobowych w Europie, USA i Chinach bardzo się od siebie różni. Na tyle, że kompromis wydaje się niemożliwy. Zresztą Amerykanie mniej lub bardziej wyraźnie dają znać, że do GDPR w stopniu wymaganym przez Unię się nie dostosują.

Co na to wszystko europejskie urzędy ds. ochrony danych osobowych? Jakie są ich wytyczne dla firm?

Niemal wszystkie milczą, wyraźnie czekając na rozwój wydarzeń – zapewne pracują nad rozwiązaniami. Pojawiają się wypowiedzi dość stanowcze, jak berlińskiego urzędu ds. ochrony danych osobowych, który uznał, że w ogóle nie można teraz transferować danych do USA i nie powinny one przekraczać unijnych granic. To najostrzejsze, jak do tej pory, oficjalne stanowisko. Co ciekawe, na poziomie federalnym Niemiec, stanowisko było łagodniejsze, dane nadal mogą trafiać za Atlantyk, ale przy spełnieniu dodatkowych warunków… których jeszcze nikt nie zna. Nasz polski prezes UODO postąpił podobnie, czyli zakomunikował, że można to robić, ale zgodnie z nowym prawem, przy czym ocena zgodności należy do każdej firmy z osobna. Nie ma zero-jedynkowych wytycznych i zapewne nie będzie.

Od czego, w takim razie, powinno się zacząć?

Każda firma, która korzysta z usług chmurowych musi się teraz zastanowić, gdzie konkretnie przetwarzane w ten sposób dane lądują. Jeśli okaże się, dajmy na to, że gdzieś na amerykańskim serwerze w ramach usługi Azure, wówczas należałoby sprawdzić, czy można zmienić lokalizację przetwarzania danych na data center w Europie. W wielu przypadkach jest to możliwe, zwłaszcza u kluczowych graczy na rynku chmurowym. W tym kontekście bardzo dobrze brzmią zapowiedzi Google’a i Microsoftu dotyczące wielkich inwestycji w „polskie” centra danych. To w przyszłości może bardzo ułatwić sprawę. Warto przy tym zwrócić uwagę, że na ocenę sytuacji może wpłynąć fakt, jakie dane przekazujemy do chmury – bo jest różnica między danymi identyfikującymi wprost osobę, a tylko pozwalającymi pośrednio ją identyfikować (jak adres IP) – oraz jak je zabezpieczamy, czyli w grę wchodzi kryptografia i kontrola nad kluczami.

Czy przeniesienie danych do Europy niweluje zagrożenia prawne?

Nie zawsze. Żeby spać spokojnie należy uważnie przeczytać wszystkie umowy z zagranicznymi dostawcami usług. Nawet, jeśli trzymają nasze dane tylko w Unii Europejskiej. Może się bowiem okazać, że w umowie jest na przykład zapis, zgodnie z którym w razie awarii tutejszego centrum danych usługodawca może dane, wyjątkowo, przerzucić do USA. Jestem jednak przekonany, że najwięksi dostawcy dostosują się do unijnych wymagań prawnych.

A co z kwestią danych, które są przetwarzane w ramach Google Analytics? Czy  jest to teraz nielegalne, bo na  amerykańskich serwerach analizowane są informacje dotyczące Europejczyków?

To są dane, które nie identyfikują wprost konkretnych osób, więc czeka nas dyskusja pomiędzy prawnikami, jak w tym przypadku interpretować wyrok TSUE. Ale bez sprawdzenia, jakie konkretne dane i w jakim wolumenie są transferowane, trudno to orzec. W moim odczuciu powinniśmy zastanowić się nad istotą orzeczenia, a więc poufnością danych i analizować, czy potencjalny dostęp do takich danych przez służby kraju trzeciego może naruszyć czyjeś prawa.

Jak wygląda sytuacja prawna waszych klientów w świetle decyzji trybunału?

Analizujemy teraz uważnie poszczególne przypadki i już widzimy, że praktyczny wpływ wyroku będzie poważny. Część klientów będzie musiała zrezygnować z niektórych narzędzi, czekamy też na reakcję dostawców, którzy już zmieniają swoje polityki.

Czy należy spodziewać się wysypu kar nakładanych przez UODO?

To zależy od UODO, ale wątpię. Sam organ musi umieć ocenić, gdzie leży granica pomiędzy szarą a czarną strefą. Na pewno zaniechanie analizy swojej sytuacji i pozostawienie transferu na podstawie Tarczy będzie dość oczywistym naruszeniem prawa. Natomiast z klauzulami sprawa nie jest aż tak oczywista. W każdym razie jestem pewny, że wyrok TSUE będzie bardzo serio traktowany przez europejskich regulatorów, bo dotyczy ważnego, ideologicznego sporu pomiędzy UE a resztą świata.

Czy czeka nas zatem rewolucja na rynku dostawców usług chmurowych na rzecz europejskich firm?

Z dużymi dostawcami ze świata europejscy klienci nie powinni mieć problemów, bo – ufam – ci się do unijnych wymogów dostosują. Problem może wystąpić w przypadku średnich i małych usługodawców spoza Europy, którzy mogą uznać, że im się to nie opłaci, ze względu na małą skalę działania czy zbyt wysokie koszty. Ich klienci będą więc wybierali bezpieczną alternatywę. W tym kontekście ciekawa wydaje się ogólna polityka Unii, wzmacniającej własne kompetencje cyfrowe, w tym chmurowe. Przykładem jest inicjatywa Gaia-X, która ma na celu stworzenie europejskiej infrastruktury chmurowej i zmniejszenie zależności europejskich podmiotów od amerykańskich dostawców usług cloudowych. Stoją za tym głównie Niemcy i Francja, za to polskich firm w tym projekcie nie ma, choć powinny się tym zainteresować. Zwłaszcza że obecnie nie brakuje funduszy unijnych dotyczących cyfryzacji.

Przypomnijmy na koniec, jak ta sprawa znalazła się w TSUE i kim jest Schrems… 

Maximilian Schrems to najbardziej znany obecnie na świecie aktywista od danych osobowych, który najpierw doprowadził do zniesienia Safe Harbour, a teraz Privacy Shield. Wykazał, że obie te konstrukcje prawne były wadliwe, gdyż systemy prawne USA i UE są ze sobą niekompatybilne. W świecie aktywistów od prywatności jest postacią wręcz kultową. Nie wątpię, że w razie ewentualnej kolejnej umowy pomiędzy UE a USA znowu o nim usłyszymy.

Rozmawiał Tomasz Gołębiowski

Artykuł Schrems II, czyli TSUE wywraca stolik pochodzi z serwisu CRN.