Prawa autorskie na hackathonie: do kogo należy projekt?

W praktyce rozstrzyga o tym, czy możesz swobodnie rozwijać pomysł poza wydarzeniem, czy organizator ma prawo komercyjnie go wykorzystać, a także — w razie konfliktu w zespole — kto odpowiada za co. Polskie prawo autorskie daje w tej sprawie dość wyraźne ramy, ale diabeł tkwi w regulaminie i w tym, kto faktycznie podpisał co.

Domniemanie twórcy: jak polskie prawo chroni uczestników hackathonu

Zacznijmy od fundamentu, który wiele osób traktuje jako oczywisty, a który wciąż bywa źródłem nieporozumień. Prawo autorskie w Polsce ma charakter twórczy — oznacza to, że chroni nie inwestycję, lecz sam akt twórczy. Konsekwencja jest prosta: kto napisał kod, narysował storyboard, zaprojektował interfejs — ten jest twórcą w rozumieniu ustawy, niezależnie od tego, ile pieniędzy w projekt włożył organizator, ile kubków kawy postawił sponsor ani ile godzin trwał hackathon.

Dwa artykuły ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych robią tu największą robotę:

• Art. 1 ust. 1 mówi wprost, że prawo autorskie przysługuje twórcy utworu będącego przejawem działalności twórczej o indywidualnym charakterze.
• Art. 8 doprecyzowuje, że prawo autorskie powstaje z chwilą ustalenia utworu — czyli od momentu, w którym kod został zapisany, prototyp zmontowany, a projekt zyskał jakąkolwiek materialną formę.

W przypadku zespołu wchodzi w grę jeszcze art. 9, który reguluje współautorstwo. Jeśli w trakcie hackathonu nad projektem pracowały trzy osoby o różnych kompetencjach — programista, designer, osoba odpowiedzialna za koncepcję — to każda z nich jest współtwórcą. To nie jest kwestia umowy, tylko samej natury ich pracy. Regulamin może ten układ uzupełnić lub przesunąć akcenty, ale nie jest w stanie wymazać faktu, że każdy współtwórca wypracował element chroniony prawem.

Prawo autorskie rodzi się w głowie i rękach twórcy, nie w kasie organizatora. Cały weekend sponsorowanego kodowania nie zmienia faktu, że autorem kodu jest programista, a nie logo na plakacie.

Ta zasada ma jedną bardzo praktyczną konsekwencję: domniemanie jest po stronie uczestnika. To organizator musi wykazać, że nabył prawa — a nie uczestnik, że ich nie oddał. Jeśli gdziekolwiek w komunikacji wydarzenia pojawiło się zdanie w stylu „prace stają się własnością organizatora", ale nikt nie podpisał stosownej umowy, w razie sporu to twórca ma prawo powiedzieć: dziękuję, ale nie zgodziłem się.

Rola regulaminu w kształtowaniu własności intelektualnej

Skoro domniemanie jest twórcze, to po co w ogóle regulamin? Po to, że ustawodawca zostawił sporo pola do czynności prawnej — czyli do umowy między organizatorem a uczestnikiem. Regulamin to właśnie ta umowa (technicznie: przyrzeczenie publiczne w rozumieniu art. 919 i 921 Kodeksu cywilnego), która może przesunąć akcent własności. Może, ale nie musi, i ma w tym konkretne granice.

W praktyce spotyka się trzy główne warianty zapisów:

Tabela nie powie, jak to wygląda na konkretnym hackathonie — musisz przeczytać regulamin. Ale porządkuje oczekiwania: jeśli jedziesz na hackathon organizowany przez fundację artystyczną i w zespole projektujesz interaktywną instalację, scenariusz z pełnym przeniesieniem praw jest mało prawdopodobny. Jeśli jedziesz na hackathon technologiczny organizowany przez bank, scenariusz odwrotny — bardzo realny.

I jeszcze jedno, co warto zobaczyć w regulaminie: klauzula o współautorstwie wewnątrz zespołu. Zwykle regulamin tego nie reguluje wcale i słusznie — to nie jest sprawa organizatora, kto ile wniósł do wspólnego projektu. Ale to oznacza, że między współtwórcami panuje domniemanie równego udziału, chyba że sami postanowili inaczej. I tu zaczyna się rozdział trzeci.

Pułapka formy pisemnej: dlaczego kliknięcie w regulamin to za mało

To chyba najczęstsze przekonanie, które trzeba skorygować: „Kliknąłem akceptuję regulamin, więc wszystko, co tam napisali, obowiązuje". W życiu codziennym — tak, w prawie autorskim — nie zawsze.

Art. 53 ustawy o prawie autorskim mówi wprost: umowa o przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej pod rygorem nieważności. To nie jest kwestia dowodowa; to jest kwestia skuteczności prawnej. Bez podpisu — czy to na papierze, czy kwalifikowanym podpisem elektronicznym — przeniesienie praw po prostu nie dochodzi do skutku. Nawet jeśli regulamin wyraźnie mówi „uczestnik przenosi prawa na organizatora", a uczestnik tylko kliknął przycisk „Akceptuję" na stronie, to ta czynność nie wywoła skutku, którego oczekuje organizator.

Co ważne, kwalifikowany podpis elektroniczny to nie to samo co „zgoda w panelu uczestnika". W polskim systemie prawnym status takiego dokumentu, jak zaawansowany podpis elektroniczny z certyfikatem kwalifikowanym, jest zrównany z podpisem odręcznym — ale zwykłe logowanie, checkbox czy potwierdzenie mailowe nim nie jest.

Konsekwencja jest taka, że organizatorzy, którzy rzeczywiście chcą przejąć prawa, muszą podpisać z uczestnikiem osobną umowę, najczęściej przed wypłatą nagrody. Stąd właśnie bierze się praktyka znana z hackathonów komercyjnych: na koniec weekendu zwycięzca dostaje formularz do podpisu, w którym przenosi prawa majątkowe na organizatora (albo udziela mu wyłącznej licencji). Bez tego formularza nagroda po prostu nie zostaje wypłacona.

Kliknięcie „akceptuję regulamin" nie zastępuje umowy przeniesienia praw. Bez papierowego podpisu lub kwalifikowanego podpisu elektronicznego organizator nie ma skutecznego przeniesienia — nawet jeśli regulamin mówi inaczej.

To nie jest szczegół prawniczy bez znaczenia — to realne zabezpieczenie dla twórcy. W razie sporu sądowego taki podpis jest pierwszą rzeczą, której szuka sędzia.

Komercyjne hackathony a przeniesienie praw majątkowych

Komercyjne hackathony — organizowane przez banki, instytucje publiczne, duże firmy technologiczne — mają własną logikę. Dla organizatora projekt to nie tylko pomysł na wydarzenie, ale potencjalny produkt, który da się dalej rozwijać, opatentować albo wdrożyć do oferty. Trudno się dziwić, że organizatorzy takich wydarzeń chcą mieć jasność co do praw.

W takim scenariuszu najczęściej pojawia się art. 921 § 3 Kodeksu cywilnego — przepis, który mówi, że organizator konkursu nabywa własność oraz autorskie prawa majątkowe do nagrodzonego dzieła tylko wtedy, gdy:

1. dokonał takiego zastrzeżenia w przyrzeczeniu publicznym (czyli regulaminie),

2. nabycie następuje z chwilą wypłacenia nagrody.

Ten drugi warunek jest kluczowy. Przeniesienie nie jest skuteczne w momencie akceptacji regulaminu ani w momencie ogłoszenia wyników, lecz dopiero w chwili fizycznego wypłacenia nagrody. To znaczy, że do tego momentu uczestnik zachowuje pełnię praw. W praktyce bywa to wykorzystywane: uczestnik, który nie zgadza się z klauzulami, może odmówić podpisania formularza, nie otrzymać nagrody, ale zachować projekt. To nie jest wygodna sytuacja, ale prawo po stronie twórcy wciąż stoi.

Osobny temat to podatek od nagrody. Przy nagrodach pieniężnych na hackathonach najczęściej stosuje się zryczałtowany 10% podatek dochodowy (art. 30 ust. 1 pkt 2 ustawy o PIT), co oznacza, że organizator albo pobiera podatek z nagrody, albo dolicza około 11,11% dodatkowej kwoty, żeby uczestnik dostał netto tyle, ile obiecano. To nie jest problem własności intelektualnej, ale przy ocenie „ile faktycznie zarabiam na tym hackathonie" warto o nim pamiętać, bo organizatorzy różnie to rozliczają.

Jeszcze jedno: w hackathonach komercyjnych pojawiają się często zapisy o wyłącznej licencji zamiast przeniesienia praw. To rozwiązanie pośrednie — twórca pozostaje właścicielem, ale organizator dostaje monopolistyczne prawo korzystania z utworu, nieraz na wiele lat i w szerokim zakresie. Z perspektywy twórcy taka licencja może być bardziej lub mniej korzystna niż przeniesienie, w zależności od szczegółów: zakresu, terytorium, czasu trwania, wyłączności. To już jest temat na osobną, szczegółową lekturę konkretnej umowy.

Współpraca w zespole: jak zabezpieczyć prawa między uczestnikami

Nawet jeśli regulamin zostawia 100% praw przy uczestnikach, pozostaje otwarte pytanie, które w praktyce wysypuje się po hackathonie, kiedy projekt zaczyna żyć własnym życiem: kto jest współtwórcą czego i w jakiej części?

Wyobraź sobie taką sytuację. Zespół trzyosobowy: Kasia pisała front-end, Bartek robił back-end i bazę danych, Mikołaj odpowiadał za koncepcję UX i prezentację. Po hackathonie okazuje się, że pomysł chce rozwinąć fundacja inwestycyjna. Kto może podpisać umowę? Wszyscy trzej — jako współtwórcy — ale każdy musi wyrazić zgodę, a zgoda nie może być jednostronna. Brak porozumienia w zespole oznacza brak możliwości korzystania z utworu w szerszym zakresie niż osobiste portfolio każdego z nich.

Dlatego praktykowane są trzy proste rozwiązania, które można wdrożyć nawet w trakcie hackathonu:

1. Umowa współautorstwa — krótki dokument (jedna-dwie strony), w którym zespół ustala: kto jest współtwórcą jakiej części projektu, w jakich proporcjach dzielą się ewentualnymi przyszłymi przychodami, kto reprezentuje zespół na zewnątrz, jak rozwiązuje się spór (np. mediacja, decyzja większości). To nie musi być elaborat — wystarczy zapis, że każdy współtwórca udziela pozostałym nieodpłatnej licencji na korzystanie z ich wspólnego wkładu w zakresie dalszego rozwijania projektu.

2. Wyznaczenie lidera lub pełnomocnika — jeden z członków zespołu dostaje pełnomocnictwo do działania w imieniu wszystkich w sprawach związanych z projektem. Najprostsze rozwiązanie, ale wymaga zaufania, bo lider może teoretycznie podpisać coś, z czym reszta się nie zgadza.

3. Jasny podział ról od pierwszego dnia — jeszcze przed kodowaniem ustalić, kto robi co, najlepiej w formie krótkiego dokumentu (markdown, trello, nawet czat). Jeśli w trakcie weekendu okaże się, że Kasia pomaga Bartkowi z bazą danych, dopisz to. W razie sporu pozwala to odtworzyć, co kto faktycznie zrobił.

Hackathon kończy się w niedzielę o 18:00. Współautorstwo zostaje z Tobą do końca życia projektu — i do końca życia każdego z członków zespołu. Warto to ustalić, zanim będzie trzeba.

Brak takich ustaleń nie przekreśla projektu, ale drastycznie utrudnia każdą poważniejszą decyzję: czy idziemy do akceleratora, czy rozwijamy po godzinach, czy sprzedajemy licencję, czy zamykamy kod.

Co wynika z tego dla uczestnika

Jeśli miałbym skondensować cały materiał w jedno zdanie: polskie prawo autorskie jest dla twórcy, regulamin jest dla organizatora, a umowa między współtwórcami jest dla zespołu. Te trzy filary trzeba widzieć osobno.

Praktyczna checklista przed następnym hackathonem:

• Przeczytaj regulamin od deski do deski, zwłaszcza sekcje „prawa autorskie", „własność intelektualna", „warunki przyznania nagrody" — nie streszczaj, nie pomijaj.
• Sprawdź, czy regulamin mówi o przeniesieniu praw czy o licencji — to dwie różne rzeczy.
• Sprawdź, czy organizator wymaga podpisu osobnej umowy — jeśli tak, masz realną negocjację przed podpisaniem.
• Ustal z zespołem podział ról i sposób reprezentacji jeszcze przed startem kodowania.
• Bądź świadomy, że nagroda pieniężna może wiązać się z 10% podatkiem — i że bez podpisanej umowy przeniesienia nagroda często nie zostaje wypłacona.

Prawo autorskie na hackathonie nie jest czarną magią ani pułapką zastawioną przez organizatorów — jest narzędziem, które działa wyraźnie po stronie twórcy, o ile twórca z niego korzysta świadomie. Po to właśnie jest ten tekst: żebyś wiedział, czego szukać w regulaminie, kiedy pytać organizatora o doprecyzowanie i kiedy uznać, że warunki Ci nie odpowiadają, zanim włożysz weekend w projekt, który potem trudno będzie odzyskać.