k0nsult.cloud / Common-Source-of-Truth / open-source-stack

Open-source / EU Tech Stack

Rejestr komponentów do budowy suwerennego stosu technologicznego. Każdy element weryfikowany pod względem licencji, SBOM, aktywności projektu, jurysdykcji EU i przenośności.

1. Rejestr komponentów

Warstwa	Rekomendacja (OSS/EU)	Licencja	Uwagi / SBOM
SIEM/SOC	Wazuh, OpenSearch	AGPL-3.0 / SSPL (Elastic)	Wazuh — hostvany EU; SBOM dostępny; uptime 99.9%; detektywny baseline
CTI	OpenCTI, MISP	AGPL-3.0, GPL-3.0	MISP — EU/PL wspierane; SBOM w repo; community-driven threat intel
Case Management	TheHive	AGPL-3.0	TheHive 5.x; SBOM w GitHub releases; workflow automation; EU/PL support
IAM	Keycloak	Apache 2.0	Red Hat; SBOM dostępny; federation (OIDC, SAML); post-kwantowe API-ready
Dokumenty	OnlyOffice, Nextcloud	AGPL-3.0	OnlyOffice CE — self-hosted; SBOM; kolaboracja real-time; NAS-friendly
Repo/CI	Gitea, GitLab CE	MIT (Gitea), SSPL (GitLab)	Gitea — lekka, zero-dependency; SBOM; GitLab CE — pełny pipeline; EU flag
Monitoring	Prometheus, Grafana	AGPL-3.0 (Grafana), Apache 2.0 (Prom)	SBOM w repozytoriach; alerting; multi-cloud; EU deployment opcje
Vector DB	Qdrant, Weaviate	AGPL-3.0, BUSL-1.1 (opcja Apache)	Qdrant — EU infrastruktura; SBOM; RAG-ready; high-dimensional indexing
Baza danych	PostgreSQL	PostgreSQL License (permissive)	De facto standard; SBOM community-driven; ACID compliant; partycje, JSON
Message Queue	NATS, RabbitMQ	Apache 2.0 (NATS), MPL-2.0 (RabbitMQ)	NATS — lightweight, high-performance; RabbitMQ — enterprise-ready; oba z SBOM

2. Kryteria doboru

Licencja permissive/copyleft

Preferuj: MIT, Apache 2.0, GPL-3.0, AGPL-3.0. Unikaj: SSPL dla core, proprietary backdoors, limitowane community clauses.

SBOM referencja

Wymóg: każdy komponent musi mieć jawnie dostępny SBOM w git/releases. Weryfikacja zależności co minimum na level 2 (direct deps + ich deps).

Aktywność projektu commits/mo

Baseline: minimum 4 commit/miesiąc (maintenance) lub backing korporacyjny (Red Hat, CNCF, itp). Dead projects = high-risk.

Jurysdykcja / Host EU flag

Preferuj: pierwotny host/repo w EU, albo aktywna EU-based community. Ci, którzy mogą uruchomić self-hosted bez USA-based cloud.

Przenośność container

Wymóg: dockerizable, helm-ready lub standard deployable (binary). Unikaj vendor lock-in; cloud-agnostic architektura.

Wsparcie community+vendor

Lepsza: backing komercyjny (Red Hat, Canonical, itp) lub mocna community. Gwarancja bug bounty i patchy security.

3. SBOM i licencje

Każdy komponent wchodzący w stos musi:

Posiadać SBOM — Software Bill of Materials w formacie SPDX/CycloneDX w repo lub release artifacts;
Dokumentować zależności — transitive dependencies muszą być znane i akceptowane (nie ślepe skopiowanie całej dependency tree);
Unikać ryzyka licencji — brak GPL-to-proprietary closure, brak embedding GPLv2 w proprietarnym kodzie;
Respektować license compatibility — jeśli mieszasz komponenty, złożenie musi być licencyjnie czyste (np. Apache 2.0 + MIT = OK, ale GPL-3.0 + proprietarny = NIE).

4. Powiązane

› Common-Source-of-Truth/bigtech-sovereignty — mapa zależności od big-tech, strategie suwerenności
› Common-Source-of-Truth/dev-security — praktyki bezpieczeństwa development pipeline
› /research — badania regulacyjne i techniczne

Zastrzeżenie informacyjne. Rejestr ma charakter informacyjny i edukacyjny. Nie stanowi rekomendacji wdrożeniowej, certyfikacji, nie jest opinią jednostki notyfikowanej ani konkluzją prawną (not a certification · not a notified body · not a legal conclusion). Przed wdrożeniem w środowisku produkcyjnym weryfikuj licencje, SBOM i roadmapy każdego komponentu u źródła. Krajowe przepisy bezpieczeństwa i compliance mogą narzucić dodatkowe wymagania.