Например, является ли это нарушением авторских прав, если я напишу класс с именем Random с той же самой целью и сигнатурами методов, что и у класса Microsoft .Net System.Random? Имеет ли значение, на каком языке написано? В этом случае я хочу написать класс Random для использования в ActionScript, в котором отсутствует встроенный класс PRNG с затравкой.
Если у кого-то есть хорошие ссылки или рекомендации для понимания того, какие аспекты программного обеспечения защищены, это тоже замечательно. И да, я знаю, что это не место для «настоящих» юридических консультаций. Если кто-то обращается в суд, указывая на общедоступную доску объявлений в качестве приоритета - позор им.
interfaces
copyright
Джошуа Хониг
источник
источник
Ответы:
Я считаю, что рассмотрение отношений между Моно и Дотнет ответит на этот вопрос. Команда Mono может использовать определения методов или открытый интерфейс, но они должны переопределить внутренние компоненты. Однако случай Android v Oracle поднимает еще несколько моментов, которые делают это очевидное различие немного размытым. В случае с AvO большинство вопросов, переданных в суд, - это патенты, относящиеся к ВМ, интерфейсы библиотеки не были предметом спора. Единственный выделенный код - это примеры, в которых в некоторой степени похоже, что внутренности были скопированы.
источник
Был похожий вопрос о схемах базы данных: копирование схемы базы данных конкурента? Я ответил там, что копирование всей схемы, вероятно, будет нарушением авторских прав, в зависимости от масштаба копирования, оцененного судьей.
Даже если ваш вопрос похож, я отвечу совсем наоборот: вы можете копировать сигнатуры методов. Почему?
На самом деле сигнатуры методов основаны на здравом смысле.
Во-первых, если мы возьмем крайний пример, Microsoft не может охранять авторское имя
Randomи подавать в суд на всех, кто будет использовать это словоRandomв любом приложении.Во-вторых, что вы пытаетесь сделать именно? Реализовать .NET Framework? Почему? Нет необходимости изобретать велосипед . Если вы знаете, как сделать его лучше, интуитивно понятнее и т. Д., Скорее всего, у вас появятся лучшие имена классов и методов, лучшая организация и т. Д. Если вы попытаетесь скопировать структуру .NET Framework, чтобы перенести ее на другой языком , значит вы не прямой конкурент Microsoftпоэтому у них нет серьезных оснований предъявлять вам иск (при этом они будут предъявлять иск к вам, если вы скопируете сам исходный код). На самом деле, они даже выиграют от вас: копирование такой структуры в другие платформы не только продемонстрирует успех .NET Framework, но и облегчит разработчикам .NET работу с другими языками, а разработчикам других языков - изучение. .СЕТЬ.
В-третьих, у них есть более серьезные дела, чем подавать в суд на всех, кто будет копировать имена методов и классов .NET Framework.
Теперь, если вы хотите скопировать весь .NET Framework и создать продукт, который будет использоваться многими разработчиками, проконсультируйтесь с юристом, прежде чем рисковать.
Пример:
Я был совершенно недоволен ограничением 259 символов в путях к файлам в .NET Framework и невозможностью использовать транзакции кода на уровне файлов. Поэтому я реализовал свой собственный
Fileкласс с методами, которые будут работать, как ожидается, для любого пути, а не только для крошечных коротких, и реализовывать транзакции. В первой версии я решил клонировать имена методовFileиDirectoryклассов . Microsoft подаст в суд на меня за это? Я в этом сомневаюсь.Во всех случаях во второй версии у меня появился новый синтаксис
new File(string fileName), который я считаю гораздо более интуитивным для меня . Клонирование имен методов иногда полезно, но у вас должна быть веская причина для этого.источник
System.Randomсодержит 8 методов (5 методов и 3 перегрузки, один методprotected). Я думаю, что вы вполне можете клонировать эти имена, и вам будет трудно доказать, что вы действительно скопировали эти имена из Microsoft.Защита авторских прав защищает «художественное выражение» произведения, а не техническую форму (цитируя Википедию ).
Защита авторских прав не защищает факты .
Таким образом, возникает вопрос, является ли API или интерфейс «фактом» или художественным выражением? Для простых API, которые являются просто списком способов получения случайных чисел и различных видов случайных чисел, API, вероятно, больше похоже на факт. Но я мог видеть, что очень сложный интерфейс (вы знаете, на те, на которые вы смотрите в течение минуты, а затем говорите «Ааа! Это впечатляет».) Можно считать «художественным выражением», достойным защиты.
Вот недавняя статья о Oracle и Google, борющихся за авторское право API, об этой самой проблеме, обсуждаемой в (США) судах.
Я не юрист, и этот пост не должен рассматриваться как юридическая консультация. Я даже не могу написать отказ от ответственности очень хорошо.
источник
Вы можете принять чисто функциональные аспекты, но вы не можете принять выразительные аспекты. Имя класса, имена методов и подписи являются чисто функциональными. Вам нужно, чтобы они взаимодействовали. Имена параметров и макросы заголовков можно считать выразительными. Например, в своем антимонопольном деле Windows Microsoft утверждала, что ничто не мешает конкуренту реплицировать API-интерфейсы Windows и создавать собственную платформу, на которой будут работать приложения Windows.
источник