Z jednej strony kody źródłowe są największym dobrem producentów oprogramowania. Od utrzymania ich w tajemnicy zależy byt firmy programistycznej. Z drugiej, klienci często żądają dostępu do kodów źródłowych, czasem tylko tak, na wszelki wypadek. Jaka jest zatem praktyka w tym zakresie na polskim rynku IT?

Na początku lat 90. Dyrekcja Generalna Lasów Państwowych (DGLP) ogłosiła przetarg na dostawy sprzętu i oprogramowania na potrzeby kompleksowego systemu informatycznego. Wygrała go firma Hewlett-Packard. Wówczas dział usług w polskim oddziale firmy był znacznie mniejszy niż obecnie. W kontrakcie zawarto więc warunek, że zanim leśnicy kupią sprzęt, musi powstać aplikacja. HP zarekomendował partnera - austriacką firmę SchnellDataServise-SDS.

Współpraca trwała sześć lat. Niestety, SDS zbankrutowała przed przekazaniem kodów źródłowych Lasom Państwowym. Zmarł właściciel firmy i sprawy spadkowe na długo zablokowały dostęp do nich. "Zdarzało się, że część poprawek została wykonana przez programistów Lasów Państwowych w formie nakładek programistycznych" - wyjaśnia Jerzy Zieliński, naczelnik Wydziału Informatyki DGLP. "Przykładowo, proces liczenia podatku był obarczony błędem, który powodował zaniżenie wyliczonego podatku o 5%. Nie dociekając, dlaczego tak się dzieje, programiści dopisywali niewielki program, który do wyniku uzyskanego z głównego systemu dodawał 5%. Użytkownik nie miał powodu do narzekań" - dodaje. Po latach Lasy Państwowe uzyskały wreszcie kody źródłowe do swojego oprogramowania i teraz samodzielnie go rozwijają.

Pierwsze kody za płoty

Przypadek Lasów Państwowych - ale również wielu instytucji i przedsiębiorstw - wskazuje, że dostęp do kodów źródłowych należy do kwestii zasadniczych, które muszą pojawić się w umowie na budowę systemu informatycznego. Dostawcy obierają jednak bardzo różną strategię ich udostępniania.

"Udostępniamy kody aplikacji" - wyjaśnia Paweł Piwowar, prezes Oracle Polska. "Natomiast nie ma mowy o ujawnieniu kodu jądra systemu, bo wtedy wystawilibyśmy na widok publiczny algorytmy kompresji danych, szyfrowania i replikacji" - dodaje. Ta polityka pozwala klientowi na modyfikowanie aplikacji czy też przenoszenie jej na inną platformę sprzętową, zarazem zabezpiecza żywotne interesy producenta. Zresztą kody źródłowe motoru bazy danych Oracle przechowuje w jednym miejscu na świecie. "Gdybyśmy je udostępniali, to tak jakbyśmy podawali każdemu przechodniowi numer karty kredytowej" - komentuje.

Inną politykę w zakresie kodów źródłowych prowadzi SAP. "Zakładamy, że cykl «życia» produktu wynosi 15-20 lat. Kod źródłowy, aktualizowany z każdą wprowadzoną zmianą czy pakietem korekcyjnym, daje klientowi bezpieczeństwo i gwarancję podtrzymania aplikacji" - mówi Jan Rey, architekt rozwiązań biznesowych w SAP Polska. Ale nie tylko. Przykładowo, w KGHM Polska Miedź, PKN Orlen, Anwilu czy sieci sklepów Żabka Polska, w których wrocławski IMG instalował system SAP, powstały duże zespoły informatyków wyspecjalizowanych w tworzeniu aplikacji w środowisku ABAP. "Licencja SAP zezwala na wstawianie fragmentów własnego kodu napisanego w języku ABAP, w którym został napisany cały system" - opowiada Marcin Granowski z IMG. Jego zdaniem to element przewagi konkurencyjnej rozwiązań SAP, umożliwiający tworzenie np. dodatkowych raportów. Nic nie stoi również na przeszkodzie, by właściciel licencji napisał program, w którym zostanie wykorzystany znaczący fragment kodu SAP. Z jednej strony uniezależnia to klienta od producenta oprogramowania, z drugiej w pewnym stopniu wymusza tworzenie własnych programów w jednorodnym środowisku. "Warunek jest jeden, by wprowadzić zmiany w kodzie, musi być pobrany klucz dostępu identyfikujący zmieniany obiekt i użytkownika-programistę, aby nasza obsługa asysty technicznej wiedziała o istnieniu zmiany w tym miejscu. Ponadto kod dopisany w przygotowanych przez SAP miejscach, zwanych user exits, jest przy nowych wersjach traktowany jak ważne dane klienta i nie narusza warunków gwarancji" - zaznacza Jan Rey.