Wprowadzenie

Tematem numer jeden, niemalże w każdym moim projekcie, jest model biznesowy i tajemnica przedsiębiorstwa. Z perspektywy lat muszę powiedzieć, że to fobia wielu (jak nie większości) przedsiębiorców i nie tylko przedsiębiorców. Nie dlatego, że chcą coś chronić, ale dlatego co i jak chronią. Nie raz już pisałem, że firmy nie raz, najpierw podpisują z dostawcami rozwiązań i konsultantami umowy o poufności, a potem wyzbywają praw do swojego know-how na ich rzecz:

W branży inżynierii oprogramowania dość powszechna jest sytuacja, gdy programista jest także projektantem, innymi słowy programista ma pełnię praw autorskich do kodu jaki tworzy a jego klient żadnych mimo, że jest inwestorem!¹

Dzisiaj drugi problem czyli bezpieczeństwo informacji a nie raz i całej firmy.

Na początek coś z zakres teorii informacji:

Zasada Kerckhoffs’a to jedna z podstawowych reguł współczesnej kryptografii. Została sformułowana pod koniec XIX wieku przez holenderskiego kryptologa Augusta Kerckhoffs’a (ur. 19 stycznia 1835, zm. 9 sierpnia 1903). Zasada ta mówi, że system kryptograficzny powinien być bezpieczny nawet wtedy, gdy są znane wszystkie szczegóły jego działania oprócz sekretnego klucza. […]

1. System powinien być, jeśli nie teoretycznie, to w praktyce nie do złamania.
2. Projekt systemu nie powinien wymagać jego tajności, a ewentualne jego ujawnienie nie powinno przysparzać kłopotów korespondentom.
3. Klucz powinien być możliwy do zapamiętania bez notowania i łatwy do zmienienia.
4. Kryptogramy powinny być możliwe do przesłania drogą telegraficzną.
5. Aparatura i dokumenty powinny być możliwe do przeniesienia i obsłużenia przez jedną osobę.
6. System powinien być prosty ? nie wymagający znajomości wielu reguł ani nie obciążający zbytnio umysłu.

Właśnie druga z tych reguł nosi obecnie nazwę zasady Kerckhoffs’a.

[…]Ideę zasady Kerckhoffs’a wyraża również przypisywane Claude’owi Shannon’owi powiedzenie “Wróg zna system” (ang. The enemy knows the system), znane pod nazwą Maksymy Shannona (ang. Shannon’s maxim).²

Zasadę tę, jako kryterium, można łatwo poszerzyć, usuwając ostatnie słowo do postaci:

Projekt systemu nie powinien wymagać jego tajności, a ewentualne jego ujawnienie nie powinno przysparzać kłopotów.

Na rynku mamy dwa przeciwstawne w pewnym sensie (o tym dalej) pojęcia: patent oraz know-how, dodać należało by do tego zestawu pojęcie prawo autorskie osobiste i majątkowe.

O bezpieczeństwie biznesowym

Na początek klasycznie kluczowe definicje:

know-how: rozumiane jest jako pakiet nieopatentowanych informacji praktycznych, wynikających z doświadczenia i badań, które są:
1.    niejawne (nie są powszechnie znane lub łatwo dostępne);
2.    istotne (ważne i użyteczne z punktu widzenia wytwarzania Know-how: ochrona tajemnicy przedsiębiorstwa).

bezpieczeństwo: stan niezagrożenia (s.j.p.)

tajemnica: sekret; też: nieujawnianie czegoś (s.j.p.)

patent: dokument przyznający jakiejś osobie lub firmie wyłączne prawo do czerpania korzyści z wynalazku; też: to prawo (s.j.p.)

informacja: to, co powiedziano lub napisano o kimś lub o czymś, także zakomunikowanie czegoś (s.j.p.)

utwór: 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 (Ustawa)

Dla zapewnienia i sprawdzenia jednoznaczności tego tekstu zbudujmy model pojęciowy (taksonomia i syntaktyka pojęć, przypominam, że nie korzystamy w takich analizach a ontologii, poniższy diagram to nie ontologia):

Warto tu zwrócić uwagę na to, że pojęcie opis patentu pojawia się w taksonomii indywidualizmu treści jak i jej dostępności. Innymi słowy opis patentu jest zarówno utworem jak i treścią nie będącą tajemnicą.
I teraz pytanie: co należy chronić i dlaczego? To zależy…

Patent to monopol, jednak fakty pokazują, że monopole trzeba samemu egzekwować, co nie zawsze jest ekonomicznie uzasadnione, przy założeniu że koszty ochrony patentu nie powinny przekroczyć korzyści z jego posiadania.  I nie mam tu na myśli tylko opłat dla Urzędu patentowego, a potencjalne stałe koszty ochrony z tytułu wytaczanych pozwów cywilnych za łamanie praw patentowych. Rynek pokazuje, że nie raz ochronę patentową można zastąpić ochroną z tytułu praw autorskich (treść opisu jakiegoś rozwiązania to utwór, patrz diagram powyżej) np. wzory przemysłowe, tym bardziej że są rzeczy których nie można opatentować, ale można opisać i chronić właśnie jako utwór (np. logikę oprogramowania).

Know-how

Know-how to kolejny ciekawy obszar, bo wymagający bardzo często ochrony. Patent z zasady jest treścią jawną, podawaną do publicznej wiadomości. Jeżeli ktoś uzna, że jego know-how stanowi o jego przewadze a nie chce czynić z niego patentu, to ma dwa wyjścia: (1) utrzymywać know-how na poziomie trudnym do naśladowania, to się nazywa utrzymywanie bariery wejścia (patrz analiza pięciu sił Portera), albo (2) utrzymywać know-how w tajemnicy przed konkurencją. To kluczowy prawdziwy powód podpisywania umów o zachowaniu poufności (drugi to prawo regulujące dostęp do informacji w spółkach giełdowych).

I teraz jeszcze raz cytowana na początku zasada:

Projekt systemu nie powinien wymagać jego tajności, a ewentualne jego ujawnienie nie powinno przysparzać kłopotów.

I to jest ideał (idealizacja) do prowadzenia analiz. Punktem wyjścia w projekcie powinna być analiza sprawdzająca czy faktycznie ujawnienie danej informacji przynosi szkodę a jeżeli tak, to dlaczego. Dalej: jeżeli know-how stanowi sobą określony mechanizm i jego ujawnienie przynosi szkodę, to faktycznie należy go – jego opis – chronić. Jak? Przede wszystkim taki, precyzyjny, opis musi w ogóle powstać. Jeżeli z jakiegoś powodu nie może być przedmiotem patentu, to pozostaje prawo autorskie. A skoro tak, to: (1) posiadaczem prawa majątkowego do opisu know-how powinien być ten, kto chroni swoje know-how, (2) jeżeli oprogramowanie ma realizować mechanizm stanowiący know-how, to dostawca (wykonawca) tego oprogramowania nie powinien mieć żadnych praw do tego know-how, o ile tylko faktycznie stanowi ono o przewadze na rynku.

Ideał jest taki jak zasada powyżej, wniosek zaś jest taki, że jeżeli o przewadze rynkowej stanowi tajemnica, jej bezpieczeństwo staje się kluczowe. A jak chronić tajemnicę czyli informacje? W ten sam sposób: system opisujący bezpieczeństwo informacji opisuje się procedurami i procesami :), a te właśnie (dokumenty opisujące procesy), zgodnie z zasadą opisaną na początku, nie powinny wymagać ochrony…

Warto na koniec dodać, że na gruncie ustawy o zwalczaniu nieuczciwej konkurencji know-how nabywane przez pracowników IT podlega obowiązkowi ochrony tajemnicy przedsiębiorstwa, który od dnia 4 września 2018 r. został określony jako bezterminowy…

Na zakończenie

Bardzo często jestem pytany o różnicę pomiędzy chronionym utworem a chronionym know-how. Popatrzmy na poniższą mapkę, znaną z książki (i gier) Wyspa Skarbów:

Otóż mapka ta jest chroniona prawem autorskim jako obraz graficzny. Jeżeli prawdą zaś jest, że treść mapki zawiera wiedzę o tym jak dotrzeć do skarbu,  to wiedza ta stanowi know-how piratów i jest trzymana w tajemnicy. Tak więc mapka ta jest utworem niosącym wiedzę o know-how. :). Wystarczająco precyzyjny projekt architektury i logiki działania oprogramowania jest także utworem, niosącym wiedzę o know-how.

A teraz popatrzcie Państwo na swoje umowy z dostawcami oprogramowania… i miejcie ograniczone zaufanie do prawników firm dostawców oprogramowania 🙂 

Dodatek: bezpieczeństwo systemowe znane także jako bezpieczeństwo proceduralne

Klasycznym jego przykładem jest uwierzytelnienie dwuskładnikowe (2FA) czy potwierdzanie double opt-in (model procesu poniżej).

Nawiązując do Zasady Kerckhoffs’a, bezpieczeństwo (metody i narzędzia) nie powinny być tajne (bezpieczeństwo przez zaciemnienie), gdyż wtedy “jedno ujawnienie” niszczy to bezpieczeństwo. Zarówno procedury 2FA jak i opt-in (to tylko dwa z wielu przykładów) nie są tajemnicą, a mimo to nikt nie powie, że ich stosowanie jest niebezpieczne.

Testowanie bezpieczeństwa informacji powinno się odbywać na poziomie procesów biznesowych i procedur. Jeżeli tu istnieją “luki” to żadna technologia szyfrowania i systemy haseł niczego nie zmienia na lepsze ale niewątpliwie podniosą koszty.

Pojęcie nadzoru autorskiego budzi wiele emocji, w branży IT jest to chyba temat tabu, głównie z powodu nadużyć twórców i dostawców oprogramowania, a także dlatego, że tu (branża IT) prawo nie zabrania pełnienia przez jeden podmiot roli projektanta i wykonawcy.

Z danych Panorama Consulting wynika, że zaledwie 12% przedsiębiorstw nie wprowadza żadnych modyfikacji systemu ERP jednak 70% firm wprowadza modyfikacje w aplikacji sięgające 25% (źr. 2017-ERP-Report):

Na budowie

Autor pewnego bloga prawnego poruszył ciekawy problem, który występuje także w projektach IT. Tu niezbyt często (a szkoda) ale występuje prawie zawsze w moich projektach, bo ja akurat realizuje projekty, w których jestem zewnętrznym projektantem. Inwestorzy to moi klienci, developer realizuje mój projekt.

Warto tu zwrócić uwagę na to, że projekty programistyczne są w prawie (prawo autorskie i ochrona know-how) pełną analogią projektów budowlanych, i przepisy te stosuje się odpowiednio. Więcej napisałem o tym w artykule o ochronie know-how.

Problem, o którym pisze autor jest zarządzanie zmianą (w IT mówimy o kastomizacji systemów np. ERP):

Wybudowanie obiektu to złożony i długotrwały proces. Od projektu do obiektu upływa dużo czasu, a inwestor często zmienia zdanie co do ostatecznego kształtu powstającego budynku. Czy inwestor może żądać wprowadzenia wszelkich zmian, wedle własnego uznania? Czy może zlecić dokonanie zmian innemu projektantowi? Czy twórca może się zmianom sprzeciwić? Jak wygląda ta sprawa na gruncie prawa autorskiego? Wcześniej pisałem o zmianach na etapie projektowania, dziś o zmianach na etapie budowania.

Projekt z dziedziny inżynierii oprogramowania, prowadzony zgodnie z najlepszymi praktykami, ma etap analizy problemu, projektowania architektury rozwiązania oraz tworzenia (dostarczenia i dostosowania) samego rozwiązania, które realizuje wybrany wykonawca. Tu także ma miejsce nadzór autora projektu nad jego realizacją (wytwarzaniem, dostosowaniem aplikacji).

To czego faktycznie inwestor może się obawiać, a z czego niestety nagminnie korzystają twórcy oprogramowania, to nadużywanie pozycji monopolu autorskiego:

[…] Warto zasygnalizować jeszcze jeden aspekt związany ze źródłem potencjalnego konfliktu między projektantem, a inwestorem. Mianowicie zdarzają się w praktyce sytuacje, gdy architekci uzależniają wprowadzenie zmiany do projektu zgodnie z zamysłem inwestora od ustanowienia dodatkowego wynagrodzenia. W takim przypadku, projektant powołuje się na swoje autorskie prawa osobiste, które zakazują osobą trzecim zmieniać jego utwór, chcąc uzyskać dodatkową korzyść majątkową. Inwestor w takich sytuacjach często byłby zupełnie pozbawiony ochrony. W literaturze pojawiły się sugestie, mimo licznych wątpliwości, żeby w takich przypadkach powoływać się na art. 5 kc, zarzucając projektantom nadużycie swoich praw. (Źródło: Prawa autorskie w ARCHITEKTURZE – Potencjalny konflikt inwestora z projektantem na tle prawa autorskiego – część 2 | IPblog – o prawie własności intelektualnej i nowych technologii)

Oprogramowanie

W branży inżynierii oprogramowania dość powszechna jest sytuacja, gdy programista jest także projektantem, innymi słowy programista ma pełnię praw autorskich do kodu jaki tworzy a jego klient żadnych mimo, że jest inwestorem! Poniżej przykład zapisu w umowie, którą niedawno audytowałem:

Wykonawca nie przenosi na Zamawiającego jakichkolwiek autorskich praw majątkowych do Oprogramowania (co dotyczy także wszystkich adaptacji, modyfikacji i kopii Oprogramowania oraz jego Dokumentacji).

Ten zapis oznacza, że dostawca oprogramowania, np. opracował (udokumentował) jakiś mechanizm działania swojego klienta (na podstawie wywiadów z nim) i zaimplementował go w wytwarzanym (rozwijanym, kastomizowanym) oprogramowaniu, jednak staje się także posiadaczem praw autorskich osobistych i majątkowych do tak opracowanej logiki biznesowej, którą potem sprzedaje (a konkretnie tylko licencjonuje) swojemu sponsorowi (i innym swoim klientom, nie raz także konkurentom sponsora). Ta logika bardzo często stanowi know-how sponsora projektu!

Zapis w innej audytowanej umowie dotyczący prac kastomizacyjnych w systemie ERP, dokonywanych przez firmę wdrażająca a nie przez producenta producenta:

W przypadku wykonania modyfikacji i dostosowania oprogramowania do potrzeb Zamawiającego, Wykonawca z dniem zapłaty wynagrodzenia za Usługi dodatkowe obejmujące ww. modyfikacje, udziela Zamawiającemu licencji na korzystanie z tych modyfikacji przez Zamawiającego, na warunkach na jakich udzielono uprzednio licencji na korzystanie z Oprogramowania. Wynagrodzenie za wykonanie przedmiotowych modyfikacji wskazanych powyżej wydzielonych części oprogramowania, obejmuje wynagrodzenie z tytułu udzielenia licencji.

To już jest kuriozum, znane z anegdot w rodzaju: “konsultant, by odpowiedzieć na pytanie Która jest teraz godzina, prosi Klienta o jego zegarek, odpowiada na pytanie, a zabrany Klientowi zegarek wypożycza mu za sowitym wynagrodzeniem”.

Ta wadliwa sytuacja, jaką tu opisałem, to np. cecha wszystkich projektów agile i tych gdzie programista jest także analitykiem i projektantem (jeżeli taki etap jest w projekcie). W efekcie projektant/wykonawca bardzo często wykorzystuje swoją pozycję podwójnie: nie wprowadza zmian dla siebie niekorzystnych (np. trudna i kosztowna realizacja) i narzuca zmiany poprawiające marże na realizowanym projekcie (upraszczanie), z czego sponsor z reguły nie zdaje sobie sprawy.  Trzecim “narzędziem” budowy marży jest godzenie się na wszelkie propozycje inwestora mając kontrakt T&M, bez ostrzegania go o konsekwencjach wprowadzanych zmian dla całego projektu (a jest nią z reguły dodatkowa pracochłonność).

Bardzo wiele  projektów programistycznych kończy się nie dlatego, że uzyskano oczekiwaną funkcjonalność a dlatego, że wyczerpano 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 umowie należy zaznaczyć, że wszelkie prace programistyczne poprzedzane są udokumentowaną analizą i projektowaniem, i że prawa majątkowe do treści tych dokumentów przechodzą na Zamawiającego. Taka sytuacja nadal jest jednak niezdrowa, bo nadal wykonawca łączy rolę projektanta i developera (czego np. prawo budowlane zabrania z uwagi na powstałą tak uprzywilejowaną pozycję developera).

Ideałem, który można łatwo osiągnąć, jest całkowite oddzielenie analizy i projektowania od realizacji (dla projektów IT zaleca to UZP w dokumencie z 2009 roku). W razie braku takich kompetencji po stronie Zamawiającego, wystarczy zatrudnić projektanta. Po prawej stronie powyżej, ilustracja z 1985 roku: MODEL to owa precyzyjna dokumentacja (to znaczy musi być precyzyjna, by można ją było uznać za projekt – utwór – chroniony prawem).

Model oprogramowania (źr. Large Scale Software Architecture, A practical Guide Using UML)

Co ciekawe, można to zrobić w dowolnej chwili nawet po podpisaniu niekorzystnej umowy (zawierającej zapisy jak te omówione powyżej). W takiej sytuacji, wykonawca, realizując projekt, otrzymuje od Zamawiającego, nie ustne czy nawet pisemne, ogólne idee swoich potrzeb, a dokumenty zawierające dokładne opracowanie projektu implementacji (logika biznesowa i architektura), którą Wykonawca ma zgodnie z umową zrealizować. Warunkiem powodzenia jest to, by autorskie prawa majątkowe do tych dokumentów były przy Zamawiającym (projektant powinien przekazać prawa majątkowe do projektu w pisemnie zawartej umowie). W takiej sytuacji Wykonawca wykonuje prawa zależne do utworu i mimo, że jest autorem implementacji, nie ma żadnych praw do dysponowania nią.

Autor cytowanego artykułu powołuje się pod jego koniec na ważny, i często zapominany paragraf Kodeksu Cywilnego:

Art. 5. Nie można czynić ze swego prawa użytku, który by był sprzeczny ze społeczno-gospodarczym przeznaczeniem tego prawa lub z zasadami współżycia społecznego. Takie działanie lub zaniechanie uprawnionego nie jest uważane za wykonywanie prawa i nie korzysta z ochrony.  (KC)

I tym akcentem, zakończę ten krótki wpis 🙂  i polecam też lekturę całego cytowanego artykułu.

Wstęp

W lutym 2017 r. opisywałem prawne aspekty pojęcia “przedmiot zamówienia” w sferze inżynierii oprogramowania. Niedawno ukazał się w prasie artykuł o domniemanym planowaniu wywłaszczenia programistów:

Sejm jest o włos od zniesienia mechanizmu ochrony autorskiej twórców aplikacji. Na razie tych, którzy informatyzowali sądy, prokuratury i komorników. ¹

Wywołał on sporą burzę w branży IT, niestety większość publikowanych w mediach wypowiedzi jest bardzo powierzchowna a niestety bardzo często wręcz fałszywa. Do tego nakładają się wypowiedzi lobbystów z branży IT, niejednokrotnie przemilczające pewne fakty a nie raz stawiające wręcz nieprawdziwe tezy. Otóż, o czym nie raz pisałem, stale …

W przestrzeni publicznej toczą się spory co do tego ?czym jest oprogramowanie?, jednak moim zdaniem, większość tych sporów ma swoje źródła w niezrozumieniu specyfiki technologii informatycznych i samego prawa, część jest skutkiem celowego lub nie, mataczenia w samych umowach. Ustawodawca, moim zdaniem bardzo słusznie, zakwalifikował oprogramowanie do utworów literackich, gdyż w swej istocie jest ono zawsze zapisem analogicznym do tekstu. Osobną kwestią jest treść tkwiąca w takim utworze (o czym on jest), co podobnie jak w przypadku literackich tekstów, może mieć ale nie musi, znaczenie. Tekst Kodu programu zinterpretowana przez odpowiednią maszynę, potocznie zwaną komputerem, decyduje o tym ?czym dany komputer jest?. Raz jest programatorem pralki a raz edytorem tekstu czy grą interaktywną. Oprogramowanie często cechuje się określonym ?mechanizmem działania?.  W literaturze z obszaru technik komputerowych i filozofii, bardzo często można spotkać teorię mówiącą, że ?komputer to uniwersalny mechanizm?. Innymi słowy komputer może być ?czymkolwiek?, decyduje o tym  ?program komputerowy?. ²

Jeżeli nałożymy na to fakt, że zamawiający w większości nie znają i nie rozumieją prawnych aspektów ochrony wartości intelektualnych, to mamy do czynienia z obecnym ogromnym bałaganem, nie tylko w administracji publicznej, ale i z tym jakie i kto ma prawa do wykorzystywanego oprogramowania. Niestety przewaga merytoryczna jaką ma branża IT nad swoimi klientami pozwala na wiele nadużyć, szczególnie w sferze zawłaszczania know-how przez twórców oprogramowania.

Wartości intelektualne w umowach

Dzisiaj  opiszę kwestie prawno-autorskie właśnie z perspektywy wartości intelektualnych w umowach. Kluczem jest uporządkowanie pojęć wykorzystywanych w umowach i ustawach.

Poniższy diagram to model pojęciowy wykonany w notacji SBVR (diagram faktów) ³:

Opiszę treść diagramu. Poszczególne pojęcia zostały zobrazowane jako prostokąty. Linie między nimi to fakty łączące je parami w określony kontekst. Strzałki łączą pojęcia ogólne z ich szczególnymi typami. Kluczowe pojęcia: utwór, know-how oraz pole eksploatacji, zostały opisane cytatami z aktów prawnych. Zestaw powiązanych kontekstem pojęć nazywamy przestrzenią pojęciową.

Treść to zawartość wypowiedzi lub dokumentu ⁴. Zawartością może być (treść niesie) ta zwane know-how. Jeżeli treść ma indywidualny charakter, jest utworem. Zgodnie z prawem jest nim każda treść o indywidualnym charakterze, w szczególności  specyfikacja (projekt techniczny) i kod programu komputerowego. Oba są utworami w rozumieniu prawa. Użytkownika korzysta z aplikacji (jest ona oprogramowaniem), ta może być wyrażona z pomocą symboli, wzorów i schematów blokowych lub/i w postaci kodu programu. Należy pamiętać, co bardzo ważne w branży inżynierskiej, że …

Program komputerowy napisany na podstawie opracowanego wcześniej projektu (podobnie jak każde inne rozwiązanie lub produkt) stanowi utwór zależny (jest to realizacja projektu). Utworem pierwotnym dla oprogramowania jest tu projekt tego oprogramowania (jeżeli powstał), w tym jego unikalna architektura. Oprogramowanie powstałe na podstawie projektu innego autora, powinno zostać oznaczone danymi autora tego projektu ⁵

Tak więc, jeżeli kod powstał na podstawie specyfikacji, jest utworem (dziełem) zależnym, jeżeli nie, jest samodzielnym utworem. Wśród wielu pól eksploatacji utworu są wydruki i uruchamianie w pamięci komputera.

Wnioski dla nabywców oprogramowania

Przede wszystkim należy podjąć decyzję o tym co licencjonujemy, do czego nabywamy prawa majątkowe i na jakich polach eksploatacji. Tak zwane oprogramowanie standardowe to produkty rynkowe sprzedawane do wielu podmiotów, tu możemy liczyć na określoną formę licencji. Jak użytkownik  najczęściej na uruchamianie w pamięci komputera, ale nie na dystrybucję. Taki zakup jest relatywnie prosty a umowy licencyjne są standardowe dla danego producenta i produktu.

Problemem jest zlecenie wykonania dedykowanego dla nas oprogramowania. Kod programu jest utworem, utwór jako treść niesie (zakładamy, że tak jest) know-how firmy zlecające wykonanie dla siebie dedykowanego oprogramowania (specyfika logiki biznesowej, mechanizmy działania różnych funkcji itp.). Na pytanie czy wykonawca musi nam przekazać w umowie praw majątkowe? Może ale nie musi (wtedy sugeruję nie zawieranie umowy i szukanie innego wykonawcy). Jednak jeżeli zamawiający najpierw opracuje specyfikację (to także utwór, zawiera dokładny opis wykonania oprogramowania) i uczyni z niej element umowy na wykonanie dla niego oprogramowania, wykonawca nie ma żadnych praw (o ile mu ich nie przekażemy) do dysponowania tak wytworzonym oprogramowaniem.

W projektach dużych, kluczową częścią powinien być projekt architektury, uwzględniający prawa do poszczególnych komponentów oraz separowanie komponentów standardowych od tych zawierających nasze know-how. To dlatego najwięcej szkód przynosi kupującym oprogramowanie tak często oferowana przez dostawców kastomizacja… czyli wbudowywanie logiki biznesowej kupującego we własny już kod, tu ma miejsce całkowite przejęcie know-how przez dostawce oprogramowania.

Nie będę opisywał detali takich umów (a są one istotne), gdyż celem moim było opisanie mechanizmów prawnych ich konstruowania i mechanizmów ochrony. Chciałem tu przede wszystkim wskazać  mechanizm nadużyć polegający na tym, że: dostawca oprogramowania oferuje (forsuje) pracę bez uprzedniego specyfikowania aplikacji (tak zwane zwinne projekty agile) lub oferuje samodzielne wykonanie takiej specyfikacji (pod nazwą analiza wymagań, analiza przed-wdrożeniowa itp.). W obu przypadkach pełnię praw autorskich (osobiste i majątkowe) pozostają przy twórcy kodu. Pozycja negocjacyjna nabywcy jest tu bardzo słaba. Dzięki temu mechanizmowi bardzo wiele form produkujących oprogramowanie wymusza na administracji publicznej zakupy z wolnej ręki, podobnie zresztą w firmach prywatnych: monopolizują prawa do oprogramowania i praktycznie całkowicie blokują konkurencję a użytkownika skazują na siebie jako dostawce usług utrzymania i rozwoju.

Dlatego niezależnie od tego co sądzimy o metodach zwinnych, warto zadbać o swoje know-how i dokumentować je. Nie warto także zlecać prac analityczno-projektowych producentom oprogramowania.

Wspomniane na początku “wywłaszczanie” programistów ma zaradzić takim nadużyciom na przyszłość. Osobną jednak kwestią, nie na ten artykuł, jest sposób przeprowadzenia tego.

___

2017-08-07 Temat stał się na tyle gorący, że Pani red. Sylwia Czubkowska w Gazecie Prawnej kontynuowała temat w rozmowie ze mną:

? Doradzałbym szklankę zimnej wody. Owszem, ten przepis jest źle napisany, ale nie jest wcale bezpodstawny. To, że w tym wypadku resort sprawiedliwości, a za chwilę może po prostu rząd, myśli o tym, by ustawowo nakazać przekazanie kodów źródłowych, z których korzysta administracja, nie jest wcale nieuzasadnione ? ocenia Jarosław Żeliński, założyciel i główny analityk firmy IT-Consulting, zajmującej się doradztwem przy inwestycjach w nowe technologie. ? Ustawowe wywłaszczenie to metoda skrajna, ale niestety może okazać się czasami niezbędne. Przecież państwo, czyli jego instytucje, za te programy firmom zapłaciło, a w niejednym przypadku wcale nie dostało pełnowartościowego produktu. Często z własnej winy, bo nie dopilnowało od razu, by zabezpieczyć swoje prawa także do kodów. A bez nich niestety produkt jest niepełnowartościowy. Czasem jednak taka konstrukcja umów to polityka firm, które kodów nie chcą przekazywać ? tłumaczy ekspert. A nie chcą, bo dzięki temu instytucja publiczna ? nie mając kodów ? jest zmuszona, by kolejne zlecenia dawać ich właścicielowi. (⁶)

Wprowadzenie

Niedawno blady strach padł na użytkowników oprogramowanie SAP AG za sprawą pewnego procesu i wyroku: 

Po niedawnym orzeczeniu brytyjskiego Sądu Najwyższego, który potwierdził prawo firmy SAP do naliczania opłat za pośrednie korzystanie z systemów SAP przy użyciu takich aplikacji innych firm jak Salesforce, WorkDay i QlikView, korzystanie pośrednie jest obecnie wymieniane przez klientów firmy SAP jako główna obawa w obszarze zarządzania licencjami SAP i kontrolowania ich kosztów. […] W ostatnich tygodniach ryzyko związane z korzystaniem pośrednim ? dotychczas głównie teoretyczne ? stało się rzeczywistością, która może zmusić wiele przedsiębiorstw do poniesienia milionowych niezabudżetowanych kosztów dodatkowych licencji SAP. (Źródło: Korzystanie pośrednie główną obawą klientów SAP – ERP-view.pl) 

Cóż to jest to “korzystanie pośrednie” i w czym problem? 

In this instance, the third party systems are accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a ?user? must be set up to gain access to the SAP system. On the surface then it can appear like only one user (or a small number of users) is performing actions on the SAP system. In reality though, the ?user? will be performing far more tasks than is possible for a single person to undertake. (Źródło: SAP Audits ? Is it impossible to gauge financial exposure? – IT Asset Knowledgebase) 

O co chodzi?

Generalnie chodzi o to, że integrowane ze sobą aplikacje wymieniają dane i “zlecają sobie” usługi, i tu warto wiedzieć co (dane, logika aplikacyjna) jest chronione prawami autorskimi i co stanowi know how. Problem tkwi w poprawnym zdefiniowaniu przedmiotu (obiektu) przetwarzania, przedmiotu prawa autorskiego i tego co stanowi know-how. 

W tekście Ochrona know-how organizacji analizowanej pisałem dość dokładnie o prawach autorskich i know-how. Tu kilka kluczowych pojęć. 

USTAWA z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych mówi:

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

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.
2. (1) Ochroną objęty może być wyłącznie sposób wyrażenia; nie są objęte ochroną odkrycia, idee, procedury, metody i zasady działania oraz koncepcje matematyczne.

USTAWA z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji, mówi, że:

Art. 11.
4. Przez tajemnicę przedsiębiorstwa rozumie się nieujawnione do wiadomości publicznej informacje techniczne, technologiczne, organizacyjne przedsiębiorstwa lub inne informacje posiadające wartość gospodarczą, co do których przedsiębiorca podjął niezbędne działania w celu zachowania ich poufności.

Tak więc mamy kluczowe pojęcie: utwór oraz know-how. Utworem jest unikalna treść  zaś know-how to nieujawnione i chronione (!) informacje (treści) techniczne, organizacyjne lub gospodarcze.

Czym jest owo “pośrednie korzystanie z systemu SAP”? Drugi tekst wyjaśnia: “accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a ?user? must be set up to gain access to the SAP system“. Czyli “pobieranie i zapisywanie danych”, użytkownik by mógł “tego dokonać” musi mieć dostęp Systemu  SAP.

Jednak sam fakt istnienia dostępu i korzystania z niego, nie oznacza korzystania z cudzych  wartości intelektualnych!

Najpierw model takiego przypadku:

Użytkownik bezpośredni Systemu to “standardowy”, licencjonowany użytkownik. Aplikacja pośrednicząca także korzysta z licencjonowanego dostępu (API). Jak, i z czego (i czy), korzysta Użytkownik pośredni Systemu?

Żeby wskazać to, z czego korzysta zewnętrzny użytkownik (aktor) Systemu, należy “zajrzeć” do wnętrza systemu. Architektura Systemu i integracji ma taką postać:

Na tym diagramie mamy trzy kluczowe elementy (tu artefakty) reprezentujące wartości intelektualne chronione prawem: Logika biznesowa, Zebrane dane i Strukturę danych. Logika biznesowa to sposób (metody) przetwarzania informacji (danych) zawarte w programie komputerowym, stanowią (mogą stanowić) know-how firmy, sam program komputerowy (jego treść) to ustalony utwór. Prawo autorskie chroni bazy danych (zebrane i uporządkowane dane) zaś struktura danych (projekt, model danych) to także utwór chroniony.

Zintegrowana z Systemem aplikacja korzysta z API Systemu. API standardowo pozwala np: na pobranie obiektu, wstawienie obiektu oraz wykonanie operacji z użyciem logiki biznesowej. 

Zasadnicze pytanie brzmi: co w Systemie stanowi produkt “działalności twórczej o indywidualnym charakterze”? Na pewno jest to oprogramowanie jako takie oraz struktura (model) danych oraz baza danych, czyli zebrane dane (z uwagi na ich unikalną strukturę, model, w bazie danych). Jednak program realizuje określoną logikę biznesową (operacje na danych) i przetwarza określone obiekty biznesowe, czyli określone zestawy danych takie jak faktura czy  dokument magazynowy WZ. Ogólnie operacje z użyciem Systemu (aplikacji) mają np. taką postać:

Jest to przykład możliwego dialogu użytkownika (aktor) z aplikacją (System). Dialog taki, niezależnie od stopnia komplikacji, będzie się składał z operacji będących logiką biznesową (czyli specyfiką dziedziny) lub techniczną (specyfiką technologii implementacji). Przedmiotem przetwarzania będą określone obiekty biznesowe (nazwane zestawy danych), komunikat na ekranie także może być takim obiektem (jeżeli tym komunikatem jest treść dokumentu a nie tylko tekst mówiący, że coś zostało wykonane np. bez błędu).

Tu jednak mamy do czynienia z oprogramowaniem wspierającym między innymi operacje opisane w ustawach (księgowe). Niewątpliwie prawo chroni strukturę danych, dane zebrane w bazie danych oraz know-how, to które jest nieznane “innym”. Jednak prawo nie chroni idei, nie chroni też tego co “jest powszechnie znane”. Warto także wiedzieć, że wdrożenie w toku którego miała miejsce tak zwana kastomizacja, “wnosi” know-how przyszłego użytkownika do kodu, i za korzystanie z tej logiki dostawca oprogramowania nie ma prawa brać wynagrodzenia. Pod warunkiem jednak, że kod realizujący to wniesione know-how jest jawnie wydzielony! 

Podsumowanie

Nie ma jednoznacznej odpowiedzi na pytanie czy w danym przypadku ma miejsce korzystanie pośrednie z oprogramowania, niewątpliwie sam fakt integracji nie stanowi korzystania pośredniego. Nie jest tez prawdą, ze sam fakt integracji automatycznie implikuje korzystanie pośrednie wymagające opłaty licencyjnej. Kluczem do stwierdzenia tego jest wiedza o architekturze systemu, o architekturze całości integracji i o tym jakie operacje i gdzie są wykonywane. Na szczęście to dostawca Systemu musi uzasadnić swoje roszczenia dotyczące własności intelektualnej, jednak korzystający z tego Systemu – jeżeli nie potrafi podać kontrargumentów – nie jest w stanie się obronić. Niestety największym problemem jest wdrożenie polegające na kastomizacji, gdyż dochodzi do “wplecenia” nowej logiki biznesowej do już istniejącej w dostarczanym oprogramowaniu.

Skutek jest taki, że dostawca oprogramowania ma podstawy prawne do ochrony kodu jaki dostarczył, jednak kupujący nie ma żadnych podstaw (dokumenty, projekt itp.) by chronić swoje know-how i  by nie płacić za swoje własne know-how “włożone” w toku wdrożenia, do wdrażanego oprogramowania.

Dlatego warto restrykcyjnie prowadzić proces analizy i projektowania, to jest umiejętnie udokumentować projekt tak, by granica pomiędzy wartościami intelektualnymi dostawcy i nabywcy oprogramowania była jasno określona. I nie jest to rola prawnika a architekta całości systemu, który musi także znać i rozumieć prawne aspekty tej architektury. 

Niedawno pisałem (Instrukcja dla prawników…) o tym, że prawnicy to nie inżynierowie. Nie był to przytyk, a zwykłe wskazanie na fakt, że to po prostu  rożne kompetencje. Problem prawa autorskiego w obszarze szeroko pojętej inżynierii jest bardzo trudny, nie jest to “wiedza humanistyczna”. Podejście prawników z reguły jednak bazuje na humanistycznej wiedzy tychże. Poniżej cytat pewnego bloga:

Utwór architektoniczny należy moim zdaniem zakwalifikować (albo traktować analogicznie w tej kwestii) do szeroko rozumianych dzieł plastycznych. Te ostatnie bowiem, w przeciwieństwie np. do utworów muzycznych lub wyrażonych słowem, dużo ściślej związane są z nośnikami na jakich są utrwalone. Utwór muzyczny może powstać, zostać usłyszany przez osoby trzecie w jego dokładnej formie i nie musi zostać utrwalony. Dzieła plastyczne muszą być natomiast urzeczywistnione w postaci obrazu lub rzeźby, aby osoby trzecie mogły się z nimi w ogóle zapoznać. Podobnie jak tradycyjne utwory plastyczne, większość utworów architektonicznych musi zostać urzeczywistniona w postaci co najmniej szkicu, rysunku, projektu, wizualizacji komputerowej, czy w końcu zrealizowanego obiektu, aby móc zaistnieć w świadomości odbiorców. (Źródło: Prawa autorskie w ARCHITEKTURZE – utwór architektoniczny według architekta | IPblog – o prawie własności intelektualnej i nowych technologii). 

Jak widać, teza brzmi: “Utwór architektoniczny należy moim zdaniem zakwalifikować […] do szeroko rozumianych dzieł plastycznych”. Autor uzasadnia to faktem ścisłego związania z nośnikiem. 

Przede wszystkim ustawodawca całkowicie odcina się od kwestii sztuki i “poziomu artyzmu” utworu oraz od nośnika. Ustawa (USTAWA z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych) mówi jasno:

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).
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);
2) plastyczne;
3) fotograficzne;
4) lutnicze;
5) wzornictwa przemysłowego;
6) architektoniczne, architektoniczno-urbanistyczne i urbanistyczne;
7) muzyczne i słowno-muzyczne;
8) sceniczne, sceniczno-muzyczne, choreograficzne i pantomimiczne;
9) audiowizualne (w tym filmowe).
2. Ochroną objęty może być wyłącznie sposób wyrażenia; nie są objęte
ochroną odkrycia, idee, procedury, metody i zasady działania oraz koncepcje
matematyczne.
3. Utwór jest przedmiotem prawa autorskiego od chwili ustalenia, chociażby
miał postać nieukończoną.
4. Ochrona przysługuje twórcy niezależnie od spełnienia jakichkolwiek
formalności.

Tak więc za podstawę przyjmujemy, że utworem 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)“. Jakiekolwiek dywagacje, czy to dzieło muzyczne czy plastyczne, nie mają tu żadnej podstawy. Czym się kierował autor bloga? Nie wiem, przypuszczam, że podobieństwem projektów architektonicznych do “rysunków” plastyków (w końcu rysunek techniczny to także “rysunek”). Uważam, że szukanie jakichkolwiek analogii to błędne podejście, ma na celu chyba wyłącznie próbę zrozumienia inżynierii, ta jednak nijak sie ma do dzieł plastycznych. Owszem, dzieło architekta ma znamiona “dzieła plastycznego” jeśli spojrzeć na nie, jak na wizualizację elewacji lub wnętrz,  jak na “obraz”, jednak wizualizacja nowego modelu samochodu sportowego także “niejednego podnieca”, zaś np. wizualizacja koła zębatego, mimo że raczej nudna, także jest “obrazem”.  Przypomnę, że utwór jest nim niezależnie od jego “wartości”. Warunkiem koniecznym i wystarczającym jest jego “indywidualny [unikalny] charakter”. 

Wprowadzanie pojęcia “zaistnienia utworu w świadomości odbiorców” jest dla mnie zupełnie niejasne, ustawodawca wymaga jedynie faktu jego utrwalenia (ustalenia). Pisanie wierszy do szuflady jest tworzeniem utworów, mimo że one nie “zaistniały w świadomości odbiorców”.

Popatrzmy na ten oto schemat:

Ustawa mówi: “nie są objęte ochroną odkrycia, idee, procedury, metody i zasady działania oraz koncepcje matematyczne”, jednak “Utwór jest przedmiotem prawa autorskiego od chwili ustalenia, chociażby
miał postać nieukończoną.”.  Indywidualny charakter wiąże się z pojęciem unikalności. Zarówno w filozofii, w logice jak i w matematyce funkcjonuje pojęcie prawdopodobieństwa; także w naukach przyrodniczych. Konkretnie chodzi tu o powtarzalność lub przeciwieństwo czyli niepowtarzalność. W nauce teoria jest uznawana za prawdziwą, jeżeli doświadczenia na jej podstawie wykazują powtarzalność efektu. Pojęcie niepowtarzalny oznacza, że prawdopodobieństwo ponownego (przypadkowego) “zaistnienia” jest “małe” (czyli bliskie zeru). Tak więc idee nie są utworami, gdyż ich ogólny charakter czyni je powtarzalnymi (wielu ludzi może wpaść na pomysł by zbudować “ładny i przestronny dom”). Dopiero Projekt konstrukcyjny ma cechy unikalności (indywidualny charakter) z racji swej precyzji opracowania, ta powoduje przypadkowe powtórne jego powstanie JEST “praktycznie”  nie możliwe (na diagramie użyto pojęć z obszaru szeroko pojętej inżynierii a nie tylko tej “budowlanej”).

Powyższy schemat pokazuje proces inżynierski od sprecyzowania Problemu (celu inwestycji) do powstania Konstrukcji inżynierskiej. Zgodnie z powyższym, pierwsze dwa etapy (Problem oraz Koncepcja konstrukcji) nie podlegają ochronie, są ideą. Pierwszym elementem stanowiącym utwór w rozumieniu Ustawy jest Projekt konstrukcji. Na jego podstawie “wykonawca” tworzy Projekt techniczny, a następnie jego realizację czyli namacalną Konstrukcję inżynierską. Utworem jest Projekt konstrukcji, jego autorem jest Projektant. Realizator tworzy utwór zależny, jakim jest Projekt techniczny (z reguły wymaga akceptacji Projektanta, tu ma miejsce np. wybór technologii itp.), a następnie realizuje inwestycję czyli powstaje Konstrukcja inżynierska. Projekt techniczny (zwany także wykonawczym, koncepcją wdrożenia) jest dziełem zależnym Projektu konstrukcji (więcej o mechanizmie prawnej ochrony projektów i know-how). 

Autor pisze, że “Przeważa pogląd, słuszny z resztą,  iż z utworem architektonicznym możemy mieć do czynienia zarówno w postaci projektu jak i wybudowanego obiektu.” Miało by to miejsce (ten drugi wariant), pod warunkiem niezaistnienia “po drodze” Projektu tego obiektu, czyli pierwszą formą utrwalenia (ustalenia) był by obiekt (Konstrukcja inżynierska).  Można tu sobie wyobrazić wybudowanie obiektu “z głowy”… 

Know-how, to ważne pojęcie. Czym ono jest w projektach inżynierskich? Wiedzą jak zostały stworzone? Owszem, projektant ma pewne know-how, zna wzorce projektowe, prawa fizyki i wiele innych, jednak nie o takie know-how tu chodzi. Słownik mówi:

know-how [wym. no-ha] ?praktyczna umiejętność lub wiedza w zakresie technologii produkcji lub technik zarządzania? 

Kluczowe jest tu słowo “lub”: jest to albo wiedza albo umiejętność. Projektant ma “umiejętność” projektowania, jednak projekt jako dokumentacja niesie także określoną wiedzę. Otóż projekt (konstrukcja inżynierska) może zawierać wiedzę stanowiąca tajemnicę przedsiębiorstwa (czyli właśnie know-how), która stanowi o przewadze konkurencyjnej, pozwala coś osiągnąć lub zdobyć.  Projekt budynku (dokumentacja) to utwór w rozumieniu prawa autorskiego. Jeżeli jednak będzie to projekt budynku będącego labiryntem prowadzącym do skarbca, to dokumentacja taka (plan korytarzy) jest także (strzeżonym) know-how. To drugi, po dokumentacji projektowej, chroniony prawem aspekt utworu, o którym wielu zapomina albo nie potrafi go chronić. Więcej o tym napisałem w artykule Ochrona know-how organizacji analizowanej. 

Autor tego artykułu, w innym swoim tekście, porusza także kwestię relacji projektant vs. inwestor vs. wykonawca.

Funkcja, zakres
Kiedy zastrzeżenia inwestora dotykają kwestii ekonomicznych, czy wcześniej ustalonych warunków, które obiekt ma spełniać, a nie ich spełnia, czy też zakresu prac zleconych, spór opiera się o prawo cywilne i zobowiązania umowne. Żeby uniknąć pierwszej sytuacji, umowa o prace projektowe powinna określać możliwie dużo informacji na temat mającego powstać obiektu, w zakresie jego funkcji, powierzchni, ceny jego wybudowania itp. Odpowiednie określenie tych kwestii wytrąci potencjalny argument inwestora, że obiekt miał być inny, a architekta, że umowa nie określała, jaki miał dokładnie być.Podobnie z zakresem prac, należy go bardzo precyzyjnie określić i zawrzeć ewentualną klauzulę dotycząca potencjalnych prac dodatkowych.      
Forma, estetyka
Natomiast gdy, gdy zastrzeżenia inwestora dotyczą estetycznej warstwy projektu spór opiera się właśnie o prawa autorskie.  Żeby uniknąć tego rodzaju sporu same postanowienia wciągnięte do umowy mogą nie wystarczyć. Na marginesie dodam, że w praktyce bardzo rzadko w umowach porusza się tą problematykę. Spór może zostać rozwiązany i strony dojdą do porozumienia, albo zakończą współprace, co czyni sprawę jeszcze ciekawszą z punktu widzenia prawa autorskiego, o czym w następnej części tego wpisu niebawem. (Źródło: Prawa autorskie w ARCHITEKTURZE – Umowa o prace projektowe, a potencjalny konflikt | IPblog – o prawie własności intelektualnej i nowych technologii)

Patrząc na powyższy schemat kolejności powstawania dokumentów, z których tylko ostatnie dwa są utworami, sprawa staje się jasna:

1. Funkcjonalność konstrukcji inżynierskiej to cechy, ktore inwestor może “opisać” , są one ideą tworzenia tej konstrukcji. 
2. Twórca Projektu konstrukcji opracowuje utwór stanowiący opis “unikalnego rozwiązania problemu inwestora”.
3. Wyłoniony wykonawca opracowuje szczegóły (rozwiązuje problemy) techniczne (np. określa materiały konstrukcyjne ścian działowych ale ma już prawa ingerencji w rozkład pomieszczeń) i realizuje inwestycję czyli buduje Konstrukcję inżynierką.  

Co tu może inwestor? Jeżeli nie będzie dodatkowych zapisów w umowie, w zasadzie nic. Autorskie prawa osobiste chronią autora i jego dzieło, zmuszają inwestora (także wykonawcę) do konsultowania z autorem każdej zmiany. Nadzór autorski to nie tylko pilnowanie by “obiekt” wyglądał tak jak chciał tego jego projektant. Nadzór autorski to także odpowiedzialność za efekt i skutki realizacji projektu oraz zarządzanie zmianą tego projektu (dokumentacji), którego projektant jest autorem. Zmiana położenia ścian działowych wewnątrz budynku także wymaga zgody autora. Ani inwestor, ani wykonawca, nie mają żadnych praw do samodzielnych ingerencji w projekt jakim jest utwór autora Projektu konstrukcji. Wykonawca z inwestorem może ustalać tylko to, co nie koliduje z projektem pierwotnym (Projekt konstrukcji). Jeżeli ktokolwiek z nich uzna, że projekt jest wadliwy, musi to zgłosić jego autorowi:

Precyzując odpowiedzialność tych dwóch podmiotów trzeba stwierdzić, że odpowiadają oni za: wady prowadzonej dokumentacji przed, w trakcie i po prowadzeniu inwestycji, wady w projekcie przed, w trakcie  i po prowadzeniu inwestycji. Niestety w takim procesie trzeba udowadniać, że wykonawca dokonał wszelkich działań, które miały na celu poinformowanie projektanta czy inwestora o tym, że istnieją wady w projekcie. Proces w takiej sprawie ma charakter typowo dowodowy. (Źródło: Projektant czy wykonawca ? komu należy przypisać odpowiedzialność w przypadku wadliwego wykonania dzieła?) 

Dokładnie takie problemy (i rozstrzygnięcia) mają miejsce w przypadku oprogramowanie (jest orzecznictwo na poziomie UE), to jest: Projekt  jest utworem a powstała na jego podstawie Konstrukcja wraz z ewentualnym opracowaniem tej konstrukcji, to utwory będące dziełami zależnymi. Mechanizm działania oprogramowania to know-how inwestora. Niewątpliwie ekipa budowlana stawiająca dom (obiekt) na podstawie projektu architektonicznego, nie nabywa do niego (projektu) żadnym praw, nie może bez zgodny autora projektu stawiać kolejnych takich samych domów. W przypadku inżynierii oprogramowania analogicznie… Programista nie nabywa żadnych praw do programu, który napisał na podstawie cudzego projektu. Ten ostatni musi być oczywiście także odpowiednio precyzyjny. Jeżeli nawet programista uzna, że projekt ma wady, nie wolno mu samemu zmieniać projektu bez zgody autora (projetanta).