Czyj jest kod wygenerowany przez AI i aplikacja zbudowana w no-code?

Serwis prowadzi zespół tomekniedzwiecki.pl — szczegóły powiązania w O serwisie.

Co dokładnie oddają ci OpenAI, Anthropic i GitHub?

Regulaminy trzech największych dostawców mówią to samo: prawa do outputu są twoje, o ile prawo pozwala je komukolwiek przypisać. OpenAI w Terms of Use obowiązujących od 1 stycznia 2026 r.: „As between you and OpenAI, and to the extent permitted by applicable law, you (a) retain your ownership rights in Input and (b) own the Output”. Anthropic w Commercial Terms of Service z 17 czerwca 2025 r.: „Customer (a) retains all rights to its Inputs, and (b) owns its Outputs”. GitHub w sekcji J swojego regulaminu: „GitHub does not claim ownership of your Input or Output”.

Dwa zastrzeżenia w tych samych dokumentach ważą więcej niż deklaracje. Pierwsze to „to the extent permitted by applicable law” oraz „if any” przy cesji — dostawca przenosi prawa, których sam może w ogóle nie mieć. Drugie to klauzula OpenAI o podobieństwie treści: „other users may receive similar output from our Services. Our assignment above does not extend to other users' output”. Nikt nie gwarantuje ci więc wyłączności na wygenerowany fragment kodu.

Czy kod wygenerowany przez AI jest w Polsce utworem?

Polskie prawo autorskie chroni „każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci” (art. 1 ust. 1 ustawy z 4 lutego 1994 r.), a twórcą w tym systemie może być wyłącznie człowiek. Stąd wniosek, który powtarza się w polskiej doktrynie: rezultat wygenerowany autonomicznie, gdy rola człowieka sprowadza się do wpisania polecenia, nie spełnia przesłanek utworu.

Tak stawia sprawę Jerzy Szczotka w „Studia Iuridica Lublinensia” 33(1)/2024, s. 323–342: dobra niematerialne wygenerowane przez AI de lege lata nie mieszczą się w definicji utworu, ponieważ nie zostały stworzone przez człowieka. W tym samym kierunku idzie amerykański Copyright Office w raporcie z 29 stycznia 2025 r. — ochrona przysługuje tylko tam, gdzie człowiek określił wystarczające elementy ekspresyjne, a „the mere provision of prompts” tego nie zapewnia.

Stan na sierpień 2026 r. jest więc taki: sam fakt użycia AI niczego nie przekreśla, ale ciężar ochrony leży po stronie ludzkiego wkładu. Im więcej realnych decyzji człowieka — architektura, dobór bibliotek, poprawki, testy, przepisane fragmenty — tym mocniejsza pozycja. Czysty output modelu może po prostu nie mieć właściciela, a wtedy nikt nie zabroni konkurentowi używać tego samego fragmentu.

Praktyczny odruch: dokumentuj wkład człowieka od pierwszego dnia. Historia commitów, code review, notatki z decyzji projektowych i lista miejsc, w których kod z modelu został przerobiony, to jedyny materiał dowodowy, jaki będziesz mieć w sporze.

Czego prawo autorskie nie ochroni, nawet gdy kod pisze człowiek

Pomysł na aplikację nie jest chroniony — chroniony jest wyłącznie sposób jego zapisania. Art. 1 ust. 2(1) ustawy: „Ochroną objęty może być wyłącznie sposób wyrażenia; nie są objęte ochroną odkrycia, idee, procedury, metody i zasady działania oraz koncepcje matematyczne”.

Dla oprogramowania powtarza to art. 74 ust. 2: „Ochrona przyznana programowi komputerowemu obejmuje wszystkie formy jego wyrażenia. Idee i zasady będące podstawą jakiegokolwiek elementu programu komputerowego, w tym podstawą łączy, nie podlegają ochronie”. Przepływ ekranów, logika biznesowa opisana słowami i model działania usługi są poza ochroną.

Konsekwencja jest niewygodna, ale prosta: konkurent może legalnie zbudować tę samą funkcjonalność od zera. To, co realnie broni pozycji, leży poza prawem autorskim — znak towarowy, zgromadzone dane, dystrybucja, tempo wdrażania i umowy o poufności z osobami, które znają szczegóły.

Co zapisać w umowie z wykonawcą, który używa AI

Bez wyraźnego postanowienia o przeniesieniu praw nie kupujesz praw, tylko licencję — art. 65 ustawy każe w takim wypadku domniemywać, że twórca udzielił licencji. Cztery zapisy poniżej zamykają najczęstsze luki, a dwa ostatnie dotyczą już wyłącznie pracy z modelami.

• Forma. Art. 53: „Umowa o przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej pod rygorem nieważności”. Równoważna jest forma elektroniczna z kwalifikowanym podpisem (art. 78[1] § 2 Kodeksu cywilnego). Skan i „ok” w mailu nie przenoszą praw.
• Pola eksploatacji. Art. 41 ust. 2: umowa obejmuje pola „wyraźnie w nich wymienione”, a ust. 4 pozwala objąć tylko pola znane w chwili zawarcia. Formuła „wszystkie pola eksploatacji” nic nie daje — potrzebna jest lista.
• B2B to nie etat. Art. 74 ust. 3 przyznaje prawa do programu pracodawcy tylko przy stosunku pracy. Przy umowie o dzieło i kontrakcie B2B nie ma automatu — brak zapisu oznacza brak praw.
• Prawa zależne. Bez zezwolenia na wykonywanie i rozporządzanie prawami zależnymi nie kupisz swobody w rozwijaniu i przepisywaniu kodu przez kolejnych wykonawców.
• Oświadczenie o narzędziach i licencjach. Wykonawca deklaruje, jakich narzędzi AI użył, oraz że kod nie narusza licencji open source. GitHub w sekcji J regulaminu przerzuca obowiązek weryfikacji outputu — łącznie z prawami osób trzecich — na użytkownika.
• Wydanie. Repozytorium z historią, dostępy do kont na platformach, zmienne środowiskowe i dokumentacja, z terminem i skutkiem niewydania. To jedyna część umowy, którą realnie egzekwujesz w dniu rozstania.

To nie jest porada prawna. Powyższe to opis przepisów i publicznych dokumentów w stanie na sierpień 2026 r.; konkretną umowę oceń z prawnikiem znającym twój projekt.

Lock-in no-code: kto pozwala wynieść kod, a kto nie

W no-code większe ryzyko dotyczy nie praw, lecz fizycznej możliwości zabrania aplikacji ze sobą. Poniższe zestawienie powstało 26 sierpnia 2026 r. z dokumentacji i cenników samych platform.

Bubble deklaruje jednocześnie, że w razie zaprzestania działalności udostępni swój kod źródłowy na licencji open source, żeby aplikacje dało się utrzymać na własnym serwerze. To obietnica w dokumentacji, a nie umowa escrow — przy ocenie ryzyka traktuj ją jak deklarację, nie zabezpieczenie.

Ile kosztuje utrzymanie opcji wyjścia — wyliczenie na cenach z 26 sierpnia 2026 r.

Cena „opcji wyjścia” jest policzalna, a różnice między planami są mniejsze, niż koszt ich braku. Poniżej nasze przeliczenie oficjalnych cen katalogowych na 24 miesiące — bez podatków, przy rozliczeniu miesięcznym i jednym miejscu w zespole.

Dopłata za wersjonowanie w GitHubie po stronie FlutterFlow to (80 − 39) × 24 = 984 USD w dwa lata. Przy rozliczeniu rocznym FlutterFlow deklaruje ok. 25% oszczędności, więc ta sama różnica spada do okolic 738 USD.

W Bubble tej pozycji w budżecie nie ma, bo nie ma czego kupić: wyjście oznacza przepisanie aplikacji od zera, a migrujesz wyłącznie dane. Zanim uznasz to za dyskwalifikację, policz odwrotną stronę — jeśli aplikacja ma żyć rok i zweryfikować popyt, cena szybkiego startu bywa wyższa niż wartość opcji, z której nigdy nie skorzystasz.

Sześć pytań przed wyborem narzędzia

1. Czy mogę dziś, w ciągu 15 minut, pobrać kompletny kod aplikacji na własny dysk — i na jakim planie?
2. Czy eksport zawiera bazę danych, konta użytkowników i integracje, czy tylko warstwę wizualną?
3. Czy wyeksportowany projekt uruchomi się poza platformą bez jej bibliotek i usług?
4. Kto ma dostęp administracyjny do konta na platformie: ja czy wykonawca, i co się dzieje po zakończeniu współpracy?
5. Czy umowa przenosi majątkowe prawa autorskie w formie pisemnej, z wymienionymi polami eksploatacji i prawami zależnymi?
6. Czy wykonawca zobowiązał się udokumentować ludzki wkład w kod powstały z pomocą AI i odpowiada za licencje zależności?

Jeżeli na pytania 1–3 odpowiedź brzmi „nie”, nie znaczy to, że narzędzie jest złe. Znaczy, że kupujesz tempo, płacąc kosztem przepisania aplikacji w dniu, w którym platforma przestanie ci wystarczać — i tę cenę warto policzyć przed startem, a nie po roku.