Чи захищені авторські права інтерфейси та підписи методів?

Наприклад, чи є порушенням авторських прав, якщо я записую клас під назвою Random з точно такою ж метою і підписами методу, що і клас Microsoft .Net System.Random від Microsoft? Чи має значення, на якій мові написано? У цьому випадку я хочу написати клас Random для використання в ActionScript, у якому відсутній вбудований клас PRNG.

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

Я вважаю, що дивлячись на стосунки між Моно і Дотнетом, відповідає на це питання. Команда Mono може використовувати визначення методів або загальнодоступний інтерфейс, але вони повинні повторно реалізувати внутрішні. Однак випадок Android v Oracle пропонує кілька інших моментів, які роблять це очевидне розмежування трохи розмитим. У справі AvO більшість пунктів, переданих до суду, є патентами, пов’язаними з VM, інтерфейси бібліотеки не викликають суперечок. Єдиний код, який був висвітлений, - це приклади, коли на деякий погляд схоже, що внутрішні файли були скопійовані.

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

Навіть якщо ваше запитання схоже, я відповім зовсім протилежне: ви можете скопіювати підписи методів. Чому?

Насправді підписи методів виходять із здорового глузду.

• По-перше, якщо ми беремо крайній приклад, Microsoft не можеRandom захистити авторське право на ім’я та подати до суду на всіх, хто використовуватиме слово Randomв будь-якій програмі.

• По-друге, що ви намагаєтеся робити саме? Повторне впровадження .NET Framework? Чому? Не потрібно винаходити колесо . Якщо ви знаєте, як зробити це краще, інтуїтивніше і т. Д., Швидше за все, ви отримаєте кращі назви класів та методів, кращу організацію тощо. Якщо ви спробуєте скопіювати структуру .NET Framework, щоб перенести її на інший мови , то ви не є прямим конкурентом Microsoft, тому у них немає серйозних причин подати до суду (якщо це сказано, вони подадуть до суду, якщо ви скопіюєте сам вихідний код). Насправді вони вам навіть виграють: копіювання такої структури в інші рамки не лише покаже успіх .NET Framework, але й полегшить розробникам .NET роботу з іншими мовами, а розробникам з інших мов - навчитися .NET.

• По-третє, у них є більш серйозні справи, ніж подавати позов до всіх, хто скопіює назви методів та класів .NET Framework.

Тепер, якщо ваш намір полягає в тому, щоб скопіювати весь .NET Framework і зробити продукт, який буде використовуватися багатьма розробниками, проконсультуйтеся з юристом, перш ніж ризикувати.

Приклад:

Я був абсолютно незадоволений обмежуючим обмеженням 259 символів у файлових шляхах у .NET Framework та неможливістю використання транзакцій з кодом на рівні файлів. Тож я реалізував власний Fileклас із методами, які працювали б, як очікувалося, для будь-якого шляху, не лише крихітних коротких, та здійснювали транзакції. У першій версії я вирішив клонувати назви методів у Fileта Directoryкласах . Буде Microsoft позов до мене за це? Я сумніваюся в цьому.

У всіх випадках, у другій версії я прийшов з новим синтаксисом new File(string fileName), який я знаходжу набагато зрозумілішим для мене . Клонування назв методів іноді корисно, але для цього потрібно мати вагомий привід.

Захист авторських прав захищає "художнє вираження" твору, а не технічну форму (цитую вікіпедію ).

Захист авторських прав не захищає факти .

Тож виникає питання, чи API чи інтерфейс - це "факт" чи художнє вираження? Для простих API, які є лише переліком способів отримання випадкових чисел та різних видів випадкових чисел, API, ймовірно, більше схожий на факт. Але, я можу побачити, що існує дуже складний інтерфейс (знаєте, ті, на які ви дивитесь хвилину, а потім кажете "Ах! Це вражаюче"), можна вважати "мистецьким виразом", гідним захисту.

Ось нещодавня стаття про боротьбу Oracle та Google за авторські права API щодо цієї проблеми, що обговорюється в судах США.

Я не юрист, і ця посада не повинна тлумачитися юридичною порадою. Я навіть не можу дуже добре писати відмови.

Ви можете приймати суто функціональні аспекти, але ви не можете приймати виразні аспекти. Ім'я класу, назви методів та підписи є суто функціональними. Вам потрібні вони для взаємодії. Імена параметрів та макроси заголовків можна вважати виразними. Наприклад, у своїй антимонопольній справі Windows Microsoft стверджувала, що ніщо не заважає конкурентові копіювати API API та створити власну платформу, на якій запускатимуться програми Windows.