Licencja na oprogramowanie to umowa, w której właściciel autorskich praw majątkowych do programu pozwala komuś z niego korzystać. Prawa zostają u właściciela. Licencjobiorca dostaje tylko to, co zapisano w umowie: konkretne pola eksploatacji, czas, terytorium i zakres.
Dla software house’u to najprostszy sposób, żeby zarobić na kodzie, który już leży w repozytoriach, i nadal go mieć. Warunek jest jeden: prawa do tego kodu muszą należeć do twojej firmy. Kod przeniesiony na klienta jest klienta.
Ta strona omawia licencję od strony właściciela software house’u w Polsce: czym różni się od przeniesienia praw, jakie są rodzaje licencji, co musi być w umowie i co w ogóle możesz licencjonować.
Czym jest licencja na oprogramowanie według polskiego prawa?
W Polsce program komputerowy jest chroniony jak utwór literacki (art. 74 ust. 1 ustawy o prawie autorskim i prawach pokrewnych, tekst jednolity Dz.U. 2025 poz. 24). Ochrona obejmuje każdą formę wyrażenia programu, czyli kod źródłowy i wynikowy. Nie obejmuje idei i zasad, na których program się opiera (art. 74 ust. 2).
Autorskie prawa majątkowe do programu obejmują trzy rzeczy (art. 74 ust. 4):
- zwielokrotnianie programu w całości lub części, także czasowe, jeśli jest potrzebne do uruchomienia,
- tłumaczenie, przystosowywanie i wszelkie zmiany w programie,
- rozpowszechnianie, w tym użyczenie i najem.
Licencja to zgoda na korzystanie z programu w jeden lub kilka z tych sposobów. Ustawa nazywa ją upoważnieniem do korzystania z utworu na polach eksploatacji wymienionych w umowie, z określeniem zakresu, miejsca i czasu (art. 67 ust. 1).
Licencja czy przeniesienie praw: co wybrać?
Przy przeniesieniu autorskie prawa majątkowe przechodzą na nabywcę. Po podpisaniu tracisz je na wymienionych polach eksploatacji i nie możesz dalej sprzedawać ani licencjonować tego kodu. Takiej umowy chce zwykle klient, który zamawia system szyty pod siebie.
Szczegóły są na stronie o przeniesieniu autorskich praw majątkowych. Przy licencji prawa zostają u ciebie. Ten sam kod możesz licencjonować kolejnym firmom, rozwijać i używać w swoich projektach.
| Licencja | Przeniesienie praw | |
|---|---|---|
| Kto ma prawa po podpisaniu | Ty | Nabywca |
| Czy możesz dalej licencjonować | Tak, przy licencji niewyłącznej | Nie |
| Forma | Wyłączna na piśmie, niewyłączna w dowolnej | Pisemna pod rygorem nieważności (art. 53) |
| Typowa cena | Niższa, płatna wielokrotnie | Wyższa, płatna raz |
Jakie są rodzaje licencji na oprogramowanie?
| Rodzaj | Co oznacza | Przepis |
|---|---|---|
| Niewyłączna | Udzielasz jej wielu firmom na tym samym polu eksploatacji | art. 67 ust. 2 |
| Wyłączna | Na danym polu eksploatacji nikt inny nie dostanie licencji | art. 67 ust. 4 i 5 |
| Sublicencja | Licencjobiorca upoważnia kolejną firmę, jeśli umowa mu na to pozwala | art. 67 ust. 3 |
| Open source | MIT, GPL, Apache i inne, licencje w rozumieniu prawa autorskiego | ustawa o prawie autorskim |
Licencja niewyłączna. Tak działa każdy produkt sprzedawany w modelu licencyjnym lub SaaS. Ustawa przyjmuje ją domyślnie: jeśli umowa nie zastrzega wyłączności, licencja jest niewyłączna (art. 67 ust. 2).
Licencja wyłączna. Zobowiązujesz się, że na danym polu eksploatacji nikt inny nie dostanie licencji. Licencjobiorca z licencją wyłączną może sam dochodzić roszczeń za naruszenie praw, jeśli umowa nie stanowi inaczej (art. 67 ust. 4).
Sublicencja. Licencjobiorca może upoważnić kogoś innego do korzystania z programu tylko wtedy, gdy umowa mu na to pozwala (art. 67 ust. 3). Jeśli licencjonujesz kod firmie, która zbuduje na nim produkt dla swoich klientów, prawo do sublicencji musi być w umowie.
Licencje open source. Biblioteki open source w twoim repozytorium mają znaczenie, kiedy licencjonujesz całość. Licencja copyleft, taka jak GPL, może narzucać warunki dystrybucji twojego własnego kodu, więc przed podpisaniem umowy zrób listę zależności i ich licencji.
Co musi być w umowie licencyjnej na oprogramowanie?
Umowa licencyjna obejmuje tylko pola eksploatacji wyraźnie w niej wymienione (art. 41 ust. 2) i tylko pola znane w chwili jej zawarcia (art. 41 ust. 4). Ogólne „licencjodawca udziela licencji na wszystkich polach eksploatacji” to proszenie się o spór. Wypisz po kolei, co licencjobiorcy wolno.
Minimum, które powinno się znaleźć w umowie:
- Przedmiot. Nazwa programu, wersja, repozytorium albo hash commita. Kod źródłowy, wynikowy czy oba.
- Pola eksploatacji. Instalacja i uruchamianie, modyfikacja, łączenie z innym oprogramowaniem, udostępnianie użytkownikom końcowym, udostępnianie w modelu SaaS, sublicencjonowanie.
- Wyłączność. Wyłączna czy niewyłączna. Jeśli wyłączna, to na jakim polu, rynku lub w jakiej branży.
- Czas. Konkretny okres albo czas nieoznaczony. Bez tego zapisu wchodzi okres domyślny z art. 66 ust. 1: 5 lat na terytorium kraju, w którym licencjobiorca ma siedzibę.
- Terytorium. Polska, UE, cały świat. Przy kliencie z DACH albo z USA domyślne terytorium z art. 66 to prawie zawsze za mało.
- Wynagrodzenie. Jednorazowa opłata, opłata roczna, opłata od użytkownika, procent od przychodu.
- Utrzymanie. Czy aktualizacje i poprawki są w cenie, czy w osobnej umowie serwisowej.
- Wypowiedzenie. Licencję na czas nieoznaczony możesz wypowiedzieć z zachowaniem terminu z umowy, a bez takiego zapisu rok naprzód, na koniec roku kalendarzowego (art. 68 ust. 1). Licencja udzielona na dłużej niż 5 lat po tym czasie liczy się jako udzielona na czas nieoznaczony (art. 68 ust. 2). Licencjobiorcy, który płaci za wieloletnie wdrożenie, ten zapis przeszkadza, więc negocjuj go świadomie.
Co software house może licencjonować?
Tylko kod, do którego twoja firma ma autorskie prawa majątkowe. Kto ma te prawa, zależy od tego, kto pisał i na jakiej umowie:
- Pracownik na umowie o pracę. Prawa majątkowe do programu napisanego przy wykonywaniu obowiązków ze stosunku pracy należą do pracodawcy, jeśli umowa nie stanowi inaczej (art. 74 ust. 3).
- Programista na B2B. Ten przepis go nie obejmuje. Prawa ma programista, dopóki nie przeniesie ich na firmę na piśmie. W polskim software housie, gdzie większość zespołu jest na B2B, tu najczęściej jest dziura. Opisujemy ją na stronie kto jest właścicielem kodu.
- Kod dla klienta. Jeśli umowa przeniosła prawa na klienta, kod jest klienta. Jeśli przeniosła tylko część albo przyznała klientowi licencję, reszta jest twoja.
Po dziesięciu latach projektów większość firm ma pokaźny zbiór takiego kodu. To kandydaci do licencji:
- własne biblioteki i frameworki,
- starter kity,
- narzędzia wewnętrzne,
- porzucone produkty,
- moduły napisane między projektami.
Jak zacząć licencjonować kod, który już masz?
Zacznij od inwentaryzacji. Wypisz wszystkie repozytoria. Przy każdym zapisz:
- kto pisał kod i na jakiej umowie (praca, B2B, podwykonawca),
- czy masz pisemne przeniesienie praw od każdej osoby spoza umowy o pracę,
- na podstawie jakiej umowy z klientem powstał kod i co ona mówi o prawach,
- jakie biblioteki open source są w środku i na jakich licencjach.
Wyjdą ci trzy grupy: kod na pewno twój, kod na pewno klienta i kod niejasny. Licencjonować możesz tylko pierwszą grupę. Trzecia wymaga przeczytania umów, a czasem dopisania brakujących przeniesień od byłych współpracowników.
Potem zostaje pytanie o cenę. Ile kod jest wart, zależy od jego wielkości, jakości, testów i tego, kto może go potrzebować. Widełki i sposób liczenia są na stronie ile jest wart kod źródłowy.
Jeśli chcesz sprzedać kod w całości, przeczytaj o sprzedaży kodu źródłowego.