Mimo zaklęć i inwektyw, oprogramowanie open source nie zniknie z powierzchni ziemi. Ze względu na to, że coraz więcej aplikacji ma darmowe odpowiedniki, producenci systemów informatycznych muszą nauczyć się żyć w nowych realiach.

Stale rosnąca popularność oprogramowania open source dostępnego wraz z kodem źródłowym zmusza firmy parające się produkcją oprogramowania komercyjnego do ustosunkowania się do tego zjawiska. Dla niemal każdego systemu komercyjnego istnieje mniej lub bardziej rozwinięta "otwarta", niekomercyjna alternatywa.

Ignorowanie open source nie jest rozsądne i wielu menedżerów ma tego świadomość. Jednocześnie jednak wielu z nich nie potrafi przeprowadzić właściwej analizy potencjalnego wpływu open source na biznes produkcji oprogramowania. Najłatwiej jest ustawić się "na nie" i dlatego w biznesowej analizie SWOT (Strengths, Weaknesses, Opportunities, Threats) wolne oprogramowanie można najczęściej znaleźć pod literą "T". Być może nie do końca słusznie.

Z biznesowego punktu widzenia open source może być zarówno zagrożeniem, jak i sprzymierzeńcem. Wszystko zależy od umiejętności i chęci zrozumienia szczegółów tego, co kryje się pod pojemnym określeniem open source: metodologii rozwoju oprogramowania, różnych sposobów licencjonowania oraz zasad funkcjonowania społeczności użytkowników i deweloperów.

Licencyjne kruczki

O zaletach rozwoju oprogramowania metodą open source napisano już tomy i sprawa ta nie podlega dyskusji. Wiele firm komercyjnych z powodzeniem nauczyło się wykorzystywać dorobek organizacyjny i narzędziowy słynnych projektów open source. Obszarem wciąż mało rozpoznanym przez świat biznesu software'owego są kwestie licencjonowania. Producent oprogramowania może korzystać z dorobku open source w sposób bierny, tj. dołączać go do własnych produktów, lub też aktywny - udostępniając cały kod własnych produktów na warunkach jednej z licencji open source. O tym, jakie potencjalnie korzyści firma może osiągać, stanowi właściwy dobór licencji.

Licencje open source nie nakładają ograniczeń na użytkowanie oprogramowania - w wersji oryginalnej lub zmodyfikowanej. Ograniczenia pojawiają się dopiero wtedy, gdy firma zamierza rozpowszechniać kod objęty licencją open source lub jego wersję zmodyfikowaną. Oto, jak działają (w uproszczeniu) popularne licencje open source:

• licencja GPL (najpopularniejsza) wymaga udostępnienia kodu źródłowego aplikacji, w której wykorzystano kod źródłowy rozpowszechniany na warunkach tej licencji;

• licencja LGPL, często stosowana w bibliotekach programistycznych rozpowszechnianych na zasadach open source, umożliwia integrację z oprogramowaniem "zamkniętym";

• licencje BSD i pochodne pozwalają na umieszczenie kodu otwartego w oprogramowaniu zamkniętym; nie nakładają na firmę żadnych szczególnych zobowiązań, np. w niektórych wersjach tego typu licencji wymaga się wymienienia pierwotnego autora czy też właściciela praw autorskich do kodu.

Powyższe trzy typy licencji nie wyczerpują wszystkich możliwości. Organizacja Open Source Initiative proponuje łącznie ponad 30 różnych wersji porozumień licencyjnych. Wiele z nich, w tym np. BSD, X, MIT, jest powszechnie stosowanych w świecie komercyjnym. Przykładowo, Apple w swoich produktach wykorzystuje kod objęty licencjami FreeBSD, a IBM i Oracle - Apache. Dużo firm oferuje produkty zawierające silnik PostgreSQL. Jest to możliwe dzięki liberalnej formule licencji z serii BSD.

Nierzadkie są również przypadki wykorzystywania w zamkniętym oprogramowaniu bibliotek rozpowszechnianych na licencji LGPL. Przykładowo, program, którego graficzny interfejs użytkownika został napisany przy użyciu wieloplatformowej biblioteki GTK+, można rozpowszechniać bez wymogu udostępnienia jego kodu źródłowego. Oczywistą korzyścią płynącą z takiej sytuacji jest możliwość darmowego wykorzystania stale rozwijanej biblioteki.

Licencja GPL budzi najwięcej kontrowersji, jest też najczęściej krytykowana przez Microsoft. U podłoża owej krytyki leży podstawowa cecha GPL: z kodu udostępnianego na warunkach tej licencji można korzystać do woli, pod warunkiem że efekt zmian również zostanie udostępniony na warunkach GPL. To dlatego Microsoft nazywa GPL licencją "wirusową", argumentując, że w przyszłości firmy tworzące oprogramowanie będą miały coraz mniejszą możliwość manewru, zwłaszcza jeśli poważna część infrastruktury internetowej będzie obsługiwana przez oprogramowanie na licencji GPL.

Oczywiście, licencja GPL nie jest pozbawiona wad - powstała 13 lat temu, kiedy trudno było przewidzieć zmiany w sposobie wykorzystania oprogramowania. Dobrym przykładem jest wykorzystywanie kodu GPL - nie do końca zgodnie z intencjami twórców oprogramowania - przez firmy oferujące wynajem aplikacji w modelu ASP. W tym przypadku kod nie jest rozpowszechniany, nie istnieje więc wymóg relicencjonowania zamkniętego kodu na warunkach GPL. Tak więc, wg obecnej wersji GPL, możemy wykorzystać kod GPL w oprogramowaniu udostępnianym np. przez CGI na witrynie WWW. Użytkownik nie ma bowiem dostępu do samego programu, lecz tylko do rezultatu jego pracy. Powstająca właśnie licencja GPL w wersji 3 ma być pozbawiona tych niedociągnięć.

Czy to się opłaca

Zupełnie inaczej wyglądają rozważania o tym, na jakiej konkretnie licencji open source udostępnić oprogramowanie stanowiące dotychczas własność firmy. Popularność licencji GPL wynika nie tylko z jej otwartego ducha, ale także z faktu, że udostępnienie kodu na jej warunkach uniemożliwia wykorzystanie kodu przez konkurenta - chyba że on także zdecyduje się na publikację swojego kodu na licencji GPL.

Z punktu widzenia interesów producenta oprogramowania wybór licencji z serii BSD jest zazwyczaj najmniej pożądany. Posługując się nią, firma praktycznie zgadza się, by rezultat pracy jej programistów został włączony do produktów innych firm, często konkurencji, jednak bez obowiązku odkrywania własnych sekretów. Licencja BSD, określana często jako "najbardziej przyjazna dla biznesu", oferuje najwięcej tym, którzy korzystają z oprogramowania rozpowszechnianego na jej warunkach, samym jego twórcom proponuje zaś niewiele. Takie są realia formalne, w praktyce jednak często zdarza się, że firma korzystająca z kodu BSD "zwraca" projektowi rozwijane przez siebie poprawki czy nawet dodatkową funkcjonalność, ponieważ zależy jej na tym, by główne drzewo projektu było synchronizowane z gałęzią rozwijaną wewnątrz firmy. Taki przypadek ma miejsce m.in. w przypadku Apple.

W odniesieniu do kodu szczególnie wartościowego, np. zawierającego unikalne algorytmy lub pomysły, często stosowane jest podwójne licencjonowanie. Przykładem może być MySQL AB, szwedzka firma oferująca serwer bazodanowy MySQL na dwóch licencjach: GPL i płatnej, której zakup jest niezbędny wtedy, gdy chcemy rozpowszechniać zamknięty produkt zawierający kod źródłowy MySQL. Z płatnych licencji MySQL korzysta m.in. Novell, który zdecydował się użyć kodu MySQL w swoich produktach.

Udostępnienie kodu źródłowego można potraktować jako dodatkowy kanał komunikacji marketingowej z istniejącymi i potencjalnymi klientami. Dotyczy to zwłaszcza sytuacji, kiedy jest udostępniany kod źródłowy produktów dodatkowych, silnie związanych z głównymi produktami generującymi przychód firmy. Otwarcie źródeł w tym przypadku może być trafną decyzją marketingową, może również przyciągnąć deweloperów skłonnych rozwijać dany projekt. Jednak nie musi.