Wstęp

Dzisiejszy wpis to efekt lek­tu­ry arty­ku­łu Pani Mec. Marty Pasztaleniec na stro­nie IP Procesowo. Kluczowe dla dzi­siej­sze­go wpi­su jego frag­men­ty to:

Programy kom­pu­te­ro­we w świe­tle kra­jo­we­go pra­wa autor­skie­go korzy­sta­ją ze szcze­gól­nej ochro­ny. Z uwa­gi na ich spe­cy­fi­kę wyłą­czo­no sto­so­wa­nie nie­któ­rych regu­la­cji z ogól­nej czę­ści pra­wa autor­skie­go, w szcze­gól­no­ści prze­pi­sów doty­czą­cych dozwo­lo­ne­go użyt­ku, któ­ry umoż­li­wia w ści­śle okre­ślo­nych oko­licz­no­ściach korzy­sta­nie z utwo­rów bez zgo­dy twór­cy, a nawet wbrew takiej zgo­dzie. Co do zasa­dy zatem jakie­kol­wiek zwie­lo­krot­nie­nie pro­gra­mu kom­pu­te­ro­we­go wyma­ga zgo­dy twór­cy. […]
Spór ma swą gene­zę w 2005 r. kie­dy to Google nabył star­tup Android Inc i roz­po­czął sta­ra­nia by wejść na rynek smart­fo­nów, two­rząc plat­for­mę do budo­wy sys­te­mów dla urzą­dzeń mobil­nych. Platforma w swym zało­że­niu mia­ła być nie­od­płat­na po to by popu­la­ry­zo­wać śro­do­wi­sko Google. Jako że język pro­gra­mi­stycz­ny Java był wów­czas jed­nym z naj­bar­dziej popu­lar­nych i powszech­nych wśród pro­gra­mi­stów, Google pod­jął roz­mo­wy z Sun Microsystems ? twór­cą Java ? na temat licen­cjo­no­wa­nia całej plat­for­my Java. Ostatecznie zde­cy­do­wał się jed­nak na budo­wę wła­snej plat­for­my. Aby jed­nak zapew­nić jej powszech­ność i łatwość sto­so­wa­nia wśród pro­gra­mi­stów zasto­so­wa­no w nim nazwy funk­cji i for­ma­tów danych cha­rak­te­ry­stycz­ne dla języ­ka Javy. Google de fac­to opra­co­wał wła­sne odpo­wied­ni­ki funk­cji Javy i nadał im nazwy takie same jak w Javie. Oracle, po prze­ję­ciu spół­ki Sun Microsystems, pozwał w 2010 r. Google o naru­sze­nie przy­słu­gu­ją­cych Oracle praw autor­skich i paten­tów. Zarzucono Google sko­pio­wa­nie bli­sko 11 500 linii dekla­ra­cji API pro­gra­mu Java (co sta­no­wi­ło 0,4 % dekla­ra­cji). […]
Sąd uznał, że dzia­ła­nie Google było ?zgod­ne z kre­atyw­nym ?postę­pem?, któ­ry jest pod­sta­wo­wym kon­sty­tu­cyj­nym celem same­go pra­wa autor­skie­go?. Według sądu dozwo­lo­ny uży­tek peł­ni więc istot­ną rolę w roz­wo­ju opro­gra­mo­wa­nia, a pra­wo autor­skie nie powin­no hamo­wać tego roz­wo­ju. (żr.: Dozwolony uży­tek pro­gra­mów kom­pu­te­ro­wych ? jak Google poko­nał Oracle w USA).

Powyższy tekst wska­zu­je na dwa cie­ka­we aspek­ty opro­gra­mo­wa­nia, o któ­rych dzi­siaj napi­szę. Pierwszy to tak zwa­ny dozwo­lo­ny uży­tek, bar­dzo czę­sto przy­wo­ły­wa­ny w spo­rach o bez­płat­ne uży­cie opro­gra­mo­wa­nia i zakres tego uży­cia. Najczęściej doty­czy gier kom­pu­te­ro­wych ale nie tyl­ko. Drugi to cha­rak­ter opro­gra­mo­wa­nia, jakim jest kod źró­dło­wy będą­cy tek­stem, oraz efekt osta­tecz­ny, jakim jest kom­pu­ter reali­zu­ją­cy okre­ślo­ny mecha­nizm”, gdzie kom­pu­ter defi­niu­je­my jako pro­ce­sor, pamięć i pro­gram” . Warto tu zwró­cić uwa­gę na pewien dro­biazg”: autor­ka (jak wie­lu innych praw­ni­ków) trak­tu­je treść pro­gra­mu jako tekst” i nie raz sto­su­je ana­lo­gię do typo­wych utwo­rów pisa­nych takich jak pro­za czy poezja, co jest poważ­nym błę­dem. Fragmenty tek­stów (esej, pra­ca dok­tor­ska, powieść, itp.) bar­dzo czę­sto mają war­tość, cze­go o nie moż­na powie­dzieć o opro­gra­mo­wa­niu (nie dzia­ła w kawał­kach). Owszem, moż­na potrak­to­wać frag­men­ty kodu lite­ra­tu­ro­wo”, jako przy­kła­dy jego struk­try i skład­ni (np. lite­ra­tu­ra na temat wzor­ców pro­jek­to­wych w inży­nie­rii opro­gra­mo­wa­nia), jed­nak nie moż­na mówić o frag­men­cie kodu, że to opro­gra­mo­wa­nie”, gdyż to z zasa­dy musi dzia­łać”, a jest to moż­li­we tyl­ko wte­dy gdy do kom­pu­te­ra zała­du­je­my kom­plet­ny pro­gram a nie cyto­wa­ny fragment”.

Prawo autorskie i dozwolony użytek

Bardzo rze­tel­ny opis dozwo­lo­ne­go użyt­ku poda­no na stro­nie Legalna Kultura:

Dozwolony uży­tek jest for­mą ogra­ni­cze­nia autor­skich praw mająt­ko­wych i daje nam moż­li­wość korzy­sta­nia z chro­nio­ne­go taki­mi pra­wa­mi utwo­ru bez koniecz­no­ści uzy­ski­wa­nia zgo­dy pod­mio­tu upraw­nio­ne­go tj. auto­ra czy też np. wydawcy/producenta, któ­ry nabył autor­skie pra­wa mająt­ko­we. (źr.: Dozwolony uży­tek).

Tu auto­rzy, podob­nie jak więk­szość dogma­ty­ków praw­ni­ków, sku­pia­ją się głów­nie na utwo­rze rozu­mia­nym jako coś co moż­na prze­czy­tać, posłu­chać, lub obej­rzeć” (a tak­że sko­pio­wać czy roz­po­wszech­niać: pola eks­plo­ata­cji). Kod pro­gra­mu, napi­sa­ny w dowol­nym, okre­ślo­nym języ­ku pro­gra­mo­wa­nia, nie­wąt­pli­wie jest tek­stem, któ­ry jako treść moż­na wyko­rzy­stać np. do celów infor­ma­cyj­nych czy edu­ka­cyj­nych. Problem poja­wia się, gdy weź­mie­my pod uwa­gę fakt, że pro­gram jako taki jest inte­gral­ną czę­ścią kom­pu­te­ra (patrz wyżej defi­ni­cja poję­cia kom­pu­ter), oraz to że wła­śnie w takim celu – uży­cie go w kom­pu­te­rze – co do zasa­dy jest two­rzo­ny (pisa­ny).

Moim zda­niem, pisa­nie w umo­wach, że pro­gram kom­pu­te­ro­wy ma jakieś inne, niż uży­cie go w kom­pu­te­rze, pola eks­plo­ata­cji jest wyra­zem nie­zro­zu­mie­nia isto­ty tego czym jest opro­gra­mo­wa­nie: na pew­no nie jest ono czymś do poczy­ta­nia”. To, że moż­na go utrwa­lić jest praw­dą, ale samo jego utrwa­la­nie nie jest jego uży­ciem. Nawet jego powie­la­nie jako tre­ści kodu, nie jest szko­dą” dla auto­ra pro­gra­mu, szko­dą będzie dopie­ro jego uży­cie w kom­pu­te­rze, bo dopie­ro wte­dy reali­zu­je on okre­ślo­ne funkcje.

Szkodliwość same­go powie­la­nia kodu pro­gra­mu jest taka sama jak szko­dli­wość powie­la­nia pro­jek­tu archi­tek­to­nicz­ne­go domu: pro­ble­mem jest nie posia­da­nie kopii pro­jek­tu, a posta­wie­nie kolej­ne­go domu na jego pod­sta­wie bez zgo­dy archi­tek­ta (auto­ra projektu).

Fundamentem Ustawy Prawo autor­skie, jest ochro­na utwo­ru czy­li tre­ści (jest nią tekst, ale tak­że każ­dy obraz czy zestaw dźwię­ków). Oprogramowanie, jako kod, zosta­ło tu (Ustawa) tak­że uwzględnione: 

Art. 1. 1. Przedmiotem pra­wa autor­skie­go jest każ­dy prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny w jakiej­kol­wiek posta­ci, nie­za­leż­nie od war­to­ści, prze­zna­cze­nia i spo­so­bu wyra­że­nia (utwór).
2. W szcze­gól­no­ści przed­mio­tem pra­wa autor­skie­go są utwo­ry:
1) wyra­żo­ne sło­wem, sym­bo­la­mi mate­ma­tycz­ny­mi, zna­ka­mi gra­ficz­ny­mi (lite­rac­kie, publi­cy­stycz­ne, nauko­we, kar­to­gra­ficz­ne oraz pro­gra­my kom­pu­te­ro­we);
2) pla­stycz­ne;
3) foto­gra­ficz­ne;
4) lut­ni­cze;
5) wzor­nic­twa prze­my­sło­we­go;
6) archi­tek­to­nicz­ne, archi­tek­to­nicz­no-urba­ni­stycz­ne i urbanistyczne;

Jednak znaj­du­je­my w Ustawie także:

Art. 23. Dozwolony uży­tek oso­bi­sty
1. Bez zezwo­le­nia twór­cy wol­no nie­od­płat­nie korzy­stać z już roz­po­wszech­nio­ne­go utwo­ru w zakre­sie wła­sne­go użyt­ku oso­bi­ste­go. Przepis ten nie upo­waż­nia do budo­wa­nia według cudze­go utwo­ru archi­tek­to­nicz­ne­go i archi­tek­to­nicz­no-urba­ni­stycz­ne­go oraz do korzy­sta­nia z elek­tro­nicz­nych baz danych speł­nia­ją­cych cechy utwo­ru, chy­ba że doty­czy to wła­sne­go użyt­ku nauko­we­go nie­zwią­za­ne­go z celem zarob­ko­wym.
2. Zakres wła­sne­go użyt­ku oso­bi­ste­go obej­mu­je korzy­sta­nie z poje­dyn­czych egzem­pla­rzy utwo­rów przez krąg osób pozo­sta­ją­cych w związ­ku oso­bi­stym, w szcze­gól­no­ści pokre­wień­stwa, powi­no­wac­twa lub sto­sun­ku towa­rzy­skie­go.
Art. 30(1). Do baz danych speł­nia­ją­cych cechy utwo­ru nie sto­su­je się art. 271 i art. 28.
Art. 35. Dozwolony uży­tek nie może naru­szać nor­mal­ne­go korzy­sta­nia z utwo­ru lub godzić w słusz­ne inte­re­sy twór­cy.
.

Art.23. już nie zawie­ra wprost poję­cia pro­gram”, usta­wo­daw­ca nie­śmia­ło” uznał, że baza danych” jed­nak nie jest już zwy­kłym utwo­rem. Ważnym zapi­sem jest jed­nak Art,35.: nie może godzić w słusz­ne inte­re­sy twór­cy”. Pozostaje tyl­ko poka­zać co i kie­dy godzi w ten słusz­ny inte­res”. Słusznym inte­re­sem twór­cy są przy­cho­dy z jego pra­cy i ozna­cze­nie go jako auto­ra. Pozostaje więc każ­do­ra­zo­wo wyka­zać, że okre­ślo­ne dzia­ła­nie (cyto­wa­nie, kopio­wa­nie itp.) umniej­sza mu, co może nie być pro­ste, a nie raz jest nie­moż­li­we. Co cie­ka­we cyto­wa­nie czy powie­la­nie utwo­ru, z zacho­wa­niem autor­skich praw oso­bi­stych, może nawet dzia­łać na korzyść twór­cy np. poka­zu­jąc jego zdol­no­ści. Wystarczy, że oso­ba powie­la­ją­ca nie czer­pie z tego żad­nych korzy­ści a udo­stęp­nio­ny utwór nie przy­no­si korzy­ści tym, któ­rzy go pozy­ska­li (wie­lu ludzi nie stać na książ­ki czy gry, więc albo nie prze­czy­ta­ją ich nigdy albo prze­czy­ta­ją za dar­mo, więc nie jest praw­dą, że powo­du­ją stra­ty przy­cho­du auto­ra, tak dzia­ła­ją np. biblioteki).

Generalnie na świe­cie toczy się deba­ta na temat poję­cia tan­tiem jako bier­nych przy­cho­dów i kry­ty­ki docho­dów bez świad­cze­nia pra­cy. Jednym z cie­kaw­szych moim zda­niem gło­sów jest uzna­nie, że czło­wiek powi­nien być wyna­gra­dza­ny za wyko­ny­wa­ną pra­cę a nie za mono­po­li­zo­wa­nie jej efek­tów. Ta idea wła­śnie przy­świe­ca idei opro­gra­mo­wa­nia open sour­ce: wyna­gro­dze­nie dosta­je­my za godzi­ny spę­dzo­ne nad jego wdra­ża­niem i roz­wi­ja­niem u jego użyt­kow­ni­ków (czy­li za świad­czo­ną pra­cę), a nie za udzie­lo­ną licen­cję, bo ta jest tu bezpłatna.

Komputer jako mechanizm

W lite­ra­tu­rze z obsza­ru filo­zo­fii infor­ma­ty­ki moż­na czę­sto zna­leźć opi­sy okre­śla­ją­ce kom­pu­ter jako uni­wer­sal­ny mecha­nizm” . Innymi sło­wy, sko­ro kom­pu­ter może reali­zo­wać roz­ma­ite funk­cje, w tym ana­lo­gicz­ne do funk­cji urzą­dzeń mecha­nicz­nych czy ele­kro-mecha­nicz­nych (np. zegar), a inte­gral­ną czę­ścią kom­pu­te­ra, odpo­wie­dzial­ną za to, jest «pro­gram», to mamy pra­wo uznać, że pro­gram (tu) to tak­że ele­ment kon­struk­cji tego urzą­dze­nia. A to już czy­ni pro­gram czymś wię­cej niż tyl­ko tek­stem”.

Nieco ponad rok temu pisa­łem o mecha­tro­ni­ce (Inteligentna pral­ka czy­li czym jest mecha­tro­ni­ka). Opisałem wte­dy meto­dę mode­lo­wa­nia urzą­dzeń elek­tro­me­cha­nicz­nych wska­zu­jąc przy­kła­dy, gdzie kom­pu­ter zastą­pił ele­ment (kom­po­nent) elek­tro­me­cha­nicz­ny, jakim jest np. pro­gra­ma­tor pral­ki. Nowoczesne urzą­dze­nia mogą zawie­rać ele­men­ty sztucz­nej inte­li­gen­cji” pozwa­la­ją­ce się nawet komu­ni­ko­wać urzą­dze­niom mię­dzy sobą (IoT: ang. Internet of Things czy­li Internet Rzeczy), a nie raz są to po pro­stu ele­men­ty reali­zu­ją­ce funk­cje auto­no­micz­nych zacho­wań (np. włą­cze­nie okre­so­we­go obro­tu bęb­na, jeże­li pral­ka nie zosta­nie otwar­ta i opróż­nio­na w cią­gu godzi­ny od zakoń­cze­nia cyklu pra­nia, co zapo­bie­ga trwa­łe­mu wygnie­ce­niu się garderoby). 

Poniżej sche­mat blo­ko­wy takiej hipo­te­tycz­nej pralki.

Schemat blo­ko­wy kon­struk­cji pral­ki auto­ma­tycz­nej (nota­cja SysML, opra­co­wa­nie wła­sne autora)

Kolorem poma­rań­czo­wym ozna­czo­no ele­men­ty będą­ce kom­pu­te­rem, któ­ry komu­ni­ku­je się z pozo­sta­ły­mi ele­men­ta­mi pral­ki na ogól­nych zasa­dach, czy­li z pomo­cą sygna­łów elek­trycz­nych, iden­tycz­nie jak każ­de inne elek­tro-mecha­nicz­ne urzą­dze­nie. Taki kom­pu­ter może komu­ni­ko­wać się z inny­mi urzą­dze­nia­mi (ste­ro­wać nimi) tak­że mecha­nicz­nie: wystar­czy, że wypo­sa­ży­my go dodat­ko­wo w ste­ro­wa­ne elek­trycz­nie cię­gna, zapad­ki, koła czy popy­cha­cze (tak dzia­ła zamek ste­ro­wa­ne­go kom­pu­te­rem zam­ka i domofonu).

Innymi sło­wy, z per­spek­ty­wy całe­go urzą­dze­nia, jakim jest np. pral­ka, odróż­nie­nie pro­gra­ma­to­ra będą­ce­go kom­pu­te­rem od pro­gra­ma­to­ra będą­ce­go mecha­nicz­nym ukła­dem zega­ro­wym, jest nie­moż­li­we. Co zresz­tą moż­na zaob­ser­wo­wać w nie­któ­rych mode­lach pra­lek (i nie tyl­ko): sta­ry mecha­nicz­ny pro­gra­ma­tor moż­na zastą­pić nowym (kom­pu­ter), bez potrze­by zmia­ny kon­struk­cji resz­ty, bo wymia­ry i meto­dy połą­cze­nia z resz­tą pral­ki zosta­ły zacho­wa­ne: stan­dard połą­cze­nia i współ­pra­cy kom­po­nen­tów urzą­dze­nia. To połą­cze­nie nazy­wa­my «inter­fej­sem». Pod poję­ciem «inter­fejs» nale­ży rozu­mieć zarów­no roz­staw otwo­rów mon­ta­żo­wych, jak i sygna­ły ste­ru­ją­ce i komu­ni­ka­ty prze­sy­ła­ne mię­dzy komponentami. 

Interfejs i jego realizacja

Interfejs to bar­dzo waż­ne poję­cie nie tyl­ko w inży­nie­rii opro­gra­mo­wa­nia. Są to gene­ral­nie wszel­kie sty­ki” mię­dzy kom­po­nen­ta­mi urzą­dzeń i urzą­dze­nia­mi. Interfejsem jest usta­lo­na śred­ni­ca rur­ki łączą­cej i mocu­ją­cej do rowe­ru sio­deł­ko. Interfejsem jest wałek z wie­lo­wy­pu­stem łączą­cy sil­nik ze sprzę­głem. Interfejsem jest (obec­nie uni­wer­sal­ne) złą­cze łado­war­ki smart­fo­na. Interfejsem jest API (Application Programming Interface) czy­li udo­stęp­nio­na moż­li­wość korzy­sta­nia z funk­cji inne­go oprogramowania.

Czym kon­kret­nie jest inter­fejs? Interfejs jest spe­cy­fi­ka­cją czy­li for­mą umo­wy, np. usta­le­nie wymia­rów wał­ka łączą­ce­go sil­nik i skrzy­nie bie­gów. Dzięki temu (umo­wa) oba te ele­men­ty (sil­nik i sprzę­gło) mogą powstać u róż­nych pro­du­cen­tów, a mimo to będą popraw­nie współ­pra­co­wa­ły. Bardzo czę­sto inter­fej­sy są powszech­nie uzna­ną umo­wą czy­li standardem. 

Schematycznie inter­fej­sy poka­zu­je­my jak poni­żej (nota­cja UML to tak­że standard): 

A. Komponenty i łączą­cy je interfejs
B. Współpraca apli­ka­cji jako korzy­sta­nie z inter­fej­su (nota­cja UML, opra­co­wa­nie wła­sne autora)

Jak czy­tać ten dia­gram? Interfejs_B to spe­cy­fi­ka­cja, czy­li opis współ­pra­cy (umo­wa). Komponent A korzy­sta z moż­li­wo­ści Komponentu B (lub zmu­sza” go to jakieś pra­cy) a robi to za pomo­cą Interfejsu_B. Interfejs_B to np. usta­lo­ne wymia­ry ww. wał­ka lub usta­lo­ny zestaw pole­ceń wymie­nia­nych mię­dzy dwo­ma apli­ka­cja­mi. Dlatego sche­mat blo­ko­wy wska­zu­ją­cy na to, że cho­dzi o opro­gra­mo­wa­nie, poza uży­ty­mi nazwa­mi, nie róż­ni się tego ogól­niej­sze­go” powy­żej. Powyższy sche­mat czy­ta­my:
- Komponent A (może on być czym­kol­wiek) korzy­sta z usług opi­sa­nych jako Interface_B (opis ten zawie­ra tak­że ocze­ki­wa­ny efekt),
- Komponent_B to mecha­nizm, któ­ry reali­zu­je usłu­gi opi­sa­ne (zade­kla­ro­wa­ne) jako Interfejs_B (ten kom­po­nent to okre­ślo­ne urzą­dze­nie elek­tro­me­cha­nicz­ne lub opro­gra­mo­wa­nie komputera).

Komponent B, jako okre­ślo­ne urzą­dze­nie lub opro­gra­mo­wa­nie (kom­pu­ter), może mieć tak­że swój opis (doku­men­ta­cja tech­nicz­na urzą­dze­nia, kod źró­dło­wy pro­gra­mu). Generalnie mówi­my, że Komponent B to imple­men­ta­cja Interfejsu_B albo że Komponent B reali­zu­je Interfejs_B.

Jeżeli Komponent A to nasz odku­rzacz a Komponent B to elek­trow­nia i sieć ener­ge­tycz­na, to Interfejs_B jest spe­cy­fi­ka­cją gniazd­ka w ścia­nie o usta­lo­nej war­to­ści napię­cia i prą­du oraz roz­sta­wie i wymia­rach otwo­rów. Aby sko­rzy­stać z zasi­la­nia, musi­my np. mieć odku­rzacz i wtycz­kę” zgod­ną ze spe­cy­fi­ka­cją inter­fej­su. Identycznie to wyglą­da gdy chce­my połą­czyć (zin­te­gro­wać) nasz sys­tem CRM z sys­te­mem GUS udo­stęp­nia­ją­cym dane pod­mio­tów gospo­dar­czych np. na pod­sta­wie nume­ru NIP (patrz API REGON).

Co do zasa­dy inter­fejs to publicz­na spe­cy­fi­ka­cja (rzad­kie wyjąt­ki, któ­rych inten­cją jest bez­pie­czeń­stwo, są jed­nak wąt­pli­wą meto­dą ochro­ny, patrz Zasada Kerckhoffssa).

Podsumowanie czyli co z tego wynika

Z powyż­sze­go moż­na wnio­sko­wać, że:

  1. każ­dy kom­po­nent sys­te­mu ma część jaw­ną: opis jak z nie­go sko­rzy­stać czy­li inter­fejs, oraz część będą­cą reali­za­cją (imple­men­ta­cją): jej opis może być jaw­ny ale chro­nio­ny paten­tem lub pra­wem autor­skim, albo nie­jaw­ny, chro­nio­ny jako know-how,
  2. z per­spek­ty­wy pra­wa autor­skie­go chro­nio­na może może być imple­men­ta­cja inter­fej­su, ale nie sam inter­fejs jako spe­cy­fi­ka­cja (pra­wo autor­skie ani paten­to­we nie chro­ni ani idei ani samej listy funk­cji czegoś), 
  3. jed­nak korzy­sta­nie, poprzez API, z usług reali­zo­wa­nych przez okre­ślo­ny kom­po­nent (imple­men­ta­cja) może wyma­gać licen­cji (patrz korzy­sta­nie pośred­nie),
  4. nie jest naru­sze­niem praw auto­ra kom­po­nen­tu (auto­ra jego pro­jek­tu) samo­dziel­ne opra­co­wa­nie wła­snej imple­men­ta­cji opu­bli­ko­wa­ne­go interfejsu,
  5. inter­fejs jako umo­wa”, to tak­że doku­ment” o okre­ślo­nej tre­ści, jed­nak jego rola i ogól­ność opi­su, pozwa­la­ją nie trak­to­wać go jak utwo­ru (inter­fejs to idea, wyrok SA w Poznaniu z dnia 4 stycz­nia 1995 r. I ACr 422/94).

Najwięcej emo­cji budzi ostat­ni punkt, i moim zda­niem na tym osa­dzo­na była isto­ta spo­ru Google vs. Oracle i wygra­na Google. Nie znam deta­li uza­sad­nie­nia tego wyro­ku, ale z opi­su skut­ków” moż­na wnio­sko­wać, że powyż­sze wyja­śnia to orze­cze­nie. Moim zda­niem wpla­ta­nie w to wąt­ku o dobro­wol­nym użyt­ku i jego roli roz­wo­jo­wej, było tu już przy­sło­wio­wym kwiat­kiem do kożu­cha, tym bar­dziej, że co do zasa­dy spe­cy­fi­ka­cja inter­fej­su i jego reali­za­cja to dwa odręb­ne byty (doku­men­ty), i sta­wia­nie tezy, że wyko­rzy­sta­nie opi­su inter­fej­su jest naru­sze­niem praw do jego imple­men­ta­cji, jest w świe­tle powyż­sze­go nie do obrony. 

Moim zda­niem całość tego spo­ru i podob­nych, pozwa­la zwró­cić uwa­gą na inny waż­ny aspekt: praw­ni­cy nie powin­ni sami oce­niać przed­mio­tu praw autor­skich, bo np. nie będąc inży­nie­ra­mi, nie mają wie­dzy o przed­mio­cie spo­ru ani zro­zu­mie­nia isto­ty przed­mio­tu spo­ru, któ­rym czę­sto jest opi­sa­ny mecha­nizm, gdzie jego opis, jako utwór w rozu­mie­niu pra­wa autor­skie­go, jest wtór­ny wobec nie­go same­go. To dla­te­go dobry praw­nik, posłu­gu­je się opi­nią bie­głe­go doty­czą­cą przed­mio­tu spo­ru, sku­pia­jąc sią na pra­wie. To, że każ­da doku­men­ta­cja tech­nicz­na to tekst i sche­ma­ty blo­ko­we to fakt, jed­nak utoż­sa­mia­nie ich wyłącz­nie z utwo­rem lite­rac­kim lub gra­ficz­nym” jest dale­ko idą­cym, i bar­dzo szko­dli­wym, uprosz­cze­niem, żeby nie powie­dzieć, że wręcz wła­śnie nie­zro­zu­mie­niem isto­ty tre­ści tych doku­men­tów i przed­mio­tu spo­ru lub przed­mio­tu umowy. 

Bardzo dobrze to zja­wi­sko opi­sa­ła Pani Mec. Renata W.Lewicka:

Prawnik powi­nien być aktyw­nym uczest­ni­kiem pla­no­wa­ne­go pro­ce­su, a biz­nes powi­nien ocze­ki­wać zro­zu­mie­nia pro­ce­su, a nie tyl­ko opi­sa­nia go w spo­sób jaki praw­nik go rozu­mie. (źr. TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK).

Źródła

Murawski, R. (Ed.). (2015). Filozofia mate­ma­ty­ki i infor­ma­ty­ki. Copernicus Center Press.
Van Horn, D., & Might, M. (2010). Abstracting Abstract Machines. ArXiv:1007.4446 [Cs]. http://​arxiv​.org/​a​b​s​/​1​0​0​7​.​4​446

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).

Dodaj komentarz

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