Source: http://czasopismo.legeartis.org/2017/03/obowiazek-dostarczenia-kodu-zrodlowego.html
Timestamp: 2017-04-30 22:35:24+00:00

Document:
Obowiązek dostarczenia kodu źródłowego: wykonawca nie musi udostępnić kodu jeśli nie wynika to z umowy
by Olgierd Rudak • 5 marca 2017 • 20 komentarzy A teraz coś z innej beczki: czy umowa o wykonanie oprogramowania, w której programista zobowiązał się do wykonania oprogramowania i przeniesienia praw, a także zgodził się na jego modyfikację, oznacza obowiązek dostarczenia kodu źródłowego? Czy zatem zamawiający może domagać się wydania kodu źródłowego powołując się na samo uprawnienie do opracowywania utworów — wskazując, że modyfikacja nie jest możliwa bez dostępu do kodu źródłowego? Amoże powinność taka wynika z przepisów prawa? (wyrok Sądu Apelacyjnego w Warszawie z 18 września 2014 r. (sygn. akt I ACa 315/14).
Obowiązek dostarczenia kodu źródłowego przez wykonawcę musi wynikać wprost z treści umowy. Nie ma przepisu lub zwyczaju, który przesądzałby o
Klient pozwał firmę programistyczną o nakazanie wydania kodu źródłowego wykonanej platformy internetowej (e-księgarni) oraz kodu maszynowego zapisanego na nośniku magnetycznym. Zdaniem strony powodowej obowiązek dostarczenia kodu źródłowego wynikał wprost z treści zawartej umowy o wykonanie oprogramowania, w myśl której wykonawca zobowiązał się do przeniesienie autorskich praw majątkowych do oprogramowania, a także wyraziła zgodę na modyfikację i rozbudowę — wszakże nie jest możliwa modyfikacja oprogramowania bez dostępu do kodu źródłowego.
Zdaniem pozwanej zgodnie z umową nie miała obowiązku wydania zamawiającemu kodu źródłowego, co miało na celu ograniczenie kosztów — gdyby strony ustaliły, że wykonawca ma dostarczyć także kod źródłowy, wyższa byłaby cena usługi. Strony celowo postanowiły, że wykonawca dostarczy wyłącznie płytę DVD do instalacji oprogramowania. Pozwana wskazała, iż wśród oprogramowania znajdują się jej autorskie rozwiązania techniczne, które ze względu na ich znaczenie i możliwość późniejszego wykorzystania nie mogą być udostępniane klientom.
art. 74 ust. 4 pr.aut.
art. 75 ust. 2 pr.aut.
Sąd prawomocnie oddalił powództwo: owszem, firma programistyczna zobowiązała się do wykonania systemu sprzedaży e-booków za wynagrodzeniem 50 tys. złotych (z czego 10% stanowiło należność za przeniesienie autorskich praw majątkowych), zgodziła się także na dokonywanie opracowań, modyfikacji i rozbudowy programu oraz na korzystanie i rozpowszechnianie w najszerszym możliwym zakresie — ale w umowie brak było klauzuli o udostępnieniu kodu źródłowego. W dodatku powód dokonał odbioru oprogramowania, podczas odbioru wyłącznie zastrzegł poprawienie jednego z systemów. W ramach odbioru zamawiający otrzymał płytę CD, na której zapisane były m.in. 3 pliki z otwartym kodem źródłowym oraz 1339 plików skompilowanych, których modyfikacja nie była możliwa bez dostępu do kodu źródłowego.
Zdaniem sądu żądanie wydania kodu źródłowego nie wynikało z umownego uprawnienia do modyfikacji oprogramowania. Zamawiający nie jest uprawniony do domagania się dostarczenia kodu źródłowego nawet z powołaniem się na — wadliwe w świetle art. 41 ust. 2 pr.aut. — postanowienie o przeniesieniu praw na „wszystkich polach eksploatacji”. Modyfikacja oprogramowania — w zakresie zawartości statycznej i merytorycznej systemu — jest możliwa bez dostępu do kodu źródłowego, zatem nie sposób wykazać, iżby nieudostępnienie kodu ograniczało zamawiającego w korzystaniu z oprogramowania.
Nie jest też utrwalonym obyczajem w branży informatycznej przekazywanie kodu źródłowego wraz z wykonanym softem — zatem zamawiający nie mógł oprzeć żądania na art. 49 ust. 1 pr.aut. Obowiązek dostarczenia kodu źródłowego nie mieści się także w uprawnieniach wynikających wprost z art. 74 ust. 4 lub art. 75 ust. 2 pr.aut.
Celem zawartej umowy było wykonanie oprogramowania sprzedaży pozwalającego na sprzedaż e-książek oraz jego instalacja, cel ten został zrealizowany, oprogramowanie zostało przez zamawiającego odebrane — zatem zgodnie z zasadą, iż wątpliwości powinny być interpretowane na korzyść twórcy (por. wyrok SN z 3 grudnia 2008 r., V CNP 82/08), nie można było uznać, iżby wykonawca przyjął na siebie obowiązek dostarczenia kodu źródłowego.
Podsumowując: zamawiający zaniedbał doprecyzowania treści umowy na etapie ustaleń z wykonawcą, zaś „dopisywanie” do umowy postanowień, które nie zostały wynegocjowane co do zasady nie jest możliwe.
Tags: art. 41 pr.aut. art. 49 pr.aut. art. 74 pr.aut. art. 75 pr.aut. program komputerowy	Post navigation
← Peryferie Wrocławia z psem. Część I: północny-zachód (Maślice, Pracze, Leśnica, Janówek)
Ojciec zatrudnił własną (ciężarną) córkę — czy to oznacza, że umowa o pracę jest pozorna? →
Ciekawe o kogo chodzi … W końcu księgarń z ebookami nie jest chyba tak dużo …
Niestety to powszechna praktyka na rynku IT – zamówić jedno, potem próbować wytupać wbrew zawartej umowie co innego.
Ano, to samo słyszałem. Programiści mają za dobrych kolegów z pracy prawników, którzy konstruują umowy niczym budowlańcy – na pozór wszystko ustalone, to znaczy tak myśli zamawiający, a dopiero później wychodzą dodatkowe koszty, bo niby nie zaszło nieporozumienie. Wniosek z tego jest taki, że umowy z IT wymagają sporej wiedzy na temat samego przedmiotu umowy i bardzo długich negocjacji.
Myślę, że każda branża ma swoją specyfikę. Kodeks cywilny jest taki sam dla wszystkich, prawo autorskie jest takie samo dla wszystkich — ale już choćby zwyczaj może być różny. Nie pracowałem dla galerii malarstwa więc tylko próbuję się zastanawiać: zamawiam obraz — ma być oprawiony czy nie? a jeśli oprawiony to w złoto, srebro czy listewki? a może to zależy od stylu — inaczej akwarele, inaczej jakiś Tycjan czy Rembrandt?
tak gdzie są pieniądze są i prawnicy, tam gdzie są prawnicy zaczynają się schody i grillowanie klientów.
Prawnik raczej bez płacącego klienta nie będzie kruszył kopii. Chyba że znajdzie się jakiś idealista (albo po prostu zainteresowany). Więc zawsze zaczyna się od tego, że „obraz mu damy, ale o ramie szczerozłotej może tylko pomarzyć”.
toż mówię, spółki IT mają kasę, więc ich stać na to, żeby mieć swoje bulteriery. Klient dostanie coś, ale nie całość, nie pełną funkcjonalność, o której była mowa podczas negocjacji. I nawet przyjmując logikę IT, czyli nie wie czego chce, to chyba dobrym tonem byłoby jasno wyłożyć, co dostanie, mówiąc językiem ludzkim.
Żeby nie było: o tym jak to wygląda ze strony branży IT nie dowiedziałem się od rozżalonego klienta, ale od … programisty.
spółka z o.o. z siedzibą w W. wniosła o nakazanie (…) spółce z o.o. w siedzibą w W. gordon.shumway
„Klient pozwał firmę programistyczną o nakazanie wydania (…) oraz kodu maszynowego zapisanego na nośniku magnetycznym.”
O jaki nośnik magnetyczny może chodzić w 2014r? Dyskietkę? Czy o klasyczny „twardy” dysk? A jeżeli tak to czy pozwany swój koszt ma go doliczyć do kosztów procesu?
Podpowiem, że najciekawiej jest w przypadków zamówień publicznych i interpretacji pojęć używanych przez zamawiającego w SIWZ.
A najśmieszniej, gdy zamawiający MUSI odebrać produkt (w jakimkolwiek stanie by nie był) w określonym terminie bo musi rozliczyć np. środki unijne które współfinansują tenże produkt.
Lista dużych projektów (>100M PLN) informatyzacji państwa które zakończyły się spektakularnym fiaskiem do łatwego znalezienia w internecie…
Jako człowiek związany z IT powiem od drugiej strony. Nie opłaca się naciągać klientów bo raz naciągnięty klient to brak klienta w przyszłości. W IT też firmy walczą o reputację. Owszem, są firmy krzaki próbujące naciągać ale szybko znikają z rynku. W porządnych firmach IT dba się o przejrzystość, transparentność nie tylko kodu ale też procesu jego tworzenia.
Osobna sprawa to zamówienia publiczne. Tu, jak zamawiający pamięta żeby wpisać w SIWZ dostarczenie kodów źródłowych to daje się mu je w pliku zabezpieczonym hasłem. I tak nikt tego nie otwiera bo nikt się nie zna a w razie gdyby próbował powie się „ups… zapomniałem, oto hasło”.
SIWZy to jedno, a co z nieinstytucjonalnymi, nieurzędowymi zamawiającymi?
A jakie to są te firmy? Bo na ten przykład pewni giganci IT mają pewne problemy z uczciwością i przejrzystością działań będąc zamieszanymi w ustawianie przetargów i łapówki. I pomimo tego wciąż realizują wielkie kontrakty.
Klientów opłaca się naciągać, niestety. Trzeba to tylko robić na zasadzie gotowania żaby. A w przypadku pewnych producentów produktów budowlanych naciąga się klientów dość jawnie i klienci nie mają tu nic do powiedzenia.
Umowa była z 2010 r., pozew z 2011 r. — może to miało być takie ogólne baktudefjuczer :)
Dla oprogramowania „z pudełka” istnieje oczywiście konkurencyjny rynek.
Dla oprogramowania na zamówienie – nie.
Dostawca zawsze postara się przywiązać do siebie kupującego (tak się szkoli sprzedawców). Polecam googla i hasło „vendor lock-in”. Sprzedawca oprogramowania zawsze starać się będzie aby nie można się go było łatwo pozbyć – bo jego oprogramowanie jest krytyczne dla funkcjonowania firmy. Np. sprzedajemy tanio oprogramowanie do księgowości, a później drogo poprawki do niego (bo ustawodawca wprowadził zmiany które tego wymagają).
Przecież przykład z artykułu RedNacza jest tutaj klasyczny. Nie damy wam kodów źródłowych więc wszelkie poprawki zamawiacie u nas.
Działa to tak samo dla nieinstytucjonalnych, nieurzędowych zamawiających.
Ci instytucjonalni i urzędowi są o tyle łatwiejsi do naciągnięcia bo są mniej kompetentni i o tyle trudniejsi, że o decyzje o wyborze dostawcy decydują zakulisowe układy (czytaj: zapisy w SIWZ które premiują konkretnego oferenta).
No tak, to wiem, można to tłumaczyć, tym, że termin, goni- klient naciska, można to tłumaczyć tym, że klient nie powiedział, ale właśnie to najbardziej wpienia – sprzedajcie pełnowartościowe produkty Robienie beta testów na klientach i kazanie sobie płacić za własne niedoróbki, jest no, ten, syństwem.. Wyjątkiem jest rzeczywiście i oczywiście ingerencja państwa (zmiana przepisów).
No ale zmiana przepisów dla pewnej klasy systemów w kilkuletnim horyzoncie czasu jest w 100% pewna. Wyłączywszy nawet księgowość, to można jeszcze wymienić potrzebę raportowania do różnych instytucji (np. regulatorów rynku), uwzględnianie zmian przepisów o ochronie danych osobowych, uwzględnienie konieczności wyświetlania komunikatu o „ciasteczkach”, obsługę nowej wersji przeglądarki, denominacja złotego, ew. przyjęcie euro itp itd…
Dla początkującego i niedoświadczonego biznesu (np. sprzedaż ebooków) problem kosztów utrzymania i dostosowywania systemów informatycznych jest rzadko dostrzegany i dlatego dają się wprowadzić na minę typu „kupiliśmy oprogramowanie bez kodów źródłowych”.
„Drogie” oprogramowanie to już jest MS Office na 2K PLN. Tylko, że ta cena jest akurat niska jak na możliwości bo akurat ten pakiet sprzedaje się to w milionach kopii.
Inna sprawa, że kiedyś pracowałem dla tego typu klientów jako freelancer – i tu było często wymaganie aby za czapkę gruszek dodawać coraz to nowe funkcjonalności do gotowego oprogramowania („bo to dla nas było oczywiste, że umawialiśmy się, że eksport danych do excela to musi być”).
Także wilcze prawa wolnego rynku działają w obydwie strony.
Woblink, Wolne lektury albo Wydawnictwo literackie :)
Dodajmy, też że klienci również często nie są bez winy. „Zrób pan to na czerwono” […. po wykonaniu …]
Ale przecież miał być niebieski …
nie bronię, i napiszę po raz kolejny: trzeba ustalić wszystko, ale trzeba być dla siebie partnerem, trzeba zrozumieć interesy stron, trzeba wyjaśniać nieścisłości. Ale kto na to ma czas dzisiaj, kiedy goni się nawet śpiąc (5h/dobę).

References: art. 74

art. 75
 art. 41
 art. 49
 art. 74
 art. 75
 art. 41
 art. 49
 art. 74
 art. 75