Ten artykuł to pewnego rodzaju kontynuacja poprzedniego: Vendor lock-in. Starałem się tu wyjaśnić czym jest projekt i wskazać, że pewne wywody prawników wydają się nie mieć żadnego uzasadnienia.

Prawo autorskie

Pomysł, aby ochronę rozwiązań branży IT oprzeć na prawie autorskim nie był specjalnie szczęśliwy. Prawo autorskie stworzono z myślą o twórcach oraz odbiorcach. (źr.: Prawa autorskie w projektach IT. Głównie o różnicach między przeniesieniem praw a licencjami)

Zaskakuje mnie taka teza, bo prawo autorskie, jak sama nazwa wskazuje, stworzono z myślą o autorach. To, że ta konkretna ustawa zawiera wiele odniesień np. do muzyki nie zmienia faktu, że reguluje wszelkie przejawy “twórczej działalności o indywidualnym charakterze”. Ta ustawa doskonale sobie radzi z każdą inżynierią, i uważam, że inżynieria oprogramowania nie jest tu żadnym wyjątkiem. Być może Pan Maruta działa tu jako lobbysta “edżajlowych programistów”, czemu chyba daje wyraz, np. tu:

Wdrożenia systemów informatycznych to zdecydowanie jedne z najbardziej skomplikowanych przedsięwzięć w branży IT. Ta oczywista oczywistość znajduje swoje potwierdzenie chociażby w kosztach związanych z realizacją wdrożeń oraz skalą ryzyka wynikającą z ewentualnego niepowodzenia projektów wdrożeniowych. (źr.: Jak pisać umowy dla projektów IT realizowanych w modelu Agile? Cz. I.)

Słowa “oczywista oczywistość” to częsty wybieg retoryczny prawników, mówiący rozmówcy “nawet nie próbuj podważać tego co powiedziałem”. Otóż niestety wielkości budżetów nie są jakieś specjalnie wielkie na tle innych inżynierii (Pan Maruta straszy kilkoma ewenementami, rzecz w tym, że podał przykłady głównie złego zarządzania zakresem projektów), a skala ryzyka projektów IT jest daleko mniejsza, bo niepowodzenia projektów IT nie powodują np. ofiar w ludziach jak w przypadku katastrof budowlanych czy komunikacyjnych. A więc nie jest to żadna “oczywista oczywistość”.

Teza Pana Maruty i jego wywody o IT natychmiast przypomniały mi inny artykuł (polecam):

TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK (źr.: https://www.linkedin.com/pulse/tw%C3%B3j-prawnik-rozumie-kontrakt-lepiej-ni%C5%BC-twoi-ludzie-warchol-lewicka/ )

Teza autora (Marcin Maruta): “Pomysł, aby ochronę rozwiązań branży IT oprzeć na prawie autorskim nie był specjalnie szczęśliwy”, jest co najmniej niezrozumiała, a sam autor jej nie uzasadnia. Autor wskazuje na rosnącą komplikacje tego prawa, ale niejako sam wskazuje źródło: lobbing pracodawców w celu złagodzenia ochrony twórców (autorów czyli ich pracowników: programistów, projektantów, architektów oprogramowania). Ten wątek pozostawię bez komentarza.

USTAWA z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych , mówi miedzy innymi:

Art. 1. 1. Przedmiotem prawa autorskiego jest każdy przejaw działalności
twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci,
niezależnie od wartości, przeznaczenia i sposobu wyrażenia (utwór).

To znaczy, że istotny jest indywidualny charakter czyli unikalność powstałej treści, nie jest istotny sposób jej wyrażenia (tekst, rysunki, głos), istotny jest fakt jej utrwalenia (ustalenie). Artykuł ten jest bardzo istotny, bo zapis ten całkowicie abstrahuje od branży, zastosowania i przydatności utworu. Coś jest utworem bo jest unikalne i powstało w wyniku twórczej (a więc celowej) działalności człowieka (człowieka bo Prawo dotyczy ludzi). Ustawa mówi wprost:

2. W szczególności przedmiotem prawa autorskiego są utwory:
1) wyrażone słowem, symbolami matematycznymi, znakami graficznymi
(literackie, publicystyczne, naukowe, kartograficzne oraz programy
komputerowe);[…]

3. Utwór jest przedmiotem prawa autorskiego od chwili ustalenia, chociażby miał postać nieukończoną

Jak widać forma (treść literacka, schematy, wzory matematyczna, program komputerowy itp.) nie ma żadnego znaczenia, liczy się wyłącznie fakt zmaterializowania się utworu w jakiejkolwiek postaci.

Art. 2. 1. Opracowanie cudzego utworu, w szczególności tłumaczenie,
przeróbka, adaptacja, jest przedmiotem prawa autorskiego bez uszczerbku dla prawa do utworu pierwotnego.
2. Rozporządzanie i korzystanie z opracowania zależy od zezwolenia twórcy utworu pierwotnego (prawo zależne), chyba że autorskie prawa majątkowe do utworu pierwotnego wygasły. W przypadku baz danych spełniających cechy utworu zezwolenie twórcy jest konieczne także na sporządzenie opracowania

Tu ważna uwaga: można bez problemu opracowywać cudze utwory “do szuflady”, jednak jakiekolwiek rozporządzanie takim opracowaniem (nawet publikacja), wymaga już zgody autora utworu pierwotnego. To bardzo istotne, bo w inżynierii realizacje są opracowaniem ich projektu. Tak jak budowla jest realizacją jej projektu wykonanego na desce kreślarskiej, tak oprogramowanie może być realizacją (opracowaniem) projektu logiki działania i architektury oprogramowania wyrażonych “słowem, symbolami matematycznymi, znakami graficznymi” (parz także ).

Innymi słowy jeżeli program powstał bez takiego projektu, jest on faktycznie samodzielnym utworem programisty (co zresztą bardzo często ma miejsce). Jeżeli jednak program (oprogramowanie, aplikacja) powstał jako opracowanie projektu wyrażonego w formie j.w. (schematy blokowe, wzory, tablice, algorytmy itp. ) jest wyłącznie implementacją (efekt starannego działania), lub utworem zależnym, jeżeli autor oddał pewną określoną swobodę progamiście. To, że to jest to rzadka sytuacja (istnienie projektu), nie zmienia faktu, że jest program nie jest tu utworem a wykonaniem utworu .

Rzesze programistów (i ich prawników) zwalczają tą tezę bo uderza ona w ich monopol.

Uważam, że orzecznictwo jest jednak po stronie projektantów i architektów systemów, w tym oprogramowania. Więcej o tym zagadnieniu napisałem w artykule Ochrona know-how. Tu skupię się na projekcie oprogramowania jako samodzielnym i pełnoprawnym utworze będącym specyfikacją oprogramowania jakie ma powstać (projekt jako wymaganie).

Projektowanie

Zacznijmy od prostego przykładu i słynnego zarazem wynalazku i patentu (w USA). Poniższy rysunek to model (specyfikacja) mechanizmu działania regulatora. Nie jest to nawet rysunek techniczny wykonawczy. Jest to utwór w rozumieniu ustawy, bo: stanowi przejaw działalności twórczej o indywidualnym charakterze, ustalony znakami graficznymi. Nie mniej jednak stanowi bardzo precyzyjny opis mechanizmu działania odśrodkowego regulatora obrotów.

PODSTAWY CYBERNETYKI REGULACJA PROCESÓW FIZJOLOGICZNYCH - ppt video online  pobierz

Poniższe zdjęcie to jedna z wielu możliwych implementacji (opracowania) powyższego mechanizmu. I co ciekawe, udowodnienie, że jest to implementacja (utwór zależny) mechanizmu opisanego powyżej, nie zajmie żadnemu sądowi zbyt wiele czasu.

Historia automatyki - Wikiwand

Tak więc jedno jest tu pewne: konkretna konstrukcja na zdjęciu powyżej jest opracowaniem utworu (utwór zależny) jakim jest schemat (model) opisujący mechanizm działania odśrodkowego regulatora obrotów Watta. I niezależnie od tego ile własnej inwencji włożył w to inżynier konstruktor tego konkretnego regulatora, jest to – konstrukcja na zdjęciu – utwór zależny. Poniżej inna konstrukcja (implementacja) tego samego mechanizmu, to także jest utwór zależny.

Regulator odśrodkowy obrotów silnika rozbryzgiwacz oleju Briggs 691968 -  skladczesci.pl

Pewną ciekawostką jest stanowisko polskiego ustawodawcy, mówiące że:

Art. 28 pkt. 5 ustawy o własności przemysłowej stanowi, iż za wynalazek nie może być uznawany ?program do maszyn cyfrowych?. Wynika z tego jasno, iż program komputerowy nie może być zatem zgłoszony do właściwego urzędu patentowego celem jego rejestracji i uzyskania stosownego patentu. Autorzy programu komputerowego mogą próbować jedynie opatentować wynalazek, który wspomagany jest programem komputerowym, niezbędnym do jego prawidłowego funkcjonowania. (źr.: Ochrona prawna programów komputerowych)

Absolutnie nie jestem zwolennikiem patentowania oprogramowania, a nawet generalnie jestem przeciwnikiem patentów, czyli trwałych monopoli na wynalazki ludzkie. Teza mówiąca, że “za wynalazek nie może być uznawany “program do maszyn cyfrowych” wydaje się nielogiczna.

Popatrzmy na to. Poniżej zdjęcie mechanicznego programatora pralki: zawiera silnik i tak zwane krzywki sterujące stykami sterownika.

Mechaniczny programator pralki

Identyczne funkcje, jako mechanizm sterujący, realizuje poniższy nowoczesny sterownik będący tak na prawdę komputerem (mikrokontroler) z programem, ten program realizuje (implementuje) identyczny mechanizm sterowania jak ten na zdjęciu powyżej, bo nie przypadkiem komputer jest określany jako “uniwersalny mechanizm” .

Programator pralki Aquamatic AQUA 100 +blokada+ silnik Sosnowiec -  Sprzedajemy.pl
Mikrokontroler pełniący funkcję programatora pralki automatycznej.

W pewnych obszarach mechanizm wykonany (opracowany, wynaleziony) jako konstrukcja mechaniczna (możliwa do opatentowania) może być zrealizowany w 100% z użyciem komputera: mechaniczny arytmometr został zastąpiony elektronicznym kalkulatorem (to jest komputer), mechaniczny zegar także programem komputera (czytaj także Model czy abstrakcja). Ładnie to opisuje autor publikacji naukowej zatytułowanej Komputer jako uniwersalny mechanizm . Innymi słowy:

skoro komputer to procesor, pamięć i program, i skoro 100% realizowanych funkcji komputera realizuje program, to znaczy sam program, bez względu na formę jego wyrazu, z zasady jest tu kompletnym opisem mechanizmu działania, podlegającym potencjalnie ochronie prawno-autorskiej i/lub know-how.

Dokładnie z tego samego powodu garnek nie jest integralną częścią chronionego przepisu potrawy kulinarnej (a są one chronione prawem np. jako produkty spożywcze regionalne, np. takie jak oscypek).

Od dekad mamy do czynienia z postępem technologii gdzie jeden z obszarów inżynierii: szeroko pojęte systemy sterowania, jest systematycznie pochłaniany przez komputery. Mechaniczne konstrukcje takie jak systemy zliczające, czasomierze, kalkulatory, sterowanie oparte o cięgna, systemy automatyki, systemy zobrazowania (np. wskazówkowe: monitor zamiast mechanicznego wskaźnika) itp. są zastępowane przez komputer (rozumiany jako procesor, pamięć i program). Kolejne konstrukcje, do niedawna wyłącznie mechaniczne, są zastępowane komputerem (patrz także niedawny artykuł: Inteligentna pralka czyli czym jest mechatronika). Proces ten postępuje, powstała notacja (rozszerzenie UML) pozwalająca na modelowanie (specyfikowanie) takich mieszanych konstrukcji: SysML:

Wszystkie powyższe konstrukcje są chronione prawem autorskim, jako ich projekty wykonane w postaci udokumentowanych (ustalonych) opisów (specyfikacji) wykonanych z użyciem schematów blokowych, zapisów związków logicznych i wzorów matematycznych. Tak więc teza, jakoby oprogramowanie wymagało jakiegoś innego specjalnego podejścia, jest moim zdaniem nie do obrony: jeżeli komputer (czyli także program) może być równoprawnym funkcjonalnie zamiennikiem konstrukcji mechanicznej (co wykazano powyżej), to znaczy że można wobec niego i konstrukcji mechanicznych, stosować te same zapisy w prawie.

Podsumowanie

Czy możliwe jest więc opracowanie specyfikacji dla wykonania oprogramowania, analogicznej jak dla urządzenia mechanicznego? Oczywiście! Powyższa pozycja literatury to jedna z wielu tego typu. Na tym blogu jest wiele przykładów takich specyfikacji. Stawianie tezy, że jedyną możliwą formą ustalenia oprogramowania jest kod źródłowy, nie ma żadnego uzasadnienia w faktach: mamy na świecie ogromną ilość dokumentacji stanowiącej precyzyjną specyfikacje oprogramowania jakie ma powstać. Oczywiście nie ma obowiązku tworzenia takich dokumentów (metody nazywane agile) ale po pierwsze jest to możliwe, po drugie jest to jednak nadal najskuteczniejsza metoda zamawiania oprogramowania. Panu Marucie, świetnemu prawnikowi, polecam jednak konfrontowanie poglądów programistów których reprezentuje, z dostępną literaturą i naukową i popularną z zakresu inżynierii oprogramowania oraz orzecznictwo w tym zakresie, np. poniższe:

Dokumentacja i inne materiały dotyczące projektowania programu komputerowego należy traktować jako program komputerowy (implementacja dyrektywy Parlamentu Europejskiego i Rady 2009/24/WE dnia 23 kwietnia 2009 (wersja ujednolicona dyrektywy Rady Wspólnoty Europejskich nr 91/250 z dnia 14 maja 1991): ?dla celów niniejszej dyrektywy pojęcie ?program komputerowy? obejmuje również przygotowawcze prace projektowe i materiał projektowy?.

Co potwierdzają także autorzy najnowszych publikacji naukowych, np.

“Programming is not solely about constructing software, programming is about designing software”. .

Podsumowując: możliwe jest opracowanie dokumentacji oprogramowania opisującej (wymagany) mechanizm jego działania i architekturę. Oprogramowanie powstałe na bazie takiej dokumentacji to implementacja projektu i stanowi ono utwór zależny w stosunku do utworu jakim jest pierwotna specyfikacja. Prawo autorskie jest tu wręcz doskonałym mechanizmem kontrolnym nad wykonawcą oprogramowania: mając prawa majątkowe do projektu technicznego, z zasady dysponujemy w pełni oprogramowaniem wykonanym na nasze zamówienie i na podstawie takiej dokumentacji. Jeżeli dostawca stworzy zamówione oprogramowanie inaczej bo po swojemu, to znaczy tylko tyle, nie zrealizował zawartej umowy i nie należy mu płacić.

Tak zwane projekty ‘agile’ to całkowity brak kontroli nad wykonawcą i nad własnym know-how. Trudno się więc dziwić, że jest to metoda forsowana przez dostawców oprogramowania i ich prawników.

(polecam także analogiczny prawomocny wyrok dotyczący muzyków grających z nut pod dyktando dyrygenta)

Źródła

Wolak, G. J. (2019). Umowa o dzieło jako zobowiązanie rezultatu. https://doi.org/10.34697/2451-0807-SP-2019-1-006
Kancelaria Sejmu. (1994). Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. http://prawo.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU19940240083
Murawski, R. (Ed.). (2015). Filozofia matematyki i informatyki. Copernicus Center Press.
Friedenthal, S., Moore, A., & Steiner, R. (2009). OMG Systems Modeling Language (OMG SysMLTM) Tutorial September, 2009. 132.
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3–5. https://doi.org/10.1109/MS.2019.2959049

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 3 komentarzy

  1. Harnaś

    Dziękuję za ten artykuł.
    Jest on też ważny w kontekście ulgi IP BOX.

    Zastanawiam się też (uproszczone podejście laika) nad zasadnością ujmowania całej pracy programistów jako twórczej do celów podatkowych oraz celem przekazania praw autorskich firmie dla której pracują. W jakimś zakresie i w pewnych przypadkach jest to często praca twórcza, ale w wielu przypadkach to wyrobnicy, jak murarze, który kodują/murują wg otrzymanego projektu.

    1. Jarosław Żeliński

      Owszem, “ujmowania całej pracy programistów jako twórczej” jest patologią, jeżeli koder pracuje pod dyktando architekta projektanta, faktycznie jest wyłącznie wyrobnikiem jak murarz a ujmowanie tego w prawo autorskie jest co najmniej nadużyciem. Np. tłumaczenia prac naukowych czy dokumentów prawnych, a nawet obszernej dokumentacji technicznej, to także takie rzemiosło. Utworem dopiero tłumaczenia powieści czy poezji, bo dopiero tu tu tłumacz ma swobodę by drugim języku oddać sens a nie literalna treść. Jest to identyczny problem jak roszczenia muzyków sesyjnych czy członków orkiestr: pracują z nut pod dyktando dyrygenta, nie ma tu żadnej sztuki, jest świetne rzemiosło. Wyrok sądu na ten temat oburzył “twórców i artystów” (opis i wyrok). Identycznie oburzają sie programiści (wielu), niestety podobnie jak opisani muzycy, przegrywają w sądach takie spory. I niestety w każdej z tych branż, jest to próba optymalizacji podatkowej.

  2. Kilka osób pytało mnie o opinię: “Pomysł, aby ochronę rozwiązań branży IT oprzeć na prawie autorskim nie był specjalnie szczęśliwy.” Pana mec. Maruty (https://maruta.pl/prawa-autorskie-w-projektach-it-glownie-o-roznicach-miedzy-przeniesieniem-praw-a-licencjami/).

    Niestety nie uzasadnił jej w powyższym tekście. Pan Maruta narzeka na to, że
    “Ze względu na swoiste ukształtowanie praw majątkowych do programu komputerowego (art. 74.4 p.a.) przeniesienie praw przez twórcę oznacza dla niego de facto brak możliwości dalszego dysponowania kodem. Nie może on go nie tylko dalej rozpowszechniać (co jest naturalną konsekwencją oddania praw), lecz także zwielokrotniać czy modyfikować.”

    Jednak autor pomija bardzo ważny fakt: to oprogramowanie powstało na zlecenie i pod dyktando zamawiającego, który pokrył całość kosztów jego powstania, czy to oprogramowanie powstało na bazie pomysłu i na koszt jego twórcy?

    Autor pisze: “Nic dziwnego, że z punktu widzenia dostawcy taka operacja zawiera olbrzymi koszt, który wpływa na wycenę tych praw lub w ogóle wyklucza daną transakcję. “. Otóż nie! Jeżeli zamawiający pokrył w 100% te koszty (np. w postaci wynagrodzenia T&M dla tego programisty) to nie ma żadnego powodu, by ten programista zachował prawa majątkowego do tego co powstało, bo wykonał pracę starannego działania.

    Reszta artykułu skupia sie na różnicy między licencją a zakupem praw majątkowych, czego tu już nie będę komentował.

    Polecam też mój nowszy artykuł:
    Ochrona programów komputerowych w prawie własności intelektualnej
    Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.