Robert Ratajczak

adwokat

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed vehicula mi sit amet tellus feugiat; a tempor ligula cursus. Phasellus euismod arcu id finibus aliquam!
[Więcej >>>]

Skontaktuj się

Elementy oprogramowania

Robert Ratajczak29 kwietnia 2016Komentarze (0)

15619815425_362a22bb50Jak pewnie zauważyłeś, częstym tematem na moim blogu jest ogólnie pojęta tematyka IT w kontekście praw autorskich. Tak jak Ci już kiedyś pisałem, wynika to w dużej części z tego, że znaczna część mojej praktyki jest związana z tym zagadnieniem.

Jedna rzecz, od której każdy prawnik mający styczność z oprogramowaniem musi pamiętać, to fakt, że oprogramowanie składa się z określonych elementów, z których nie każdy podlega ochronie przez prawo autorskiej. Poniżej znajdziesz opis tych elementów, większość z nich będzie osobno analizowana w tym również, jeśli chodzi o prawa autorskie.

Analizę rozpocząć należy od warstwy tekstowej ? najpierw powstaje algorytm. To jest baza, która jest następnie przetwarzana na kod źródłowy i maszynowy. To algorytm właśnie (lub algorytmy) oddaje tok myślowy i proces tworzenia oprogramowania.

Kod źródłowy jest natomiast zapisem algorytmu w języku programowania (wysokiego poziomu lub w języku asemblera), i jako taki jest nieczytelny dla komputera. Dopiero język maszynowy powstający na skutek tłumaczenia kodów źródłowych lub asemblerowych może być odczytany przez komputer. Jest on zapisywany w języku tzw. niskiego poziomu. Taki język jest już odczytywany przez komputer, nie ma jednak możliwości odczytania go przez człowieka (śmiało więc można go przekazywać drugiej stronie 🙂 . Tu jest dużo argumentów przeciw uznaniu ochrony prawno-autorskiej kodu wynikowego, ponieważ jest on tworzony przez maszynę automatycznie i jest zapisywany w pamięci komputera. Stąd też ochrony w tym zakresie powinniśmy poszukiwać poza prawem autorskim (patenty, ochrona w zakresie umów nienazwanych).

Warstwa tekstowa oprogramowania to nie wszystko. Jak wiadomo najważniejsze dla odbiorcy jest to, co widzi i to jak mu się pracuje na danym oprogramowaniu. Te elementy wchodzą już w zakres warstwy niezwiązanej z tekstem. To jest wszystko to, co widzimy i na czym pracujemy (popularnie nazywa się tą warstwę ?look ?n feel?). Ustalenia czy, a jeśli tak to, które elementy z tej warstwy podlegają ochronie autorskiej wymaga każdorazowej analizy. Spośród elementów tej warstwy można wymienić: interfejsy, skróty klawiszowe, funkcjonalności, warstwę graficzną.

To tyle tytułem ?rozkładu jazdy? w zakresie struktury oprogramowania J. Odpocznij w długi weekend, zbierz siły i od nowego miesiąca zapraszam na lekturę wpisów dedykowanych poszczególnym elementom oprogramowania.

Photo Credit: ethnosax via Compfight cc

SaaS a prawa autorskie

Robert Ratajczak22 kwietnia 2016Komentarze (0)

7164985816_5f8458066fDzisiejszym wpisem kontynuuję tematykę związaną z branżą IT. Czym jest tzw. SaaS?

Skrót ten pochodzi od sformułowania Software as a Service i dotyczy w dużym skrócie jednego z najdynamiczniej rozwijającego się segmentu rynku eksploatacji oprogramowania komputerowego.

W dużym skrócie model ten polega na tym, iż możemy korzystać, na warunkach określonych umową, z określonego oprogramowania, które znajduje się na serwerach dostawcy. My łączymy się z tym serwerem, gdy chcemy korzystać z oprogramowania. Nie ma, zatem potrzeby instalowania całego softwaru u nas lokalnie, najczęściej wystarczy przeglądarka internetowa, względnie jakieś wtyczki do niej, rzadziej końcówki klienckie instalowane u nas lokalnie na dysku. Znika, zatem problem hardwaru u klienta. Model ten wiąże się z duża wygodą dla każdej ze stron. Dostawca ma większą kontrolę nad oprogramowaniem, użytkownik zaś jest wolny od ciągłego wyścigu z aktualizacjami hardwaru, nie musi nadto instalować nic lokalnie, uaktualniać tego itd.

Pytanie jest następujące ? jak zidentyfikować taką umowę?
Odpowiedź niestety nie jest prosta 🙂 i zależy od wielu składowych (używanie oprogramowania w sposób okresowy czy też jednorazowy, czy dochodzi do zwielokrotnienia choćby elementów interfejsu oprogramowania towarzyszącego czy też nie, itp.)

Globalnie rzecz ujmując, najbliżej tej umowie jest do umowy o świadczenie usług, gdzie odpowiednio stosuje się przepisy kodeksu cywilnego dot. umowy zlecenia.

Przeciwko uznaniu umowy w zakresie SaaS za umowę licencyjną, (która na pierwszy rzut oka najczęściej przychodzi na myśl ? i to o dziwo również prawnikom) przemawia choćby fakt, że użytkownik nie uzyskuje bezpośredniego dostępu do utworu i co więcej, nie dochodzi do jego zwielokrotnienia. O licencji może być mowa w zakresie oprogramowania pomocniczego lub elementów interfejsu przesyłanych Internetem, jest to jednak wtedy osobna umowa, nieobejmująca swym zakresem umowy SaaS.

Jak więc widzisz, komplet regulacji dotyczący Saas w każdym konkretnym przypadku może przybierać różne konfiguracje, począwszy od jednej umowy cywilnoprawnej, po kilka umów obejmujących różne aspekty choćby transmisji obiektów w sieci Internet, w wykonaniu głównego celu umowy, jakim jest korzystania z oprogramowania.

Photo Credit: Kenny Nguyen Art via Compfight cc

NFZ a prawa autorskie

Robert Ratajczak09 lutego 20164 komentarze

388240719_4d67ae2891Dziś przy porannej kawie miałem okazję przeczytać artykuł dotyczący śledztwa jakie zostało wszczęte w związku z zaniedbaniami w NFZ, które narosły przez lata, a to w związku z obsługą informatyczną NFZ.

Link do artykułu znajduje się >tutaj<.

Okazuje się, że taka instytucja jak NFZ – wedle relacji prasowych – w umowach z wykonawcą dostarczającym system informatyczny, nie zabezpieczyła kwestii praw autorskich.

Szczerze mówiąc nie mieści mi się to w głowie, by nikt nie zwrócił uwagi na taki „detal”.Tłumaczenia jednej ze stron że wówczas taka była praktyka pozostawię bez komentarza….

Cóż, sposobów utraty pieniędzy jest mnóstwo, jak się okazuje prawa autorskie służą pomocą 🙂 Na poważnie jednak, mimo iż nie widziałem umów o których mowa w tym artykule, tak łatwo bym tematu nie odpuścił, być może dałoby radę wykazać że wolą stron, w ramach ustalonego wynagrodzenia, było przeniesie również praw autorskich, biorąc pod uwagę choćby wartość kontraktu, ale to już jest tylko gdybanie.

Zachęcam do lektury artykuł podlinkowanego wyżej.

Photo Credit: Tom Simpson via Compfight cc

Fixed Price czy Time & Material ?

Robert Ratajczak25 stycznia 20163 komentarze

6059188509_8c12001450Klienci firm IT co do zasady lubią mieć zamknięte budżety, chcą wiedzieć że poszczególne projekty nie przekroczą określonej przez dyrektorów finansowych górnych pułapów budżetu. Działa to trochę jak w branży motoryzacyjnej, księgowi decydują o wszystkim 😉

To problem bardzo często występujący w praktyce moich klientów i zdarza się że jest przyczyną wielu nieporozumień i konfliktów.

Zacznijmy jednak od początku, czym różni się Fixed Price od Time & Material ?

Zacznijmy od Fixed Price, w dużym skrócie sprowadza się to do modelu wynagrodzenia ryczałtowego, od początku jako zamawiający znamy budżet. Nie ważne co dzieje się w trakcie projektu, dodatkowe wynagrodzenie dla wykonawcy nie należy się. Z góry znamy zakres pracy i harmonogram. Często używa się porównania, że praca jest w tym przypadku wykonywana wodospadowo.

Tak jak pisałem, ta metodyka pracy jest popularna, ale ma też istotne wady. Logicznie rzecz biorąc nie leży przecież w interesie wykonawcy pokazywanie, po etapie analitycznym, klientowi zbyt dużo. Nie daj Boże dojdzie do rozszerzenia zakresu prac, a nikt nie lubi robić w tej samej cenie więcej niż na początku założył. Walka zaczyna się na etapie odbioru oprogramowania 🙂

Alternatywą jest metodyka pracy określana jako Time & Material, jest to przyrostowa metodyka zarządzania projektami. Projekt jest dzielony na mniejsze części tzw. sprinty lub itercje. Każdy sprint jest przedmiotem analizy, testów, i finalnie dany pakiet jest instalowany na instancji produkcyjnej klienta. To warunek przejścia z pracami dalej. Co istotne jednak, jest to bardzo partnerski model zarządzania projektem. W tym przypadku tworzony jest zespół z przedstawicieli obu stron, wymagane jest więc po stronie zamawiającego odpowiedni zaplecze IT. Wymagania zamawiającego często ewoluują, na bieżąco testowane są określone rozwiązania. W takim wypadku siłą rzeczy, nie ma zamkniętego budżetu, wynagradzane są poszczególne etapy prac, w zależności od sumy stawek godzinowych zespołu projektowego.

Moje doświadczenie z obsługi kilku firm z branży IT wskazują na przewagę modelu T&M. Zdarza się że projekt startuje jako Fixed Price, jednak zamawiający dojrzewa w toku prac, uznając wyższość modelu T&M, choć ostatnio zaliczyłem casus odwrotny, dla prawnika to mały koszmar 🙂

Photo Credit: Umberto Fistarol via Compfight cc

Specyfikacja wymagań użytkownika

Robert Ratajczak21 sierpnia 2015Komentarze (1)

 

12435854853_0648e5ab50W poprzednim wpisie pisałem o tym, że proces powstawania oprogramowania na zamówienie (lub dostosowanie już istniejącego) jest wieloetapowy, co siłą rzeczy znajduje swoje odzwierciedlenie w umowach regulujących te kwestie.

Niniejszy wpis ma za zadanie pokazać Ci jak wyglądają poszczególne etapy, ze szczególnym uwzględnieniem określenia wymagań użytkownika.

Informatycy cykle życia oprogramowania określają następująco:

  1. Określenie wymagań użytkownika,
  2. Wytworzenie oprogramowania,
  3. Wdrożenie,
  4. Eksploatacja,
  5. Serwis

Jest to tym samym rozkład jazdy dla każdego projektu IT.

Jak widzisz, etapem wyjściowym jest określenie wymagań użytkownika. Ma to sens. Najpierw, bowiem należy zidentyfikować potrzeby klienta, a więc: jaki jest cel powstania oprogramowania, jakie ma ono spełniać zadania, jak ma być używane (prostota obsługi, interfejs, szybkość działania), oraz w końcu zapewnić zgodność z innym oprogramowaniem działającym już u klienta (system operacyjny, inne oprogramowanie współpracujące).

Oprogramowanie, tak jak większość rzeczy, nie może funkcjonować w próżni. Dlatego też następnie przeprowadzane jest tzw. studium wykonalności, tj. ustala się i uwzględnia aspekty organizacyjne klienta, ludzkie, ekonomiczne i wiele innych.

Efektem powyższych działań jest utworzenie dokumentu – specyfikacji wymagań użytkownika. Dokument ten ma fundamentalne znaczenie w dalszych pracach, on zawiera wszystkie założenia, uwarunkowania i szczegóły. To jest, bowiem ten wzór do osiągnięcia, którego firma IT dąży, wykonując zlecenie.

Niestety często zdarza się tak, że w toku prac, po stronie klienta pojawiają się nowe pomysły i kwestie, które nie były pierwotnie brane pod uwagę.

Praktyka wtedy jest dwojaka: albo strony starają się udokumentować te nowe ustalenia w jakiejś formie, (co niestety, prędzej aniżeli później „rozjedzie” nam się z całą resztą), albo też, i to jest wzór do którego powinno się dążyć, należy powtórzyć w niezbędnym zakresie etap 1 opisany powyżej  i to dla dobra obu stron.

Niestety, jak to często w życiu bywa, problemem są pieniądze. Musisz, bowiem pamiętać, że prace firmy IT opisane wyżej, czyli określenie wymagań użytkownika, jest odpłatne, co jest zrozumiałe, bo angażuje zasoby tak czasu jak i pracowników wykonawcy. A nikt nie chce płacić dwa razy za (teoretycznie) to samo, nawet jak konieczność poniesienia tego kosztu jeszcze raz leży po stronie klienta.

Ok wstęp, zatem mamy za nami.

W kolejnym wpisie opiszę Ci kolejne zagadnienie, które często jest przyczyną wielu konfliktów przy projektach związanych z oprogramowaniem, tj wybór konkretnej metodyki pracy firmy IT, co ma bardzo duże znaczenie na wiele istotnych kwestii, w tym zasady ustalania wynagrodzenia.

Photo Credit: Arenamontanus via Compfight cc