Ten artykuł należy do cyklu o akcie o cyberodporności (CRA); kontekst znajdziesz we wprowadzeniu do CRA. Społeczność open source obawiała się, że CRA obciąży obowiązkami pojedynczych twórców. Rozporządzenie wprowadza tu rozróżnienia, które warto rozumieć, zanim wyciągnie się wniosek „CRA zabija open source”.
Czym jest wolne i otwarte oprogramowanie w rozumieniu CRA?
Wolne i otwarte oprogramowanie to oprogramowanie, którego kod źródłowy jest ogólnie dostępny, a licencja zapewnia każdemu prawo do bezpłatnego dostępu, używania, modyfikowania i redystrybucji.
Tak rozumie je motyw 18 rozporządzenia. Takie oprogramowanie jest opracowywane, utrzymywane i dystrybuowane jako ogólnodostępne, w tym za pośrednictwem platform internetowych.
Czy CRA dotyczy open source?
CRA obejmuje wolne i otwarte oprogramowanie tylko wtedy, gdy jest ono udostępniane na rynku w ramach działalności handlowej.
To kluczowe rozgraniczenie. Zgodnie z motywami 17–18 dostarczanie produktów kwalifikujących się jako wolne i otwarte oprogramowanie, które nie są monetyzowane przez ich producentów, nie powinno być uznawane za działalność handlową. Samo finansowe wsparcie projektu przez przedsiębiorstwa, udział w jego rozwoju czy regularne wydawanie nowych wersji nie przesądzają jeszcze o handlowym charakterze. CRA nie ma też zastosowania do osób fizycznych lub prawnych tworzących kod dla wolnego i otwartego oprogramowania poza zakresem swojej odpowiedzialności.
Zagadnienie, do kogo CRA kieruje swoje obowiązki — w tym rozróżnienie między producentem, importerem i dystrybutorem — wyjaśniamy w artykule Podmioty gospodarcze w CRA.
Kim jest opiekun otwartego oprogramowania?
Opiekun otwartego oprogramowania to osoba prawna, która trwale wspiera rozwój wolnego i otwartego oprogramowania przeznaczonego do celów działalności handlowej i odgrywa główną rolę w zapewnieniu jego opłacalności.
Motyw 19 wymienia tu m.in. niektóre fundacje oraz podmioty opracowujące i publikujące open source w kontekście biznesowym. Dla takich podmiotów CRA przewiduje mniej restrykcyjny i dostosowany reżim regulacyjny — nie zrównuje ich z producentami. To istotne rozróżnienie, bo błędna klasyfikacja projektu może skutkować albo nadmiarowym compliance, albo ryzykiem sankcji — podobnie jak w przypadku klasyfikacji produktów na zwykłe, ważne i krytyczne.
Jakie obowiązki ma opiekun otwartego oprogramowania?
Opiekun otwartego oprogramowania wprowadza i dokumentuje w weryfikowalny sposób politykę cyberbezpieczeństwa wspierającą rozwój bezpiecznego produktu.
Obowiązek ten wynika z art. 24 CRA. Jest on celowo lżejszy niż katalog obowiązków producenta z art. 13 — koncentruje się na polityce cyberbezpieczeństwa i wspieraniu bezpiecznego rozwoju oprogramowania, a nie na ocenie zgodności czy oznakowaniu CE. Z naszego doświadczenia fundacje i podmioty utrzymujące popularne biblioteki powinny już dziś udokumentować swoją politykę bezpieczeństwa, bo to ona będzie punktem odniesienia dla organów. Pełny katalog obowiązków producenta, dla porównania, opisujemy w artykule Obowiązki producentów i okres wsparcia (art. 13).
Co z komponentami open source w produkcie komercyjnym?
Jeśli producent wbudowuje komponent open source do swojego monetyzowanego produktu, odpowiada za zgodność całego produktu z CRA.
Wyłączenia po stronie społeczności open source nie zdejmują odpowiedzialności z producenta, który buduje na otwartych komponentach produkt komercyjny. To on wprowadza produkt do obrotu i odpowiada m.in. za postępowanie z podatnościami — także tymi pochodzącymi z wykorzystanych bibliotek. Wracamy do tego w artykule Postępowanie z podatnościami i SBOM.
Warto też pamiętać, że art. 8 KSC nakłada obowiązki w zakresie bezpieczeństwa łańcucha dostaw produktów ICT — co obejmuje również komponenty open source używane przez podmioty objęte ustawą o krajowym systemie cyberbezpieczeństwa.
Jak możemy Ci pomóc?
W Legal Geek pomagamy ustalić, czy Twój projekt open source jest objęty CRA, czy działasz jako opiekun otwartego oprogramowania i jak udokumentować politykę cyberbezpieczeństwa z art. 24. Wspieramy też firmy budujące produkty komercyjne na komponentach open source w ułożeniu odpowiedzialności za podatności.
Co dalej w cyklu?
- Akt o cyberodporności (CRA) — wprowadzenie
- Kogo dotyczy CRA — czym jest „produkt z elementami cyfrowymi”
- Podmioty gospodarcze w CRA
- Postępowanie z podatnościami i SBOM
- Obowiązki producentów i okres wsparcia
