Licencje i SLA

• Subskrypcja powiązana z kontem użytkownika i urządzeniem (HWID).
• Klucz / uprawnienie wydawane po potwierdzeniu płatności i weryfikacji backendu (Firebase).

• Aplikacja generuje identyfikator na podstawie cech maszyny (m.in. płyta główna, CPU — dokumentacja techniczna); hasz przesyłany do Firebase.
• Powiązanie 1:1 licencji z jednym HWID w opisie produktowym — zmiana komputera wymaga procedury migracji (zdefiniuj w polityce wsparcia).

Proces z architektury PL:

1. Aplikacja identyfikuje urządzenie (HWID).
2. Backend (Firebase + automatyzacja) weryfikuje uprawnienia użytkownika.
3. Backend wydaje uprawnienie / odblokowuje pola (isPaid).
4. Aplikacja aktywuje funkcje (Gemini Pro, pełna analityka itd.).

• Po udanej płatności Stripe → webhook → Make.com / funkcja chmurowa → aktualizacja isPaid dla rekordu powiązanego z użytkownikiem i HWID.

• Limity zapytań (np. 50/mies. w przykładzie z PDF) lub funkcje tylko częściowe (METAR tak, pełna analityka nie).

• Kompilacja (PyInstaller/Nuitka), obfuskacja, ukrywanie konsoli — utrudnienie inżynierii wstecznej.
• SHA-256 przy identyfikatorze — odporność na „ręczne” fałszowanie HWID (wg opisu produktowego).

PDF nie zawiera tabeli P1–P4 — dla komercji należy dodać:

• dostępność usług (Firebase, Stripe, API Gemini),
• okna konserwacji portalu Hangar,
• czasy reakcji wsparcia.

• RODO — minimalizacja danych w logach; jasna retencja black box i ustawień.
• DPA z dostawcami (Google Cloud/Firebase, Stripe, OpenAI jeśli Whisper API, CheckWX).
• Lokalizacja danych — zgodnie z wymaganiami szkół (ATO) i rynków docelowych.