Często spotykam się z różnymi metodami uwzględniania prawa w ??dokumentacji wymagań?. Jakim wymaganiem jest ??zgodność z obowiązującym prawem?? I trudniejsze pytanie: czy zmiana prawa to zmiana wymagań? Inny aspekt problemu to analiza i definicja (opis) tej zgodności z prawem. Spotkać można się z metodą polegającą na traktowaniu każdego (mającego wpływ na system) paragrafu np. ustawy jako wymagania. Problem zgodności oprogramowania z prawem ma dwa aspekty. Zgodność oprogramowania z prawem polega na tym, że ??oprogramowanie nie może ograniczać stosowania prawa to jest nie może wymuszać swoimi ograniczeniami działań niezgodnych z prawem?. Ja osobiście rekomenduję rozciągnięcie tej definicji na ??ani nie powinno pozwalać na łamanie prawa?. Tu jednak wielu uważa, że ??zamawiam narzędzie i używam jak chcę, na swoja odpowiedzialność?. Coś w tym jest, warto jednak zostawić ??włącznik?. (źr.: Prawo a wymagania … )
Dzisiaj czytam:
To administrator odpowiada za zabezpieczenia systemów ? a więc także za to, że pracownik zdołał skopiować dane osobowe na zewnętrzny nośnik. […] W ocenie WSA w toku postępowania PUODO prawidłowo ustalił, iż w SGGW dopuszczono się licznych uchybień, w szczególności nie przeprowadzono właściwej analizy ryzyka i oceny zagrożeń już na etapie projektowania systemów (privacy by design) oraz nie wdrożono odpowiednich środków zapewniających bezpieczeństwo danych, w tym przed możliwością wyeksportowania danych z systemu na zewnątrz.(źr.: Odpowiedzialność administratora za naruszenie zasady privacy by design)
Rzecz w tym, że administrator, w rozumieniu prawa, to także podmiot zlecający powstanie oprogramowania, które go wspiera w realizacji jego obowiązków, a jednym z nich jest egzekwowanie ustalonych zasad.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
Autor recenzowanego tekstu odnosi sie do skutków ekonomicznych, pomija jednak całkowicie skutki prawne kastomizacji kodu oprogramowania, które mają wpływ na koszty i ochronę wartości intelektualnych. Autor pisze we wstępie:
Celem niniejszego opracowania jest analiza możliwych metod kastomizacji systemów informatycznych zarządzania przeprowadzona z ekonomicznego punktu widzenia, w tym w szczególności opłacalności stosowania oprogramowania standardowego i wykorzystania poszczególnych metod jego adaptacji. […] Kastomizację systemu informatycznego ogólnie należy rozumieć jako jego adaptację do potrzeb konkretnego podmiotu. M. Flasiński określił kastomizację, jako ?konfigurację systemu, osadzenie w systemie za pomocą prac programistycznych dodatkowych funkcjonalności oraz modyfikację istniejących funkcjonalności systemu?
Dostarczanie oprogramowania i jego wdrażanie, wiąże się jego ewentualnym dostosowaniem do potrzeb użytkownika. Autor powyższego opracowania, stosując nieprecyzyjne definicje pojęć, wprowadza czytelnika w błąd, opisując przyczyny i konsekwencje związane z szeroko pojętym dostosowaniem oprogramowania do potrzeb użytkownika. Niestety z tego dokumentu korzysta wielu prawników, nazywając go nie raz nawet „wykładnią”.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
Dzisiejszy wpis to efekt lektury artykułu Pani Mec. Marty Pasztaleniec na stronie IP Procesowo. Kluczowe dla dzisiejszego wpisu jego fragmenty to:
Programy komputerowe w świetle krajowego prawa autorskiego korzystają ze szczególnej ochrony. Z uwagi na ich specyfikę wyłączono stosowanie niektórych regulacji z ogólnej części prawa autorskiego, w szczególności przepisów dotyczących dozwolonego użytku, który umożliwia w ściśle określonych okolicznościach korzystanie z utworów bez zgody twórcy, a nawet wbrew takiej zgodzie. Co do zasady zatem jakiekolwiek zwielokrotnienie programu komputerowego wymaga zgody twórcy. […] Spór ma swą genezę w 2005 r. kiedy to Google nabył startup Android Inc i rozpoczął starania by wejść na rynek smartfonów, tworząc platformę do budowy systemów dla urządzeń mobilnych. Platforma w swym założeniu miała być nieodpłatna po to by popularyzować środowisko Google. Jako że język programistyczny Java był wówczas jednym z najbardziej popularnych i powszechnych wśród programistów, Google podjął rozmowy z Sun Microsystems ? twórcą Java ? na temat licencjonowania całej platformy Java. Ostatecznie zdecydował się jednak na budowę własnej platformy. Aby jednak zapewnić jej powszechność i łatwość stosowania wśród programistów zastosowano w nim nazwy funkcji i formatów danych charakterystyczne dla języka Javy. Google de facto opracował własne odpowiedniki funkcji Javy i nadał im nazwy takie same jak w Javie. Oracle, po przejęciu spółki Sun Microsystems, pozwał w 2010 r. Google o naruszenie przysługujących Oracle praw autorskich i patentów. Zarzucono Google skopiowanie blisko 11 500 linii deklaracji API programu Java (co stanowiło 0,4 % deklaracji). […] Sąd uznał, że działanie Google było ?zgodne z kreatywnym ?postępem?, który jest podstawowym konstytucyjnym celem samego prawa autorskiego?. Według sądu dozwolony użytek pełni więc istotną rolę w rozwoju oprogramowania, a prawo autorskie nie powinno hamować tego rozwoju. (żr.: Dozwolony użytek programów komputerowych ? jak Google pokonał Oracle w USA).
Powyższy tekst wskazuje na dwa ciekawe aspekty oprogramowania, o których dzisiaj napiszę. Pierwszy to tak zwany dozwolony użytek, bardzo często przywoływany w sporach o bezpłatne użycie oprogramowania i zakres tego użycia. Najczęściej dotyczy gier komputerowych ale nie tylko. Drugi to charakter oprogramowania, jakim jest kod źródłowy będący tekstem, oraz efekt ostateczny, jakim jest „komputer realizujący określony mechanizm”, gdzie komputer definiujemy jako „procesor, pamięć i program” . Warto tu zwrócić uwagę na pewien „drobiazg”: autorka (jak wielu innych prawników) traktuje treść programu jako „tekst” i nie raz stosuje analogię do typowych utworów pisanych takich jak proza czy poezja, co jest poważnym błędem. Fragmenty tekstów (esej, praca doktorska, powieść, itp.) bardzo często mają wartość, czego o nie można powiedzieć o oprogramowaniu (nie działa w kawałkach). Owszem, można potraktować fragmenty kodu „literaturowo”, jako przykłady jego struktry i składni (np. literatura na temat wzorców projektowych w inżynierii oprogramowania), jednak nie można mówić o fragmencie kodu, że to „oprogramowanie”, gdyż to z zasady „musi działać”, a jest to możliwe tylko wtedy gdy do komputera załadujemy kompletny program a nie „cytowany fragment”.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
Od czasu do czasu jestem pytany o to, kiedy używać diagramu aktywności UML. Od 2015 roku specyfikacja UML wskazuje, że diagramy te są narzędziem modelowania metod czyli logiki kodu (dla Platform Independent Model): aktywności (activities) to nazwy metod, zadania/kroki (actions) to elementy kodu (przykłady w dalszej części).
Gdy powstawał UML, diagramy aktywności były używane także do modelowanie procesów biznesowych. W roku 2004 opublikowano specyfikację notacji BPMN, która w zasadzie do roku 2015 „przejęła” po UML funkcję narzędzia modelowania procesów biznesowych. W 2015 roku formalnie opublikowano specyfikację UML 2.5, gdzie generalnie zrezygnowano z używania UML do modeli CIM. Obecnie Mamy ustabilizowaną sytuację w literaturze przedmiotu: BPMN wykorzystujemy w modelach CIM (modele biznesowe), UML w modelach PIM i PSM jako modele oprogramowania (a modele systemów: SysML, profil UML).
Na przełomie lat 80/90-tych rozpoczęto prace nad standaryzację notacji modelowania obiektowego, w 1994 opublikowano UML 0.9, w 2001 roku pojawiają się pierwsze publikacje o pracach nad notacją BPMN, jednocześnie pojawia się Agile Manifesto, od 2004 roku ma miejsce spadek zainteresowania dokumentowaniem projektów programistycznych, w 2004 rok publikowano specyfkację BPMN 1.0, od tego roku ma miejsce wzrost zainteresowania modelowaniem procesów biznesowych, powoli stabilizuje się obszar zastosowania notacji UML. W 2015 roku opublikowano UML 2.5, stosowanie analizy (CIM) i i projektowania (PIM), jako etapu poprzedzającego implementacje, stało się standardem (źr. wykresu: Google Ngram).
Tak więc obecnie:
Nie używamy diagramów aktywności do modelowania procesów biznesowych. Do tego służy notacja BPMN!
Diagram aktywności może być modelem kodu na wysokim lub niskim poziomie abstrakcji, operujemy wtedy odpowiednio aktywnościami (activity) lub działaniami (actions). Te ostatnie to w zasadzie reprezentacja poleceń programu.
Nie ma czegoś takiego jak „proces systemowy”, oprogramowanie realizuje „procedury”.
Projektując oprogramowanie zgodnie ze SPEM , powstaje Platform Independent Model. W praktyce już na tym etapie programujemy, bo tworzymy logikę i obraz przyszłego kodu. Taka forma dokumentowania pozwala także lepiej chronic wartości intelektualne zamawiającego.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
Tym razem o czymś co potrafi zabić 😉 czyli czym jest dokument oraz fakt i obiekt. Czym się różni zakup kilku produktów, w tym samym sklepie, w np. godzinnych odstępach czasu, od zakupu wszystkich razem? Poza formą udokumentowania, niczym: w sklepie to samo i tyle samo zeszło ze stanu magazynu, a my wydaliśmy w obu przypadkach tyle samo pieniędzy (o promocjach później)! W pierwszym przypadku mamy kilka faktów zakupu, w drugim, jeden, ale zawsze tyle samo obiektów (produkt). Faktura (paragon) to dokument opisjący fakt, przedmiot sprzedaży jest obiektem. Tu obiektem jest opisywany przedmiot zakupu. Ten artykuł to przykład architektury usługi aplikacji, która jest nieczuła na takie różnice.
Wprowadzenie
Żeby uporządkować treść, w stosunku to architektury aplikacji tu nie będę używał pojęć „klasa i obiekt” a komponent i dokument. Pojęcia obiekt i fakt tu będą dotyczyły świata realnego, to odpowiednio: opisywany przedmiot i zdarzenie z nim powiązane. Innymi słowy: dokument może opisywać obiekt lub zdarzenie z nim powiązane. Np. produkt oraz fakt jego sprzedania (dwa byty: separowanie kontekstu dokumentów). Konkretne oprogramowanie jako system, to komponenty (w UML obiekty określonej klasy) oraz dane zorganizowane np. jako dokumenty (dokument: nazwana, określona struktura danych). Aplikacje przetwarzają dane opisujące realny świat, co ładnie pokazał i opisał Smith :
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512
Projektowanie oprogramowania to tworzenie jego modelu, potem pozostaje już tylko jego implementacja. Obecnie prace projektowe i przygotowanie do implementacji także są zaliczane do „programowania” .
Projekt systemu sprzedaży
Każda analiza powinna być oparta na ontologii z dziedziny problemu. Dzięki czemu nazwy dokumentów, atrybutów i ich wartości będą spójne, jednoznaczne i niesprzeczne. Poniżej prosty model pojęciowy dla dziedziny opisywanego tu problemu:
Model pojęciowy (diagram faktów SBVR lub model pojęciowy, diagram klas UML)
(UWAGA! Powyższy model nie jest żadnym „modelem dziedziny” ani „modelem danych”. To model pojęciowy).
Modele pojęciowe służą do zarządzania systemem pojęć (ontologia) dla danego modelu oprogramowania. Testowanie tego modelu polega na sprawdzeniu czy każda para połączonych semantycznie pojęć tworzy poprawne i prawdziwe(!) zdanie w języku naturalnym (tu musimy brać poprawkę na fleksję języka polskiego), np. «sprzedający wystawia fakturę» (fakt) lub «faktura jest dokumentem» (typ).
Oprogramowanie służy do przetwarzania danych, dlatego warto opisać jak się to odbywa. Bardzo wygodną metodą projektowania struktur danych dokumenty (w tym opisie diagram struktur złożonych notacji UML). Po pierwsze są one zrozumiałe dla przyszłego użytkownika, po drugie metoda ta pozwala uwolnić się od wad modeli relacyjnych: usunięcie redundancji nazw co prowadzi do utraty ich kontekstu. Dokumenty często mają różny kontekst, znaczenie pojęć zależy od kontekstu. Relacyjny model danych, pozbawiony redundancji, jest stratny: utrwalone dane nie stanowią żadnej informacji a dokumentem jest dopiero wynik zapytania SQL do tabel.
W przypadku opisywanego tu projektu wygląda to tak:
Struktury danych zorganizowanych w dokumenty (notacja UML)
Mamy tu dwa dokumenty: Oferta i Faktura. Pojęcie Produkt ma swoją definicję realna (definicja atrybutowa: poprzez cechy): jest to „cos co ma nazwę, cenę i ilość”. Atrybuty Produktu na dokumentach przyjmują wartości opisane tym typem. Po drugie dokument niesie kontekst więc nadaje nazwie znaczenie: np. data to data faktury i data oferty. To nie są te same daty, a produkt oferowany (jako atrybut oferty) nie musi być tym samym produktem sprzedanym (jako atrybut Faktury).
Poniżej, na diagramie sekwencji, widać, że dla komponentu zarządzającego stanami magazynowymi nie ma żadnego znaczenia ile jest (było) faktur, operacje zmiany ilości to pojedyncze operacje. Tak zaprojektowana aplikacja jest odporna na to ile produktów jest na ofercie i fakturze, mogą to być różne ilości. Oba te dokumenty: oferta i faktura, to całkowicie odrębne konstrukcje, to dokumenty rządzące się każdy inną logiką i mające każdy inny cykl życia (tu np. Oferta nie jest utrwalana). Często stosowane konstrukcje, takie jak „dziedziczenie faktury i oferty po dokumencie” są tu najgorszym pomysłem.
Architektura. Nasza aplikacja to kilka współpracujących komponentów:
Obiektowy (komponentowy) model dziedziny.
Klasy oznaczone stereotypem «Document» to ciągi znaków (np. XML) stanowiące wartości atrybutów i parametry wywołań operacji. (w UML: ?Document? A human-readable file. Subclass of ?File?. )
Model architektury to statyczny model, a ten może być niezrozumiały, dlatego zawsze wzbogacamy projekt techniczny architektury modelem dynamiki systemu: diagramem sekwencji. Diagram taki powinien powstać dla każdej usługi aplikacji (przypadku użycia):
Powyższy diagram pokazuje współpracę komponentów, opisane wcześniej dokumenty są wartościami atrybutów i parametrami wywoływanych operacji i ich odpowiedzi. Powyższa architektura z powodzeniem wykona także usługi wglądu do historycznych faktur czy aktualizację cennika.
Poprawna obiektowa architektura i kompletny projekt techniczny aplikacji (model PIM) opisuje precyzyjnie jak wykonać implementacje i nie zawiera projektu żadnej bazy danych, ani tym bardziej zapytań SQL. Implementacja utrwalania nie może mieć wpływu na logikę biznesową systemu ani nawet zawierać jej!
Samo opracowanie relacyjnego modelu danych oraz zapytań SQL, by generować powyższe dokumenty z wariantami dotyczącymi różnych ilości oferowanych i zamawianych, zajmie kilkakrotnie więcej czasu niż opracowanie powyższego, gotowego do implementacji, projektu. Opracowanie modelu relacyjnego bazy danych, wymagało by dodatkowo wiedzy o wszystkich pozostałych dokumentach w tym systemie, a tego z reguły nigdy nie wiemy na początku!
Powyższy model to w pełni współpracujące obiekty mające operacje, a podstawowym związkiem modelu obiektowego jest związek użycia (wywołania operacji), czyli nie jest to tak zwany anemiczny model dziedziny.
Tu także warto zwrócić uwagę na kolejny częsty błąd i antywzorzec w projektach deklarowanych jako obiektowe: stosowanie dziedziczenia. Jest to mieszanie modeli pojęciowych i architektury (dziedziczenie, jako współdzielenie, łamie podstawową zasadę paradygmatu obiektowego jaką jest hermetyzacja). Dlatego model pojęciowy i model architektury to z zasady dwa odrębne modele z powodów jak wyżej opisane.
Modelowanie architektury systemu
Podsumowanie
Powyższy opis to krótki ale praktycznie kompletny Opis Techniczny Oprogramowania. Wymaga niewielkich uzupełnień (ewentualne schematy opisujące metody operacji). Wykonanie implementacji na jego podstawie nie powinno sprawić problemu osobie radzącej sobie z czytaniem notacji UML. Projekt jest na tyle precyzyjny, że stanowi utwór w rozumieniu prawa autorskiego (programista nie ma tu żadnej swobody decyzji w pisaniu kodu dla tej części). Projekt taki to także opis określonego mechanizmu działania, zawiera więc opis know-how i jako jego udokumentowana forma chroni to know-how (ustawa o przeciwdziałaniu nieuczciwej konkurencji).
Dlatego każdy program komputerowy napisany na podstawie takiej dokumentacji, z zasady jest utworem zależnym. Developer ma prawa autorskie osobiste do kodu jaki napisze, ale nie ma prawa do dysponowania tym kodem: ma je posiadacz praw majątkowych do projektu, który jest tu utworem pierwotnym. Jedyny wybór jaki ma tu developer to wybór technologii jakiej użyje.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
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.
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):
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 jakim jest schemat 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. Skąd teza mówiąca, że „za wynalazek nie może być uznawany ?program do maszyn cyfrowych?”?. Wydaje się ona nielogiczna.
Popatrzmy na to. Poniżej zdjęcie mechanizmu 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)
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.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.