Drugi program o podobnym zachowaniu
SAS oferował system analityczny. World Programming stworzyło produkt pozwalający uruchamiać skrypty użytkowników tego systemu. Według ustaleń opisanych w odesłaniu WPL nie miało dostępu do kodu źródłowego SAS i nie dekompilowało kodu obiektowego; badało zachowanie programu i korzystało z dokumentacji. Spór obejmował także instrukcje i warunki licencji. (pkt 23–28 i 44). [1]
Z perspektywy metodyki ważne jest, że nazwa produktu nie definiuje jednego przedmiotu ochrony. Kod, sposób wywołania funkcji, opis polecenia w podręczniku i zbiór danych testowych mogą wymagać odrębnych pytań. Dlatego raport rozpoczynający się od zdania „skopiowano program” powinien najpierw wyjaśnić, jaki konkretnie materiał i jaka czynność kryją się pod tym skrótem.
Trzy odpowiedzi z 2 maja 2012 r.
TSUE uznał, że funkcjonalność programu, język programowania i format plików służący korzystaniu z funkcji nie są postacią wyrażenia programu chronioną jako taki program. Dopuścił obserwowanie, badanie i testowanie przez licencjobiorcę w granicach wskazanych w wyroku. Odrębnie zastrzegł możliwość naruszenia przez przejęcie twórczego wyrażenia zawartego w instrukcji. (pkt 39–46, 50–62 i 63–70). [1]
Wyrok interpretował dyrektywę 91/250. Jej ujednolicona następczyni, dyrektywa 2009/24, zachowuje rozróżnienie idei i sposobu wyrażenia oraz reguły obserwacji i testowania. Artykuł 6 dotyczy innego mechanizmu — dekompilacji dla interoperacyjności z określonymi warunkami. Nie należy przedstawiać badania zachowania i dekompilacji jako jednej nieograniczonej czynności. [2]
Brak ochrony jako postaci programu nie oznacza automatycznie braku każdej ochrony. W pkt 45 Trybunał pozostawił możliwość odrębnej oceny języka i formatu jako utworów na gruncie dyrektywy 2001/29, jeżeli spełniają wymóg własnej twórczości intelektualnej autora. To kolejny powód, aby dokładnie wskazywać podstawę prawną oraz analizowany przedmiot. [1]
Metoda redakcyjna: protokół niezależnej implementacji
Proponowany protokół zaczyna się od spisu materiałów dostępnych zespołowi: legalnie uzyskane kopie, publiczna dokumentacja, własne pomiary i biblioteki zewnętrzne. Dla każdego materiału zapisujemy źródło, wersję, datę pozyskania i ograniczenia użycia. Historia repozytorium pomaga odtworzyć tworzenie kodu, lecz sama w sobie nie wyjaśnia, czy autor korzystał wcześniej z cudzej chronionej postaci.
Następnie przygotowujemy specyfikację funkcjonalną, która opisuje wejścia, wyjścia, warunki i obserwowalne błędy bez przenoszenia akapitów instrukcji. Autor testu powinien odróżnić własny przypadek kontrolny od przykładu przejętego z dokumentacji. Przy porównaniu wyników trzeba zachować dane wejściowe, parametry środowiska i wersje obu produktów. Zgodność jednego wyniku nie dowodzi ani kopiowania, ani pełnej zgodności systemów.
W organizacji pracy pomocne może być rozdzielenie opracowania specyfikacji i implementacji, z kontrolą przepływu materiałów. To redakcyjna propozycja ograniczenia niepewności dowodowej, nie ustawowa gwarancja legalności określana czasem jako „clean room”. Sama etykieta procesu nie zastępuje informacji, kto rzeczywiście widział materiały i co trafiło do produktu. Należy zachować także niezgodne wyniki oraz decyzje o samodzielnym przeprojektowaniu rozwiązania.
Przykład: migracja raportowania w przedsiębiorstwie
Hipotetyczna firma chce uruchamiać własne skrypty raportowe w nowym systemie. Projekt można podzielić na parser poleceń, obliczenia, import plików i podręcznik. Dla każdej warstwy tworzymy kartę pochodzenia. Stara instrukcja może służyć do zidentyfikowania funkcji, ale w nowej instrukcji potrzebna jest osobna kontrola sposobu wyrażenia, układu i przykładów.
Zespół przygotowuje testy dla pustego pliku, błędnego formatu, znaków narodowych i wartości granicznych. Raport wyjaśnia, które zachowania są potrzebne do realizacji zadania użytkownika, a które odtworzono z przyzwyczajenia. Nie formułujemy z tego automatycznej oceny naruszenia. Ćwiczenie ma ujawnić pochodzenie decyzji technicznych i elementy wymagające osobnego zbadania umowy, praw autorskich lub tajemnicy przedsiębiorstwa.
Literatura i granice porównania z innymi sprawami
Gerald Spindler opublikował omówienie „Grenzen des Softwareschutzes: Das Urteil des EuGH in Sachen SAS Institute”, Computer und Recht 28(7), 2012, s. 417–422, DOI 10.9785/ovs-cr-2012-417. Wydawca potwierdza dane bibliograficzne. Rekord służy dalszej lekturze; nie przedstawiamy niewidocznego pełnego tekstu jako przeczytanego ani nie przypisujemy autorowi własnych propozycji organizacji projektu. [3]
SAS należy czytać obok, lecz odrębnie od amerykańskiej sprawy Google przeciwko Oracle. Różnią się podstawy prawne i pytania poddane sądom. W analizie dla Polski zaczynamy od prawa UE i polskiej implementacji, a porównanie zagraniczne wykorzystujemy do uporządkowania problemu technicznego. Nie zamieniamy europejskiego rozróżnienia idei i wyrażenia w amerykański test fair use ani odwrotnie.
Na końcu analizy warto stworzyć listę materiałów przeznaczonych do publikacji: opis funkcji, grafiki, podręcznik, przykłady i komunikaty błędów. Każdy przechodzi oddzielną kontrolę pochodzenia. To zapobiega sytuacji, w której samodzielnie napisany kod zostaje udostępniony razem z cudzą instrukcją lub ilustracją, której statusu wcześniej nie sprawdzono. Weryfikacja produktu powinna obejmować także otoczenie dokumentacyjne, z którym trafi on do użytkownika.
Co wynika z analizy
- Rozdziel funkcjonalność, kod, format danych i dokumentację.
- Dokumentuj pochodzenie specyfikacji, testów i własnej implementacji.
- Nie utożsamiaj obserwacji programu z nieograniczoną dekompilacją ani kopiowaniem instrukcji.
Granice interpretacji
Studium dotyczy wykładni prawa UE w C-406/10, a nie wszystkich późniejszych sporów między SAS i WPL w innych państwach. Nie rozstrzyga ważności patentów, naruszenia tajemnicy ani każdej klauzuli umownej. Protokół pracy jest komentarzem redakcyjnym.
Źródła i dalsza lektura
- 1TSUE, SAS Institute przeciwko World Programming ↗
C-406/10; ECLI:EU:C:2012:259; 2.05.2012; CELEX:62010CJ0406
Źródło pierwotne; fakty pkt 23–28, zakres ochrony pkt 39–46, testowanie pkt 50–62, instrukcja pkt 63–70.
- 2Dyrektywa w sprawie ochrony prawnej programów komputerowych ↗
Dyrektywa 2009/24/WE, art. 1 ust. 2, art. 5 ust. 3, art. 6 i 8; CELEX:32009L0024
Ujednolicona następczyni dyrektywy 91/250 analizowanej w wyroku; rozdziela obserwację od dekompilacji.
- 3Gerald Spindler, Grenzen des Softwareschutzes: Das Urteil des EuGH in Sachen SAS Institute ↗
Computer und Recht 28(7), 2012, 417–422; DOI:10.9785/ovs-cr-2012-417
Zweryfikowane metadane wydawcy; numer drukowany z lipca 2012 r., rekord online z 3.04.2013. Bez przypisywania tez z niedostępnego tekstu.