Kto jest właścicielem kodu źródłowego aplikacji?

Krótka odpowiedź

To, kto jest właścicielem kodu źródłowego aplikacji, zależy od umowy, a nie dzieje się automatycznie. Bez zapisu o przeniesieniu praw wykonawca może zachować prawa do kodu, który stworzył. Powinieneś zadbać, by to Twoja firma była właścicielem kodu, konta Apple i repozytorium, na piśmie, zanim zaczniesz. To Twoja najlepsza ochrona przed sytuacją, w której agencja trzyma Twój kod jako zakładnika. To informacja ogólna, a nie porada prawna. Jeśli szukasz też porządnego partnera, zobacz nasz przewodnik jak napisać brief dla agencji aplikacji.

Kto domyślnie jest właścicielem kodu

Pierwszą rzeczą, która zaskakuje wielu założycieli, jest to, że zapłata za stworzenie aplikacji nie zawsze oznacza automatyczne posiadanie jej kodu. Intuicja podpowiada, że skoro płacisz, kod jest Twój, ale prawo w wielu miejscach działa inaczej: prawa autorskie do kodu należą domyślnie do tego, kto go napisał, chyba że umowa wyraźnie przenosi je na Ciebie.

Oznacza to, że bez odpowiedniego zapisu możesz znaleźć się w dziwnej sytuacji: zapłaciłeś za aplikację, ale wykonawca zachowuje prawa do kodu, a Ty masz jedynie prawo z niej korzystać. To nie jest teoretyczne, to źródło wielu problemów, które przydarzają się firmom, które nie zadbały o ten szczegół. Dobra wiadomość jest taka, że rozwiązanie jest proste: umowa musi jasno stanowić, że po zapłacie własność kodu przechodzi na Twoją firmę. To jeden zapis, ale jeden z najważniejszych w całym projekcie, i trzeba go ustalić, zanim cokolwiek się zacznie, a nie odkrywać jego brak później.

Dlaczego musisz być właścicielem kodu

Posiadanie kodu źródłowego to nie formalność ani prawnicza drobnostka; to kontrola nad własną aplikacją i Twoją przyszłością. Gdy jesteś właścicielem kodu, możesz robić z aplikacją, co chcesz: rozwijać ją, zmieniać dostawcę, zatrudnić kogoś innego do jej utrzymania, albo po prostu wiedzieć, że Twój produkt naprawdę należy do Ciebie.

Gdy nie jesteś właścicielem, każda z tych rzeczy staje się zależna od kogoś innego. Chcesz coś zmienić? Musisz wrócić do tego jednego wykonawcy. Chcesz zmienić dostawcę, bo współpraca się nie układa? Możesz odkryć, że nie możesz zabrać ze sobą własnej aplikacji. To odwrócenie władzy jest dokładnie tym, czego chcesz uniknąć, bo zamienia partnera w jedyną drogę i pozbawia Cię wyboru. Posiadanie kodu, budowanego natywnie w Swift, oznacza, że aplikacja jest aktywem Twojej firmy, a nie czymś wypożyczonym od dostawcy, który może zmienić zdanie. Dla każdego, kto traktuje aplikację poważnie, ta kontrola jest bezcenna, bo to ona decyduje, czy Twój produkt jest naprawdę Twój, czy tylko wypożyczony na warunkach kogoś innego.

Co obejmuje posiadanie aplikacji

Element	Dlaczego go potrzebujesz
Kod źródłowy	To sama aplikacja; bez niego nie masz nic
Repozytorium	Miejsce, gdzie kod żyje; musisz mieć do niego dostęp
Konto Apple Developer	Twoja obecność w App Store i sama aplikacja
Loginy i dostępy	Wszystko łączy się przez nie

Własność to coś więcej niż sam kod, i tabela pokazuje pełny obraz. Sam kod źródłowy bez dostępu do repozytorium, w którym mieszka, wciąż zostawia Cię zależnym. Podobnie konto Apple Developer Program musi być na Twoje nazwisko, bo to ono trzyma Twoją aplikację w App Store; jeśli należy do wykonawcy, on kontroluje Twoją obecność w sklepie. Zasada jest prosta: powinieneś posiadać i kontrolować cały projekt, kod, repozytorium, konto Apple i wszystkie dostępy. Dopiero wtedy masz pełną kontrolę i żaden pojedynczy dostawca nie może odciąć Cię od Twojej własnej aplikacji ani wstrzymać jej, by coś wymusić.

Problem zakładniczego kodu

Oto konkretny scenariusz, który przyprowadza wielu założycieli do tego pytania, i który zdarza się częściej, niż powinien. Firma płaci agencji za zbudowanie aplikacji, ale kod mieszka w repozytorium agencji, a konto Apple należy do agencji. Wszystko idzie dobrze, dopóki się nie zepsuje: pojawia się spór o opłaty za utrzymanie, chęć zmiany dostawcy albo po prostu pogorszenie współpracy. I nagle firma odkrywa, że nie może zabrać swojej aplikacji, bo tak naprawdę jej nie kontroluje.

To jest kod trzymany jako zakładnik, i jest to realne ryzyko, o którym krążą historie. Agencja, która trzyma Twój kod i konto, ma nad Tobą dźwignię: możesz czuć się zmuszony płacić więcej, niż jest to uczciwe, albo zostać przy dostawcy, którego byś zmienił, bo alternatywą jest utrata aplikacji. Ochroną nie jest zaufanie, że nigdy się to nie zdarzy, lecz uniknięcie samej możliwości poprzez posiadanie kodu, repozytorium i konta od początku. Gdy to Ty jesteś właścicielem, nikt nie może wziąć Twojej aplikacji jako zakładnika, bo jest ona po prostu Twoja, niezależnie od tego, jak potoczy się współpraca.

Warto podkreślić, że problem zakładniczego kodu rzadko wynika ze złej woli od samego początku. Częściej zaczyna się niewinnie: mała agencja albo freelancer buduje aplikację, kod naturalnie ląduje w ich repozytorium, konto Apple zakładają na siebie, bo tak było im wygodniej, i nikt o tym nie pomyślał, dopóki wszystko szło dobrze. Dopiero gdy pojawia się napięcie, ten wygodny układ zamienia się w dźwignię. Dlatego ochrona nie polega na szukaniu nieuczciwych dostawców, lecz na ustaleniu własności z każdym dostawcą z góry, nawet z tym, któremu ufasz, bo to chroni relację przed sytuacją, w której interesy się rozejdą. Dobrzy partnerzy rozumieją to i sami proponują jasne warunki własności, zanim o nie zapytasz.

Jak zapewnić sobie własność

Dobra wiadomość jest taka, że ochrona przed tym wszystkim jest prosta, o ile zadbasz o nią z góry, przed rozpoczęciem, a nie po. Kilka kroków wystarczy.

1. Zapisz przeniesienie praw w umowie. Umowa powinna jasno stanowić, że po zapłacie prawa autorskie do kodu przechodzą na Twoją firmę. To zdecydowanie najważniejszy zapis w całej umowie.
2. Trzymaj kod w repozytorium, które kontrolujesz. Nie w prywatnym repozytorium wykonawcy, lecz w takim, do którego masz pełny dostęp jako właściciel.
3. Załóż konto Apple na swoje nazwisko. Twoja obecność w App Store i sama aplikacja powinny należeć do Ciebie, nie do dostawcy.
4. Zbierz wszystkie dostępy. Upewnij się, że masz każdy login i klucz, tak by nic nie było zamknięte wyłącznie u wykonawcy.

Wątek łączący te kroki jest jeden: kontrolę zapewniasz sobie, ustalając ją na piśmie, zanim praca się zacznie. Rzetelny partner zgadza się na to bez oporów, bo dla niego to normalne, i chętnie zapisuje własność w umowie. To, jak wykonawca reaguje na pytanie o własność, samo w sobie wiele mówi, i jest to pytanie, które warto zadać wcześnie, jeszcze zanim uzgodnicie cenę i zakres, bo odpowiedź na nie mówi Ci o partnerze więcej niż niejeden punkt oferty.

Sygnały ostrzegawcze

Sygnał ostrzegawczy	Co oznacza
Niechęć do zapisania przeniesienia praw	Może chcieć zachować kontrolę nad Twoim kodem
Kod tylko w repozytorium wykonawcy	Nie masz pełnego dostępu do własnej aplikacji
Konto Apple na nazwisko agencji	Kontroluje Twoją obecność w sklepie
Wymijające odpowiedzi o własności	Unika tematu, który powinien być jasny
Uzależnianie kodu od dalszych opłat	Klasyczna zapowiedź zakładniczego kodu

Tabela zbiera znaki, na które warto uważać, zanim podpiszesz umowę. Każdy z nich sugeruje dostawcę, który może chcieć zachować dźwignię, zamiast oddać Ci pełną kontrolę. Żaden pojedynczy sygnał nie musi przesądzać sprawy, ale wzorzec jest wymowny, a niechęć do jasnego ustalenia własności jest najpoważniejszym z nich. Rzetelny partner odpowiada na te pytania wprost i bez wahania, bo nie ma nic do ukrycia. Wymijanie, mętne odpowiedzi albo presja, by szybko podpisać bez wyjaśnienia własności, to znaki, by się zatrzymać.

Własność a utrzymanie to nie to samo

Warto rozwiać częste nieporozumienie, bo bywa źródłem sporów: posiadanie kodu i to, kto utrzymuje aplikację, to dwie różne rzeczy, i jedno nie wyklucza drugiego. Możesz być pełnym właścicielem kodu, a jednocześnie z własnego wyboru zlecać jego utrzymanie tej samej agencji, która go zbudowała, bo zna go najlepiej. Własność nie oznacza, że tracisz partnera; oznacza, że zostajesz z nim, bo chcesz, a nie dlatego, że musisz.

Na tym właśnie polega różnica między zdrową a niezdrową relacją. W zdrowej agencja utrzymuje Twoją aplikację, bo robi to dobrze i cenisz jej pracę, a Ty przez cały czas jesteś właścicielem kodu i mógłbyś odejść, gdyby coś się popsuło. W niezdrowej agencja utrzymuje Twoją aplikację, bo trzyma kod i nie masz dokąd pójść. Ta sama usługa, zupełnie inny układ sił. Gdy jesteś właścicielem kodu, opłaty za utrzymanie stają się uczciwą wymianą, którą oceniasz na jej wartość, a nie okupem, który płacisz z przymusu. Dlatego posiadanie kodu w rzeczywistości poprawia współpracę przy utrzymaniu, zamiast ją psuć: obie strony wiedzą, że relacja trwa dzięki jakości, a nie dzięki uwięzieniu, i to zwykle sprawia, że dostawca stara się bardziej, bo wie, że w każdej chwili mógłbyś wybrać inaczej.

Kiedy sprawa jest bardziej złożona

Bądź świadomy, że to informacja ogólna, a nie porada prawna, i że w kilku sytuacjach sprawa własności bywa bardziej złożona. Aplikacje często korzystają ze sprawdzonych, zewnętrznych składników i bibliotek o otwartym kodzie; nie jesteś ich właścicielem, lecz korzystasz z nich na ich licencjach, co jest normalne i w porządku. Rzetelny partner powie Ci, co jest Twoim kodem na wyłączność, a co pochodzi z takich składników, tak byś rozumiał, co dokładnie posiadasz. W bardziej złożonych lub dużych projektach warto, by umowę sprawdził prawnik, bo szczegóły prawa autorskiego i przenoszenia praw potrafią być zawiłe i zależą od jurysdykcji.

Dla większości aplikacji jednak zasada jest prosta i osiągalna: powinieneś być właścicielem kodu, który dla Ciebie napisano, oraz konta i repozytorium, a rzetelny partner chętnie Ci to zapewni na piśmie. Zespół, który projektuje i buduje pod jednym dachem, jak my, przekazuje pełną własność kodu, który tworzymy, i utrzymuje Twój dostęp do repozytorium i konta Apple Developer Program przez cały czas, bo Twoja aplikacja powinna należeć do Ciebie. Zobacz przykłady w naszej pracy i porozmawiaj z nami o swoim projekcie, i o własności kodu, podczas krótkiej rozmowy.