Wstęp

W lutym 2017 r. opisywałem prawne aspekty pojęcia „przedmiot zamówienia” w sferze inżynierii oprogramowania. Niedawno ukazał się w prasie artykuł o domniemanym planowaniu wywłaszczenia programistów:

Sejm jest o włos od zniesienia mechanizmu ochrony autorskiej twórców aplikacji. Na razie tych, którzy informatyzowali sądy, prokuratury i komorników. ¹

Wywołał on sporą burzę w branży IT, niestety większość publikowanych w mediach wypowiedzi jest bardzo powierzchowna a niestety bardzo często wręcz fałszywa. Do tego nakładają się wypowiedzi lobbystów z branży IT, niejednokrotnie przemilczające pewne fakty a nie raz stawiające wręcz nieprawdziwe tezy. Otóż, o czym nie raz pisałem, stale …

W przestrzeni publicznej toczą się spory co do tego ?czym jest oprogramowanie?, jednak moim zdaniem, większość tych sporów ma swoje źródła w niezrozumieniu specyfiki technologii informatycznych i samego prawa, część jest skutkiem celowego lub nie, mataczenia w samych umowach. Ustawodawca, moim zdaniem bardzo słusznie, zakwalifikował oprogramowanie do utworów literackich, gdyż w swej istocie jest ono zawsze zapisem analogicznym do tekstu. Osobną kwestią jest treść tkwiąca w takim utworze (o czym on jest), co podobnie jak w przypadku literackich tekstów, może mieć ale nie musi, znaczenie. Tekst Kodu programu zinterpretowana przez odpowiednią maszynę, potocznie zwaną komputerem, decyduje o tym ?czym dany komputer jest?. Raz jest programatorem pralki a raz edytorem tekstu czy grą interaktywną. Oprogramowanie często cechuje się określonym ?mechanizmem działania?.  W literaturze z obszaru technik komputerowych i filozofii, bardzo często można spotkać teorię mówiącą, że ?komputer to uniwersalny mechanizm?. Innymi słowy komputer może być ?czymkolwiek?, decyduje o tym  ?program komputerowy?. ²

Jeżeli nałożymy na to fakt, że zamawiający w większości nie znają i nie rozumieją prawnych aspektów ochrony wartości intelektualnych, to mamy do czynienia z obecnym ogromnym bałaganem, nie tylko w administracji publicznej, ale i z tym jakie i kto ma prawa do wykorzystywanego oprogramowania. Niestety przewaga merytoryczna jaką ma branża IT nad swoimi klientami pozwala na wiele nadużyć, szczególnie w sferze zawłaszczania know-how przez twórców oprogramowania.

Wartości intelektualne w umowach

Dzisiaj  opiszę kwestie prawno-autorskie właśnie z perspektywy wartości intelektualnych w umowach. Kluczem jest uporządkowanie pojęć wykorzystywanych w umowach i ustawach.

Poniższy diagram to model pojęciowy wykonany w notacji SBVR (diagram faktów) ³:

Opiszę treść diagramu. Poszczególne pojęcia zostały zobrazowane jako prostokąty. Linie między nimi to fakty łączące je parami w określony kontekst. Strzałki łączą pojęcia ogólne z ich szczególnymi typami. Kluczowe pojęcia: utwór, know-how oraz pole eksploatacji, zostały opisane cytatami z aktów prawnych. Zestaw powiązanych kontekstem pojęć nazywamy przestrzenią pojęciową.

Treść to zawartość wypowiedzi lub dokumentu ⁴. Zawartością może być (treść niesie) ta zwane know-how. Jeżeli treść ma indywidualny charakter, jest utworem. Zgodnie z prawem jest nim każda treść o indywidualnym charakterze, w szczególności  specyfikacja (projekt techniczny) i kod programu komputerowego. Oba są utworami w rozumieniu prawa. Użytkownika korzysta z aplikacji (jest ona oprogramowaniem), ta może być wyrażona z pomocą symboli, wzorów i schematów blokowych lub/i w postaci kodu programu. Należy pamiętać, co bardzo ważne w branży inżynierskiej, że …

Program komputerowy napisany na podstawie opracowanego wcześniej projektu (podobnie jak każde inne rozwiązanie lub produkt) stanowi utwór zależny (jest to realizacja projektu). Utworem pierwotnym dla oprogramowania jest tu projekt tego oprogramowania (jeżeli powstał), w tym jego unikalna architektura. Oprogramowanie powstałe na podstawie projektu innego autora, powinno zostać oznaczone danymi autora tego projektu ⁵

Tak więc, jeżeli kod powstał na podstawie specyfikacji, jest utworem (dziełem) zależnym, jeżeli nie, jest samodzielnym utworem. Wśród wielu pól eksploatacji utworu są wydruki i uruchamianie w pamięci komputera.

Wnioski dla nabywców oprogramowania

Przede wszystkim należy podjąć decyzję o tym co licencjonujemy, do czego nabywamy prawa majątkowe i na jakich polach eksploatacji. Tak zwane oprogramowanie standardowe to produkty rynkowe sprzedawane do wielu podmiotów, tu możemy liczyć na określoną formę licencji. Jak użytkownik  najczęściej na uruchamianie w pamięci komputera, ale nie na dystrybucję. Taki zakup jest relatywnie prosty a umowy licencyjne są standardowe dla danego producenta i produktu.

Problemem jest zlecenie wykonania dedykowanego dla nas oprogramowania. Kod programu jest utworem, utwór jako treść niesie (zakładamy, że tak jest) know-how firmy zlecające wykonanie dla siebie dedykowanego oprogramowania (specyfika logiki biznesowej, mechanizmy działania różnych funkcji itp.). Na pytanie czy wykonawca musi nam przekazać w umowie praw majątkowe? Może ale nie musi (wtedy sugeruję nie zawieranie umowy i szukanie innego wykonawcy). Jednak jeżeli zamawiający najpierw opracuje specyfikację (to także utwór, zawiera dokładny opis wykonania oprogramowania) i uczyni z niej element umowy na wykonanie dla niego oprogramowania, wykonawca nie ma żadnych praw (o ile mu ich nie przekażemy) do dysponowania tak wytworzonym oprogramowaniem.

W projektach dużych, kluczową częścią powinien być projekt architektury, uwzględniający prawa do poszczególnych komponentów oraz separowanie komponentów standardowych od tych zawierających nasze know-how. To dlatego najwięcej szkód przynosi kupującym oprogramowanie tak często oferowana przez dostawców kastomizacja… czyli wbudowywanie logiki biznesowej kupującego we własny już kod, tu ma miejsce całkowite przejęcie know-how przez dostawce oprogramowania.

Nie będę opisywał detali takich umów (a są one istotne), gdyż celem moim było opisanie mechanizmów prawnych ich konstruowania i mechanizmów ochrony. Chciałem tu przede wszystkim wskazać  mechanizm nadużyć polegający na tym, że: dostawca oprogramowania oferuje (forsuje) pracę bez uprzedniego specyfikowania aplikacji (tak zwane zwinne projekty agile) lub oferuje samodzielne wykonanie takiej specyfikacji (pod nazwą analiza wymagań, analiza przed-wdrożeniowa itp.). W obu przypadkach pełnię praw autorskich (osobiste i majątkowe) pozostają przy twórcy kodu. Pozycja negocjacyjna nabywcy jest tu bardzo słaba. Dzięki temu mechanizmowi bardzo wiele form produkujących oprogramowanie wymusza na administracji publicznej zakupy z wolnej ręki, podobnie zresztą w firmach prywatnych: monopolizują prawa do oprogramowania i praktycznie całkowicie blokują konkurencję a użytkownika skazują na siebie jako dostawce usług utrzymania i rozwoju.

Dlatego niezależnie od tego co sądzimy o metodach zwinnych, warto zadbać o swoje know-how i dokumentować je. Nie warto także zlecać prac analityczno-projektowych producentom oprogramowania.

Wspomniane na początku „wywłaszczanie” programistów ma zaradzić takim nadużyciom na przyszłość. Osobną jednak kwestią, nie na ten artykuł, jest sposób przeprowadzenia tego.

___

2017-08-07 Temat stał się na tyle gorący, że Pani red. Sylwia Czubkowska w Gazecie Prawnej kontynuowała temat w rozmowie ze mną:

? Doradzałbym szklankę zimnej wody. Owszem, ten przepis jest źle napisany, ale nie jest wcale bezpodstawny. To, że w tym wypadku resort sprawiedliwości, a za chwilę może po prostu rząd, myśli o tym, by ustawowo nakazać przekazanie kodów źródłowych, z których korzysta administracja, nie jest wcale nieuzasadnione ? ocenia Jarosław Żeliński, założyciel i główny analityk firmy IT-Consulting, zajmującej się doradztwem przy inwestycjach w nowe technologie. ? Ustawowe wywłaszczenie to metoda skrajna, ale niestety może okazać się czasami niezbędne. Przecież państwo, czyli jego instytucje, za te programy firmom zapłaciło, a w niejednym przypadku wcale nie dostało pełnowartościowego produktu. Często z własnej winy, bo nie dopilnowało od razu, by zabezpieczyć swoje prawa także do kodów. A bez nich niestety produkt jest niepełnowartościowy. Czasem jednak taka konstrukcja umów to polityka firm, które kodów nie chcą przekazywać ? tłumaczy ekspert. A nie chcą, bo dzięki temu instytucja publiczna ? nie mając kodów ? jest zmuszona, by kolejne zlecenia dawać ich właścicielowi. (⁶)