Kod źródłowy i GitHub – czyje to jest na B2B? Prawa autorskie a konkurencja

Wyobraź sobie taką sytuację: od dwóch lat piszesz świetny kod dla dużego fintechu. Rozwiązujesz skomplikowane problemy, optymalizujesz bazy danych, tworzysz elegancką architekturę. Jesteś dumny ze swojej pracy. Ale kiedy rekruter z innej firmy prosi Cię o link do GitHub, oblewa Cię zimny pot. Twój profil świeci pustkami. Dlaczego? Bo wszystko, co napisałeś, należy do klienta. A może… wcale nie?

Wielu programistów na B2B żyje w przekonaniu, że zasady są takie same jak na etacie – „płacą mi, więc kod jest ich”. To jeden z najgroźniejszych mitów, który może kosztować Cię albo utratę autorskich narzędzi, albo pozew za naruszenie praw autorskich. Dzisiaj wyjaśnimy sobie, jak budować portfolio, nie łamiąc prawa, i co tak naprawdę podpisujesz w umowie B2B.

Kiedy kod staje się własnością klienta?

Zacznijmy od trzęsienia ziemi. W przeciwieństwie do umowy o pracę, gdzie pracodawca nabywa prawa do kodu „z automatu” (wynika to wprost z ustawy), w relacji B2B nic nie dzieje się samo.

Jeśli w Twojej umowie B2B nie ma precyzyjnego zapisu o przeniesieniu praw autorskich majątkowych, to kod… zostaje Twój. Twój klient otrzymuje jedynie licencję (często niewyłączną) na korzystanie z niego. Brzmi jak świetna wiadomość dla Ciebie? Teoretycznie tak. W praktyce to bomba z opóźnionym zapłonem.

Dlaczego? Ponieważ większość korporacji prędzej czy później zorientuje się w braku tego zapisu. Wtedy zaczynają się nerwowe negocjacje, często w atmosferze konfliktu. Z drugiej strony, jeśli podpiszesz zbyt szerokie przeniesienie praw autorskich, możesz nieświadomie pozbawić się prawa do korzystania z własnych, wypracowanych przez lata bibliotek czy snippetów w przyszłych projektach.

Portfolio na GitHubie a tajemnica firmy

To najczęstsze pytanie, jakie słyszę podczas konsultacji: „Mecenasie, czy mogę wrzucić ten kawałek kodu na mojego publicznego GitHuba jako próbkę umiejętności?”.

Odpowiedź prawnika brzmi: to zależy. Odpowiedź praktyka: bądź bardzo ostrożny.

Nawet jeśli umowa jest nieprecyzyjna w kwestii praw autorskich, niemal na pewno chroni Cię tajemnica przedsiębiorstwa. Wrzucenie na publiczne repozytorium fragmentu kodu, który zawiera logikę biznesową klienta, unikalne algorytmy czy (o zgrozo!) zahardcodowane hasła lub klucze API, to prosta droga do pozwu o odszkodowanie.

Jak to ugryźć bezpiecznie?

• Zanonimizuj kod: Usuń wszelkie odniesienia do klienta, nazw projektów i specyficznej logiki biznesowej.
• Stwórz Demo: Zamiast wrzucać kod produkcyjny, napisz podobny moduł w czasie wolnym, rozwiązujący ten sam problem techniczny, ale w oderwaniu od kontekstu klienta.
• Pytaj o zgodę: Czasami prosty e-mail do CTO z pytaniem o zgodę na publikację małego fragmentu w celach edukacyjnych czyni cuda.

Wykorzystanie fragmentów kodu w innych projektach (Biblioteki)

Tutaj wchodzimy na minę, na której wybucha wielu senior developerów. Masz swój „niezbędnik” – zestaw funkcji, klas i helperów, które kopiujesz z projektu do projektu, bo przyspieszają pracę. Nazywamy to Background IP.

Jeśli w umowie B2B zgodzisz się na przeniesienie praw do „wszystkich utworów powstałych w trakcie współpracy” bez żadnych wyłączeń, technicznie rzecz biorąc, sprzedajesz klientowi prawa do swojego „niezbędnika”.

Co to oznacza w czarnym scenariuszu? Używając tego samego kodu u kolejnego klienta, naruszasz prawa autorskie poprzedniego. Aby tego uniknąć, w umowie musi znaleźć się zapis, że przeniesienie praw dotyczy tylko kodu dedykowanego (Foregound IP), a Twoje narzędzia (Background IP) są jedynie licencjonowane klientowi na czas nieokreślony.

Klauzule IP w umowach B2B

Analizując umowy dla programistów, zawsze szukam „świętej trójcy” w sekcji o własności intelektualnej. Zanim podpiszesz kontrakt, sprawdź te trzy punkty:

1. Moment przeniesienia praw: Klient chce, by prawa przechodziły „z chwilą ustalenia utworu” (czyli jak tylko napiszesz linię kodu). Ty powinieneś walczyć o zapis: „z chwilą zapłaty wynagrodzenia”. To Twoje najlepsze zabezpieczenie przed niewypłacalnym kontrahentem.
2. Pola eksploatacji: Czy są wymienione? W polskim prawie „wszystkie pola eksploatacji” to za mało. Muszą być konkretnie wyliczone (np. utrwalanie, zwielokrotnianie, wprowadzanie do obrotu).
3. Prawa zależne: Czy klient nabywa prawo do modyfikacji kodu? Zazwyczaj tak musi być, ale warto to doprecyzować.

Pamiętaj też, że kwestie IP są ściśle powiązane z poufnością. Dobrze skonstruowana umowa o zachowaniu poufności (NDA) / klauzula poufności powinna jasno rozdzielać, co jest chronionym know-how klienta, a co jest Twoją ogólną wiedzą programistyczną, której nie da się „wykasować” z głowy.

Nie podpisuj w ciemno – chroń swój dorobek

Kod źródłowy na B2B to waluta. Nie oddawaj jej za darmo, jeśli nie musisz, i nie przywłaszczaj jej, jeśli Ci nie wolno. Twoja umowa to nie tylko formalność do faktury – to dokument, który decyduje, czy po zakończeniu projektu zostajesz z pustymi rękami, czy z rozbudowanym portfolio i własnymi narzędziami.

Masz wątpliwości co do zapisów w swoim kontrakcie? Boisz się, że nieświadomie naruszasz prawa autorskie? Skontaktuj się ze mną. Przeanalizujemy Twoją umowę i zabezpieczymy Twoją przyszłość jako niezależnego eksperta.

FAQ – Najczęściej zadawane pytania