Jak zacząć z open source i nie zginąć w licencjach

Po co w ogóle open source? Korzyści i realny obraz

Krok 1: zdefiniuj swój cel, zanim zaczniesz z open source

Start w open source bez jasnego celu zwykle kończy się szybkim zniechęceniem lub chaosem w licencjach. Pierwszy krok to odpowiedź na pytanie: po co w ogóle chcesz wejść w open source. Inne wybory podejmiesz, jeśli budujesz portfolio juniora, inne – tworząc produkt SaaS, a jeszcze inne – gdy szukasz społeczności i chcesz dzielić się wiedzą.

Przydatne jest proste ćwiczenie: zapisz jeden główny cel i dwa cele poboczne. Przykładowo: „Główny cel: wejść w open source, żeby pokazać w CV realne kontrybucje do znanych projektów. Cele poboczne: nauczyć się code review i zrozumieć, jak działają licencje w praktyce”. Takie uporządkowanie pomaga później wybierać projekty i licencje, zamiast rzucać się na pierwsze lepsze repozytoria.

Warto też ustalić horyzont czasowy. Jeśli chcesz w ciągu trzech miesięcy zrobić kilka drobnych kontrybucji, skupisz się na małych zadaniach i prostych projektach. Jeśli myślisz o własnym narzędziu open source rozwijanym latami, już na starcie trzeba inaczej spojrzeć na licencje, markę i model rozwoju.

Co sprawdzić na tym etapie?

• Czy potrafisz w jednym zdaniu napisać, dlaczego chcesz zacząć z open source?
• Czy wiesz, czy bardziej zależy ci na nauce, portfolio, czy budowaniu produktu?
• Czy masz choć wstępny plan (np. 2–3 godziny tygodniowo na kontrybucje)?

Co realnie daje udział w open source: więcej niż tylko „fajnie brzmi w CV”

Open source przyspiesza rozwój techniczny i zawodowy w sposób, którego trudno doświadczyć w pojedynkę. Wchodząc w projekt, widzisz prawdziwy kod produkcyjny, standardy, testy, dyskusje o architekturze. To nie są przykłady z kursów, tylko realne problemy: migracje wersji, regresje, edge case’y.

Dodatkową warstwą są kontakty. Nawet kilka dobrych pull requestów (PR) potrafi zbudować relację z maintainerem, który później napisze rekomendację na LinkedIn lub poleci cię do rekrutacji. Wielu programistów dostało pierwszą sensowną pracę właśnie dzięki temu, że ktoś z projektu open source powiedział: „Znam tę osobę, robiła u nas dobry kod i słuchała feedbacku”.

Udział w open source to również świetny poligon do nauki narzędzi i procesów: git, CI/CD, code review, issue tracker, automatyzacja wydań. Wszystko w realnym kontekście biznesowym. Zamiast naśladować workflow z tutoriali, od razu funkcjonujesz w środowisku przypominającym dobrze poukładaną firmę.

Co sprawdzić?

• Czy wiesz, jaką konkretną umiejętność chcesz poprawić dzięki open source (np. testy, architektura, DevOps)?
• Czy masz profil na GitHub/GitLab pokazujący twoje aktywności w jednym miejscu?

„Kod jest na GitHubie” a prawdziwe open source – kluczowa różnica

Wiele osób myli dwa światy: publiczne repozytorium i open source. Samo wrzucenie kodu na GitHuba bez licencji to wciąż „wszystkie prawa zastrzeżone”. Z prawnego punktu widzenia inni nie mają jasnej zgody, co mogą z tym kodem zrobić. Mogą go co najwyżej przeczytać, ale już użycie w projekcie lub modyfikowanie + publikacja może być naruszeniem praw autorskich.

Prawdziwy projekt open source to repozytorium, w którym są przynajmniej:

• jasno określona licencja w pliku LICENSE lub podobnym,
• informacja o autorach / opiekunach,
• zazwyczaj jakiś opis zasad współpracy (np. CONTRIBUTING.md).

Jeśli chcesz zacząć z open source i nie zginąć w licencjach, koniecznie rozróżniaj: „repo publiczne” to nie to samo, co „repo na licencji open source”. Brak licencji to czerwone światło: nie klonuj, nie publikuj dalej, nie wszywaj do własnego produktu.

Co sprawdzić?

• Czy każdy używany przez ciebie projekt ma wyraźnie zaznaczoną licencję?
• Czy rozumiesz, że publiczność repozytorium nie oznacza automatycznie wolnego wykorzystania?

Małe, konkretne przykłady efektów udziału w open source

Przykład z praktyki: początkujący developer frontendu znalazł w popularnej bibliotece UI błąd w komponencie formularza. Wysłał PR z poprawką i testami. Maintainer nie tylko zmerge’ował zmianę, ale zaprosił go do dyskusji nad refaktoryzacją całego modułu. Po kilku miesiącach ten sam developer miał w CV sensowny blok „kontrybucje open source”, a w referencjach – opiekuna projektu z dużą rozpoznawalnością.

Inny scenariusz: mały zespół tworzący wewnętrzne narzędzie do generowania raportów zdecydował się otworzyć kod na licencji MIT. Trochę obawiali się „kradzieży” pomysłu, ale zamiast tego dostali PR z poprawką wydajności i integracją z innym narzędziem. Ostatecznie ich wewnętrzne rozwiązanie stało się rozpoznawalnym komponentem w ekosystemie języka, co przełożyło się na łatwiejszą rekrutację (kandydaci znali narzędzie).

Oba przykłady mają wspólny mianownik: świadomy wybór licencji i jasna komunikacja, na co autorzy się zgadzają. Bez tego projekty mogłyby utknąć w „szarej strefie” prawnej, w której nikt nie ma odwagi dotknąć kodu.

Czy open source faktycznie jest dla ciebie?

Choć open source daje dużo korzyści, nie zawsze jest idealną odpowiedzią. Jeśli budujesz produkt, którego główną przewagą jest sekretny algorytm – pełne otwarcie kodu może nie mieć sensu. Wtedy można myśleć o hybrydach: np. open source tylko klienta lub SDK, a logikę biznesową trzymać w zamkniętym back-endzie.

Są też osoby, którym zwyczajnie bardziej odpowiada praca w zamkniętych zespołach i projektach wewnętrznych. W takim przypadku udział w open source nadal może pomóc (np. krótkie kontrybucje do znanych bibliotek), ale nie musi być głównym elementem kariery.

Co sprawdzić?

• Czy twój produkt lub pomysł realnie zyskuje na byciu open source, czy raczej na budowaniu przewagi dzięki wiedzy niedostępnej publicznie?
• Czy masz gotowość na publiczną krytykę i code review – nie każdy to lubi, choć z czasem bywa bardzo rozwijające.

Podstawy, bez których łatwo się zgubić: prawo autorskie i licencje w IT

Krok 1: zrozum domyślne ustawienie – „wszystkie prawa zastrzeżone”

Prawo autorskie w uproszczeniu działa tak: jeśli coś stworzyłeś, z automatu masz do tego prawa. Nie trzeba niczego rejestrować, zgłaszać ani oznaczać. Dotyczy to także kodu źródłowego – nawet prostych skryptów. Domyślność jest brutalna z perspektywy open source: „wszystkie prawa zastrzeżone”.

To oznacza, że inni nie mają prawa kopiować, modyfikować, rozpowszechniać ani sprzedawać twojego kodu, chyba że dasz im licencję. Publiczne repozytorium bez pliku LICENSE nie zmienia tego stanu rzeczy. Ktoś może podejrzeć kod, ale nie wolno mu zrobić z nim tego, co zwykle kojarzy się z open source.

Jeśli chcesz korzystać z cudzych bibliotek, musisz sprawdzić, czy autor udzielił ci licencji. Jeśli chcesz, żeby inni korzystali z twojego kodu – też musisz licencję wybrać. To rdzeń całego tematu „jak zacząć z open source i nie zginąć w licencjach”.

Prawa osobiste i majątkowe – prosty podział bez prawniczego żargonu

W Polsce (i w wielu innych krajach) wyróżnia się dwie główne grupy praw autorskich:

• prawa osobiste – związane z twoją osobą jako twórcy,
• prawa majątkowe – związane z możliwością zarabiania i decydowania o wykorzystaniu utworu.

Prawa osobiste są nieprzenoszalne. Nie możesz zrzec się autorstwa kodu, możesz co najwyżej pozwolić komuś podpisywać projekt nazwą firmy, ale z prawnego punktu widzenia twórcą i tak pozostajesz. Do praw osobistych należy m.in. prawo do bycia wskazanym jako autor oraz prawo do nienaruszalności formy utworu.

Prawa majątkowe możesz przenieść (np. umową o pracę) albo udzielić licencji – czyli dać zgodę na korzystanie z kodu w określony sposób. Licencja open source jest właśnie taką zgodą. Mówi: „Masz prawo używać, kopiować, modyfikować mój kod na takich a takich warunkach”. Bez licencji cudzy kod jest dla ciebie w praktyce „tylko do czytania”.

Co robi licencja: jasny zestaw dozwolonych i zabronionych działań

Licencja to nic innego jak zestaw zasad gry. Mówi, co wolno, czego nie wolno oraz na jakich warunkach można dalej rozpowszechniać kod. Przykładowo:

• MIT pozwala praktycznie na wszystko, byle zachować informację o autorze i zrzeczenie odpowiedzialności.
• GPL wymaga, by projekty pochodne publikować na tej samej licencji (tzw. copyleft).
• Apache 2.0 oprócz zgody na użycie zawiera również postanowienia dotyczące patentów.

Dzięki licencji nie musisz z każdym użytkownikiem podpisywać osobnej umowy. Ustanawiasz ogólne warunki – ktoś, kto korzysta z kodu, akceptuje je, używając go zgodnie z licencją. Dlatego tak ważne jest, by licencję dobrać świadomie, a nie „jakąkolwiek, byle była”. Późniejsze zmiany są możliwe, ale trudne – szczególnie przy większej liczbie kontrybutorów.

„Znalazłem w internecie, więc mogę użyć” – dlaczego to prowadzi na minę

Popularny, ale bardzo ryzykowny skrót myślowy brzmi: „skoro ktoś wrzucił kod na bloga/Gista/Stack Overflow, to mogę go wziąć i wbudować w produkt”. Prawnie to tak nie działa. Bez jasnej zgody (licencji) możesz co najwyżej zainspirować się rozwiązaniem, ale kopiowanie linijek 1:1 i wklejanie do komercyjnego projektu jest co najmniej dyskusyjne.

Serwisy typu Stack Overflow mają swoje licencje treści (np. warianty Creative Commons), które np. wymagają przypisania autorstwa. W praktyce mało kto to robi. W projektach komercyjnych lepiej zastanowić się dwa razy, zanim wklei się fragment od nieznanej osoby. W razie sporu prawnego pojawia się pytanie: na jakiej podstawie używasz tego kodu?

Najbezpieczniejsze podejście: albo korzystasz z kodu, który ma jasno określoną licencję open source kompatybilną z twoim projektem, albo traktujesz znalezione fragmenty jedynie jako inspirację i przepisujesz rozwiązanie po swojemu.

Kontrola zrozumienia: czy licencja to dla ciebie formalność, czy fundament?

Kod bez licencji jest jak dom bez aktu własności. Może stoi, może jest ładny, ale przy pierwszym poważniejszym konflikcie robi się bardzo nieprzyjemnie. Świadome działanie w open source zaczyna się od przyjęcia, że licencja to fundament korzystania z kodu, a nie nudny dodatek.

Co sprawdzić?

• Czy w twoich repozytoriach jest plik LICENSE lub inna wyraźna informacja o licencji?
• Czy rozumiesz w 1–2 zdaniach, na co zgadzasz się, używając danej licencji w swoim projekcie?

Najpopularniejsze licencje open source – mapa terenu

Główne rodziny licencji: permisive vs copyleft

Świat licencji open source da się z grubsza podzielić na dwie duże grupy:

• permissive (permisywne) – licencje pozwalające na bardzo szerokie wykorzystanie, także w projektach zamkniętych,
• copyleft – licencje, które wymagają, by projekty pochodne pozostawały open source na tych samych lub podobnych zasadach.

Do pierwszej grupy należą m.in. MIT, BSD, Apache 2.0. Są popularne, bo są proste i „biznesowo przyjazne”: możesz wziąć bibliotekę, użyć jej w zamkniętym produkcie, nawet komercyjnym, pod warunkiem spełnienia kilku nieskomplikowanych wymogów (zwykle informacja o autorach, licencja w dokumentacji itp.).

Do copyleft zalicza się przede wszystkim rodzina GPL (GPLv2, GPLv3), LGPL i AGPL. Ich idea jest inna: skoro korzystasz z tej wolności, podziel się również własnymi zmianami na tych samych zasadach. To tzw. „efekt wirusowy” (choć to określenie bywa nielubiane przez społeczność), który ma wymusić, by oprogramowanie pochodne też pozostało open source.

„Charakterystyki uliczne”: MIT, GPL, Apache 2.0 w jednym zdaniu

Żeby szybko odnaleźć się w terenie, wystarczy zapamiętać krótkie, „uliczne” definicje najważniejszych licencji:

Szybkie „ściągi”: MIT, GPL, Apache 2.0 w praktyce

Zamiast wkuwać całe teksty licencji, lepiej mieć w głowie prostą „ściągę” i wiedzieć, gdzie dopytać o szczegóły.

• MIT – „rób prawie co chcesz, ale mnie nie pozywaj i mnie wspomnij”. Możesz używać w projektach komercyjnych, zamkniętych, SaaS, bibliotekach. Warunki:
  • musisz zachować informację o autorach i treść licencji,
  • autor nie ponosi odpowiedzialności za skutki użycia kodu.
• GPL (np. GPLv3) – „możesz używać, jeśli także otworzysz swój kod na tej samej zasadzie”. Nadaje się do:
  • aplikacji, które chcesz, by zawsze pozostały wolne,
  • narzędzi CLI, programów desktopowych, systemów, gdzie kod jest dystrybuowany użytkownikom.

  Wymusza upublicznienie kodu pochodnego przy jego dalszej dystrybucji.

• Apache 2.0 – „permisywna jak MIT, ale z dodatkowymi zapisami o patentach”. Dobra, jeśli:
  • działasz w środowisku, gdzie patenty mają znaczenie (większe firmy, korporacje),
  • chcesz zminimalizować ryzyko, że ktoś użyje twojego kodu i jednocześnie zaatakuje cię patentowo.

Jako punkt wyjścia: gdy nie masz żadnych obostrzeń biznesowych, a zależy ci tylko na prostocie – MIT. Gdy bronisz „wolności kodu” przed zamknięciem – GPL. Gdy myślisz o współpracy z większymi firmami lub patentach – Apache 2.0.

Co sprawdzić?

• Czy wiesz w jednym zdaniu, jak MIT, GPL i Apache 2.0 wpływają na możliwość użycia kodu w projektach komercyjnych?
• Czy potrafisz powiedzieć, dlaczego wybrałeś konkretną licencję, a nie „bo tak robią inni”?

LGPL, AGPL, BSD – mniej oczywiste, a często spotykane

Poza „wielką trójką” pojawia się kilka licencji, które wywołują pytania przy przeglądaniu zależności w projekcie.

• LGPL – „GPL, ale lżejsza dla bibliotek”. Dotyczy głównie sytuacji, gdy:
  • korzystasz z biblioteki w formie dynamicznego linkowania (np. .so, .dll),
  • nie chcesz, by cała twoja aplikacja musiała być GPL, ale akceptujesz obowiązek udostępnienia modyfikacji samej biblioteki.

  Typowe w bibliotekach C/C++, komponentach systemowych, niektórych frameworkach.

• AGPL – „GPL dla świata SaaS”. Domyślny „wytrych” SaaS – ktoś bierze GPL, hostuje w chmurze, nie dystrybuuje binarek, więc nie „aktywuje” GPL. AGPL próbuje to zamknąć:
  • jeśli udostępniasz oprogramowanie AGPL użytkownikom przez sieć,
  • musisz umożliwić im dostęp do kodu źródłowego twojej wersji.

  Często spotykana w narzędziach serwerowych, panelach administracyjnych, systemach do hostowania.

• BSD 2‑Clause / 3‑Clause – bardzo zbliżone do MIT, drobne różnice w brzmieniu i dodatkowym zastrzeżeniu dotyczącym użycia nazw autorów do promocji. W praktyce:
  • firmy i prawnicy traktują je niemal tak samo jak MIT,
  • nadają się świetnie do bibliotek, frameworków, narzędzi CLI.

Typowy błąd: założenie, że LGPL/AGPL to „prawie MIT, na pewno jest ok do komercyjnego użycia”. To krótsza droga do konfliktu z działem prawnym niż zaimportowanie całej GPL‑owej bazy do zamkniętego produktu.

Co sprawdzić?

• Czy potrafisz wyjaśnić różnicę między GPL a LGPL na konkretnym przykładzie (np. aplikacja + biblioteka)?
• Czy wiesz, że AGPL ma „ząb” w kontekście SaaS, a nie tylko przy klasycznej dystrybucji binarek?

Efekt „zarażania” kodu: kiedy copyleft naprawdę się uruchamia

Wokół GPL i spółki narosło mnóstwo mitów. Żeby uniknąć paniki „wszystko nam się zaraziło GPL‑em”, trzeba złapać kilka prostych reguł.

Krok 1: rozróżnij użycie od pochodności.

• Jeśli tylko uruchamiasz program na serwerze/komputerze (np. Linux, narzędzie CLI, serwer bazodanowy) – nie tworzysz automatycznie utworu pochodnego. Możesz mieć obok zupełnie zamkniętą aplikację.
• Jeśli linkujesz bibliotekę GPL do swojego kodu (statycznie lub dynamicznie – tu zaczynają się detale prawne) i dystrybuujesz całość – powstaje mocne ryzyko, że całą aplikację trzeba potraktować jak utwór pochodny i udostępnić na GPL.

Krok 2: sprawdź model dystrybucji.

• Dystrybucja binarek / kodu – klasyczny przypadek „uruchomienia” copyleft. Dajesz klientowi aplikację do instalacji → wchodzisz w tryb obowiązków licencyjnych (kod źródłowy, warunki dalszego rozpowszechniania itd.).
• SaaS (tylko dostęp przez sieć) – tu standardowa GPL w wielu scenariuszach nie „gryzie”. Dlatego powstała AGPL, która rozszerza obowiązki także na udostępnianie przez sieć.

Krok 3: oceń, czy na pewno potrzebujesz copyleft w swoim projekcie.

Jeśli:

• tworzysz komponent, który ma być używany w wielu zamkniętych produktach,
• chcesz maksymalnie ułatwić adopcję przez firmy,

to copyleft może bardziej przeszkadzać niż pomagać. Z kolei jeśli budujesz narzędzie, które potencjalnie ktoś mógłby zamknąć i sprzedawać bez oddawania czegokolwiek społeczności – mocne copyleft bywa świadomym wyborem.

Co sprawdzić?

• Czy rozumiesz, w jakich sytuacjach twój kod stanie się „utworem pochodnym” względem zależności na GPL/LGPL/AGPL?
• Czy wiesz, czy twój projekt będzie dystrybuowany, czy tylko hostowany jako usługa?

Jak wybrać licencję do własnego projektu – konkretne scenariusze

Krok 1: odpowiedz sobie, po co w ogóle otwierasz kod

Zanim wybierzesz licencję, zatrzymaj się i nazwij cel. Bez tego łatwo skończyć z przypadkową licencją.

Najczęstsze motywacje:

• budowa portfolio – chcesz pokazać jakość kodu, sposób pracy, przyciągnąć rekruterów,
• budowa ekosystemu – zależy ci, by inne projekty korzystały z twojego, integrowały się z nim,
• ochrona „wolności” projektu – nie chcesz, żeby ktoś zrobił zamknięty fork i nigdy nie oddał zmian,
• model biznesowy wokół open source – np. płatne wsparcie, rozszerzenia, hosting, dual licensing.

Dla każdej z tych opcji sensowne mogą być inne licencje. Jeśli nie wiesz, po co otwierasz kod, to tak jakbyś wybierał opony do samochodu bez wiedzy, czy jedziesz w góry, czy na tor.

Co sprawdzić?

• Czy jesteś w stanie jednym zdaniem powiedzieć, dlaczego ten konkretny projekt ma być open source?
• Czy twoja odpowiedź wskazuje raczej na „maksymalna adopcja”, czy „maksymalna ochrona przed zamknięciem”?

Scenariusz: małe narzędzie / biblioteka, portfolio developera

Klasyka: prosta biblioteka, plugin, narzędzie CLI, którym chcesz się pochwalić w CV.

Cel: jak najwięcej osób może użyć, forkować, włączać do swoich projektów. Nie chcesz być supportem pół branży ani śledzić, kto gdzie tego używa.

Bezpieczne opcje:

• MIT – najprostszy wybór, krótki tekst, mało obostrzeń, bardzo niski próg akceptacji w firmach,
• BSD 2‑Clause – praktycznie tak samo „miękka” jak MIT, jeśli preferujesz tę rodzinę licencji.

Typowy błąd: wybór GPL „bo brzmi poważniej”, bez świadomości, że część firm po prostu nie będzie mogła legalnie włączyć twojego narzędzia do swoich produktów.

Co sprawdzić?

• Czy zgadzasz się, by twoje narzędzie było włączane do zamkniętych, komercyjnych produktów bez obowiązku otwierania ich kodu?
• Czy tekst licencji, którą wybrałeś, jesteś w stanie przejrzeć i zrozumieć w 10–15 minut bez bólu głowy?

Scenariusz: framework / kluczowa biblioteka dla innych projektów

Gdy tworzysz coś, co ma być podstawą wielu innych aplikacji, kwestia licencji mocno wpływa na adopcję.

Jeśli zależy ci na szerokim użyciu (w tym komercyjnym):

• MIT / BSD / Apache 2.0 – firmy będą mogły użyć frameworka bez konieczności otwierania własnego kodu.
• Apache 2.0 bywa preferowana, gdy spodziewasz się większych graczy i chcesz uregulować temat patentów.

Jeśli chcesz, by wszystkie forki i rozszerzenia pozostały open source:

• GPL / LGPL – wymuszą, by projekty pochodne również były otwarte. Spodziewaj się jednak mniejszej adopcji w zamkniętych produktach.

Krótkie, realistyczne zderzenie: zespół buduje framework front‑endowy pod MIT i po paru latach widzi go w produktach trzech dużych firm. Gdyby użyli GPL, część z tych firm w ogóle nie mogłaby go dotknąć ze względów prawnych.

Co sprawdzić?

• Czy wolisz 100 użytkowników, z których 80 to firmy, czy 20, ale wszyscy obowiązkowo open source? Licencja wpływa na ten rozkład.
• Czy framework ma być fundamentem ekosystemu komercyjnego (raczej MIT/Apache), czy raczej „twierdzą wolnego kodu” (raczej GPL)?

Scenariusz: narzędzie serwerowe / SaaS z planem na model biznesowy

Przy projektach serwerowych i SaaS kluczowe pytanie brzmi: czy dopuszczasz sytuację, w której ktoś hostuje twoje rozwiązanie jako usługę, nie oddając nic społeczności?

Opcja 1: maksymalna adopcja, mało ograniczeń

• MIT / Apache 2.0 – każdy może hostować twoje narzędzie jako usługę, budować na nim biznes, sprzedawać instalacje on‑premise.
• Ty możesz zarabiać np. na płatnym hostingu, wsparciu, funkcjach enterprise.

Opcja 2: ochrona przed „wyssaniem” projektu przez duży podmiot

• AGPL – jeśli ktoś hostuje twoją aplikację, musi udostępnić kod swojej wersji użytkownikom.
• Duże firmy często mają polityki „non‑AGPL”; to świadomy trade‑off: ochrona przed pasożytniczym hostingiem vs mniejsza adopcja korporacyjna.

Opcja 3: dual licensing (dla bardziej zaawansowanych)

• Publicznie udostępniasz kod pod np. AGPL,
• firmom, które chcą używać rozwiązania komercyjnie bez obowiązku otwierania kodu, sprzedajesz oddzielną licencję komercyjną.

To model stosowany przez część firm open‑core. Wymaga jednak spójnych umów z kontrybutorami (zwykle przeniesienie praw autorskich lub Contributor License Agreement).

Co sprawdzić?

• Czy planujesz zarabiać głównie na usłudze/hostingu, czy na licencjonowaniu kodu?
• Czy jesteś gotów na mniejszą adopcję w dużych firmach w zamian za mocniejszą ochronę (AGPL/dual licensing)?

Scenariusz: projekt w pracy – kod firmowy w publicznym repozytorium

Jeśli chcesz otworzyć projekt rozwijany w firmie, licencja przestaje być tylko twoją decyzją. W grę wchodzi polityka prawna organizacji.

Krok 1: ustal, kto jest faktycznym właścicielem praw

• Przy umowie o pracę – zwykle firma.
• Przy B2B – zależy od zapisów umowy; często prawa majątkowe przechodzą na klienta.

Krok 2: sprawdź politykę open source w firmie

• Niektóre organizacje mają domyślną licencję (np. Apache 2.0 lub MIT) dla wewnętrznych projektów open source.

Krok 3: uzgodnij z działem prawnym i biznesem, co tak naprawdę wolno wypuścić