Producent programów informatycznych a licencja i gwarancja produktu

Licencja na program i własność kodu

Producent programów informatycznych dostarcza użytkownikowi prawo do korzystania z programu, a nie sam program w sensie własności. Umowa licencyjna określa, kto może go używać, na ilu stanowiskach, w jakim zakresie i przez jaki czas. Prawa autorskie do kodu zostają zwykle u producenta, chyba że umowa o wykonanie oprogramowania przenosi je na zamawiającego.

Rozróżnienie ma znaczenie przy audycie oraz zmianie dostawcy, a także przy sprzedaży firmy, bo wtedy trzeba wykazać, jakie prawa faktycznie przysługują. Zapis o licencji powinien być więc równie dokładny jak zapis o cenie. Zakres oraz liczba użytkowników muszą wynikać z dokumentu, podobnie jak okres ważności, a nie z ustnych ustaleń.

Modele licencjonowania

Ten sam program można licencjonować na kilka sposobów, a wybrana jednostka rozliczenia wpływa na koszt przy wzroście firmy. Poniższa tabela zestawia najczęstsze modele.

Przy modelu współbieżnym program musi umieć policzyć aktywne sesje. Zapytanie poniżej ilustruje mechanizm liczenia zalogowanych użytkowników w bazie SQL Server. Tabela i kolumny są przykładowe i nie opisują schematu produktu.

SELECT COUNT(DISTINCT UzytkownikId) AS ZalogowaniTeraz
FROM dbo.SesjaUzytkownika
WHERE Wygasa > SYSDATETIME();

Wynik porównuje się z limitem z umowy. Przy przekroczeniu program może odmówić nowej sesji albo tylko zapisać zdarzenie w dzienniku, co zależy od zapisów licencji. Różnicę warto ustalić przed wdrożeniem, bo blokada logowania w środku zmiany zatrzymuje pracę magazynu.

Licencje na składniki osób trzecich

Program zwykle korzysta z komponentów, które mają własne licencje, na przykład z systemu operacyjnego i silnika bazy danych. Licencja na aplikację nie obejmuje ich automatycznie. Edycje SQL Server różnią się limitami zasobów i dostępnymi funkcjami, co opisuje dokumentacja edycji i składników SQL Server w Microsoft Learn. Edycja Express ma na przykład ograniczony rozmiar pojedynczej bazy.

Wymagania serwera i licencje w konkretnym produkcie zbiera specyfikacja programu WMS.net dla działu IT, a rachunek kosztów w kilku latach pokazuje tekst o licencji jednorazowej i abonamencie.

Reguła: licencja na program nie zawiera licencji na bazę danych ani na system operacyjny, chyba że umowa wymienia je wprost.

Kod źródłowy i depozyt

Zamawiający, który nie nabywa praw do kodu, zabezpiecza się czasem depozytem kodu źródłowego. Kod trafia do niezależnego podmiotu, a umowa wskazuje warunki jego wydania, na przykład upadłość producenta albo zaprzestanie wsparcia. Bez takiego zapisu klient pozostaje uzależniony od dostawcy, nawet gdy program działa poprawnie.

Rejestr licencji w organizacji

Licencje wymagają ewidencji po stronie klienta. Rejestr zawiera numer i typ licencji oraz liczbę stanowisk lub sesji, a także datę ważności i osobę odpowiedzialną za odnowienie. Bez rejestru wygasająca subskrypcja zaskakuje dział IT dopiero wtedy, gdy program przestaje się uruchamiać.

Ewidencja pomaga również przy audycie. Producent może zażądać wykazu instalacji, a firma, która ma go pod ręką, kończy kontrolę w jeden dzień. Gdy liczba stanowisk rośnie szybciej niż liczba licencji, rejestr pokazuje różnicę przed audytem, nie po nim.

Dane klienta po zakończeniu umowy

Licencja wygasa, ale dane zapisane w programie pozostają własnością klienta. Umowa powinna określać format eksportu, na przykład pliki CSV albo kopię bazy z opisem schematu, oraz czas, w którym producent wykona eksport i usunie kopie po swojej stronie. Opis bazy z pakietu dokumentacji pozwala wtedy przenieść dane do innego systemu bez odtwarzania struktury z zapytań.

Dokumentacja produktu i jej odbiorcy

Program bez dokumentacji jest trudny do utrzymania, ponieważ wiedza o nim zostaje w głowach osób, które go wdrożyły. Producent przekazuje więc zestaw dokumentów, z których każdy ma innego odbiorcę i inny cykl aktualizacji.

Dokumentacja administratora

Ten dokument decyduje o tym, czy firma poradzi sobie po odejściu osoby, która instalowała system. Powinien opisywać kolejność instalacji, ustawienia serwera aplikacji i bazy oraz zasady tworzenia kopii. Panel ustawień programu magazynowego, w którym administrator klienta dopasowuje menu i uprawnienia oraz raporty, opisuje strona o konfiguracji programu magazynowego.

Szablony wydruków i raportów należą do dokumentacji tak samo jak kod. Pliki definicji raportów w formacie RDL przechowuje się razem z wersją programu, co omawia tekst o raportach RDL i wydrukach w SQL Report Builder. Dzięki temu po aktualizacji wiadomo, który szablon pasuje do której wersji.

Dokumentacja w projekcie na zamówienie

Przy oprogramowaniu tworzonym na zamówienie do zestawu dochodzą dokumenty z fazy przygotowania. Analiza przedwdrożeniowa kończy się specyfikacją funkcjonalną, a projekt architektury uwzględnia istniejącą infrastrukturę i planowane integracje. Znaczenie tej fazy opisuje strona o analizie przedwdrożeniowej. Specyfikacja staje się później miarą odbioru, bo odpowiada na pytanie, czy program robi to, co uzgodniono.

Przy odbiorze dokumentacji sprawdza się cztery cechy, które przesądzają o jej użyteczności.

• Aktualność - dokument wskazuje numer wersji programu, której dotyczy.
• Kompletność - wszystkie moduły dostarczone w projekcie mają opis.
• Odtwarzalność - administrator potrafi na jego podstawie zainstalować środowisko testowe.
• Dostępność - dokument jest przekazany w formie, którą klient może przechowywać i przeszukiwać.

Aktualizacje i prawo do nowych wydań

Licencja nie mówi sama, czy klient ma prawo do nowych wersji. Zapis o aktualizacjach jest osobnym elementem umowy i zwykle wiąże się z opłatą za asystę powdrożeniową. Tekst o kosztach oprogramowania magazynowego wymienia tę opłatę wśród składników całkowitego kosztu posiadania, do których należą też licencja i wdrożenie oraz szkolenia i rozszerzenia.

W modelu SaaS aktualizacje wykonuje dostawca, a użytkownik nie instaluje niczego lokalnie. W instalacji lokalnej aktualizacja jest zadaniem wspólnym producenta i działu IT klienta. Numerację wersji i rodzaje wydań opisuje tekst o cyklu wydań produktu, więc tutaj istotne jest tylko to, co umowa gwarantuje przy każdym z nich.

Zgodność programu z bazą po aktualizacji

Aplikacja i baza muszą pochodzić z tej samej serii wydań, żeby aktualizację uznać za zakończoną. Program może to sprawdzać przy starcie i odmawiać pracy na bazie w niezgodnej wersji, zamiast po cichu uszkadzać dane. Poniższy fragment w języku C# ilustruje to sprawdzenie. Metoda odczytu wersji schematu jest przykładowa.

Version aplikacja = typeof(Program).Assembly.GetName().Version;
Version schemat = PobierzWersjeSchematu(polaczenie);

if (schemat.Major != aplikacja.Major)
{
    throw new InvalidOperationException(
        "Baza ma wersję " + schemat + ", a aplikacja " + aplikacja + ". Uruchom aktualizację.");
}

Cykl wsparcia składników platformy

Producent programu odpowiada za własny kod, natomiast składniki platformy mają własny cykl wsparcia. W polityce stałego cyklu życia Microsoft opisuje wsparcie podstawowe przez co najmniej pięć lat oraz dodatkowy okres wsparcia dla niektórych produktów, co przedstawia strona o stałej polityce cyklu życia produktów Microsoft. Po zakończeniu wsparcia platformy aktualizacja programu staje się kwestią bezpieczeństwa, nie wygody.

Gwarancja a rękojmia i wsparcie po odbiorze

Trzy pojęcia bywają używane zamiennie, choć opisują różne zobowiązania. Gwarancja jest dobrowolnym oświadczeniem producenta, a jej zakres oraz czas wynikają z dokumentu gwarancyjnego lub umowy. Rękojmia wynika z przepisów Kodeksu cywilnego, a w relacjach między przedsiębiorcami umowa może ją ukształtować odmiennie, dlatego jej zakres warto potwierdzić z prawnikiem.

Rozróżnienie rękojmi i gwarancji przy reklamacjach towarów opisuje tekst o podstawie prawnej reklamacji w Studio RMA.net. Ta sama logika odnosi się do oprogramowania, o ile umowa nie stanowi inaczej.

Błąd czy zmiana wymagań

Najczęstszy spór po odbiorze dotyczy tego, czy zgłoszenie jest błędem objętym gwarancją, czy życzeniem nowej funkcji. Miarą jest specyfikacja przyjęta przy odbiorze. Odstępstwo od uzgodnionego opisu jest wadą, a funkcja spoza opisu jest zmianą i wymaga wyceny.

Reguła: wada oznacza odstępstwo od specyfikacji odbiorowej, a nowe oczekiwanie jest zmianą zakresu.

Okres gwarancji i jego początek

Okres gwarancji liczy się od podpisania protokołu odbioru, a nie od dnia instalacji. Umowa powinna wskazywać, co ten okres przerywa, na przykład zmiany w kodzie lub w bazie wykonane przez osobę niezwiązaną z producentem. Bez takiego zapisu każda ingerencja klienta w środowisko staje się potencjalnym sporem o przyczynę błędu.

Wyłączenia z gwarancji

Umowy wymieniają sytuacje, w których producent nie odpowiada za nieprawidłowe działanie programu. Zwykle są to awarie sprzętu i sieci klienta oraz błędy w danych wprowadzonych przez użytkowników. Wyłączeniem bywa też zmiana środowiska wykonana bez uzgodnienia, na przykład przeniesienie bazy na inny serwer.

Wyłączenia nie zwalniają producenta z diagnozy, bo przyczynę trzeba wskazać, żeby uznać zgłoszenie za leżące poza gwarancją. Z tego powodu dziennik zdarzeń programu i logi serwera stanowią materiał dowodowy dla obu stron, a ich przechowywanie warto opisać w dokumentacji administratora.

Wsparcie i umowa SLA

Warunki reakcji i dostępności wsparcia określa umowa SLA dopasowana do skali i charakteru wdrożenia. Opisuje ona kategorie zgłoszeń, czas reakcji na każdą z nich oraz godziny, w których wsparcie jest dostępne. Konkretne wartości ustala się w umowie, a nie w opisie produktu, dlatego ta strona ich nie podaje.

Odbiór programu i przekazanie dokumentów

Odbiór jest momentem, w którym ryzyko przechodzi na klienta, więc powinien mieć formalny protokół. Zawiera on wynik testów, listę znanych ograniczeń i wykaz przekazanych dokumentów. Szkolenia poprzedzają uruchomienie, aby zespół klienta od pierwszego dnia pracował na nowym narzędziu. Przygotowanie zespołu w magazynie opisuje strona o wdrożeniu systemu WMS i przygotowaniu zespołu.

Technologie i formaty dostawy programu

Forma dostawy wpływa na licencję i dokumentację oraz na sposób aktualizacji. SoftwareStudio wymienia w ofercie Microsoft Visual Studio oraz języki C# i Java, a logikę bazodanową zapisuje w T-SQL na bazie MS SQL Server. Warstwę webową buduje na platformie .NET, w tym ASP.NET, o czym pisze także strona o aplikacjach webowych.

• Aplikacja Windows - program w wersji Forms Edition, instalowany na stacjach roboczych i aktualizowany osobno.
• Aplikacja webowa - program dostępny z przeglądarki, aktualizowany na serwerze.
• Aplikacja mobilna - dedykowany program na wybrane platformy, komunikujący się z głównym systemem.
• Raporty SSRS - definicje raportów w formatach HTML oraz PDF, a także Excel, przechowywane w usłudze raportowej.

Raporty SQL Server Reporting Services są dostarczane razem z programem, a ich subskrypcje i harmonogramy opisuje tekst o Reporting Services i subskrypcjach raportów. Każdy z czterech formatów ma inne konsekwencje dla dokumentacji: aplikacja Windows wymaga instrukcji instalacji klienta, a raporty potrzebują opisu źródeł danych.

Ogólne zasady współpracy przy programach tworzonych na indywidualne zamówienie opisuje strona o tworzeniu programów informatycznych, a zakres usług wykonawcy zbiera oferta usług SoftwareStudio.