Model licencjonowania¶

Cele licencji¶

Licencjonowanie powinno jednocześnie:

zapewnić klientowi lokalne działanie, eksport danych i brak przymusowej chmury;
umożliwić audyt oraz rozwój ekosystemu;
finansować bezpieczeństwo, stabilne wydania i compatibility;
chronić znaki, certyfikację i płatne pakiety;
respektować licencje modeli, zależności, aplikacji i danych;
nie udawać, że jedna licencja pasuje do kodu, wag, treści i usług.

Wybór dokładnej licencji wymaga osobnej decyzji prawnej przed publikacją. Poniżej jest docelowa struktura, nie automatyczny wybór konkretnego tekstu licencji.

Proponowana architektura licencji¶

1. Open-source Core¶

Protokoły, podstawowe Execution Fabric, SDK adapterów, schema, CLI administracyjne i podstawowe UI mogą być dostępne na licencji open-source zatwierdzonej przez organizację OSI. Klient może sam hostować, audytować i odzyskać system. Licencja copyleft albo permissive to decyzja strategiczna: copyleft lepiej chroni wspólne ulepszenia, permissive ułatwia adopcję i integrację komercyjną.

2. Commercial Platform¶

Zaawansowane Control Center, fleet management, enterprise identity, certyfikowane update channels, compliance exports, managed policy packs, high availability i support tooling mogą być komercyjne. Nie powinny blokować odczytu własnych danych ani recovery po wygaśnięciu abonamentu; tryb read-only/export pozostaje dostępny.

3. Pakiety branżowe i pluginy¶

Każdy pakiet ma własną licencję, publishera i support window. Marketplace rozróżnia open, commercial, source-available i proprietary. Manifest wskazuje zależności i pola wykorzystania. Licencja pakietu nie może zmienić twardej polityki core.

4. Modele i wagi¶

Model Registry przechowuje licencję exact artifactu, dozwolone użycie komercyjne, ograniczenia redystrybucji, wymagane notice i źródło. NORBI nie „przelicencjonowuje” modelu. Appliance może zawierać tylko modele, których dystrybucja jest dozwolona; inne pobiera klient z właściwego źródła.

5. Treści i dane klienta¶

Klient zachowuje własność danych wejściowych i wyników w zakresie dozwolonym przez prawo oraz licencje źródeł. Dostawca nie uzyskuje automatycznie prawa do treningu, benchmarku ani telemetrii. Opt-in improvement ma osobną zgodę, zakres, anonimizację i możliwość wycofania.

Jednostki licencyjne¶

Preferowane są proste jednostki:

instalacja/Control Plane;
aktywny zespół lub przedział użytkowników;
oddział/remote site dla pakietu;
connector do systemu zewnętrznego;
poziom wsparcia;
appliance/support, nie token lokalnego modelu.

Licencja per job/token komplikuje offline, prywatność i przewidywalność. Można stosować fair-use limits dla support lub aktualizacji, ale runtime lokalny nie powinien zatrzymywać pracy przez brak połączenia z serwerem licencyjnym.

Offline entitlement¶

Entitlement jest podpisanym dokumentem z product IDs, zakresem, terminem i publicznym kluczem walidacji. Normalna weryfikacja działa offline. Renewal może wymagać okresowego importu pliku, ale grace period zapobiega nagłemu zatrzymaniu. Po wygaśnięciu system nie kasuje danych ani nie blokuje eksportu; płatne funkcje przechodzą do jawnego stanu restricted/read-only zgodnie z umową.

Znaki i certyfikacja¶

Kod może być open-source, a znak NORBI oraz oznaczenia „Certified” pozostają kontrolowane. Fork nie może przedstawiać się jako certyfikowany produkt bez przejścia testów. Partner używa znaku zgodnie z programem i może go utracić po naruszeniu bezpieczeństwa lub support obligations.

Publisher ustala cenę i support, platforma pobiera udział za dystrybucję, signing, test infrastructure i billing. Klient widzi pełną cenę, licencję, data practices, network/account scope oraz capabilities przed zakupem. Zakup nie aktywuje pluginu; instalacja i activation pozostają oddzielne.

Dual licensing¶

Jeżeli core używa copyleft, dual licensing może umożliwić partnerom zamknięte appliance/embedding na licencji komercyjnej. Musi być jasne, które pliki i copyrights są objęte. Contributor agreement albo Developer Certificate of Origin wymaga przemyślanej polityki, aby nie zniechęcać społeczności.

Exit i anty-lock-in¶

Umowa zapewnia eksport: artifacts z metadata/lineage, jobs/workflows, audit w udokumentowanym formacie, memory records, configurations bez sekretów oraz mappings do systemów źródłowych. Sekrety są eksportowane przez platformę sejfu, nie w dumpie NORBI. Po rozwiązaniu umowy klient może utrzymać ostatnią dozwoloną wersję zgodnie z licencją albo przejść do open core.

Ryzyka i decyzje do zamknięcia¶

Do decyzji prawnej należą: rodzaj licencji core, granica modułów komercyjnych, patent policy, contributor policy, użycie znaku, odpowiedzialność za pakiety partnerów, prawo konsumenckie, AI regulations i jurysdykcje. Nie należy publikować kodu ani marketplace bez zamknięcia tych punktów.