OPEN SOURCE W ŚRODOWISKACH KORPORACYJNYCH
Oprogramowanie open source jest szeroko stosowane w infrastrukturze IT organizacji — od systemów operacyjnych (Linux), przez bazy danych (PostgreSQL, MariaDB), po platformy kontenerowe (Kubernetes) i narzędzia monitoringu (Prometheus, Zabbix). Używanie oprogramowania open source w celach komercyjnych wymaga rozumienia ograniczeń licencyjnych.
Zastrzeżenie technologiczne
Articles published on this website summarize publicly available information, industry research and educational materials.
TYPY LICENCJI OPEN SOURCE
| Licencja | Typ | Obowiązek ujawnienia kodu | Użycie komercyjne |
|---|---|---|---|
| MIT | Permisywna | Nie | Tak, bez ograniczeń |
| Apache 2.0 | Permisywna | Nie | Tak; wymaga zachowania NOTICE |
| BSD 2/3-Clause | Permisywna | Nie | Tak, bez ograniczeń |
| GPL v2 | Copyleft silny | Tak (przy dystrybucji) | Tak; kod pochodny musi być GPL |
| GPL v3 | Copyleft silny | Tak (przy dystrybucji) | Tak; dodatkowe wymagania patentowe |
| LGPL | Copyleft słaby | Tylko modyfikacje biblioteki | Tak; aplikacje mogą być proprietary |
| AGPL v3 | Copyleft sieciowy | Tak; nawet użycie przez sieć | Ograniczone dla SaaS z modyfikacjami |
| SSPL | Source-available | Tak; cały stack obsługowy | Bardzo ograniczone dla chmury |
Uwaga: SSPL i BSL (Business Source License) nie są akceptowane przez OSI jako licencje open source, choć kod jest dostępny publicznie.
MODELE WSPARCIA KOMERCYJNEGO
Dla oprogramowania open source w środowiskach produkcyjnych dostępne są modele wsparcia komercyjnego:
- Enterprise edition: producent oferuje wersję z dodatkowymi funkcjami i wsparciem (Red Hat Enterprise Linux, SUSE, Canonical Ubuntu Pro)
- Support contract: umowa wsparcia bez dodatkowych funkcji (np. wsparcie community PostgreSQL przez firmy trzecie)
- Managed service: dostawca chmury zarządza oprogramowaniem open source (AWS RDS for MySQL, Azure Database for PostgreSQL)
| Projekt | Dostawca wsparcia | Model |
|---|---|---|
| Linux (RHEL) | Red Hat | Enterprise edition + support |
| PostgreSQL | EnterpriseDB, Percona | Support contract + managed |
| Kubernetes | Red Hat OpenShift, Rancher | Enterprise distribution |
| Elasticsearch | Elastic (Elastic Cloud) | SaaS + enterprise features |
ZARZĄDZANIE ZALEŻNOŚCIAMI OPEN SOURCE
Większość aplikacji enterprise korzysta z dziesiątek do setek bibliotek open source. Zarządzanie nimi obejmuje:
- Software Composition Analysis (SCA): automatyczne skanowanie zależności pod kątem licencji i podatności (np. OWASP Dependency-Check, FOSSA, Snyk)
- SBOM (Software Bill of Materials): ustrukturyzowany spis komponentów oprogramowania — format SPDX lub CycloneDX
- Polityka licencyjna: lista zaakceptowanych i zabronionych licencji, zdefiniowana przez dział prawny organizacji
- Vulnerability management: monitorowanie CVE (Common Vulnerabilities and Exposures) i patch management
RYZYKA LICENCYJNE
GPL contamination — ryzyko dla oprogramowania proprietary
Jeśli oprogramowanie proprietary łączy się statycznie z biblioteką GPL (GPL v2 lub v3), cały produkt może być objęty wymogiem ujawnienia kodu źródłowego. Ryzyko minimalizują: (1) linkowanie dynamiczne z bibliotekami LGPL zamiast GPL, (2) izolacja komponentów GPL w osobnych procesach komunikujących się przez API/IPC, (3) przegląd licencji wszystkich zależności przez dział prawny.
License sprawl — proliferacja różnych licencji
Duże projekty mogą używać dziesiątek licencji. Automatyczne narzędzia SCA (FOSSA, Snyk, Black Duck) generują raporty zgodności. Kluczowe: (1) polityka zabraniająca AGPL/GPL w aplikacjach SaaS bez dedykowanego przeglądu prawnego, (2) whitelist permisywnych licencji (MIT, Apache 2.0, BSD) jako bezpiecznie akceptowalnych, (3) obowiązkowy przegląd licencji przy dodawaniu nowych zależności.
NAJCZĘSTSZE PYTANIA
Czy używanie PostgreSQL wymaga opłat licencyjnych?
PostgreSQL jest licencjonowany na PostgreSQL License — licencji permisywnej podobnej do BSD. Użycie PostgreSQL w dowolnym celu (komercyjnym, non-profit, wewnętrznym) jest bezpłatne. Opłaty mogą wynikać z zakupu komercyjnego wsparcia od firm trzecich (EnterpriseDB, Percona, Crunchy Data) lub korzystania z managed service w chmurze (AWS RDS, Azure Database for PostgreSQL).
Co zmienia przejście Elasticsearch / Redis na SSPL?
Elasticsearch (od 7.11) i Redis (od 7.4 dla modułów) zmieniły licencję z Apache 2.0/BSD na SSPL lub RSAL. SSPL wymaga ujawnienia kodu całego "service stack" jeśli oprogramowanie jest oferowane jako managed service przez sieć — dotyczy przede wszystkim dostawców chmury. Organizacje używające tych narzędzi wewnętrznie, bez oferowania ich jako usługi, zazwyczaj nie są objęte tym ograniczeniem. Zalecana konsultacja z działem prawnym przed aktualizacją do wersji objętej SSPL.