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.
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.
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.
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.
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” .
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.
Czym jest program komputerowy – co chronimy?
Analizując zakres chronionych elementów programu komputerowego warto wskazać, że ochroną nie będzie objęty również graficzny interfejs użytkownika. Kwestia ta była analizowana w orzeczeniu TSUE[iv] – wyroku z dnia 22 grudnia 2010 r. w sprawie C-393/09 – Bezpečnostní softwarová asociace – Svaz softwarové ochrany v. Ministerstvo kultury. Argumentując brak ochrony dla graficznego interfejsu użytkownika, TSUE wskazał, iż taki interfejs nie stanowi formy wyrażenia programu komputerowego w rozumieniu art. 1 ust. 2 dyrektywy 91/250 w sprawie ochrony prawnej programów komputerowych. Z treści wyroku można wywnioskować, iż zdaniem TSUE formą wyrażenia programu jest taka konstrukcja, której odtworzenie prowadziłoby do odtworzenia samego programu, pozwalając w ten sposób komputerowi na wypełnienie jego funkcji. Z kolei, jak zauważa TSUE, „interfejsy są częściami programu komputerowego umożliwiającymi wzajemne połączenie i interakcję wszystkich elementów oprogramowania i sprzętu komputerowego z innym oprogramowaniem i sprzętem, jak również z użytkownikami, tak aby stały się one w pełni funkcjonalne. Graficzny interfejs użytkownika jest interfejsem interakcji, pozwalającym na komunikację pomiędzy programem komputerowym a użytkownikiem. W związku z tym graficzny interfejs użytkownika nie pozwala na powielanie tego programu komputerowego, lecz stanowi po prostu element tego programu, za pomocą którego użytkownicy wykorzystują właściwości omawianego programu”. Innymi słowy, nie można uznać interfejsów za formę wyrażenia programu, gdyż wykorzystując interfejs nie jesteśmy w stanie odtworzyć treści programu komputerowego. Natomiast trzeba zauważyć, na co zresztą zwrócił również uwagę TSUE w komentowanym orzeczeniu, że interfejs – jeśli będzie spełniał warunki uznania go za utwór – może być chroniony na podstawie przepisów ogólnych.
https://www.parp.gov.pl/component/content/article/57199:ochrona-programow-komputerowych-w-prawie-wlasnosci-intelektualnej-czesc-i
Wskazówki czyli na podst. Art.33. Dz.U.2023.0.1170 t.j. – Ustawa z dnia 30 czerwca 2000 r. – Prawo własności przemysłowej:
Opis wynalazku powinien przedstawiać (ujawniać) wynalazek na tyle jasno i wyczerpująco, aby znawca mógł ten wynalazek urzeczywistnić, a ekspert mógł dokonać rzeczowej analizy porównawczej z dotychczasowym stanem techniki. Za „znawcę z danej dziedziny” uważa się przeciętnego praktyka dysponującego przeciętną, ogólnie dostępną wiedzą z danej dziedziny w odpowiednim czasie, który dysponuje typowymi środkami i możliwościami prowadzenia prac i doświadczeń. Przyjmuje się, że specjalista taki ma dostęp do stanu techniki; tzn. informacji zawartych w podręcznikach, monografiach, książkach. Zna także informacje zawarte w opisach patentowych i publikacjach naukowych, jeżeli wynalazek dotyczy rozwiązań, które są na tyle nowe, że nie są zawarte w książkach. Ponadto, potrafi korzystać ze stanu techniki w działalności zawodowej do rozwiązywania problemów technicznych. Przedstawiony wynalazek powinien więc nadawać się do odtworzenia bez dodatkowej twórczości wynalazczej. Pod pojęciem tym należy rozumieć dodatkową działalność umysłową, eksperymentalną związaną z niepełną informacją techniczną zawartą w opisie wynalazku, a także konieczność dodatkowych uzupełniających badań naukowych, niezbędnych do realizacji rozwiązania według wynalazku w pełnym zakresie żądanej ochrony. Odtworzenie wynalazku powinno być możliwe na podstawie przeciętnej wiedzy specjalisty w danej dziedzinie, bez nadmiernego wysiłku.
Pyrża, A. (Ed.). (2006). Poradnik wynalazcy: metodyka badania zdolności patentowej wynalazków i wzorów użytkowych. Urząd Patentowy Rzeczypospolitej Polskiej. https://uprp.gov.pl/sites/default/files/inline-files/Poradnik%20wynalazcy.%20Metodyka%20badania%20zdolno%C5%9Bci%20patentowej%20wynalazk%C3%B3w%20i%20wzor%C3%B3w%20u%C5%BCytkowych.%20Wydanie%20I.pdf
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)
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.
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.
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