SAS Institute: функціональна сумісність програми та копіювання охоронюваної форми

Інша програма зі схожою поведінкою

SAS пропонував аналітичну систему. World Programming створило продукт, здатний виконувати скрипти користувачів цієї системи. За обставинами, описаними у зверненні, WPL не мало доступу до вихідного коду SAS і не декомпілювало об’єктний код: воно досліджувало поведінку програми та документацію. Спір охоплював також посібники й умови ліцензії (пункти 23–28 і 44). ^[1]

З погляду методики назва продукту не визначає єдиний об’єкт охорони. Код, виклик функції, опис команди в посібнику та тестовий набір даних можуть потребувати різних запитань. Звіт зі словами «скопійовано програму» спочатку має пояснити конкретний матеріал і дію, приховані за таким скороченням, і визначити належний рівень порівняння.

Три відповіді від 2 травня 2012 року

Суд визнав, що функціональність програми, мова програмування та формат файлів для використання функцій не є формою вираження, охоронюваною як сама комп’ютерна програма. Він допустив спостереження, вивчення й тестування ліцензіатом за визначених умов. Окремо можливе порушення при відтворенні творчого вираження з посібника (пункти 39–46, 50–62 і 63–70). ^[1]

Рішення тлумачило Директиву 91/250. Її кодифікована наступниця, Директива 2009/24, зберігає розрізнення ідей і вираження та правила спостереження й тестування. Стаття 6 стосується іншого механізму — декомпіляції для сумісності за певних умов. Дослідження поведінки й декомпіляцію не слід подавати як одну необмежену дію. ^[2]

Відсутність охорони як форми вираження програми автоматично не виключає будь-яку охорону. У пункті 45 Суд залишив можливість окремо оцінювати мову й формат як твори за Директивою 2001/29, якщо вони є власним інтелектуальним творінням автора. Отже, потрібно точно визначати правову основу та досліджуваний об’єкт. ^[1]

Редакційна методика: протокол незалежної реалізації

Запропонований протокол починається зі списку матеріалів команди: правомірно отриманих копій, публічної документації, власних вимірювань і зовнішніх бібліотек. Для кожного записують джерело, версію, дату отримання та обмеження використання. Історія репозиторію допомагає відтворити створення коду, але сама не пояснює, чи автор раніше звертався до чужої охоронюваної форми.

Далі створюють функціональну специфікацію з входами, виходами, умовами та спостережуваними помилками без перенесення абзаців посібника. Автор тесту має розрізняти власний контрольний приклад і приклад із документації. Порівняння результатів потребує збереження вхідних даних, параметрів середовища та версій продуктів. Один однаковий результат не доводить ні копіювання, ні повної сумісності систем.

Може бути корисним розділення підготовки специфікації та реалізації з контролем передавання матеріалів. Це редакційна пропозиція зменшення доказової невизначеності, а не встановлена законом гарантія правомірності, яку іноді пов’язують із назвою clean room. Назва процесу не замінює відомостей про те, хто бачив матеріали та що увійшло до продукту. Зберігайте також розбіжності й рішення самостійно перепроєктувати реалізацію.

Приклад: міграція корпоративної звітності

Гіпотетичне підприємство хоче виконувати власні звітні скрипти в новій системі. Проєкт можна поділити на аналіз команд, розрахунки, імпорт файлів і посібник. Для кожного шару створюють картку походження. Старий посібник може допомогти визначити функції, але нова інструкція потребує окремої перевірки тексту, структури та прикладів.

Команда тестує порожні файли, неправильний формат, національні символи та граничні значення. Звіт пояснює, яка поведінка потрібна для завдання користувача, а що відтворили за звичкою. Це не дає автоматичного висновку про порушення. Вправа виявляє походження технічних рішень та питання для окремого аналізу договору, авторського права чи комерційної таємниці.

Література та межі порівняння прецедентів

Gerald 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. Видавець підтверджує бібліографічні дані. Запис слугує подальшому читанню: ми не подаємо недоступний повний текст як прочитаний і не приписуємо автору власних організаційних пропозицій. ^[3]

SAS варто читати поруч, але окремо від американської справи Google проти Oracle. Нормативні підстави та запитання судам відрізняються. Для польського проєкту починають із права ЄС і польської імплементації, а порівняння допомагає впорядкувати технічну проблему. Європейське розрізнення ідей і вираження не слід замінювати американським тестом fair use чи навпаки.

Наприкінці складіть перелік матеріалів для оприлюднення: описи функцій, графіку, посібник, приклади й повідомлення про помилки. Кожен потребує окремої перевірки походження. Інакше самостійно написаний код може поширюватися разом із чужою неперевіреною інструкцією чи ілюстрацією. Перевірка продукту має охоплювати також документацію, з якою його отримає користувач, та межі дозволеного використання цих матеріалів.

Джерела та подальше читання

1. 1
   Суд ЄС, SAS Institute проти World Programming ↗

   C-406/10; ECLI:EU:C:2012:259; 2.05.2012; CELEX:62010CJ0406

   Первинне джерело: факти 23–28, охорона 39–46, тестування 50–62, посібник 63–70.

2. 2
   Директива про правову охорону комп’ютерних програм ↗

   Директива 2009/24/WE, art. 1 п. 2, art. 5 п. 3, art. 6 і 8; CELEX:32009L0024

   Кодифікована наступниця Директиви 91/250, дослідженої у справі; розділяє спостереження й декомпіляцію.

3. 3
   Gerald 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

   Перевірено метадані видавця: друкований номер за липень 2012 року, онлайн-запис 3.04.2013. Без приписування тез із недоступного тексту.