Open source i free source oraz zasady ich wykorzystania w firmie

Brak jest świadomości tego, że istnieje różnica pomiędzy oprogramowaniem o otwartych źródłach – open source software – a wolnym oprogramowaniem – free software. Wielu użytkowników nie wie nawet, że wolne i otwarte oprogramowanie też są objęte jakąś licencją. Pół biedy, jeśli jest to użytkownik prywatny. Gorzej, gdy w dużej firmie, w szczególności programistycznej, na szczeblu zarządczym spotykamy się z takim samym poziomem (nie)wiedzy.

W tym artykule nie będę wyjaśniał różnic czy szczegółowo omawiał licencji. Skupię się raczej na tym jak świadomie, bezpiecznie i z korzyścią dla wielu stron zacząć używać otwartego oprogramowania w dużej firmie tworzącej oprogramowanie komercyjne. Posłużę się przykładem procesu zarządzania użyciem open source wdrożonego w Microsoft. Z uwagi na rozmiary firmy i amerykańskie prawo patentowe – któremu firma podlega – proces ten jest bardzo restrykcyjny. Dotyczyć to może jednak dowolnej firmy, a mniejsze niż Microsoft mogą mieć znacznie większy problemy z podźwignięciem się w sytuacji naruszenia praw licencyjnych, czy patentowych i związanego z nimi ewentualnego procesu.

Modele użycia i ich definicje

Open source w firmach jest powszechny, gorzej z jego świadomym użyciem. Pierwszym krokiem procesu powinno być stworzenie (lub opisanie istniejących) modeli użycia takiego oprogramowania i ich precyzyjne zdefiniowanie oraz przygotowanie odpowiedniego procesu użycia programu. Proces szczegółowo wylicza licencje OSI dopuszczone w każdym z modeli użycia, określa niezbędne dokumenty i ustala zakres odpowiedzialności pracownika. Złamanie przez pracownika modelu użycia lub niedostosowanie się do którejkolwiek z reguł określonych w procesie może skutkować sankcjami wobec takiej osoby.

Mówimy o dużej organizacji, która wytwarza własne oprogramowanie licencjonowane potem dla użytkowników końcowych (instytucjonalnych i prywatnych). Mamy więc do czynienia z zespołami programistów, czy architektów oprogramowania, produkcją i logistyką, ale także z całymi zastępami tzw. pracowników merytorycznych w działach sprzedaży, finansów i marketingu. Całość procesu jest wspierana także przez prawników specjalizujących się w prawie ochrony własności intelektualnej, licencjach open source i prawie patentowym.

Scenariusze użycia open source

Natychmiast nasuwa się więc używanie OSS w codziennej pracy, także na własne potrzeby. Ludzie pracujący w tak dużej społeczności nie są zuniformizowani. Mają swoje przyzwyczajenia i ulubione narzędzia lub potrzebują narzędzi specjalnych do konkretnego zadania. Ich rolą jest często również znajomość innych produktów – konkurencyjnych do własnych lub stanowiących de facto standard w określonym sektorze rynkowym. Są wśród nich często produkty open source.

Drugi obszar, w którym w firmie programistycznej może pojawiać się oprogramowanie open source to oczywiście użycie kodu we własnych produktach. Mogą to być całe gotowe produkty, których własne, zmodyfikowane i przebudowane wersje (tzw. fork) są przez firmę rozpowszechniane i wspierane lub o fragmentach kodu (poszczególne moduły, czy biblioteki) włączonych do własnych produktów.

Kolejny krok to zaangażowanie programistów firmy w trwające projekty open source. To naturalny i wręcz pożądany kierunek. Programiści korzystający z dobrodziejstw open source powinni włączyć się w działania społeczności rozwijającej produkty, z których korzystają. Wspierać wiedzą i doświadczeniem, aby udoskonalać kolejne wersje projektu.

I wreszcie udostępnienie własnego produktu na otwartej licencji. Przypominam, że cały czas mamy na myśli firmę, której model biznesowy jest oparty na licencjonowaniu oprogramowania klientom i dla której kluczowe jest zachowanie jego integralności. Przyjrzyjmy się, jak te modele użycia zostały zdefiniowane w Microsoft.

Użycie w codziennej pracy

Firma przyjmuje dwie nadrzędne zasady dla tej definicji: absolutne przestrzeganie wszystkich wymagań licencyjnych, jakim podlega program, którego chcemy użyć; całkowita separacja scenariuszy użycia kodu programów w tym modelu od jakiegokolwiek kontaktu z klientem.

Jeżeli zachowana jest zgodność z punktem pierwszym użycie gotowych aplikacji jest dość oczywiste. Używamy narzędzia w celu uzyskania pożądanego efektu i – jeśli licencja na to pozwala – swobodnie posługujemy się wynikiem pracy. Znajomość licencji gotowego programu, którego używamy wewnątrz firmy jest tutaj kluczowa. Programy składają się często z wielu, niezależnie rozwijanych pakietów, często udostępnionych na różnych licencjach. Może się więc okazać, że niektóre pakiety są objęte licencją, która nie zezwala na użycie programu do celów, do jakich chcielibyśmy go użyć. Przykładem może być jedna z popularnych dystrybucji systemu Linux, złożona z 1122 pakietów, objętych w sumie 33, różnymi licencjami open source. 87 pakietów użytych w tej dystrybucji miało tzw. podwójne licencjonowanie – inna licencja przy użyciu komercyjnym, inna przy niekomercyjnym.

Punkt drugi z kolei jednoznacznie mówi nam, że nie wolno nam używać takiego kodu w żadnych usługach sieciowych, czy w modelu hostowanym, jeśli miałyby one mieć kontakt z użytkownikiem końcowym. W środowiskach czysto deweloperskich możemy więc używać np. automatów testujących, czy kompilatorów kodu, ale zabronione byłoby użycie analizatora składniowego (parsera), ponieważ powoduje on zmianę w kodzie źródłowym analizowanego programu.

Jeżeli pracownik potrzebuje poznać produkt open source np. w celu dokonania konkurencyjnej analizy funkcjonalności (competitive inteligence), czy przetestowania możliwości współpracy między produktami open source a produktami własnej firmy, to dokonuje zgłoszenia użycia OSS właśnie w modelu „na potrzeby własne”. W związku z tym duża odpowiedzialność spoczywa na pracowniku. W formularzu – z podłączonym obiegiem dokumentów – wprowadzamy odpowiednie informacje, specyfikując zakres użycia danego produktu, i, jeśli produkt jest objęty jedną z dopuszczonych do takiego użycia licencji, otrzymujemy automatyczną zgodę na korzystanie z produktu.

W sytuacji badań porównawczych konkurencji pojawiają się dodatkowe ograniczenia dotyczące wyników takich porównań. Na przykład, nie jest dozwolone publikowanie wyników porównań poza organizacją, jeśli w analizie były użyte produkty w fazie rozwoju innej niż „wspierana rynkowa”. Pozostałe ograniczenia nie dotyczą już strony technicznej, a raczej kodeksu postępowania pracowników i dobrych zasad biznesowych.

Użycie kodu we własnych produktach

Wykorzystanie gotowych bibliotek dostępnych jest doskonałym sposobem na zwiększenie efektywności i wydajności programistów, poprawia również rentowność projektu. Są również sytuacje, w których unikanie wykorzystania „obcego” kodu byłoby bezsensowne i nieuzasadnione ekonomicznie. Przykładowo, jeżeli tworzymy rozszerzenie do produktu open source w celu zapewnienia wsparcia konkretnego protokołu, czy formatu plików, to oczywiste jest użycie bibliotek pochodzących z tamtego produktu zamiast tworzenie własnych. Taki kod może również być użyty w usługach sieciowych, mogą to być także skrypty uruchamiane po stronie użytkownika.

Proces zarządzania dołączeniem kodu do własnych produktów jest najbardziej skomplikowany.  Absolutnie krytyczna jest dobra znajomość specyfiki licencji, którym podlega używany kod i uzyskanie zgody działu prawnego. Jeśli firma nadal chce zachować możliwość dystrybucji swojego produktu w modelu licencji komercyjnej, lista licencji, z którymi możliwa jest współpraca ulega skróceniu. Licencje Copyleft wymagają bowiem by wszelkie produkty powstałe z użyciem jakiegokolwiek kodu udostępnianego w taki sposób również były w przyszłości udostępniane na tej samej licencji Copyleft. Konieczne jest więc bardzo dokładne sprawdzenie licencji, jakim podlega użyty kod.

Dobrą praktyką (ale nie jest to wymóg prawny) może być wprowadzenie metodyki oznaczania kodu open source – w Microsoft obowiązuje specjalna zasada znakowania obcego kodu, tak, aby każdy inny programista od razu widział, że ma do czynienia z kodem pochodzącym od podmiotów trzecich. Oprócz znakowania kodu, wymagane jest dołączanie szczegółowej informacji skąd i kiedy kod został pobrany, a także dołączenie wszystkich wymaganych plików (typu readme.txt czy licence.txt) wymaganych przez oryginalną licencję. Zaleca się także przechowywanie takiego kodu w oddzielnych repozytoriach w odpowiedni sposób oznaczonych.

W tym modelu użycia open source wymagane są konsultacje w grupach biznesowych związanych z produktem. Zwłaszcza w zakresie planowanego rozwoju produktu, abyśmy – wprowadzając do programu kod strony trzeciej – nawet całkowicie zgodnie z zasadami licencji – nie spowodowali zagrożenia patentowego (specyfika amerykańskiego prawa patentowego – „first to invent”).

Zaangażowanie w trwających projektach

Gdy mówimy o zaangażowaniu programistów firmy komercyjnej w trwających projektach open source, to sytuacja jest trochę prostsza od strony licencji, ale chyba najtrudniejsza, jeśli chodzi o zarządzanie kwestiami własności intelektualnych. O ile bezdyskusyjne jest wsparcie projektów w zakresie np. lokalizacji produktu, o tyle czysto programistyczne wsparcie projektów (tworzenie nowego kodu, poprawki i uzupełnienia) niesie już za sobą więcej wyzwań. Nie ma wprawdzie znaczenia, na jakiej licencji będzie udostępniany projekt, ważniejsze jest natomiast, aby kod, który jest wnoszony do projektu przez „naszych” programistów był bezpieczny od strony własności intelektualnej i praw patentowych. Konieczne są więc szczegółowe, bieżące uzgodnienia z grupami produktowymi dotyczące przyszłej funkcjonalności naszych produktów i ich obszarów wspólnych ze wspieranym projektem. Przed rozpoczęciem pracy w danym projekcie dział prawny zobowiązany jest dokonać analizy zasad wprowadzania kodu do projektu (contribution agreement), aby upewnić się, że nie niosą one ze sobą jakiegoś dodatkowego zobowiązania. Na szczęście jednak istnieją dwie zasady ułatwiające życie chętnym – zasada „de minimis no curat lex” oraz „sample code exception”.

Pierwsza (prawo nie troszczy się o drobiazgi) pozwala na wsparcie projektu w zakresie wszelkich poprawek i uzupełnień, które nie wprowadzają samodzielnie istotnych zmian funkcjonalności oraz nie są objęte jakimś ograniczeniem patentowym Microsoft (według wiedzy zespołu). Zasada druga (wyłączenie dla kodu przykładowego) obowiązuje dla wszelkich publikacji kodu do 1000 linii, objętego licencją Apache 2 lub Ms-PL1, własnego autorstwa, w 100% oryginalnego (nie może być użyty w żadnych istniejących produktach). Z założenia wyjątek ten został stworzony w celach edukacyjnych i stosuje się go często, jako przekazanie dobrych praktyk, typowych technik, wspomaganie wdrożeń lub zilustrowanie określonego scenariusza. Może on jednak posłużyć również w celu wspomagania projektów open source.

Udostępnienie produktu na otwartej licencji

Chyba najmniej skomplikowany model z wymienionych. Od strony prawnej wymaga tylko zgłoszenia, że chcemy taki projekt realizować i wybrania licencji, na której projekt zostanie udostępniony. Obowiązują zresztą te same wyjątki jak wcześniej, chociaż trudno chyba wyobrazić sobie w pełni funkcjonalny produkt napisany w 1000 liniach kodu. Trochę trudniej jest od strony funkcjonalności – podobnie, jak w wypadku współuczestnictwa w projektach, tak i tutaj musimy bardzo dokładnie przestrzegać uzgodnień z grupami produktowymi i na bieżąco konsultować planowane funkcjonalności.

Obszar uzgodnień produktowych i zagrożeń patentowych jest krytyczny w chwili, gdy w otwartych projektach biorą udział programiści na co dzień zaangażowani w rozwój naszego produktu. Mózg ludzki pracuje w sposób podświadomy i działając w obszarze jakiegoś problemu, możemy podświadomie problem „rozwiązać”, gdy przełączymy się na inny tok myślenia. Potem może się okazać, że programista wykorzystał swój pomysł i napisał kod w obydwu projektach taki sam, i – bez żadnej złej woli ze strony pracownika – firma może mieć w przyszłości problemy natury prawno-patentowej. Pragnąc uniknąć takich zagrożeń Microsoft powołał spółkę-córkę – Microsoft Open Technologies, której pracownicy na co dzień nie są włączeni w pracę nad typowymi produktami tego koncernu i mogą bez ograniczeń poświecić się tworzeniu oprogramowania udostępnianego na licencjach otwartych. Możliwe jest również zwiększenie swoich możliwości biznesowych poprzez modyfikację wybranej licencji (w sytuacji, gdy jest to możliwe), albo zastosowanie modelu podwójnego licencjonowania (użycie komercyjne i niekomercyjne).

Jak wdrożyć zarządzanie użyciem OSS w firmie

Na koniec trzeba pamiętać, że OSS jest chroniony prawnie i są organizacje (fundacje parasolowe) – także w Polsce, które zajmują się prawną ochroną otwartych projektów. W zespołach współpracują prawnicy zajmujący się prawem własności intelektualnej i prawem patentowym z inżynierami, programistami i kierownikami otwartych projektów. Dbając o rozwój otwartego oprogramowania organizacje te świadczą także usługi dla firm komercyjnych, pomagając wdrażać procesy zarządzania użyciem OSS. Zdobyte w ten sposób środki przeznaczane są na wsparcie otwartych projektów.

Podstawą jest stworzenie lub opisanie istniejących modeli użycia oprogramowania open source i ich precyzyjne zdefiniowanie oraz przygotowanie odpowiedniego procesu użycia programu. Proces szczegółowo wylicza licencje OSI dopuszczone w każdym z modeli użycia, określa niezbędne dokumenty i ustala zakres odpowiedzialności pracownika.

1. 1. Użycie w codziennej pracy – Microsoft przyjmuje dwie nadrzędne zasady dla tej definicji: absolutne przestrzeganie wszystkich wymagań licencyjnych, jakim podlega program, którego chcemy użyć; całkowita separacja scenariuszy użycia kodu programów w tym modelu użycia od jakiegokolwiek kontaktu z klientem. W środowiskach czysto deweloperskich możemy więc używać np. automatów testujących, czy kompilatorów kodu, ale zabronione byłoby użycie analizatora składniowego (parsera), ponieważ powoduje on zmianę w kodzie źródłowym analizowanego programu.
2. 2. Użycie we własnych produktach – W Microsoft obowiązuje specjalna zasada znakowania obcego kodu, tak, aby każdy inny programista od razu widział, że ma do czynienia z kodem pochodzącym od podmiotów trzecich. Oprócz znakowania kodu, wymagane jest dołączanie szczegółowej informacji skąd i kiedy kod został pobrany, a także dołączenie wszystkich wymaganych plików (typu readme.txt czy licence.txt) wymaganych przez oryginalną licencję. Zaleca się także przechowywanie takiego kodu w oddzielnych repozytoriach w odpowiedni sposób oznaczonych.
3. 3. Zaangażowanie w trwających projektach open source – Microsoft pozwala na wsparcie projektu w zakresie wszelkich poprawek i uzupełnień, które nie wprowadzają samodzielnie istotnych zmian funkcjonalności oraz nie są objęte jakimś ograniczeniem patentowym Microsoft.
4. 4. Udostępnienie produktu na otwartej licencji – Microsoft powołał spółkę-córkę Microsoft Open Technologies, której pracownicy na co dzień nie są włączeni w pracę nad typowymi produktami tego koncernu i mogą się bez ograniczeń poświecić tworzeniu oprogramowania udostępnianego na licencjach otwartych.

Ryszard Dałkowski jest właściciel i konsultantem w firmie Exertum