Pojęcie nad­zo­ru autor­skie­go budzi wie­le emo­cji, w bran­ży IT jest to chy­ba temat tabu, głów­nie z powo­du nad­użyć twór­ców i dostaw­ców opro­gra­mo­wa­nia, a tak­że dla­te­go, że tu (bran­ża IT) pra­wo nie zabra­nia peł­nie­nia przez jeden pod­miot roli pro­jek­tan­ta i wykonawcy.

Z danych Panorama Consulting wyni­ka, że zale­d­wie 12% przed­się­biorstw nie wpro­wa­dza żad­nych mody­fi­ka­cji sys­te­mu ERP jed­nak 70% firm wpro­wa­dza mody­fi­ka­cje w apli­ka­cji się­ga­ją­ce 25% (źr. 2017-ERP-Report):

Na budowie

Autor pew­ne­go blo­ga praw­ne­go poru­szył cie­ka­wy pro­blem, któ­ry wystę­pu­je tak­że w pro­jek­tach IT. Tu nie­zbyt czę­sto (a szko­da) ale wystę­pu­je pra­wie zawsze w moich pro­jek­tach, bo ja aku­rat reali­zu­je pro­jek­ty, w któ­rych jestem zewnętrz­nym pro­jek­tan­tem. Inwestorzy to moi klien­ci, deve­lo­per reali­zu­je mój projekt.

Warto tu zwró­cić uwa­gę na to, że pro­jek­ty pro­gra­mi­stycz­ne są w pra­wie (pra­wo autor­skie i ochro­na know-how) peł­ną ana­lo­gią pro­jek­tów budow­la­nych, i prze­pi­sy te sto­su­je się odpo­wied­nio. Więcej napi­sa­łem o tym w arty­ku­le o ochro­nie know-how.

Problem, o któ­rym pisze autor jest zarzą­dza­nie zmia­ną (w IT mówi­my o kasto­mi­za­cji sys­te­mów np. ERP):

Wybudowanie obiek­tu to zło­żo­ny i dłu­go­trwa­ły pro­ces. Od pro­jek­tu do obiek­tu upły­wa dużo cza­su, a inwe­stor czę­sto zmie­nia zda­nie co do osta­tecz­ne­go kształ­tu powsta­ją­ce­go budyn­ku. Czy inwe­stor może żądać wpro­wa­dze­nia wszel­kich zmian, wedle wła­sne­go uzna­nia? Czy może zle­cić doko­na­nie zmian inne­mu pro­jek­tan­to­wi? Czy twór­ca może się zmia­nom sprze­ci­wić? Jak wyglą­da ta spra­wa na grun­cie pra­wa autor­skie­go? Wcześniej pisa­łem o zmia­nach na eta­pie pro­jek­to­wa­nia, dziś o zmia­nach na eta­pie budowania.

Projekt z dzie­dzi­ny inży­nie­rii opro­gra­mo­wa­nia, pro­wa­dzo­ny zgod­nie z naj­lep­szy­mi prak­ty­ka­mi, ma etap ana­li­zy pro­ble­mu, pro­jek­to­wa­nia archi­tek­tu­ry roz­wią­za­nia oraz two­rze­nia (dostar­cze­nia i dosto­so­wa­nia) same­go roz­wią­za­nia, któ­re reali­zu­je wybra­ny wyko­naw­ca. Tu tak­że ma miej­sce nad­zór auto­ra pro­jek­tu nad jego reali­za­cją (wytwa­rza­niem, dosto­so­wa­niem aplikacji).

To cze­go fak­tycz­nie inwe­stor może się oba­wiać, a z cze­go nie­ste­ty nagmin­nie korzy­sta­ją twór­cy opro­gra­mo­wa­nia, to nad­uży­wa­nie pozy­cji mono­po­lu autorskiego:

[…] Warto zasy­gna­li­zo­wać jesz­cze jeden aspekt zwią­za­ny ze źró­dłem poten­cjal­ne­go kon­flik­tu mię­dzy pro­jek­tan­tem, a inwe­sto­rem. Mianowicie zda­rza­ją się w prak­ty­ce sytu­acje, gdy archi­tek­ci uza­leż­nia­ją wpro­wa­dze­nie zmia­ny do pro­jek­tu zgod­nie z zamy­słem inwe­sto­ra od usta­no­wie­nia dodat­ko­we­go wyna­gro­dze­nia. W takim przy­pad­ku, pro­jek­tant powo­łu­je się na swo­je autor­skie pra­wa oso­bi­ste, któ­re zaka­zu­ją oso­bą trze­cim zmie­niać jego utwór, chcąc uzy­skać dodat­ko­wą korzyść mająt­ko­wą. Inwestor w takich sytu­acjach czę­sto był­by zupeł­nie pozba­wio­ny ochro­ny. W lite­ra­tu­rze poja­wi­ły się suge­stie, mimo licz­nych wąt­pli­wo­ści, żeby w takich przy­pad­kach powo­ły­wać się na art. 5 kc, zarzu­ca­jąc pro­jek­tan­tom nad­uży­cie swo­ich praw. (Źródło: Prawa autor­skie w ARCHITEKTURZE – Potencjalny kon­flikt inwe­sto­ra z pro­jek­tan­tem na tle pra­wa autor­skie­go – część 2 | IPblog – o pra­wie wła­sno­ści inte­lek­tu­al­nej i nowych technologii)

Oprogramowanie

W bran­ży inży­nie­rii opro­gra­mo­wa­nia dość powszech­na jest sytu­acja, gdy pro­gra­mi­sta jest tak­że pro­jek­tan­tem, inny­mi sło­wy pro­gra­mi­sta ma peł­nię praw autor­skich do kodu jaki two­rzy a jego klient żad­nych mimo, że jest inwe­sto­rem! Poniżej przy­kład zapi­su w umo­wie, któ­rą nie­daw­no audytowałem:

Wykonawca nie prze­no­si na Zamawiającego jakich­kol­wiek autor­skich praw mająt­ko­wych do Oprogramowania (co doty­czy tak­że wszyst­kich adap­ta­cji, mody­fi­ka­cji i kopii Oprogramowania oraz jego Dokumentacji).

Ten zapis ozna­cza, że dostaw­ca opro­gra­mo­wa­nia, np. opra­co­wał (udo­ku­men­to­wał) jakiś mecha­nizm dzia­ła­nia swo­je­go klien­ta (na pod­sta­wie wywia­dów z nim) i zaim­ple­men­to­wał go w wytwa­rza­nym (roz­wi­ja­nym, kasto­mi­zo­wa­nym) opro­gra­mo­wa­niu, jed­nak sta­je się tak­że posia­da­czem praw autor­skich oso­bi­stych i mająt­ko­wych do tak opra­co­wa­nej logi­ki biz­ne­so­wej, któ­rą potem sprze­da­je (a kon­kret­nie tyl­ko licen­cjo­nu­je) swo­je­mu spon­so­ro­wi (i innym swo­im klien­tom, nie raz tak­że kon­ku­ren­tom spon­so­ra). Ta logi­ka bar­dzo czę­sto sta­no­wi know-how spon­so­ra projektu!

Zapis w innej audy­to­wa­nej umo­wie doty­czą­cy prac kasto­mi­za­cyj­nych w sys­te­mie ERP, doko­ny­wa­nych przez fir­mę wdra­ża­ją­ca a nie przez pro­du­cen­ta producenta:

W przy­pad­ku wyko­na­nia mody­fi­ka­cji i dosto­so­wa­nia opro­gra­mo­wa­nia do potrzeb Zamawiającego, Wykonawca z dniem zapła­ty wyna­gro­dze­nia za Usługi dodat­ko­we obej­mu­ją­ce ww. mody­fi­ka­cje, udzie­la Zamawiającemu licen­cji na korzy­sta­nie z tych mody­fi­ka­cji przez Zamawiającego, na warun­kach na jakich udzie­lo­no uprzed­nio licen­cji na korzy­sta­nie z Oprogramowania. Wynagrodzenie za wyko­na­nie przed­mio­to­wych mody­fi­ka­cji wska­za­nych powy­żej wydzie­lo­nych czę­ści opro­gra­mo­wa­nia, obej­mu­je wyna­gro­dze­nie z tytu­łu udzie­le­nia licencji.

To już jest kurio­zum, zna­ne z aneg­dot w rodza­ju: kon­sul­tant, by odpo­wie­dzieć na pyta­nie Która jest teraz godzi­na, pro­si Klienta o jego zega­rek, odpo­wia­da na pyta­nie, a zabra­ny Klientowi zega­rek wypo­ży­cza mu za sowi­tym wynagrodzeniem”.

Ta wadli­wa sytu­acja, jaką tu opi­sa­łem, to np. cecha wszyst­kich pro­jek­tów agi­le i tych gdzie pro­gra­mi­sta jest tak­że ana­li­ty­kiem i pro­jek­tan­tem (jeże­li taki etap jest w pro­jek­cie). W efek­cie projektant/wykonawca bar­dzo czę­sto wyko­rzy­stu­je swo­ją pozy­cję podwój­nie: nie wpro­wa­dza zmian dla sie­bie nie­ko­rzyst­nych (np. trud­na i kosz­tow­na reali­za­cja) i narzu­ca zmia­ny popra­wia­ją­ce mar­że na reali­zo­wa­nym pro­jek­cie (uprasz­cza­nie), z cze­go spon­sor z regu­ły nie zda­je sobie spra­wy. Trzecim narzę­dziem” budo­wy mar­ży jest godze­nie się na wszel­kie pro­po­zy­cje inwe­sto­ra mając kon­trakt T&M, bez ostrze­ga­nia go o kon­se­kwen­cjach wpro­wa­dza­nych zmian dla całe­go pro­jek­tu (a jest nią z regu­ły dodat­ko­wa pracochłonność).

Bardzo wie­le pro­jek­tów pro­gra­mi­stycz­nych koń­czy się nie dla­te­go, że uzy­ska­no ocze­ki­wa­ną funk­cjo­nal­ność a dla­te­go, że wyczer­pa­no budżet lub czas, lub oba te zasoby.

Czy można inaczej? Oczywiście.

źr. Figure 1: Computers, Models, and the Embedding World (Smith 1985)

W umo­wie nale­ży zazna­czyć, że wszel­kie pra­ce pro­gra­mi­stycz­ne poprze­dza­ne są udo­ku­men­to­wa­ną ana­li­zą i pro­jek­to­wa­niem, i że pra­wa mająt­ko­we do tre­ści tych doku­men­tów prze­cho­dzą na Zamawiającego. Taka sytu­acja nadal jest jed­nak nie­zdro­wa, bo nadal wyko­naw­ca łączy rolę pro­jek­tan­ta i deve­lo­pe­ra (cze­go np. pra­wo budow­la­ne zabra­nia z uwa­gi na powsta­łą tak uprzy­wi­le­jo­wa­ną pozy­cję developera).

Ideałem, któ­ry moż­na łatwo osią­gnąć, jest cał­ko­wi­te oddzie­le­nie ana­li­zy i pro­jek­to­wa­nia od reali­za­cji (dla pro­jek­tów IT zale­ca to UZP w doku­men­cie z 2009 roku). W razie bra­ku takich kom­pe­ten­cji po stro­nie Zamawiającego, wystar­czy zatrud­nić pro­jek­tan­ta. Po pra­wej stro­nie powy­żej, ilu­stra­cja z 1985 roku: MODEL to owa pre­cy­zyj­na doku­men­ta­cja (to zna­czy musi być pre­cy­zyj­na, by moż­na ją było uznać za pro­jekt – utwór – chro­nio­ny prawem).

Model opro­gra­mo­wa­nia (źr. Large Scale Software Architecture, A prac­ti­cal Guide Using UML)

Co cie­ka­we, moż­na to zro­bić w dowol­nej chwi­li nawet po pod­pi­sa­niu nie­ko­rzyst­nej umo­wy (zawie­ra­ją­cej zapi­sy jak te omó­wio­ne powy­żej). W takiej sytu­acji, wyko­naw­ca, reali­zu­jąc pro­jekt, otrzy­mu­je od Zamawiającego, nie ust­ne czy nawet pisem­ne, ogól­ne idee swo­ich potrzeb, a doku­men­ty zawie­ra­ją­ce dokład­ne opra­co­wa­nie pro­jek­tu imple­men­ta­cji (logi­ka biz­ne­so­wa i archi­tek­tu­ra), któ­rą Wykonawca ma zgod­nie z umo­wą zre­ali­zo­wać. Warunkiem powo­dze­nia jest to, by autor­skie pra­wa mająt­ko­we do tych doku­men­tów były przy Zamawiającym (pro­jek­tant powi­nien prze­ka­zać pra­wa mająt­ko­we do pro­jek­tu w pisem­nie zawar­tej umo­wie). W takiej sytu­acji Wykonawca wyko­nu­je pra­wa zależ­ne do utwo­ru i mimo, że jest auto­rem imple­men­ta­cji, nie ma żad­nych praw do dys­po­no­wa­nia nią.

Autor cyto­wa­ne­go arty­ku­łu powo­łu­je się pod jego koniec na waż­ny, i czę­sto zapo­mi­na­ny para­graf Kodeksu Cywilnego:

Art. 5. Nie moż­na czy­nić ze swe­go pra­wa użyt­ku, któ­ry by był sprzecz­ny ze spo­łecz­no-gospo­dar­czym prze­zna­cze­niem tego pra­wa lub z zasa­da­mi współ­ży­cia spo­łecz­ne­go. Takie dzia­ła­nie lub zanie­cha­nie upraw­nio­ne­go nie jest uwa­ża­ne za wyko­ny­wa­nie pra­wa i nie korzy­sta z ochro­ny. (KC)

I tym akcen­tem, zakoń­czę ten krót­ki wpis 🙂 i pole­cam też lek­tu­rę całe­go cyto­wa­ne­go artykułu.

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.