Zaloguj się Dla niezalogowanych – pokazuję tylko 1 sygnaturę (nie licząć dokumentów premium).
Zamów dostęp aby widzieć wszystkie sygnatury i przeglądać bez ograniczeń.

Przejdź do II-TOM-REKOMENDACJI-PREZESA-UZP-ZAMoWIENIA-PUBLICZNE-NA-SYSTEMY-INFORMATYCZNE.pdf 248 fragmentów

2022-03-09 » Wzorcowe dokumenty / Wzorcowe dokumenty dot. ustawy Pzp z 2019 r.

na tyle twórczy, że przesądzi to o powstaniu programu, który może być przedmiotem samodzielnej ochrony, w grę wchodzić będzie również regulacja dotycząca utworów zależnych (czyli tłumaczeń, przeróbek, adaptacji utworów) z art. 2 pr. aut. Zgodnie z art. 2 pr. aut. dla samego tworzenia utworów zależnych w stosunku do utworu pierwotnego nie jest konieczna zgoda właściciela praw autorskich do utworu pierwotnego, natomiast zgody takiej wymaga korzystanie z powstałych utworów zależnych oraz rozporządzanie nimi. W przypadku szczególnej kategorii utworów, jakimi są programy komputerowe, wspomniany art. 74 ust. 4 pkt 2 pr. aut. przesądza, że już samo dokonanie zmiany w oprogramowaniu będzie wymagać zgody twórcy. Dlatego też, nie tylko korzystanie z utworów zależnych, ale już ich wytwarzanie, które nierozerwalnie wiąże się z modyfikacją oprogramowania będzie wymagać zgody właściciela praw autorskich do pierwotnego programu komputerowego. W odniesieniu natomiast do wykonywania praw zależnych, w art. 46 pr. aut. wprowadzono domniemanie, zgodnie z którym "jeżeli umowa nie stanowi inaczej, twórca zachowuje wyłączne prawo zezwalania na wykonywanie zależnego prawa autorskiego, mimo że w umowie postanowiono o przeniesieniu całości autorskich praw majątkowych". Z przepisu art. 46 pr. aut. wynika wprost, że w razie braku wskazania w umowie przeniesienia majątkowego prawa lub udzielenia licencji na zezwalanie na wykonywanie zależnego prawa autorskiego, zamawiający nie może korzystać z opracowań utworu, czyli dla przykładu: twórczej modyfikacji, tłumaczenia ...

zamówienia obejmuje budowę rozwiązania od podstaw, poprzez wytworzenie nowego oprogramowania, specyficznego dla danego zamawiającego, to w pełni uzasadnione może być oczekiwanie zamawiającego, aby zamawiający nabył w jak najszerszym zakresie prawa autorskie do stworzonego dla niego produktu. Jeżeli natomiast przedmiotem zamówienia co do zasady ma być oprogramowanie standardowe, które będzie w toku wdrożenia podlegało wyłącznie odpowiedniej konfiguracji, to oczekiwanie przez zamawiającego przeniesienia na niego majątkowych praw autorskich do takiego systemu może być uznane za nieuzasadnione - jako nieadekwatne i w niezasadny sposób ograniczające konkurencję. W przypadku, gdy przedmiotem zamówienia jest świadczenie usług w modelu SaaS, PaaS lub IaaS, kwestią dyskusyjną (i zależną od stanu faktycznego) jest to, na ile podmiot korzystający z oprogramowania w ogóle wkracza w sferę wyłączności wynikającą z prawa autorskiego. Niniejsze Rekomendacje nie są właściwym miejscem, by ten spór rozstrzygać. Zamawiający powinni jednak mieć na uwadze, że w praktyce spotykane są bardzo różne modele dotyczące udostępniania oprogramowania w modelu chmury obliczeniowej. Są wśród nich modele, w których usługodawcy nie udzielają licencji, lecz w ramach swoich usług udostępniają oprogramowanie, a zamawiający może korzystać z niego jako tzw. legalny użytkownik ...

zamawiającego lub innych podmiotów trzecich (innych wykonawców) możliwości wykonywania swobodnych modyfikacji oprogramowania oraz dokumentacji oprogramowania, w tym zezwalania na wykonywanie praw zależnych w odniesieniu do takiego oprogramowania oraz jej dokumentacji (zob. Rekomendacja szczegółowa nr 14.2) - co istotne uprawnienie to może być przekazane w postaci licencji lub jako przeniesienie praw na zamawiającego; • Zastrzeżenie obowiązku wydania kodów źródłowych do oprogramowania zamawiającemu oraz zastrzeżenie możliwości przekazania tych kodów źródłowych także innym wykonawcom, którzy będą modyfikować stworzone przez wykonawcę oprogramowanie (zob. Rekomendacja szczegółowa nr 13.8); • Określenie warunków gwarancji jakości na oprogramowanie w taki sposób, aby wykonywanie uprawnień nabytych przez zamawiającego do dokonywania modyfikacji oprogramowania przez podmioty trzecie nie wyłączało całkowicie odpowiedzialności wykonawcy za działanie całego systemu; • Określenie w OPZ zasad poufności realizacji zamówienia oraz postanowień dot. tajemnicy przedsiębiorstwa wykonawcy, tak, aby nie blokowały one w praktyce uprawnień zamawiającego do udostępniania oprogramowania i jego kodów źródłowych podmiotom trzecim, jeśli jest to ...