Ten arty­kuł to pew­ne­go rodza­ju kon­ty­nu­acja poprzed­nie­go: Vendor lock-in. Starałem się tu wyja­śnić czym jest pro­jekt i wska­zać, że pew­ne wywo­dy praw­ni­ków wyda­ją się nie mieć żad­ne­go uzasadnienia. 

Prawo autorskie

Pomysł, aby ochro­nę roz­wią­zań bran­ży IT oprzeć na pra­wie autor­skim nie był spe­cjal­nie szczę­śli­wy. Prawo autor­skie stwo­rzo­no z myślą o twór­cach oraz odbior­cach. (źr.: Prawa autor­skie w pro­jek­tach IT. Głównie o róż­ni­cach mię­dzy prze­nie­sie­niem praw a licen­cja­mi)

Zaskakuje mnie taka teza, bo pra­wo autor­skie, jak sama nazwa wska­zu­je, stwo­rzo­no z myślą o auto­rach. To, że ta kon­kret­na usta­wa zawie­ra wie­le odnie­sień np. do muzy­ki nie zmie­nia fak­tu, że regu­lu­je wszel­kie prze­ja­wy ​„twór­czej dzia­łal­no­ści o indy­wi­du­al­nym cha­rak­te­rze”. Ta usta­wa dosko­na­le sobie radzi z każ­dą inży­nie­rią, i uwa­żam, że inży­nie­ria opro­gra­mo­wa­nia nie jest tu żad­nym wyjąt­kiem. Być może Pan Maruta dzia­ła tu jako lob­by­sta ​„edżaj­lo­wych pro­gra­mi­stów”, cze­mu chy­ba daje wyraz, np. tu:

Wdrożenia sys­te­mów infor­ma­tycz­nych to zde­cy­do­wa­nie jed­ne z naj­bar­dziej skom­pli­ko­wa­nych przed­się­wzięć w bran­ży IT. Ta oczy­wi­sta oczy­wi­stość znaj­du­je swo­je potwier­dze­nie cho­ciaż­by w kosz­tach zwią­za­nych z reali­za­cją wdro­żeń oraz ska­lą ryzy­ka wyni­ka­ją­cą z ewen­tu­al­ne­go nie­po­wo­dze­nia pro­jek­tów wdro­że­nio­wych. (źr.: Jak pisać umo­wy dla pro­jek­tów IT reali­zo­wa­nych w mode­lu Agile? Cz. I.)

Słowa ​„oczy­wi­sta oczy­wi­stość” to czę­sty wybieg reto­rycz­ny praw­ni­ków, mówią­cy roz­mów­cy ​„nawet nie pró­buj pod­wa­żać tego co powie­dzia­łem”. Otóż nie­ste­ty wiel­ko­ści budże­tów nie są jakieś spe­cjal­nie wiel­kie na tle innych inży­nie­rii (Pan Maruta stra­szy kil­ko­ma ewe­ne­men­ta­mi, rzecz w tym, że podał przy­kła­dy głów­nie złe­go zarzą­dza­nia zakre­sem pro­jek­tów), a ska­la ryzy­ka pro­jek­tów IT jest dale­ko mniej­sza, bo nie­po­wo­dze­nia pro­jek­tów IT nie powo­du­ją np. ofiar w ludziach jak w przy­pad­ku kata­strof budow­la­nych czy komu­ni­ka­cyj­nych. A więc nie jest to żad­na ​„oczy­wi­sta oczywistość”. 

Teza Pana Maruty i jego wywo­dy o IT natych­miast przy­po­mnia­ły mi inny arty­kuł (pole­cam):

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 auto­ra (Marcin Maruta): ​„Pomysł, aby ochro­nę roz­wią­zań bran­ży IT oprzeć na pra­wie autor­skim nie był spe­cjal­nie szczę­śli­wy”, jest co naj­mniej nie­zro­zu­mia­ła, a sam autor jej nie uza­sad­nia. Autor wska­zu­je na rosną­cą kom­pli­ka­cje tego pra­wa, ale nie­ja­ko sam wska­zu­je źró­dło: lob­bing pra­co­daw­ców w celu zła­go­dze­nia ochro­ny twór­ców (auto­rów czy­li ich pra­cow­ni­ków: pro­gra­mi­stów, pro­jek­tan­tów, archi­tek­tów opro­gra­mo­wa­nia). Ten wątek pozo­sta­wię bez komentarza. 

Innymi sło­wy jeże­li pro­gram powstał bez takie­go pro­jek­tu, jest on fak­tycz­nie samo­dziel­nym utwo­rem pro­gra­mi­sty (co zresz­tą bar­dzo czę­sto ma miej­sce). Jeżeli jed­nak pro­gram (opro­gra­mo­wa­nie, apli­ka­cja) powstał jako opra­co­wa­nie pro­jek­tu wyra­żo­ne­go w for­mie j.w. (sche­ma­ty blo­ko­we, wzo­ry, tabli­ce, algo­ryt­my itp. ) jest wyłącz­nie imple­men­ta­cją (efekt sta­ran­ne­go dzia­ła­nia), lub utwo­rem zależ­nym, jeże­li autor oddał pew­ną okre­ślo­ną swo­bo­dę pro­ga­mi­ście. To, że to jest to rzad­ka sytu­acja (ist­nie­nie pro­jek­tu), nie zmie­nia fak­tu, że jest pro­gram nie jest tu utwo­rem a wyko­na­niem utwo­ru .

Uważam, że orzecz­nic­two jest jed­nak po stro­nie pro­jek­tan­tów i archi­tek­tów sys­te­mów, w tym opro­gra­mo­wa­nia. Więcej o tym zagad­nie­niu napi­sa­łem w arty­ku­le Ochrona know-how. Tu sku­pię się na pro­jek­cie opro­gra­mo­wa­nia jako samo­dziel­nym i peł­no­praw­nym utwo­rze będą­cym spe­cy­fi­ka­cją opro­gra­mo­wa­nia jakie ma powstać (pro­jekt jako wymaganie).

Projektowanie

Zacznijmy od pro­ste­go przy­kła­du i słyn­ne­go zara­zem wyna­laz­ku i paten­tu (w USA). Poniższy rysu­nek to model (spe­cy­fi­ka­cja) mecha­ni­zmu dzia­ła­nia regu­la­to­ra. Nie jest to nawet rysu­nek tech­nicz­ny wyko­naw­czy. Jest to utwór w rozu­mie­niu usta­wy, bo: sta­no­wi prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny zna­ka­mi gra­ficz­ny­mi. Nie mniej jed­nak sta­no­wi bar­dzo pre­cy­zyj­ny opis mecha­ni­zmu dzia­ła­nia odśrod­ko­we­go regu­la­to­ra obrotów. 

Poniższe zdję­cie to jed­na z wie­lu moż­li­wych imple­men­ta­cji (opra­co­wa­nia) powyż­sze­go mecha­ni­zmu. I co cie­ka­we, udo­wod­nie­nie, że jest to imple­men­ta­cja (utwór zależ­ny) mecha­ni­zmu opi­sa­ne­go powy­żej, nie zaj­mie żad­ne­mu sądo­wi zbyt wie­le czasu. 

Tak więc jed­no jest tu pew­ne: kon­kret­na kon­struk­cja na zdję­ciu powy­żej jest opra­co­wa­niem utwo­ru (utwór zależ­ny) jakim jest sche­mat (model) opi­su­ją­cy mecha­nizm dzia­ła­nia odśrod­ko­we­go regu­la­to­ra obro­tów Watta. I nie­za­leż­nie od tego ile wła­snej inwen­cji wło­żył w to inży­nier kon­struk­tor tego kon­kret­ne­go regu­la­to­ra, jest to – kon­struk­cja na zdję­ciu – utwór zależ­ny. Poniżej inna kon­struk­cja (imple­men­ta­cja) tego same­go mecha­ni­zmu, to tak­że jest utwór zależny. 

Pewną cie­ka­wost­ką jest sta­no­wi­sko pol­skie­go usta­wo­daw­cy, mówią­ce że: 

Art. 28 pkt. 5 usta­wy o wła­sno­ści prze­my­sło­wej sta­no­wi, iż za wyna­la­zek nie może być uzna­wa­ny ?pro­gram do maszyn cyfro­wych?. Wynika z tego jasno, iż pro­gram kom­pu­te­ro­wy nie może być zatem zgło­szo­ny do wła­ści­we­go urzę­du paten­to­we­go celem jego reje­stra­cji i uzy­ska­nia sto­sow­ne­go paten­tu. Autorzy pro­gra­mu kom­pu­te­ro­we­go mogą pró­bo­wać jedy­nie opa­ten­to­wać wyna­la­zek, któ­ry wspo­ma­ga­ny jest pro­gra­mem kom­pu­te­ro­wym, nie­zbęd­nym do jego pra­wi­dło­we­go funk­cjo­no­wa­nia. (źr.: Ochrona praw­na pro­gra­mów kom­pu­te­ro­wych)

Absolutnie nie jestem zwo­len­ni­kiem paten­to­wa­nia opro­gra­mo­wa­nia, a nawet gene­ral­nie jestem prze­ciw­ni­kiem paten­tów, czy­li trwa­łych mono­po­li na wyna­laz­ki ludz­kie. Teza mówią­ca, że ​„za wyna­la­zek nie może być uzna­wa­ny ​„pro­gram do maszyn cyfro­wych” wyda­je się nielogiczna.

Popatrzmy na to. Poniżej zdję­cie mecha­nicz­ne­go pro­gra­ma­to­ra pral­ki: zawie­ra sil­nik i tak zwa­ne krzyw­ki ste­ru­ją­ce sty­ka­mi sterownika. 

Identyczne funk­cje, jako mecha­nizm ste­ru­ją­cy, reali­zu­je poniż­szy nowo­cze­sny ste­row­nik będą­cy tak na praw­dę kom­pu­te­rem (mikro­kon­tro­ler) z pro­gra­mem, ten pro­gram reali­zu­je (imple­men­tu­je) iden­tycz­ny mecha­nizm ste­ro­wa­nia jak ten na zdję­ciu powy­żej, bo nie przy­pad­kiem kom­pu­ter jest okre­śla­ny jako ​„uni­wer­sal­ny mecha­nizm” .

W pew­nych obsza­rach mecha­nizm wyko­na­ny (opra­co­wa­ny, wyna­le­zio­ny) jako kon­struk­cja mecha­nicz­na (moż­li­wa do opa­ten­to­wa­nia) może być zre­ali­zo­wa­ny w 100% z uży­ciem kom­pu­te­ra: mecha­nicz­ny aryt­mo­metr został zastą­pio­ny elek­tro­nicz­nym kal­ku­la­to­rem (to jest kom­pu­ter), mecha­nicz­ny zegar tak­że pro­gra­mem kom­pu­te­ra (czy­taj tak­że Model czy abs­trak­cja). Ładnie to opi­su­je autor publi­ka­cji nauko­wej zaty­tu­ło­wa­nej Komputer jako uni­wer­sal­ny mecha­nizm . Innymi słowy: 

Dokładnie z tego same­go powo­du gar­nek nie jest inte­gral­ną czę­ścią chro­nio­ne­go prze­pi­su potra­wy kuli­nar­nej (a są one chro­nio­ne pra­wem np. jako pro­duk­ty spo­żyw­cze regio­nal­ne, np. takie jak oscypek). 

Od dekad mamy do czy­nie­nia z postę­pem tech­no­lo­gii gdzie jeden z obsza­rów inży­nie­rii: sze­ro­ko poję­te sys­te­my ste­ro­wa­nia, jest sys­te­ma­tycz­nie pochła­nia­ny przez kom­pu­te­ry. Mechaniczne kon­struk­cje takie jak sys­te­my zli­cza­ją­ce, cza­so­mie­rze, kal­ku­la­to­ry, ste­ro­wa­nie opar­te o cię­gna, sys­te­my auto­ma­ty­ki, sys­te­my zobra­zo­wa­nia (np. wska­zów­ko­we: moni­tor zamiast mecha­nicz­ne­go wskaź­ni­ka) itp. są zastę­po­wa­ne przez kom­pu­ter (rozu­mia­ny jako pro­ce­sor, pamięć i pro­gram). Kolejne kon­struk­cje, do nie­daw­na wyłącz­nie mecha­nicz­ne, są zastę­po­wa­ne kom­pu­te­rem (patrz tak­że nie­daw­ny arty­kuł: Inteligentna pral­ka czy­li czym jest mecha­tro­ni­ka). Proces ten postę­pu­je, powsta­ła nota­cja (roz­sze­rze­nie UML) pozwa­la­ją­ca na mode­lo­wa­nie (spe­cy­fi­ko­wa­nie) takich mie­sza­nych kon­struk­cji: SysML:

Wszystkie powyż­sze kon­struk­cje są chro­nio­ne pra­wem autor­skim, jako ich pro­jek­ty wyko­na­ne w posta­ci udo­ku­men­to­wa­nych (usta­lo­nych) opi­sów (spe­cy­fi­ka­cji) wyko­na­nych z uży­ciem sche­ma­tów blo­ko­wych, zapi­sów związ­ków logicz­nych i wzo­rów mate­ma­tycz­nych. Tak więc teza, jako­by opro­gra­mo­wa­nie wyma­ga­ło jakie­goś inne­go spe­cjal­ne­go podej­ścia, jest moim zda­niem nie do obro­ny: jeże­li kom­pu­ter (czy­li tak­że pro­gram) może być rów­no­praw­nym funk­cjo­nal­nie zamien­ni­kiem kon­struk­cji mecha­nicz­nej (co wyka­za­no powy­żej), to zna­czy że moż­na wobec nie­go i kon­struk­cji mecha­nicz­nych, sto­so­wać te same zapi­sy w prawie. 

Podsumowanie

Czy moż­li­we jest więc opra­co­wa­nie spe­cy­fi­ka­cji dla wyko­na­nia opro­gra­mo­wa­nia, ana­lo­gicz­nej jak dla urzą­dze­nia mecha­nicz­ne­go? Oczywiście! Powyższa pozy­cja lite­ra­tu­ry to jed­na z wie­lu tego typu. Na tym blo­gu jest wie­le przy­kła­dów takich spe­cy­fi­ka­cji. Stawianie tezy, że jedy­ną moż­li­wą for­mą usta­le­nia opro­gra­mo­wa­nia jest kod źró­dło­wy, nie ma żad­ne­go uza­sad­nie­nia w fak­tach: mamy na świe­cie ogrom­ną ilość doku­men­ta­cji sta­no­wią­cej pre­cy­zyj­ną spe­cy­fi­ka­cje opro­gra­mo­wa­nia jakie ma powstać. Oczywiście nie ma obo­wiąz­ku two­rze­nia takich doku­men­tów (meto­dy nazy­wa­ne agi­le) ale po pierw­sze jest to moż­li­we, po dru­gie jest to jed­nak nadal naj­sku­tecz­niej­sza meto­da zama­wia­nia opro­gra­mo­wa­nia. Panu Marucie, świet­ne­mu praw­ni­ko­wi, pole­cam jed­nak kon­fron­to­wa­nie poglą­dów pro­gra­mi­stów któ­rych repre­zen­tu­je, z dostęp­ną lite­ra­tu­rą i nauko­wą i popu­lar­ną z zakre­su inży­nie­rii opro­gra­mo­wa­nia oraz orzecz­nic­two w tym zakre­sie, np. poniższe: 

Dokumentacja i inne mate­ria­ły doty­czą­ce pro­jek­to­wa­nia pro­gra­mu kom­pu­te­ro­we­go nale­ży trak­to­wać jako pro­gram kom­pu­te­ro­wy (imple­men­ta­cja dyrek­ty­wy Parlamentu Europejskiego i Rady 2009/24/WE dnia 23 kwiet­nia 2009 (wer­sja ujed­no­li­co­na dyrek­ty­wy Rady Wspólnoty Europejskich nr 91/250 z dnia 14 maja 1991): ?dla celów niniej­szej dyrek­ty­wy poję­cie ?pro­gram kom­pu­te­ro­wy? obej­mu­je rów­nież przy­go­to­waw­cze pra­ce pro­jek­to­we i mate­riał projektowy?.

Co potwier­dza­ją tak­że auto­rzy naj­now­szych publi­ka­cji nauko­wych, np. 

„Programming is not sole­ly abo­ut con­struc­ting softwa­re, pro­gram­ming is abo­ut desi­gning softwa­re”. .

Podsumowując: moż­li­we jest opra­co­wa­nie doku­men­ta­cji opro­gra­mo­wa­nia opi­su­ją­cej (wyma­ga­ny) mecha­nizm jego dzia­ła­nia i archi­tek­tu­rę. Oprogramowanie powsta­łe na bazie takiej doku­men­ta­cji to imple­men­ta­cja pro­jek­tu i sta­no­wi ono utwór zależ­ny w sto­sun­ku do utwo­ru jakim jest pier­wot­na spe­cy­fi­ka­cja. Prawo autor­skie jest tu wręcz dosko­na­łym mecha­ni­zmem kon­tro­l­nym nad wyko­naw­cą opro­gra­mo­wa­nia: mając pra­wa mająt­ko­we do pro­jek­tu tech­nicz­ne­go, z zasa­dy dys­po­nu­je­my w peł­ni opro­gra­mo­wa­niem wyko­na­nym na nasze zamó­wie­nie i na pod­sta­wie takiej doku­men­ta­cji. Jeżeli dostaw­ca stwo­rzy zamó­wio­ne opro­gra­mo­wa­nie ina­czej bo po swo­je­mu, to zna­czy tyl­ko tyle, nie zre­ali­zo­wał zawar­tej umo­wy i nie nale­ży mu płacić. 

Tak zwa­ne pro­jek­ty «agi­le» to cał­ko­wi­ty brak kon­tro­li nad wyko­naw­cą i nad wła­snym know-how. Trudno się więc dzi­wić, że jest to meto­da for­so­wa­na przez dostaw­ców opro­gra­mo­wa­nia i ich prawników. 

(pole­cam tak­że ana­lo­gicz­ny pra­wo­moc­ny wyrok doty­czą­cy muzy­ków gra­ją­cych z nut pod dyk­tan­do dyry­gen­ta)

Źródła