Language of document : ECLI:EU:C:2021:193

OPINIA RZECZNIKA GENERALNEGO

MACIEJA SZPUNARA

przedstawiona w dniu 10 marca 2021 r.(1)

Sprawa C13/20

Top System SA

przeciwko

État belge

[wniosek o wydanie orzeczenia w trybie prejudycjalnym złożony przez cour d’appel de Bruxelles (sąd apelacyjny w Brukseli, Belgia)]

Odesłanie prejudycjalne – Prawo autorskie i prawa pokrewne – Dyrektywa 91/250/EWG – Ochrona prawna programów komputerowych – Artykuł 5 ust. 1 – Wyjątki od czynności zastrzeżonych – Czynności konieczne do poprawienia błędów – Artykuł 6 – Dekompilacja programu komputerowego






 Wprowadzenie

1.        W ramach niniejszej sprawy Trybunał ma ponownie możliwość pochylić się nad specyfiką ochrony prawnej programów komputerowych. O ile bowiem zarówno na gruncie prawa Unii(2), jak i prawa międzynarodowego(3) uznaje się, że programy komputerowe są chronione prawem autorskim jak utwory literackie, różnią się one jednak od nich pod wieloma względami. Ich szczególny charakter, jako przedmiotów ochrony, odzwierciedla się w mechanizmach tej ochrony, które na tyle różnią się od zasad ogólnych prawa autorskiego, że niektórzy autorzy mówią o de facto systemie ochrony sui generis(4).

2.        Przede wszystkim programy komputerowe nie tylko mają cel użytkowy, ale także użyteczność ta ma bardzo szczególny charakter: sprawia, że komputery działają. Program taki składa się bowiem z zespołu instrukcji, które, wykonywane przez komputer, pozwalają mu na realizację pewnych zadań(5). Wynika z tego, że – w odróżnieniu od wszystkich innych kategorii przedmiotów chronionych prawem autorskim – programy komputerowe nie są przeznaczone do użytku poprzez ludzką percepcję. Pierwsze programy komputerowe były zresztą uznawane za dodatek do samej maszyny i dopiero stopniowo software zyskał swój niezależny charakter w stosunku do hardware(6).

3.        Co prawda w pewnych sytuacjach, które mogą być istotne z punktu widzenia prawa autorskiego, zapoznanie się z programem komputerowym przez człowieka może być użyteczne, na przykład w celu stworzenia programu konkurencyjnego lub uzupełniającego, niemniej co do zasady to komputer, a nie użytkownik, „zapoznaje się” z programem i go wykonuje. Użyteczność dla użytkownika tkwi zatem nie w samym programie komputerowym, lecz w funkcjach, które program ów pozwala wdrożyć komputerowi. Zbliża to programy komputerowe bardziej do wynalazków chronionych patentem niż do utworów „klasycznie” chronionych prawem autorskim.

4.        Z tej pierwszej cechy charakterystycznej programów komputerowych wynika druga, a mianowicie sposób ich wyrażania. Skoro bowiem program komputerowy nie jest przeznaczony dla percepcji ludzkiej, lecz do odczytu przez maszynę, to powinien zostać wyrażony w sposób zrozumiały dla tej maszyny. Tym środkiem wyrażenia jest kod binarny będący „zapisem”, który zadowala się dwoma znakami zazwyczaj przedstawianymi jako 0 i 1, przy czym, znowu, to przedstawienie jest umowne na użytek człowieka. Procesor komputera „odczytuje” te znaki jako różne wartości napięcia elektrycznego.

5.        O ile programy dla tak zwanych komputerów „pierwszej generacji” były często kodowane bezpośrednio w formie binarnej, o tyle współczesne programy są zbyt złożone, by móc je tworzyć, a nawet czytać, w tej formie. Istnieją zatem języki programowania, zwane „językami wysokiego poziomu”, które zawierają różne instrukcje dla komputerów, zakodowane w formie wyrażenia zbliżonej do języka naturalnego, a zatem czytelne dla człowieka i zrozumiałe dla osób znających te języki. Program komputerowy stworzony w takim języku programowania stanowi jego „kod źródłowy”. Ów kod źródłowy jest następnie kompilowany za pomocą specjalnego programu zwanego „kompilatorem” do postaci „kodu obiektowego” lub „kodu maszynowego”, czyli form zrozumiałych i wykonalnych dla komputera(7).

6.        Niemniej w praktyce programy komputerowe są zazwyczaj komunikowane użytkownikom jedynie w formie kodu obiektowego. Pozwala to na korzystanie z tych programów poprzez wykonywanie ich na komputerze, ale nie pozwala na zapoznanie się z ich treścią, co jest niezwykłe w przypadku utworu chronionego prawem autorskim. Kwestia, czy i, ewentualnie, w jakim zakresie użytkownik programu komputerowego może dokonać translacji kodu obiektowego owego programu na kod źródłowy (taką operację nazywa się „dekompilacją”) w celu zapoznania się z ich treścią, jest właśnie sednem niniejszej sprawy.

7.        Kwestia ta prowadzi do trzeciej cechy charakterystycznej programów komputerowych jako przedmiotów ochrony prawem autorskim: związku między tą ochroną a klasyczną zasadą prawa autorskiego, zgodnie z którą prawo to nie chroni idei, lecz wyłącznie formy ich wyrażenia. Zasada ta odzwierciedla założenie prawa autorskiego, które polega na przyczynianiu się nie tylko do tworzenia, chroniąc kreatywne dzieło autorów, ale także do rozpowszechniania idei i do dostępu do nich, zapobiegając ich monopolizacji, dzięki czemu idee te mogą stanowić źródło innych dzieł twórczych. Natomiast okoliczność, że wyrażenie programów komputerowych w formie, w jakiej są zazwyczaj ujawniane, jest niedostrzegalne dla człowieka, pozwala ukryć idee leżące u podstaw tych programów, przyznając tym samym ich autorom ochronę przekraczającą to, co jest uzasadnione celami prawa autorskiego(8). Programy komputerowe stanowią zatem jedyną kategorię chronionych utworów, w odniesieniu do których dostęp do leżących u podstaw idei poprzez zwykłą analizę za pomocą zmysłów niewymagającą czynności podlegających monopolowi autora jest niemożliwy(9).

8.        Te uwagi wstępne wydawały mi się konieczne do umiejscowienia niniejszej sprawy w szczególnym kontekście ochrony programów komputerowych przez prawo autorskie. Kluczowy problem tej sprawy dotyczący prawa do dekompilacji programu nie pojawia się bowiem wobec żadnej innej kategorii chronionych przedmiotów z tej prostej przyczyny, że operacja dekompilacji ani żadna inna analogiczna operacja nie jest konieczna, aby dotrzeć do treści utworów należących do kategorii innych niż programy komputerowe.

 Ramy prawne

 Prawo Unii

9.        Artykuł 1 dyrektywy Rady 91/250/EWG z dnia 14 maja 1991 r. w sprawie ochrony prawnej programów komputerowych(10) stanowi:

„1.      Zgodnie z przepisami niniejszej dyrektywy państwa członkowskie chronią prawem autorskim programy komputerowe w taki sposób jak [jako] dzieła literackie w rozumieniu Konwencji berneńskiej o ochronie dzieł literackich i artystycznych. Do celów niniejszej dyrektywy pojęcie »programy komputerowe« obejmuje ich przygotowawczy materiał projektowy.

2.      Zgodnie z niniejszą dyrektywą ochronie podlega każda forma wyrażenia programu komputerowego. Koncepcje i zasady, na których opierają się wszystkie elementy programu komputerowego, włącznie z tymi, na których opierają się ich interfejsy, nie podlegają ochronie prawa autorskiego na podstawie niniejszej dyrektywy.

3.      Program komputerowy podlega ochronie, jeżeli jest oryginalny w takim rozumieniu, że jest własną intelektualną twórczością jego autora. Żadnych innych kryteriów nie stosuje się przy dokonywaniu jego kwalifikacji do ochrony”.

10.      Zgodnie z art. 4 lit. a) i b) tej dyrektywy:

„Z zastrzeżeniem przepisów art. 5 i 6 prawa wyłączne uprawnionego w rozumieniu art. 2 obejmują prawo do wykonywania lub zezwalania na:

a)      trwałe lub czasowe powielanie programu komputerowego jakimikolwiek środkami i w jakiejkolwiek formie, częściowo lub w całości. W zakresie, w jakim ładowanie, wyświetlanie, uruchamianie, transmitowanie lub przechowywanie programu komputerowego wymaga takiego powielenia, takie czynności wymagają uzyskania zezwolenia uprawnionego;

b)      translację, adaptację, porządkowanie i jakiekolwiek inne modyfikacje programu komputerowego i powielenie wyników tych działań bez uszczerbku dla praw osoby, która modyfikuje program”.

11.      Zgodnie z art. 5 ust. 1 rzeczonej dyrektywy:

„W braku szczególnych przepisów umownych czynności określone w art. 4 lit. a) i b) nie wymagają zezwolenia uprawnionego, jeśli są konieczne do użycia [używania] programu przez uprawnionego nabywcę zgodnie z zamierzonym celem [jego przeznaczeniem], włącznie z poprawianiem błędów”.

12.      Wreszcie art. 6 tej dyrektywy, zatytułowany „Dekompilacja”, stanowi:

„1.      Zezwolenie uprawnionego nie jest wymagane, jeśli powielanie kodu i translacja jego form w rozumieniu art. 4 lit. a) i b) jest niezbędne do otrzymania informacji koniecznych do osiągnięcia interoperacyjności niezależnie stworzonego programu komputerowego z innymi programami, z zastrzeżeniem spełnienia następujących warunków:

a)      czynności te są wykonywane przez licencjobiorcę lub osobę mającą prawo do używania kopii programu, lub upoważnioną osobę działającą w ich imieniu;

b)      informacje konieczne do osiągnięcia interoperacyjności nie były uprzednio łatwo dostępne dla osób określonych w lit. a);

[oraz]

c)      czynności te są ograniczone do tych części oryginalnego programu, które są niezbędne dla osiągnięcia interoperacyjności.

2.      Przepisy ust. 1 nie upoważniają do tego, by informacje uzyskane na ich podstawie były:

a)      wykorzystane do celów innych niż osiągnięcie interoperacyjności niezależnie od siebie stworzonych programów komputerowych;

b)      przekazywane osobom trzecim, z wyjątkiem [sytuacji] kiedy są konieczne dla interoperacyjności niezależnie od siebie stworzonych programów;

lub

c)      wykorzystane w celu rozwijania, produkcji lub obrotu programami komputerowymi znacznie podobnymi w swoim wyrazie lub do jakichkolwiek innych czynności naruszających prawo autorskie.

3.      Zgodnie z przepisami Konwencji berneńskiej o ochronie dzieł literackich i artystycznych niniejszy artykuł nie może być interpretowany tak, aby możliwe było jego stosowanie w sposób, który bez uzasadnienia narusza słuszne interesy uprawnionego lub pozostaje w sprzeczności z normalnym korzystaniem z programu komputerowego”.

13.      Dyrektywa 91/250 została uchylona, ze skutkiem od dnia 24 maja 2009 r., na podstawie art. 10 dyrektywy 2009/24/WE(11). Niemniej okoliczności faktyczne będące przedmiotem postępowania głównego podlegają, ratione temporis, dyrektywie 91/250. Ponadto mające zastosowanie przepisy tej dyrektywy nie zostały zmienione.

 Prawo belgijskie

14.      Artykuły 4, 5 i 6 dyrektywy 91/250 zostały transponowane do prawa belgijskiego w zasadniczo dosłownym brzmieniu w drodze art. 5, 6 i 7 loi du 30 juin 1994 transposant en droit belge la directive 91/250/CEE du Conseil du 14 mai 1991 concernant la protection juridique des programmes d’ordinateur (ustawy z dnia 30 czerwca 1994 r. transponującej do prawa belgijskiego dyrektywę Rady 91/250/EWG z dnia 14 maja 1991 r. w sprawie ochrony prawnej programów komputerowych)(12).

 Okoliczności faktyczne, postępowanie i pytania prejudycjalne

15.      Selor (urząd ds. doboru kadr administracji federalnej) jest belgijską instytucją publiczną, która została włączona do federalnej służby publicznej ds. strategii i obsługi odpowiadającej za dobór i dysponowanie przyszłymi współpracownikami różnych służb administracji publicznej. État belge (państwo belgijskie) zostało wskazane jako strona w postępowaniu głównym.

16.      Spółka Top System SA, będąca spółką prawa belgijskiego, rozwija oprogramowanie komputerowe i świadczy na rzecz swoich klientów różne usługi informatyczne. Od wielu lat współpracuje z Selorem.

17.      Top System jest między innymi autorem szeregu aplikacji opracowanych na zamówienie Selora, w tym „SWA” (Selor Web Access) zwanej też „eRecruiting”. Aplikacje te składają się z jednej strony z elementów zaprojektowanych „na miarę”, w odpowiedzi na szczególne potrzeby i wymagania Selora, i z drugiej strony elementów pozyskanych przez Top System z „TSF” (Top System Framework) – programu, którego spółka ta jest autorem. Jednym z elementów TSF jest „DGE” (DataGridEditor). Selor posiada licencję na używanie aplikacji opracowanych przez Top System.

18.      W dniu 6 lutego 2008 r. Selor i Top System zawarli umowy o świadczenie usług; przedmiotem jednej z tych umów była instalacja i konfiguracja nowego środowiska informatycznego oraz zintegrowanie i migracja źródeł aplikacji Selora do tego nowego środowiska. W okresie od czerwca do października 2008 r. wymieniono wiadomości elektroniczne w przedmiocie problemów dotykających niektóre aplikacje, w szczególności aplikację eRecruiting.

19.      Doszło do sporu przed sądami gospodarczymi w Brukseli (Belgia). W szczególności w dniu 6 lipca 2009 r. Top System wystąpił do tribunal de commerce de Bruxelles (sądu handlowego w Brukseli, Belgia) z powództwem przeciwko Selorowi i État belge (państwu belgijskiemu) mającym na celu zasadniczo stwierdzenie dokonanej przez Selora dekompilacji programu ramowego TSF. Top System podniósł w szczególności naruszenie jego praw wyłącznych do TSF i zażądał nakazania Selorowi i État belge (państwu belgijskiemu) zapłaty odszkodowania. Sprawa została przekazana tribunal de première instance de Bruxelles (sądowi pierwszej instancji w Brukseli, Belgia), który uznał żądanie o odszkodowanie za bezpodstawne.

20.      Top System odwołał się od tego wyroku do sądu odsyłającego. Przed tym sądem Selor przyznał, że dokonał dekompilacji pewnej części TSF – której funkcje zostały zintegrowane w aplikacjach Selora – w celu wyłączenia wadliwej funkcji. Selor twierdzi, że był uprawniony do dokonania tej dekompilacji w pierwszej kolejności na mocy umowy – twierdzenie to sąd odsyłający oddala jako bezpodstawne – i w drugiej kolejności na mocy przepisów transponujących art. 5 ust. 1 dyrektywy 91/250. Natomiast Top System, kwestionując istnienie jakichkolwiek błędów w swoich programach, twierdzi, że dekompilacja programu komputerowego jest dozwolona poza ramami umownymi jedynie na mocy art. 6 owej dyrektywy i nie do celów poprawienia błędów, lecz do celów interoperacyjności niezależnych programów.

21.      W tych okolicznościach cour d’appel de Bruxelles (sąd apelacyjny w Brukseli, Belgia) postanowił zawiesić postępowanie i zwrócić się do Trybunału z następującymi pytaniami prejudycjalnymi:

„1)      Czy art. 5 ust. 1 dyrektywy [91/250] należy interpretować w ten sposób, że zezwala on uprawnionemu nabywcy programu komputerowego na dokonanie dekompilacji całości lub części tego programu, jeżeli dekompilacja ta jest konieczna, aby pozwolić mu na poprawienie błędów mających wpływ na funkcjonowanie tego programu, również w przypadku, gdy poprawka ta polega na wyłączeniu funkcji mającej wpływ na poprawne funkcjonowanie aplikacji, której program ten jest częścią?

2)      W przypadku udzielenia odpowiedzi twierdzącej na pytanie pierwsze – czy ponadto muszą zostać spełnione warunki określone w art. 6 dyrektywy [91/250] lub jakieś inne warunki?”.

22.      Wniosek o wydanie orzeczenia w trybie prejudycjalnym wpłynął do Trybunału w dniu 14 stycznia 2020 r. Uwagi na piśmie przedstawiły strony postępowania głównego i Komisja Europejska. Ze względu na obecne okoliczności związane z kryzysem sanitarnym Trybunał postanowił odwołać rozprawę. Na pytania postawione przez Trybunał strony udzieliły odpowiedzi na piśmie.

 Analiza

 W przedmiocie pierwszego pytania prejudycjalnego

23.      Poprzez pierwsze pytanie prejudycjalne sąd odsyłający zmierza w istocie do ustalenia, czy art. 5 ust. 1 dyrektywy 91/250 zezwala uprawnionemu nabywcy programu komputerowego na dokonanie dekompilacji tego programu, jeżeli dekompilacja ta jest konieczna do poprawienia błędów mających wpływ na funkcjonalność programu. Z postanowienia odsyłającego wynika, że wątpliwości tego sądu dotyczą w szczególności argumentu wysuniętego przez Top System, zgodnie z którym dekompilacja programu komputerowego jest dozwolona jedynie w sytuacji przewidzianej w art. 6 owej dyrektywy(13), a zatem jest wykluczona w sytuacjach objętych art. 5 rzeczonej dyrektywy. Odpowiedź na to pytanie wymaga zbadania prerogatyw uprawnionego z tytułu praw autorskich do danego programu komputerowego wobec uprawnionego nabywcy tego programu.

 W przedmiocie związku między uprawnionym a uprawnionym nabywcą programu komputerowego

24.      Przede wszystkim art. 4 dyrektywy 91/250 przewiduje prawa wyłączne uprawnionego z tytułu praw autorskich, o charakterze zapobiegawczym(14), do jego programu komputerowego. Pierwszym z tych praw jest prawo do powielania, które zostało określone w sposób bardzo szeroki, ponieważ obejmuje nie tylko wszelką formę powielania, trwałą lub czasową, ale także czynności powielania konieczne do korzystania z programu. Tymczasem, w przeciwieństwie do innych kategorii utworów, w każdym razie tych dystrybuowanych na ich własnym nośniku, program komputerowy, aby można było z niego korzystać, zawsze wymaga powielenia, nawet jedynie czasowego, do pamięci komputera. W odniesieniu do programów komputerowych prawa wyłączne uprawnionego stanowią zatem głębszą ingerencję w sferę prywatną użytkownika niż w przypadku innych kategorii przedmiotów ochrony, ponieważ wymagają one de facto zezwolenia tego uprawnionego nawet do samego korzystania z programu. Dyrektywa 91/250 nie zawiera zaś wyjątków równoważnych z wyjątkami przewidzianymi w art. 5 ust. 1 i art. 5 ust. 2 lit. b) dyrektywy 2001/29/WE(15).

25.      Następnie dyrektywa 91/250 poddaje monopolowi uprawnionego cały szereg czynności związanych z modyfikacjami programu komputerowego, w tym „powielenie wyników tych działań”. Także w tym przypadku prawa uprawnionego są szczególnie szerokie w stosunku do klasycznych rozwiązań prawa autorskiego, zgodnie z którymi modyfikacje utworu mogą ewentualnie wejść do sfery wyłącznej autora jedynie w drodze publicznego ujawnienia wyniku modyfikacji.

26.      Tym samym monopol uprawnionego z tytułu praw autorskich do programu komputerowego obejmuje nie tylko klasyczne czynności korzystania z utworu na gruncie prawa autorskiego, ale także korzystanie z tego utworu w sferze prywatnej użytkownika.

27.      Wreszcie dyrektywa 91/250 przewiduje prawo do dystrybucji, którego niniejsza sprawa nie dotyczy.

28.      To szerokie określenie prerogatyw uprawnionego jest jednak ograniczone w odniesieniu do jego relacji z uprawnionym nabywcą jego programu komputerowego. Zgodnie ze zdaniem wprowadzającym art. 4 dyrektywy 91/250 prawa wyłączne przyznaje się uprawnionemu „z zastrzeżeniem art. 5 i 6” tej dyrektywy. Tym samym, nawet jeśli artykuły te zostały przedstawione jako wyjątki od praw wyłącznych(16), w rzeczywistości stanowią one ograniczenie nieodłącznie związane z tymi prawami. Zgodnie z art. 5 ust. 1 rzeczonej dyrektywy czynności określone w art. 4 lit. a) i b) – czyli powielanie i jakiekolwiek inne modyfikacje programu – nie wymagają zezwolenia uprawnionego, jeśli są konieczne do używania programu przez uprawnionego nabywcę, w tym do poprawiania błędów.

29.      Artykuł 5 ust. 1 dyrektywy 91/250 zawiera niemniej własne zastrzeżenie, polegające na tym, że czynności uprawnionego nabywcy danego programu komputerowego wykonywane w ramach używania tego programu nie podlegają monopolowi uprawnionego „w braku szczególnych przepisów umownych”.

30.      Podsumowując – rzeczywistym rezultatem art. 4 lit. a) i b) dyrektywy 91/250 jest umożliwienie uprawnionemu z tytułu praw autorskich do programu komputerowego, w ramach jego relacji z uprawnionym nabywcą jego programu, określenia w drodze umowy, w szczegółowy sposób, warunków korzystania z tego programu przez owego nabywcę. Natomiast w braku takich postanowień umownych nabywca może dokonać czynności podlegających co do zasady monopolowi uprawnionego, pod warunkiem że pozostanie w ramach korzystania z odnośnego programu zgodnie z jego przeznaczeniem, co obejmuje także poprawianie błędów.

31.      Ponadto prawdą jest, że zgodnie z motywem siedemnastym dyrektywy 91/250 „ładowanie i uruchamianie konieczne do użycia kopii programu, która została zgodnie z prawem nabyta, oraz poprawianie jej błędów nie może być umownie zabronione”. Należy jednak stwierdzić, że analiza części normatywnej tej dyrektywy prowadzi do przeciwnych wniosków. Rzeczona dyrektywa nie tylko nie zawiera bowiem żadnego wyraźnego przepisu odpowiadającemu temu motywowi, ale nawet nie dopuszcza ona wykładni, która by szła w tym kierunku. Jedyny przepis dyrektywy 91/250, który można by wziąć pod uwagę, czyli art. 5 ust. 1, traktuje w ten sam sposób wszystkie czynności wymienione w art. 4 lit. a) i b) owej dyrektywy. Przepis ten nie pozostawia zatem żadnego marginesu dla interpretacji pozwalającej usunąć pewne czynności, a mianowicie ładowanie i uruchamianie programu, a także poprawianie błędów z zakresu zastrzeżenia dotyczącego szczególnych przepisów umownych, o których mowa w art. 5 ust. 1 wspomnianej dyrektywy. Tymczasem, chociaż motywy dyrektywy mogą wskazywać kierunek wykładni przepisów odzwierciedlających te motywy, nie mają one jednak wartości normatywnej pozwalającej im zastąpić nieistniejące przepisy lub prowadzić do wykładni contra legem.

32.      Jest tak tym bardziej, że, jak wyraźnie stanowi art. 9 ust. 1 zdanie drugie dyrektywy 91/250, wszystkie przepisy umowne sprzeczne z art. 6 oraz z art. 5 ust. 2 i 3 tej dyrektywy są nieważne. Niewymienienie tam przez prawodawcę Unii art. 5 ust. 1 rzeczonej dyrektywy należy zatem uznać za zamierzone.

33.      Jak twierdzi Komisja w odpowiedzi na pytanie postawione przez Trybunał w tej kwestii, jest możliwe, że motyw siedemnasty dyrektywy 91/250 odzwierciedla brzmienie pierwotnego projektu tej dyrektywy(17). Projekt ten, w swym art. 5 ust. 1, odróżniał bowiem umowy licencyjne negocjowane między stronami od tak zwanych „umów adhezyjnych”, w odniesieniu do których swoboda umów nabywcy programu komputerowego ograniczała się do decyzji o zawarciu lub niezawarciu danej umowy. Zdaniem Komisji wskazany w motywie siedemnastym zakaz dotyczy wyłącznie tej drugiej kategorii umów. Niemniej ostatecznie przyjęty tekst art. 5 ust. 1 dyrektywy 91/250 nie dokonuje tego rozróżnienia. Dlatego też postanowienia każdej umowy licencyjnej na używanie programu komputerowego mogą regulować wszystkie aspekty tego używania, w tym ładowanie i uruchamianie, a także poprawianie błędów.

34.      Nie jest to aż tak nieracjonalne, jak wydaje się to na pierwszy rzut oka. Oczywiście trudno jest wyobrazić sobie licencję na używanie programu, która całkowicie zakazywałaby tego używania. Używanie programu można jednak ograniczyć na przykład w odniesieniu do liczby komputerów, na których program ten można zainstalować i go używać, tak że ładowanie i uruchamianie programu na dodatkowych komputerach, w tym przez tego samego nabywcę(18), byłoby zakazane. Jest tak tym bardziej w przypadku poprawiania błędów, które zazwyczaj nie zalicza się do czynności koniecznych do używania programu komputerowego zgodnie z jego przeznaczeniem. Poprawianie błędów można zatem zastrzec dla uprawnionego z tytułu praw autorskich, nie naruszając przy tym spójności licencji na używanie programu(19).

35.      Rozumiem zatem ustalenie dokonane przez Trybunał w wyroku SAS Institute(20), zgodnie z którym, jak wynika z motywu siedemnastego dyrektywy 91/250, ładowanie i uruchamianie konieczne do użycia programu komputerowego nie może być umownie zabronione, w ten sposób, że licencja na używanie całkowicie zakazująca czynności koniecznych do tego użycia byłaby wewnętrznie sprzeczna(21). Natomiast ustalenia tego nie można moim zdaniem interpretować jako przyznającego autonomiczną wartość normatywną temu motywowi.

36.      W odniesieniu, w szczególności, do poprawiania błędów wykładnia, zgodnie z którą nie można byłoby umownie wykluczyć uprawnienia nabywcy programu do poprawiania błędów, prowadziłaby do zaburzenia równowagi, ze szkodą dla uprawnionych z tytułu praw autorskich. Ów brak równowagi byłby tym znaczniejszy, gdyby Trybunał przyjął moją propozycję odpowiedzi w niniejszej sprawie i stwierdził, że nabywcy należy przyznać uprawnienie do przeprowadzenia dekompilacji programu w celu dokonania tej poprawki bez uprzedniego ubiegania się o zezwolenie uprawnionego. Pozbawiłoby to bowiem tego uprawnionego wszelkiej możliwości sprzeciwienia się takiej dekompilacji(22).

37.      Kwestia ta nie wydaje się jednak mieć znaczenia w okolicznościach takich jak rozpatrywane w postępowaniu głównym. Z akt sprawy wynika bowiem, że umowa zawarta między Top System i Selorem nie zawiera żadnego postanowienia zakazującego Selorowi poprawiania błędów w programach komputerowych spółki Top System, a w każdym razie spółka ta nie powołuje się na takie postanowienia przed sądem odsyłającym. Tym samym, zgodnie z art. 5 ust. 1 dyrektywy 91/250, Selor jest uprawniony do poprawienia błędów w odnośnych programach.

38.      Należy zatem dokonać teraz analizy kwestii, czy przepis ten pozwala nabywcy programu komputerowego na przeprowadzenie dekompilacji tego programu w celu poprawienia w nim błędów. Rozpocznę tę analizę pewnymi wyjaśnieniami dotyczącymi pojęcia „dekompilacji”.

 W przedmiocie pojęcia dekompilacji

39.      Jak już wskazałem(23), program komputerowy napisany przez programistę w języku programowania zrozumiałym dla człowieka musi następnie zostać przekształcony w formę zrozumiałą dla komputera, czyli na język maszynowy. Operację tę wykonuje się za pomocą specjalnego programu zwanego kompilatorem i nazywa się ją kompilacją. Postać programu w języku programowania zwana jest kodem źródłowym, a postać w języku maszynowym – kodem obiektowym. Nie chodzi tutaj o zwykłą transkrypcję programu w kodzie binarnym, lecz o translację instrukcji sformułowanych w sposób funkcyjny i abstrakcyjny w kodzie źródłowym na konkretne instrukcje dla komponentów procesora komputera o danej architekturze. Niektóre programy napisane w językach programowania bardziej zbliżonych do języka maszynowego (tak zwanych językach niskiego poziomu) nie są kompilowane, lecz poddawane asemblacji. Jest to operacja analogiczna do kompilacji, a skoro dyrektywa 91/250 nie rozróżnia tych dwóch operacji, należy uznać, że programy kompilowane i programy poddane asemblacji należy z punktu widzenia prawa traktować w ten sam sposób.

40.      Programy komputerowe są zasadniczo rozpowszechniane w formie kodu obiektowego. Kod obiektowy nie jest zaś zrozumiały dla człowieka. Dlatego też uprawniony nabywca programu komputerowego, w zakresie, w jakim chce zaznajomić się z treścią programu i dokonać w nim zmian, w szczególności w celu poprawienia błędów, musi dokonać modyfikacji kodu obiektowego, którym dysponuje, do formy programu zrozumiałej dla człowieka, czyli sformułowanej w języku programowania. Operacja ta, zwana dekompilacją, polega na powieleniu, na podstawie instrukcji dla procesora wpisanych w kod obiektowy, instrukcji funkcyjnych programu. Dekompilacja jest zatem rodzajem inżynierii wstecznej (reverse engineering), czyli stosowaną do programów komputerowych operacją, w drodze której udaje się odkryć konstrukcję złożonego narzędzia, wychodząc od produktu końcowego.

41.      Dekompilacja nie umożliwia jednak powielenia oryginalnego kodu źródłowego danego programu komputerowego. Przy procesie kompilacji traci się bowiem niektóre informacje zawarte w kodzie źródłowym, które nie są niezbędne dla funkcjonowania procesora komputera, i proces dekompilacji nie umożliwia ich odzyskania. Ponadto ten sam kod źródłowy może dać różne rezultaty po kompilacji w zależności od parametrów kompilatora. Wynik dekompilacji stanowi więc trzecią wersję programu, często nazywaną quasi-kodem źródłowym. Faktem pozostaje jednak, że tak zdekompilowany program można ponownie skompilować do działającego kodu obiektowego.

 W przedmiocie dekompilacji jako elementu monopolu autora

42.      Zapytane o kwestię, czy dekompilacja programu komputerowego jest objęta prawami wyłącznymi autora określonymi w art. 4 lit. a) i b) dyrektywy 91/250, zainteresowane strony, które przedstawiły uwagi na piśmie w niniejszej sprawie, jednogłośnie odpowiedziały w sposób twierdzący. Komisja przedstawiła szczegółową odpowiedź w tym zakresie. Jej zdaniem w istocie, chociaż dekompilacja jako taka nie została bezpośrednio wskazana w tych przepisach, szereg czynności, które razem składają się na proces dekompilacji, takich jak powielanie i modyfikacje programu komputerowego, został wyraźnie poddany monopolowi autora.

43.      Podzielam ten pogląd.

44.      Zgodnie z art. 1 ust. 2 zdanie pierwsze dyrektywy 91/250 ochronie przewidzianej przez tę dyrektywę podlega bowiem każda forma wyrażenia programu komputerowego. Jak orzekł już Trybunał, zarówno kod źródłowy, jak i kod obiektowy stanowią formy wyrażenia programu komputerowego; obie te formy podlegają ochronie(24). Przejście z jednej formy do drugiej wymaga zatem powielenia i modyfikacji programu.

45.      Co się tyczy dekompilacji – polega ona na przekształceniu programu w postaci kodu obiektowego (chronionej) w quasi‑kod źródłowy. Ten ostatni kod stanowi powielenie programu wynikające z jego modyfikacji, a ta modyfikacja polega na translacji języka maszynowego na język programowania. Powielenie takie wyraźnie podlega prawu wyłącznemu autora programu na podstawie art. 4 lit. b) dyrektywy 91/250.

46.      Potwierdza to zresztą motyw dziewiętnasty tej dyrektywy, zgodnie z którym „niedozwolone powielanie, translacja, adaptacja lub przekształcanie formy kodu, w której kopia programu komputerowego została udostępniona, stanowi naruszenie wyłącznych praw autora”.

47.      Wreszcie ostateczne potwierdzenie na to, że dekompilacja wchodzi w zakres art. 4 lit. a) i b) dyrektywy 91/250, można znaleźć w art. 6 ust. 1 tej dyrektywy. Artykuł 6 owej dyrektywy, zatytułowany „Dekompilacja”, odnosi się bowiem do „powielani[a] kodu i translacj[i] jego form w rozumieniu art. 4 lit. a) i b)”(25) rzeczonej dyrektywy. Chodzi więc tutaj o pośrednią definicję pojęcia dekompilacji w rozumieniu dyrektywy 91/250, która to definicja wyraźnie odsyła do praw wyłącznych autora programu komputerowego wymienionych w art. 4 lit. a) i b) owej dyrektywy.

48.      Należy zatem stwierdzić, że dekompilacja programu komputerowego wchodzi w zakres praw wyłącznych autora takiego programu przewidzianych w art. 4 lit. a) i b) dyrektywy 91/250.

 W przedmiocie włączenia dekompilacji do zakresu art. 5 ust. 1 dyrektywy 91/250

49.      Stwierdzenie dokonane w poprzednim punkcie niniejszej opinii oznacza, że odpowiedź na pytanie, czy dekompilacja korzysta z wyjątku (lub też, lepiej, ograniczenia) przewidzianego w art. 5 ust. 1 dyrektywy 91/250, musi być twierdząca. Jestem w tej kwestii zgodny z Komisją.

50.      Zgodnie z tym przepisem bowiem uprawniony nabywca programu komputerowego ma prawo do dokonania czynności wymienionych w art. 4 lit. a) i b) dyrektywy 91/250, gdy czynności te są konieczne do używania owego programu, włącznie z poprawianiem błędów. Dlatego też, zgodnie z logiką, jeśli dekompilacja lub czynności się na nią składające, takie jak powielanie czy modyfikacje kodu, wchodzą w zakres ochrony na podstawie art. 4 lit. a) i b) owej dyrektywy, czynności te muszą też wchodzić w zakres objęty art. 5 ust. 1 rzeczonej dyrektywy.

51.      Przedstawiona przez Top System wykładnia tych przepisów, zgodnie z którą dekompilacja wchodzi w sferę monopolu autora na podstawie art. 4 lit. a) i b) dyrektywy 91/250, ale nie stanowi wyjątku przewidzianego w art. 5 ust. 1 owej dyrektywy, nie może zostać przyjęta. Konstrukcja oraz brzmienie tych przepisów wyraźnie wskazują, że te dwie wykładnie nie mogą funkcjonować jednocześnie.

 W przedmiocie znaczenia art. 6 dyrektywy 91/250

52.      Top System twierdzi natomiast, że art. 6 dyrektywy 91/250 powinien nadawać inny kierunek wykładni art. 5 ust. 1 owej dyrektywy, niż ta, którą zaproponowałem powyżej. Zdaniem tej spółki art. 6 rzeczonej dyrektywy stanowi swego rodzaju lex specialis i jest jedynym przepisem dotyczącym dekompilacji. Charakter lex specialis tego przepisu wyklucza dekompilację z zakresu stosowania art. 5 ust. 1 dyrektywy 91/250. Zważywszy zaś, że art. 6 tej dyrektywy zezwala na dekompilację wyłącznie w celu zapewnienia interoperacyjności niezależnie stworzonych programów komputerowych, dekompilacja w celu poprawienia błędów w programie komputerowym dokonana bez zezwolenia uprawnionego z tytułu praw autorskich jest zakazana.

53.      Argumentacja ta nie wytrzymuje jednak krytyki.

54.      Jak bowiem wskazałem, art. 5 ust. 1 dyrektywy 91/250 nie wymienia poszczególnych czynności, które obejmuje. Przepis ów ogranicza się do odesłania do art. 4 lit. a) i b) owej dyrektywy, zwalniając z obowiązku uzyskania zezwolenia uprawnionego z tytułu praw autorskich „czynności określone” w tym art. 4 lit. a) i b), gdy są one konieczne do używania programu komputerowego. Ponadto przepis ów nie zawiera żadnego zastrzeżenia dotyczącego art. 6 rzeczonej dyrektywy.

55.      Z kolei art. 6 ust. 1 dyrektywy 91/250 dotyczy dwóch szczególnych kategorii spośród czynności objętych przez art. 4 lit. a) i b) owej dyrektywy, czyli „powielania kodu” i „translacji jego form”, i to jeżeli czynności te są niezbędne do otrzymania informacji koniecznych do osiągnięcia interoperacyjności niezależnie stworzonego programu komputerowego z innymi programami, czyli celu odmiennego od tego określonego w art. 5 ust. 1 rzeczonej dyrektywy.

56.      Nic nie wskazuje zatem na to, że art. 6 dyrektywy 91/250 stanowi lex specialis w stosunku do art. 5 ust. 1 owej dyrektywy. Te dwa przepisy mają różny zakres stosowania, ponieważ dotyczą one dwóch różnych sytuacji. Artykuł 5 ust. 1 dotyczy czynności koniecznych do używania programu komputerowego, włącznie z poprawianiem błędów, podczas gdy art. 6 dotyczy czynności koniecznych do zapewnienia interoperacyjności stworzonych niezależnie programów. Przepisy te są zatem od siebie niezależne i nie pozostają w stosunku lex specialis i lex generalis

57.      Argument Top System, zgodnie z którym art. 6 dyrektywy 91/250 jest jedynym przepisem zezwalającym na dekompilację programu komputerowego, należy zatem odrzucić.

 Wpływ prac przygotowawczych dotyczących dyrektywy 91/250

58.      Wniosku, zgodnie z którym art. 5 ust. 1 dyrektywy 91/250 obejmuje dekompilację programu komputerowego w celu poprawienia w nim błędów, nie podważają, w przeciwieństwie do twierdzeń Top System, informacje wynikające z prac przygotowawczych dotyczących tej dyrektywy.

59.      Nie podzielam zatem argumentacji Top System wysuniętej w szczególności w odpowiedzi na pytania Trybunału, zgodnie z którą prace przygotowawcze dyrektywy 91/250 miałyby wykazywać, że dekompilacja chronionego programu komputerowego jest możliwa jedynie w okolicznościach i do celów określonych w art. 6 owej dyrektywy. Dokumenty przywołane przez Top System wskazują bowiem, że jasne było od początku prac, iż określone w art. 4 lit. a) i b) rzeczonej dyrektywy prawa wyłączne autora obejmują dekompilację chronionego programu. Zważywszy zaś, że art. 5 ust. 1 dyrektywy 91/250 pozwala uprawnionemu nabywcy wykonać każdą czynność wymienioną w art. 4 lit. a) i b) owej dyrektywy, jeżeli jest ona konieczna do używania programu, włącznie z poprawianiem błędów, niechybnie obejmuje to też dekompilację. Tym samym cała prowadzona podczas procedury legislacyjnej w sprawie dyrektywy 91/250 dyskusja, która doprowadziła do dodania do pierwotnego projektu Komisji obecnego art. 6 owej dyrektywy, dotyczyła dekompilacji przeprowadzanej poza zwykłym używaniem programu, a zatem poza zakresem art. 5 ust. 1 rzeczonej dyrektywy. Chodziło bowiem o dekompilację do celów interoperacyjności programów stworzonych przez niezależnych autorów.

60.      Błędne jest zatem twierdzenie, jak czyni to Top System, że kwestia dekompilacji jest definitywnie wykluczona z art. 5 dyrektywy 91/250. Aby dekompilacja była usunięta z zakresu art. 5 ust. 1 tej dyrektywy, musiałaby także zostać wyłączona z zakresu art. 4 lit. a) i b) owej dyrektywy, co spowodowałoby całkowite usunięcie dekompilacji z wyłącznej sfery uprawnionego z tytułu praw autorskich, ponieważ brak jest innych przepisów mogących mu zapewnić ochronę przed dekompilacją. Wniosek taki byłby zaś absurdalny.

61.      Jedyne, co wykazują prace przygotowawcze dotyczące dyrektywy 91/250, to to, że początkowy pomysł włączenia wyjątku odnoszącego się do dekompilacji do celów interoperacyjności do szczególnego ustępu art. 5 owej dyrektywy (odrębnego od ust. 1) został porzucony na rzecz utworzenia nowego, bardziej rozbudowanego artykułu poświęconego temu wyjątkowi. Nie wpływa to natomiast w żaden sposób na zakres art. 5 ust. 1 rzeczonej dyrektywy.

62.      Prawdą jest, że Rada znacznie ograniczyła zakres tego nowego wyjątku. Porzucono w szczególności początkowo przedstawiony przez Komisję pomysł zezwolenia na dekompilację do celów bieżącego utrzymania nowostworzonego programu współdziałającego ze zdekompilowanym programem. Można to moim zdaniem wyjaśnić faktem, że na mocy art. 9 ust. 1 zdanie drugie dyrektywy 91/250 nie można odstąpić od tego wyjątku w drodze umownej, w przeciwieństwie do przypadku art. 5 ust. 1. Celem była zatem ochrona uprawnionych z tytułu praw autorskich przed nadużyciami. Pozostaje jednak faktem, że w tym przypadku dekompilacja została przeprowadzona w celach innych niż normalne używanie programu(26).

63.      Podzielam zatem stanowisko Komisji, zgodnie z którym prace przygotowawcze dotyczące dyrektywy 91/250 nie pozwalają na dojście do wniosku odmiennego od tego, jaki wynika z wykładni literalnej i systemowej art. 5 ust. 1 owej dyrektywy.

 Propozycja odpowiedzi

64.      Proponuję tym samym odpowiedzieć na pierwsze pytanie prejudycjalne, iż art. 5 ust. 1 dyrektywy 91/250 należy interpretować w ten sposób, że zezwala on uprawnionemu nabywcy programu komputerowego na przeprowadzenie dekompilacji tego programu, jeżeli jest ona konieczna do poprawienia błędów mających wpływ na funkcjonowanie owego programu.

 W przedmiocie drugiego pytania prejudycjalnego

65.      Poprzez drugie pytanie prejudycjalne sąd odsyłający zmierza do ustalenia, czy w przypadku gdyby art. 5 ust. 1 dyrektywy 91/250 należało interpretować w ten sposób, że zezwala on uprawnionemu nabywcy programu komputerowego na przeprowadzenie dekompilacji tego programu, jeżeli jest ona konieczna do poprawienia błędów, dekompilacja ta powinna spełniać wymogi przewidziane w art. 6 owej dyrektywy lub też inne wymogi.

 W przedmiocie możliwości zastosowania wymogów wynikających z art. 6 dyrektywy 91/250

66.      Artykuł 6 dyrektywy 91/250 wprowadza wyjątek od praw wyłącznych uprawnionego z tytułu praw autorskich do programu komputerowego pozwalający na dekompilację tego programu, jeżeli jest to konieczne do zapewnienia kompatybilności z nim innego niezależnie stworzonego programu. Wyjątkowi temu towarzyszy szereg warunków i zakazów wymienionych w owym przepisie.

67.      Zgodnie z moją analizą(27) art. 6 dyrektywy 91/250 pozostaje niezależny w stosunku do art. 5 owej dyrektywy, w szczególności do jej art. 5 ust. 1. Wyjątek, który ustanawia art. 6 rzeczonej dyrektywy, ma zakres stosowania i cele odmienne od wyjątku przewidzianego w art. 5 ust. 1 tej dyrektywy oraz inaczej określa też czynności, na których dokonanie zezwala.

68.      Wymogi przewidziane w art. 6 dyrektywy 91/250 nie mogą zatem mieć zastosowania ani bezpośrednio, ani w drodze analogii do wyjątku przewidzianego w art. 5 ust. 1 owej dyrektywy.

69.      Nie oznacza to jednak, że zastosowanie tego ostatniego wyjątku nie podlega żadnym wymaganiom.

 W przedmiocie innych mających zastosowanie wymogów

70.      Z uwagi bowiem na sformułowanie art. 5 ust. 1 dyrektywy 91/250 niektóre warunki i niektóre ograniczenia są nieodłącznie związane z wyjątkiem od praw wyłącznych ustanowionym w tym przepisie(28).

71.      Przede wszystkim z wyjątku tego korzysta jedynie uprawniony nabywca programu komputerowego. Kwestia te nie wydaje się rodzić problemów w postępowaniu głównym i nie wymaga zatem szerszego omówienia.

72.      Następnie dokonane czynności, w niniejszej sprawie czynności, które jako całość stanowią dekompilację programu komputerowego(29), muszą być konieczne do umożliwienia używania tego programu w sposób zgodny z jego przeznaczeniem, a w szczególności do poprawienia błędów. Warunek ten prowadzi do wskazanych poniżej uwag.

73.      Po pierwsze, należy zdefiniować pojęcie „błędu”. Samo istnienie błędu w programie komputerowym może bowiem stanowić przedmiot sporu między autorem a użytkownikiem tego programu(30). To, co z punktu widzenia użytkownika może stanowić błąd, może być funkcjonalnością lub opcją zamierzoną z punktu widzenia autora owego programu. Chociaż dyrektywa 91/250 nie zawiera definicji tego pojęcia, można ją jednak wywnioskować z brzmienia i celu art. 5 ust. 1 owej dyrektywy.

74.      Zgodnie z tym przepisem dokonane przez uprawnionego nabywcę programu komputerowego czynności muszą mu umożliwić „[używanie] programu […] zgodnie z zamierzonym celem [z jego przeznaczeniem], włącznie z poprawianiem błędów”. Poprawianie błędów stanowi więc element używania programu zgodnie z jego przeznaczeniem.

75.      Przeznaczenie programu komputerowego jest mu nadawane przez jego autora lub, w zależności od przypadku, uzgadniane przez dostawcę i nabywcę programu podczas transakcji sprzedaży. Błąd jest zatem wadliwym działaniem uniemożliwiającym używanie programu zgodnie z owym przeznaczeniem. Jedynie poprawianie takich błędów może uzasadniać dokonywanie czynności przez użytkownika, w tym dekompilacji, bez zgody uprawnionego z tytułu praw autorskich.

76.      Natomiast żadna zmiana ani ulepszenie programu w stosunku do jego pierwotnego przeznaczenia nie stanowi poprawiania błędów uzasadniającego takie czynności. Chodzi tu zwłaszcza o aktualizację programu związaną z postępem technologicznym. Inaczej mówiąc – starzenie się pod względem technologicznym programu komputerowego nie stanowi błędu w rozumieniu art. 5 ust. 1 dyrektywy 91/250.

77.      Jako że programy komputerowe nie tylko stanowią kategorię utworów użytkowych, ale także wchodzą w zakres szczególnie dynamicznego sektora rozwoju technologicznego, normalne jest, że z czasem dezaktualizują się. Zaradzenie temu problemowi przestarzałego charakteru przez aktualizację programów komputerowych tudzież przez zastąpienie ich nowymi programami należy do normalnego wykorzystania tych programów jako przedmiotów chronionych prawem autorskim i w konsekwencji do prerogatyw uprawnionego z tytułu tego prawa.

78.      Po drugie, interwencja użytkownika programu komputerowego musi być konieczna z punktu widzenia realizowanego celu. W niniejszym przypadku powstaje pytanie, czy i w jakim zakresie dekompilacja programu komputerowego jest konieczna do celów poprawienia w nim błędów.

79.      Z pewnością istnieją błędy, które mogą zostać poprawione bez dostępu do kodu źródłowego programu, „ręcznie” przez użytkownika lub za pomocą przeznaczonego do tego oprogramowania. Strony, które przedstawiły uwagi w niniejszej sprawie, wydawały zgadzać się jednak co do tego, że poprawianie błędów zazwyczaj wymaga wprowadzenia zmian w samym kodzie programu. Ponieważ kod obiektowy jest niezrozumiały dla człowieka, takie poprawienie wymaga dotarcia do oryginalnego kodu źródłowego lub translacji kodu obiektowego na kod źródłowy (quasi‑kod źródłowy(31)). Rodzi się zatem następujące pytanie: w jakich okolicznościach potrzeba ta uzasadnia dekompilację programu przez uprawnionego nabywcę?

80.      Top System twierdzi, że takie przypadki są bardzo rzadkie i wyjątkowe. Według tej spółki w większości sytuacji albo uprawniony nabywca programu komputerowego posiada już kod źródłowy, albo uprawniony z tytułu praw autorskich udziela mu dostępu do tego kodu, albo też na podstawie umowy w sprawie bieżącego utrzymania uprawniony z tytułu tych praw jest zobowiązany do poprawienia błędów.

81.      Pomijam sytuację, w której uprawniony nabywca dysponuje nieskompilowaną lub już zdekompilowaną wersją programu, czyli ma dostęp do kodu źródłowego. Oczywiste jest, że w takim przypadku nie ma konieczności przeprowadzania dekompilacji. Bardziej problematyczny jest stosunek między tym nabywcą a uprawnionym z tytułu praw autorskich do programu komputerowego oraz ich wzajemne zobowiązania. Niemniej nie chodzi tutaj o konieczność przeprowadzenia dekompilacji programu w celu poprawienia błędów, lecz o warunek zastosowania art. 5 ust. 1 dyrektywy 91/250, a mianowicie brak przepisów umownych sprzeciwiających się temu.

82.      Gwoli przypomnienia: art. 5 ust. 1 dyrektywy 91/250 ma zastosowanie „[w] braku szczególnych przepisów umownych”. Inaczej mówiąc, umowa sprzedaży programu może regulować używanie programu, w tym poprawianie błędów, ograniczając możliwość nabywcy do dokonania, do celów poprawienia tych błędów, czynności należących do monopolu uprawnionego. Ograniczenie to może osiągnąć rozmiary całkowitego zakazu poprawiania błędów przez nabywcę(32). W takim wypadku wyjątek przewidziany w tym przepisie nie znajduje zastosowania, a czynności nabywcy ograniczają się do tych zezwolonych na podstawie umowy.

83.      Natomiast jeżeli umowa między stronami nie zawiera takiego ograniczenia, uprawniony nabywca programu komputerowego może moim zdaniem dokonać czynności wymienionych w art. 4 lit. a) i b) dyrektywy 91/250, w tym dekompilacji programu, jeżeli okazuje się to konieczne, w szczególności do poprawienia błędów. Nabywca ten nie ma innych zobowiązań względem uprawnionego z tytułu praw autorskich do programu. Nie jest on zatem zobowiązany do zwracania się do uprawnionego o poprawienie błędów ani do wnoszenia o dostęp do kodu źródłowego programu, ani do wytaczania powództwa zmierzającego do nakazania uprawnionemu wykonania takiej czy innej czynności. Natomiast o ile takie zobowiązania nie wynikają z art. 5 ust. 1 rzeczonej dyrektywy, o tyle należy pamiętać, że dekompilacja jest procesem pracochłonnym, kosztownym i dającym niepewne rezultaty. W praktyce użytkownicy sięgną po tę technikę dopiero w ostateczności(33).

84.      Oczywiście w przypadku sporu to do właściwego sądu będzie należało ustalenie dokładnej treści praw i zobowiązań umownych stron umowy sprzedaży programu komputerowego.

85.      Chociaż poprawienie błędu wymaga często zmiany niewielkiego fragmentu kodu programu komputerowego, odnalezienie tego fragmentu może wymagać dekompilacji znacznej części, a nawet całego programu. Dlatego też nie można uznać takiej dekompilacji za niekonieczną do poprawienia błędu, ponieważ mogłoby to uniemożliwić dokonanie tej poprawki i pozbawić skuteczności (effet utile) wyjątek przewidziany w art. 5 ust. 1 dyrektywy 91/250. Uprawniony nabywca programu komputerowego może zatem na podstawie tego przepisu dokonać dekompilacji programu w zakresie koniecznym do poprawienia błędu sensu stricto, ale także do poszukiwania tego błędu i części programu, która powinna zostać zmieniona.

86.      Wreszcie należy stwierdzić, że art. 5 ust. 1 dyrektywy 91/250 nie wskazuje w żaden sposób ograniczeń w zakresie korzystania z informacji uzyskanych za pomocą dekompilacji programu komputerowego, takich jak te zawarte w art. 6 ust. 2 owej dyrektywy. Nie wynika z tego jednak, że uprawniony nabywca programu komputerowego, który przeprowadził dekompilację tego programu w celu poprawienia w nim błędów, może swobodnie korzystać następnie z wyniku tej dekompilacji do innych celów.

87.      Artykuł 4 lit. b) dyrektywy 91/250 poddaje pod monopol autora nie tylko „translację, adaptację, porządkowanie i jakiekolwiek inne modyfikacje programu komputerowego”, ale także „powielenie wyników tych działań”, czyli w przypadku dekompilacji – kod źródłowy wynikający z tej dekompilacji. Tym samym jakiekolwiek powielenie owego kodu w celu innym niż poprawienie błędów podlega zezwoleniu uprawnionego z tytułu praw autorskich. Ponadto art. 4 lit. c) tej dyrektywy zakazuje publicznej dystrybucji kopii programu komputerowego bez zgody uprawnionego z tytułu praw autorskich do tego programu, co ma zastosowanie także do kopii kodu źródłowego wynikającego z dekompilacji.

88.      Natomiast zgodnie z art. 1 ust. 2 dyrektywy 91/250 informacje, które nie tworzą programu w ścisłym znaczeniu, czyli jego formy wyrażenia, nie podlegają ochronie(34).

89.      Proponuję zatem, aby na drugie pytanie prejudycjalne odpowiedzieć, iż art. 5 ust. 1 dyrektywy 91/250 należy interpretować w ten sposób, że dekompilacja programu komputerowego dokonana na podstawie tego przepisu przez uprawnionego nabywcę do celów poprawienia w nim błędów nie podlega wymogom przewidzianym w art. 6 owej dyrektywy. Dekompilacja taka może jednakże zostać przeprowadzona jedynie w zakresie koniecznym do poprawienia tych błędów i w granicach zobowiązań umownych nabywcy.

 Wnioski

90.      W świetle powyższych rozważań proponuję na pytania prejudycjalne postawione przez cour d’appel de Bruxelles (sąd apelacyjny w Brukseli, Belgia) udzielić następujących odpowiedzi:

1)      Artykuł 5 ust. 1 dyrektywy Rady 91/250/EWG z dnia 14 maja 1991 r. w sprawie ochrony prawnej programów komputerowych należy interpretować w ten sposób, że zezwala on uprawnionemu nabywcy programu komputerowego na przeprowadzenie dekompilacji tego programu, jeżeli jest ona konieczna do poprawienia błędów mających wpływ na funkcjonowanie owego programu.

2)      Artykuł 5 ust. 1 dyrektywy 91/250 należy interpretować w ten sposób, że dekompilacja programu komputerowego dokonana na podstawie tego przepisu przez uprawnionego nabywcę do celów poprawienia w nim błędów nie podlega wymogom przewidzianym w art. 6 owej dyrektywy. Dekompilacja taka może jednakże zostać przeprowadzona jedynie w zakresie koniecznym do poprawienia tych błędów i w granicach zobowiązań umownych nabywcy.


1      Język oryginału: francuski.


2      Zobacz pkt 9 niniejszej opinii.


3      Zobacz art. 4 traktatu WIPO o prawie autorskim, przyjętego w Genewie w dniu 20 grudnia 1996 r.


4      Zobacz w szczególności R. Markiewicz, Ilustrowane prawo autorskie, Wolters Kluwer, Warszawa, 2018, s. 463. Inni autorzy uznają programy komputerowe za „pisma z nadania prawa”, zob. M. Vivant, J.-M. Bruguière, Droit d’auteur et droits voisins, Dalloz, Paris, 2015, s. 183.


5      M.-Ch. Janssens, „The Software Directive”, w: I.A. Stamatoudi i P. Torremans, EU Copyright Law. A Commentary, Edward Elgar Publishing, Cheltenham, 2014, s. 89–148, w szczególności s. 93.


6      J. Bing, „Copyright Protection of Computer Programs”, w: E. Derclaye (ed.), Research Handbook on the Future of EU Copyright, Edward Elgar Publishing, Cheltenham, 2009, s. 401–425, w szczególności s. 401.


7      Lub, dokładniej rzecz ujmując, dla procesorów o określonej architekturze, ponieważ instrukcje w postaci kodu obiektowego są specyficzne dla każdego typu procesora i nie będą wykonywane przez procesor innego typu.


8      Zobacz w szczególności D.S. Karjala, „Copyright Protection of Computer Documents, Reverse Engeneering and Professor Miller”, University of Dayton Law Review, 1994, vol. 19, s. 975–1020.


9      N. Shemtov, Beyond the Code. Protection of Non-Textual Features of Software, Oxford University Press, Oxford, 2017, s. 28. Dla szerszego opracowania dotyczącego dychotomii idea–wyrażenie w prawie autorskim i jej zastosowania do programów komputerowych zobacz w szczególności s. 102–127 tej pozycji.


10      Dz.U. 1991, L 122, s. 42.


11      Dyrektywa Parlamentu Europejskiego i Rady z dnia 23 kwietnia 2009 r. w sprawie ochrony prawnej programów komputerowych (Dz.U. 2009, L 111, s. 16).


12      Moniteur belge z dnia 27 lipca 1994 r., s. 19 315.


13      A mianowicie w celu zapewnienia interoperacyjności programu komputerowego stworzonego niezależnie od zdekompilowanego programu.


14      Uprawniony ma prawo do „wykonywania lub zezwalania”.


15      Dyrektywa Parlamentu Europejskiego i Rady z dnia 22 maja 2001 r. w sprawie harmonizacji niektórych aspektów praw autorskich i pokrewnych w społeczeństwie informacyjnym (Dz.U. 2001, L 167, s. 10).


16      Artykuł 5 dyrektywy 91/250 nosi tytuł „Wyjątki od czynności zastrzeżonych”.


17      Zobacz wniosek dotyczący dyrektywy Rady w sprawie ochrony prawnej programów komputerowych [COM(88) 816 wersja ostateczna], przedstawiony przez Komisję w dniu 5 stycznia 1989 r.


18      W przeciwieństwie do art. 5 ust. 3 dyrektywy 91/250 art. 5 ust. 1 owej dyrektywy wspomina nie o użytkowniku kopii programu, lecz o nabywcy programu, niezależnie od liczby nabytych kopii.


19      Ponadto umowy w sprawie używania programów komputerowych będą podlegać innym przepisom, takim jak przepisy prawa zobowiązań, ochrony konsumentów czy też konkurencji. Przepisy te ograniczą swobodę zawierania umów stron, chroniąc nabywców programów komputerowych przed nadużyciami ze strony uprawnionych z tytułu praw autorskich do tych programów.


20      Wyrok z dnia 2 maja 2012 r. (C‑406/10, EU:C:2012:259, pkt 58).


21      Jako sprzeczna z samym celem umowy w sprawie używania programu komputerowego.


22      Nie można zaś wykluczyć, że dekompilacja jest przeprowadzana w nielegalnych celach niezwiązanych z poprawianiem błędów.


23      Zobacz pkt 5 niniejszej opinii.


24      Wyrok z dnia 2 maja 2012 r., SAS Institute (C‑406/10, EU:C:2012:259, pkt 37, 38).


25      Podkreślenie moje.


26      Ponadto, jak wyjaśnię poniżej, art. 5 ust. 1 dyrektywy 91/250 nie zezwala moim zdaniem na dekompilację programu komputerowego do celów bieżącego utrzymania zdekompilowanego programu, chyba że w celu poprawienia błędów w ścisłym znaczeniu (zob. pkt 75 i 76 niniejszej opinii).


27      Zobacz w szczególności pkt 52–56 niniejszej opinii.


28      Zobacz w szczególności M.-Ch. Janssens, op.cit., s. 127.


29      Zobacz pkt 45–47 niniejszej opinii.


30      W postępowaniu głównym Top System zaprzecza istnieniu błędu w odnośnym programie, pomimo że sąd odsyłający informuje o opinii biegłego stwierdzającej istnienie takiego błędu.


31      Zobacz pkt 41 niniejszej opinii.


32      Możliwość taka moim zdaniem istnieje, pomimo brzmienia motywu siedemnastego dyrektywy 91/250 (zob. pkt 31–34 niniejszej opinii).


33      Ta cecha charakterystyczna dekompilacji często jest podkreślana przez wielu autorów. Zobacz w szczególności J. Bing, op.cit., s. 423, 424.


34      Muszę zasygnalizować, że według mnie wykładnia ta nie przyznaje uprawnionemu z tytułu praw autorskich do programu komputerowego ochrony mniejszej niż ta przyznana przez art. 6 ust. 2 dyrektyw 91/250 w przypadku dekompilacji do celów interoperacyjności niezależnie stworzonych programów. Artykuł 6 ust. 2 tej dyrektywy czytany w świetle jej art. 1 ust. 2 może być bowiem interpretowany jedynie w ten sposób, że pojęcie „informacji” oznacza jedynie elementy programu komputerowego, które podlegają ochronie na mocy rzeczonej dyrektywy, czyli jego formy wyrażenia, a nie „[k]oncepcje i zasady, na których opierają się” te elementy. Ponadto przypominam, że zgodnie z art. 9 ust. 1 zdanie drugie dyrektywy 91/250 dekompilacja oparta na art. 6 owej dyrektywy nie może zostać umownie wykluczona, w przeciwieństwie do dekompilacji dokonanej do celów poprawienia błędów.