Startup rozwija swój flagship product przez 2 lata. Zespół to głównie developerzy z firm body leasingowych - 8 z 10 osób. Core algorithm, architektura, cały codebase napisany przez zewnętrznych specjalistów. Przychodzi runda B finansowania, due diligence, i pytanie od prawnika VC: “Czy macie przeniesione wszystkie prawa autorskie do kodu od podwykonawców?” CEO sprawdza umowy. Cisza. Nikt o tym nie pomyślał.
Przeczytaj także
- Czy body leasing jest dobry dla startupów? Wady i Zalety
- Body leasing a umowy B2B - Wzajemne powiązania i na co należy zwrócić uwagę
- Czy body leasing jest odpowiednim wyborem dla małych firm? Korzyści i wyzwania
Ta sytuacja powtarza się w dziesiątkach firm. W pogoni za szybkim rozwojem, zapominają o fundamentalnej kwestii: kto jest właścicielem kodu który tworzą zewnętrzni specjaliści? W świetle polskiego prawa autorskiego odpowiedź nie jest oczywista - i może być bardzo kosztowna jeśli nie zostanie rozwiązana prawidłowo w umowie.
Jak polskie prawo autorskie traktuje kod stworzony przez zewnętrznych developerów?
Domyślna zasada: twórca jest właścicielem. W polskim prawie autorskim (ustawa z 1994 r.) autorskie prawa majątkowe przysługują twórcy - osobie która stworzyła utwór. Developer który napisał kod jest pierwotnie jego właścicielem, niezależnie od tego kto mu zapłacił.
Wyjątek: utwór pracowniczy. Jeśli utwór został stworzony w ramach stosunku pracy, pracodawca nabywa autorskie prawa majątkowe z chwilą przyjęcia utworu (art. 12 ustawy). Ale to dotyczy tylko umowy o pracę - nie umowy B2B, nie zlecenia, nie body leasing.
Body leasing = nie stosunek pracy. Developer z firmy body leasingowej nie jest twoim pracownikiem. Jest pracownikiem (lub kontrahentem) dostawcy body leasing. Automatyczne przeniesienie praw nie następuje.
Umowa reguluje przeniesienie. Żeby klient body leasing nabył prawa do kodu - musi to być wyraźnie uregulowane w umowie. I to w specyficzny sposób wymagany przez prawo autorskie.
Łańcuch praw może być długi. Developer → Firma body leasing → Klient. Każde ogniwo musi prawidłowo przenosić prawa. Dziura w jednym ogniwie = dziura w całym łańcuchu.
Jakie są wymagania prawne dla skutecznego przeniesienia praw autorskich?
Forma pisemna pod rygorem nieważności. Art. 53 ustawy o prawie autorskim: umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej. Bez podpisu na papierze (lub kwalifikowanego podpisu elektronicznego) - przeniesienie jest nieważne.
Określenie pól eksploatacji. Art. 41 ust. 2: umowa o przeniesienie praw obejmuje tylko te pola eksploatacji, które są w niej wyraźnie wymienione. Ogólne “przeniesienie wszystkich praw” bez wymienienia pól - jest ryzykowne.
Pola eksploatacji przykładowo:
- utrwalanie i zwielokrotnianie (kopiowanie)
- obrót oryginałem lub egzemplarzami (sprzedaż)
- rozpowszechnianie (udostępnianie publiczne)
- wynajem, użyczenie
- wprowadzenie do pamięci komputera
- publiczne wykonanie, wystawienie, wyświetlenie
- nadawanie, reemitowanie
- publiczne udostępnianie (internet)
Nieznane pola eksploatacji. Art. 41 ust. 4: przeniesienie praw na pola eksploatacji nieznane w chwili zawarcia umowy - wymaga odrębnej umowy. Klauzula “i wszystkie przyszłe pola eksploatacji” jest nieskuteczna.
Utwory przyszłe z ograniczeniami. Przeniesienie praw do utworów które jeszcze nie powstały jest możliwe, ale muszą być dostatecznie określone. “Wszystko co developer napisze” może być zbyt ogólne.
Jak wygląda prawidłowa konstrukcja umowy body leasing pod kątem IP?
Trójstronna relacja. Developer - Dostawca body leasing - Klient. Trzeba uregulować: (1) Developer przenosi prawa na Dostawcę, (2) Dostawca przenosi prawa na Klienta. Alternatywnie: Developer przenosi prawa bezpośrednio na Klienta z reprezentacją przez Dostawcę.
Klauzula IP w umowie ramowej. Umowa między Klientem a Dostawcą powinna zawierać:
- zobowiązanie Dostawcy do zapewnienia przeniesienia praw od developerów
- określenie momentu przeniesienia (np. przy odbiorze sprint/deliverable)
- listę pól eksploatacji
- oświadczenie że Dostawca ma prawo przenosić (ma je od developerów)
- regulację dotyczącą oprogramowania open source używanego w projekcie
Umowa między Dostawcą a Developerem. Dostawca musi mieć umowę z developerem która:
- przenosi prawa do utworów na Dostawcę (lub bezpośrednio na Klienta)
- obejmuje wszystkie niezbędne pola eksploatacji
- jest w formie pisemnej
Cesja praw vs. licencja. Przeniesienie (cesja) oznacza że zbywca traci prawa. Licencja oznacza że zachowuje prawa ale udziela pozwolenia na korzystanie. Dla kodu który ma być własnością klienta - cesja jest bezpieczniejsza.
Co z kodem open source i third-party libraries?
Developer nie tworzy wszystkiego od zera. Używa frameworków, bibliotek, narzędzi. Prawa do tych elementów pozostają przy ich autorach. Licencje open source określają warunki użycia.
Licencje permissive (MIT, BSD, Apache 2.0). Pozwalają na włączenie do proprietary software z minimalnymi wymaganiami (attribution, zachowanie license notice). Generalnie bezpieczne dla projektów komercyjnych.
Licencje copyleft (GPL, AGPL). Wymagają udostępnienia derivative works na tej samej licencji. Użycie GPL library w twoim produkcie może wymagać open-sourcowania twojego kodu. AGPL dotyczy też network use (SaaS).
SBOM i license compliance. Klient powinien wymagać listy wszystkich dependencies i ich licencji. Bez tego - ryzyko naruszenia licencji third-party.
Umowa powinna regulować. Developer oświadcza że: (1) kod autorski jest oryginalny, (2) użyte komponenty third-party są legalnie licencjonowane, (3) licencje są kompatybilne z komercyjnym użyciem przez Klienta.
Jakie ryzyka wiążą się z niedoregulowaniem IP przy body leasing?
Brak zdolności do dyspozycji własnością. Jeśli nie masz praw autorskich do kodu - nie możesz go legalnie sprzedać, licencjonować, sublicencjonować. To blokuje M&A, licencjonowanie produktu, partnerstwa.
Due diligence w rundzie inwestycyjnej. VC/PE przeprowadzają IP due diligence. Brak czystych praw = red flag. Może zablokować inwestycję lub znacząco obniżyć wycenę.
Spory z byłymi dostawcami. Kończy się współpraca z firmą body leasing. Twierdzą że ich developer napisał kod więc mają do niego prawa. Bez czystych umów - kosztowny spór sądowy.
Roszczenia od developerów. Konkretny developer kończy projekt, zakłada konkurencyjną firmę, twierdzi że “jego” kod został ukradziony. Bez udokumentowanego przeniesienia - ryzyko.
Problemy przy exit. Sprzedajesz firmę, kupujący chce gwarancji że cały kod jest legalny. Nie możesz dać takiej gwarancji bo nie masz umów z wszystkimi developerami sprzed 5 lat.
Naruszenie licencji open source. Developer użył GPL library, ty nie wiesz, sprzedajesz closed-source produkt. FSF pisze cease-and-desist. Reputacyjne i finansowe konsekwencje.
Jak przeprowadzić IP audit istniejącej współpracy body leasing?
Zebranie dokumentacji. Wszystkie umowy z dostawcami body leasing. Wszystkie zamówienia/statement of work. Sprawdzenie czy zawierają klauzule IP.
Identyfikacja luk. Które umowy nie mają przeniesienia praw? Które mają niekompletne pola eksploatacji? Które są tylko w formie email (nieważne)?
Lista developerów i ich wkładu. Kto pracował, kiedy, nad czym. Mapowanie autorów do kodu. Git blame i historia commitów pomagają.
Remediation plan. Dla każdej luki - rozwiązanie: aneks do umowy, nowa umowa, oświadczenie. Priorytetyzacja według ryzyka i wartości kodu.
Dla byłych współpracowników. Jeśli dostawca lub developer już nie współpracuje - trzeba ich znaleźć i podpisać umowę post factum. Może wymagać negocjacji (i potencjalnie wynagrodzenia).
Dokumentacja going forward. Wprowadzenie standardów dla wszystkich nowych współprac: template umowy, checklist IP, review prawny.
Co powinien zawierać IP due diligence checklist dla nowych projektów body leasing?
Przed rozpoczęciem:
- Czy umowa ramowa zawiera klauzulę IP z pełnymi polami eksploatacji?
- Czy forma umowy jest prawidłowa (pisemna)?
- Czy Dostawca oświadcza że ma prawa do przeniesienia?
- Czy regulowana jest kwestia oprogramowania open source?
W trakcie projektu:
- Czy każdy developer podpisał odpowiednie dokumenty?
- Czy jest śledzenie kto pisze jaki kod (git)?
- Czy jest prowadzony rejestr użytych bibliotek i licencji (SBOM)?
- Czy code review obejmuje check na problematyczne licencje?
Przy zakończeniu/deliverable:
- Czy jest formalne przyjęcie utworów (protokół odbioru)?
- Czy dokumentacja przeniesienia jest kompletna?
- Czy SBOM jest aktualny i zweryfikowany?
Przy zakończeniu współpracy:
- Czy wszystkie prawa zostały przeniesione?
- Czy developer nie zachowuje kopii kodu (poza portfolio)?
- Czy NDA pozostaje w mocy?
Jak uregulować prawa do narzędzi i reusable components developera?
Developer przynosi toolkit. Doświadczeni developerzy mają własne narzędzia, snippets, biblioteki które używają w wielu projektach. Przeniesienie praw do nich na jednego klienta by uniemożliwiło dalsze używanie.
Rozwiązanie: licencja zamiast cesji dla generic tools. “Developer udziela Klientowi niewyłącznej, bezterminowej licencji na narzędzia X, Y, Z używane w projekcie. Prawa do tych narzędzi pozostają przy Developerze/Dostawcy.”
Rozróżnienie: project-specific vs. generic. Kod specyficzny dla projektu (business logic, features) - cesja na Klienta. Kod generic (utils, helpers używane wszędzie) - licencja.
Dokumentacja rozróżnienia. Lista komponentów z określeniem: “cesja” lub “licencja”. Zapobiega późniejszym sporom “ale to moje narzędzie!”
Unikanie derivative works issue. Jeśli project-specific kod jest derivative work narzędzia developera - kwestia się komplikuje. Architektura powinna to uwzględniać.
Jakie zapisy chronią obie strony - klienta i dostawcę?
Dla klienta (nabywcy praw):
- Oświadczenie dostawcy że kod jest oryginalny i nie narusza praw osób trzecich
- Gwarancja że dostawca ma prawo do przeniesienia (ma je od developerów)
- Indemnity clause - dostawca pokryje szkody z roszczeń IP osób trzecich
- Prawo do sublicencjonowania i modyfikacji bez ograniczeń
- Brak ograniczeń terytorialnych i czasowych
Dla dostawcy:
- Wyraźne określenie że przeniesienie następuje po zapłacie (retencja IP jako security)
- Prawo do referencji i showcase (z zachowaniem poufności)
- Licencja na generic tools/components (nie traci swojego toolkitu)
- Ograniczenie odpowiedzialności do wartości umowy
- Procedura akceptacji (po odbiorze klient nie może kwestionować IP)
Dla developera:
- Jasność co do zakresu przeniesienia (nie “wszystko co stworzysz w życiu”)
- Zachowanie praw do swojego pre-existing toolkitu
- Prawo do portfolio/demonstracji (bez ujawniania tajemnic)
- Wynagrodzenie za przeniesienie (wliczone w stawkę)
Jak różni się sytuacja przy różnych modelach współpracy?
Time & Materials body leasing: Developer pracuje pod kierownictwem klienta, kod powstaje “w locie”. Przeniesienie praw powinno być ciągłe (np. przy każdym sprint review) lub automatyczne po stworzeniu. Kluczowe: ciągłość przeniesienia, nie tylko na koniec projektu.
Fixed-price project: Deliverable jest zdefiniowany. Przeniesienie praw następuje przy odbiorze końcowym (lub milestone). Retencja IP do momentu płatności jest standardowa. Klient musi upewnić się że WSZYSTKIE prawa są przenoszone (w tym intermediate deliverables).
Managed services / outsourcing: Dostawca utrzymuje system, wprowadza zmiany. Nowy kod powstający w ramach utrzymania - czy klient nabywa prawa? Musi być wyraźnie uregulowane.
Consulting / advisory: Konsultant dostarcza analizy, rekomendacje, dokumentację. To też utwory w rozumieniu prawa autorskiego. Czy raporty, prezentacje, specyfikacje są przenoszone?
Jak ARDURA Consulting wspiera ochronę własności intelektualnej w body leasing?
Zabezpieczenie IP w projektach body leasing wymaga nie tylko wiedzy prawnej, ale przede wszystkim sprawdzonego partnera, który rozumie złożoność tego zagadnienia. ARDURA Consulting od lat specjalizuje się w dostarczaniu zespołów IT z pełnym uregulowaniem kwestii własności intelektualnej — to standard, nie dodatek.
Dzięki sieci 500+ seniorów z udokumentowanym doświadczeniem, ARDURA Consulting zapewnia transparentne umowy z kompletnym łańcuchem przeniesienia praw autorskich. Średni czas wdrożenia specjalisty to zaledwie 2 tygodnie, a klienci oszczędzają średnio 40% kosztów w porównaniu z budowaniem zespołów in-house. Wskaźnik retencji na poziomie 99% oznacza stabilność zespołu i ciągłość prawną IP przez cały cykl projektu. Ponad 211+ zrealizowanych projektów to potwierdzona praktyka w zabezpieczaniu praw do kodu i compliance z licencjami open source.
Każda umowa ARDURA Consulting zawiera klauzulę IP z pełnymi polami eksploatacji, oświadczenie o prawidłowym łańcuchu praw oraz regulację dotyczącą komponentów third-party. Skontaktuj się z nami, aby omówić bezpieczną współpracę z gwarancją czystych praw do kodu.
Tabela: Checklist IP dla umowy body leasing
| Obszar | Element do uwzględnienia | Kto odpowiedzialny | Ryzyko pominięcia |
|---|---|---|---|
| Forma umowy | Pisemna z podpisami (lub kwalifikowany e-podpis) | Legal obu stron | Nieważność przeniesienia |
| Pola eksploatacji | Pełna lista (utrwalanie, zwielokrotnianie, rozpowszechnianie, modyfikacja, sublicencja, etc.) | Legal klienta | Ograniczone prawa |
| Łańcuch praw | Oświadczenie dostawcy że ma prawa od developerów | Dostawca + legal | Dziura w łańcuchu, brak skutecznego przeniesienia |
| Moment przeniesienia | Określony (przy odbiorze, przy zapłacie, ciągle) | Obie strony | Spór o timing |
| Open source | Lista dozwolonych licencji, SBOM requirement | Development team + legal | Naruszenie licencji GPL/AGPL |
| Pre-existing IP | Rozróżnienie: cesja dla project-specific, licencja dla generic | Developer + legal | Developer traci swoje narzędzia |
| Indemnity | Dostawca pokrywa roszczenia IP osób trzecich | Legal klienta | Klient ponosi koszt sporów |
| Autorskie prawa osobiste | Zrzeczenie się lub niewykonywanie (autorstwo, integralność) | Legal | Developer może blokować modyfikacje |
| Terytorialny zakres | ”Cały świat” bez ograniczeń | Legal klienta | Ograniczone użycie geograficzne |
| Czasowy zakres | ”Bezterminowo” | Legal klienta | Prawa wygasają |
| Dokumentacja | Protokoły odbioru, git history, SBOM | PM/Tech Lead | Brak dowodów własności |
| Poufność | NDA obejmuje kod jako informację poufną | Legal obu stron | Wyciek kodu |
Własność intelektualna przy body leasing to obszar gdzie błędy są drogie i trudne do naprawienia. Umowa która “jakoś” reguluje IP może okazać się niewystarczająca gdy pojawią się prawdziwe pieniądze - inwestycja, sprzedaż firmy, spór sądowy.
Kluczowe wnioski:
- Domyślnie developer jest właścicielem kodu - przeniesienie wymaga wyraźnej umowy
- Forma pisemna jest obowiązkowa - email czy ustna umowa nie wystarczy
- Pola eksploatacji muszą być wymienione - “wszystkie prawa” to za mało
- Łańcuch praw musi być kompletny - developer → dostawca → klient
- Open source ma swoje licencje - SBOM i license compliance są konieczne
- Pre-existing tools developera to odrębna kwestia - licencja zamiast cesji
- IP audit należy robić regularnie - nie tylko przy due diligence
Najlepsza praktyka: zaangażuj prawnika specjalizującego się w IP i IT na etapie negocjacji umowy body leasing, nie gdy pojawią się problemy.
ARDURA Consulting oferuje transparentne umowy body leasing z pełnym uregulowaniem kwestii własności intelektualnej. Nasi klienci otrzymują czyste prawa do kodu, compliance z licencjami open source i dokumentację spełniającą wymogi due diligence. Skontaktuj się z nami aby omówić bezpieczną współpracę z zewnętrznymi specjalistami IT.