{"id":4142,"title":"\u0412\u043e\u0437\u043c\u043e\u0436\u043d\u044b \u043b\u0438 \u0440\u043e\u043c\u0430\u043d\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u043e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0432 \u043a\u043e\u0441\u043c\u043e\u0441\u0435","url":"\/redirect?component=advertising&id=4142&url=https:\/\/vc.ru\/promo\/259126-open-talk&hash=619216e3e9743866f344bb263e71457c73d6babac6c93e7424a225d484d8095d","isPaidAndBannersEnabled":false}
Право
Moscow Digital School

Как доказать в суде, кто автор программного обеспечения?

Эксперты Moscow Digital School рассказывают, как компании защитить свой софт, какие доказательства необходимо собрать и как избежать распространенных ошибок.

Может показаться, что это легко и всегда можно будет оформить все необходимые «бумажки» потом. Но на практике очень часто бывает, что ключевые разработчики уволились и с ними больше ничего нельзя подписать, старая электронная переписка потерялась, а ключевые свидетели успели забыть, кто за что отвечал. В результате, компании не могут подтвердить авторство конкретных работников и проигрывают дело в суде.

В этой статье эксперты Moscow Digital School Анастасия Нерчинская и Вадим Перевалов рассказывают, как компании защитить свой софт, какие доказательства необходимо собрать и как избежать распространенных ошибок.

Когда необходимо доказавать авторство?

Разработчики часто хранят на рабочем компьютере свои собственные проекты, а иногда даже используют их в работе. Поскольку программа хранится на рабочем компьютере, руководство компании может считать, что это продукт компании. Разработчик же, если программа создана в нерабочее время или вне его трудовых обязанностей, может считать такую программу своей. И когда разработчик уходит в другую компанию, споры о правах на такие программы часто оказываются в суде (например, можно вспомнить обстоятельства дела NGINX, а также недавнее дело по иску А. Мамичева к ООО «Интервим»).

Если компания приобрела права на ПО не от первоначальных авторов, а у другого правообладателя, ей не всегда необходимо будет доказывать всю цепочку переходов исключительного права на ПО от первоначальных авторов до конечного приобретателя. В таких случаях компания может использовать «презумпцию правообладания». В рамках нее правообладателем считается лицо, указанное в качестве приобретателя исключительного права в договоре об отчуждении исключительного права.

Устанавливать обстоятельства возникновения авторства не требуется до тех пор, пока другая сторона в деле не начнет со ссылками на конкретные доказательства оспаривать принадлежность исключительного права предполагаемому правообладателю. Но если это произойдет, исход дела во многом будет зависеть от того, кто из сторон сможет доказать, что ПО было создано конкретными авторами и права на данное ПО перешли именно ей.

Как доказать авторство?

При доказывании авторства истцы обычно полагаются на «презумпцию авторства», согласно которой автором ПО считается лицо, указанное на экземпляре ПО, в Реестре программ для ЭВМ (который ведет Роспатент) или которое идентифицировано иным образом в соответствии с п. 1 ст. 1300 ГК РФ. Чаще всего истец предъявляет суду свидетельство о государственной регистрации ПО, в котором он указан автором. Ответчик, чтобы выиграть спор, должен опровергнуть эту презумпцию, то есть убедительно доказать, что запись о регистрации ПО является недостоверной и ПО на самом деле было создано иными лицами. При этом Верховный Суд РФ опубликовал разъяснения, согласно которым истец и ответчик могут доказывать авторство с помощью любых доказательств. О каких доказательствах идет речь?

В деле А. Мамичева против ООО «Интервим» (Определение Третьего кассационного суда общей юрисдикции от 31.08.2020 по делу N 88-10803/2020) суд ссылался на некие «общепринятые в отрасли разработки программного обеспечения, доказательства своего авторства». В числе таких доказательств суд отметил «…свидетельство о включении данного программного обеспечения в реестр российского программного обеспечения; свидетельства размещения кода программного обеспечения в какой-либо общедоступной или закрытой системе управления кодом; договоры на поставку данного, или родственному ему, программного обеспечения заказчикам - третьим лицам; документацию на разработку данного программного обеспечения; представляющие данное программное обеспечение в качестве отдельного продукта презентации возможным заказчикам, подготовленные ранее. В качестве единственного свидетельства своего авторского права истец предъявляет указание в коде программы на то, что программа разработана им...».

С данным выводом суда трудно согласиться, поскольку разработчик может не иметь намерений или договоренностей с клиентами о монетизации своего ПО. При этом если в файлах с исходным кодом будет указана информация об авторе, это будет соответствовать требованиям законодательства и должно создавать презумпцию авторства. То есть ответчик должен будет опровергнуть сведения об авторах ПО, указанные в его исходном коде.

Какое доказательство является наиболее надежным?

Наиболее убедительным доказательством для суда является заключение эксперта об авторстве. При проведении компьютерно-технической (автороведческой) экспертизы при достаточности информации в кодовой базе могут быть обнаружены файлы с информацией об авторах, а также установлен «почерк» и «стиль» конкретных авторов. Но такая экспертиза является дорогостоящей, требует значительного времени и не может быть проведена, если нет необходимых сравнительных материалов.

Как еще можно доказать авторство?

Участник процесса может попытаться доказать авторство, не прибегая к проведению судебных экспертиз. Поскольку разработка ПО практически полностью перешла «в онлайн», программисты при создании ПО почти всегда используют комплексные инструменты программирования и ИТ-системы (которые часто интегрируются друг с другом), предназначенные для создания, управления и хранения кодовой базы. Это могут быть среды разработки, хранилища информации (репозитории), трекинговые системы, системы контроля версий ПО и т.п.

Поскольку такие системы предназначены для работы в электронной среде, почти все они работают по принципу создания учетных записей (аккаунтов), через которые осуществляется доступ к их функционалу. Как правило, разработчики, создающие исходный код ПО, имеют личные учетные записи (логин + пароль) во всех используемых информационных системах. Логин (идентификатор пользователя) обычно «привязывается» к адресу электронной почты конкретного лица. Например, чтобы сохранить (записать) созданный фрагмент исходного кода в репозитории с подключенной системой версионирования, разработчик должен иметь учетную запись с правами доступа, позволяющими делать так называемые «коммиты» (операции по внесению записи в репозиторий) и «чек-ауты» (операции по извлечению конкретной версии кодовой базы на локальный ресурс разработчика).

Суды принимают в качестве доказательств скриншоты из таких информационных систем, используемых при разработке ПО В частности, суды признают допустимым установление авторов ПО на основе идентификационных данных (логинов учетных записей) при сопоставлении их с предоставленными сведениями об адресах электронной почты конкретных лиц - потенциальных авторов ПО.

В одном из споров суд при анализе доказательств авторства ПО отметил следующее: «При написании программы для ЭВМ современные разработчики используют специальные технические средства, которые позволяют фиксировать каждые изменения, их авторов и даты - т.н. «сервисы по управлению версиями». В данном случае при создании Программы был использован сервис «Bitbucket», который хранит все версии Программы, опубликованные в ходе ее создания. Работа над созданием Программы с фиксацией ее версий в репозитории «Bitbucket» была прекращена в августе 2016 года. Принт-скрины финальной версии Программы с серверной и клиентской частью для различных компьютерных и мобильных платформ, данные по записям об изменении версий программы (коммиты), позволяют увидеть хронологию развития Программы и автора каждого изменения исходного кода. Идентификация лица, которое внесло изменение в исходный код, происходит через псевдоним, который привязан к электронной почте этого лица. В коммитах отражены три электронных адреса - dima.kurilchenko@gmail.com, принадлежащий Курильченко Д.Е., kv@indee.ru и viktrorcor@gmail.com., принадлежащие Комаровских В.А. Анализ исходного кода Программы свидетельствует о том, что она была создана творческим трудом Курильченко Д.Е. (в части программного кода) и Комаровских В.А. (в части визуальных решений и программного кода). Упоминание их псевдонимов содержится во всех файлах исходного кода. Сведений о соответчиках, указанных в файлах исходного кода Программы, не содержится, что подтверждается данными из репозитория «Bitbucket». Более того, Юсибов О.Н.о. не имел доступа к исходному коду до подписания соглашения о партнерстве.»

(Решение Фрунзенского районный суд г. Санкт-Петербурга по делу № 2-3145/2018 от 18 сентября 2018 года).

Таким образом, использование инструментов разработки и управления кодом, позволяет довольно легко проиллюстрировать важные аспекты создания ПО, такие как:

· круг лиц, имеющих доступ к кодовой базе (однако, это само по себе не означает, что все они являлись авторами ПО, но авторами ПО вряд ли могут являться лица, которые не имели доступа к репозиторию);

· период создания ПО (или его конкретной версии, MVP и т.п.);

· даты «подключения» к процессу разработки и прекращения участия в ней конкретных лиц;

· хронологию развития программы;

· изменения, внесенные в каждую версию ПО, в том числе удаление строк кода;

· количество строк кода в абсолютном выражении и в процентах, созданных каждым разработчиком (это позволяет оценить значимость вклада разработчика и его роль);

· общее количество «коммитов», сделанных каждым разработчиком,

и другую полезную информацию, с помощью которой можно сделать выводы о круге предполагаемых авторов и их вкладе в создание ПО.

Кто считается автором ПО, а кто не может быть признан автором ПО?

В свидетельствах о государственной регистрации ПО очень часто в качестве авторов указываются лица, которые авторами ПО в действительности не являются, например, руководители компаний. В заявлении на государственную регистрацию заявитель делают простую отметку о том, что подтверждает достоверность сведений об авторстве, а Роспатент в процессе регистрации ПО эту информацию никак не проверяет. Это приводит к тому, что автором ПО может быть указано фактически любое (даже вымышленное) лицо.

При этом авторством нельзя наделить лицо, которое не является автором. Отказ от авторства ничтожен, а любые документы, в которых авторами ПО будут «назначены» посторонние лица, не будут иметь никакой юридической силы. Причем ссылаться в суде на недействительность таких документов сможет любой автор ПО, даже если он сам ранее подписал их.

Нередко такие ошибки совершаются потому, что у разработчиков и представителей бизнеса отсутствует понимание, кто с правой точки зрения является автором ПО.

Авторами ПО могут являться только лица, чьим творческим трудом создано ПО. Несмотря на крайне низкий «порог» творчества, под которым обычно понимается самостоятельность создания ПО, а не его новизна и принципиальная неповторимость, в этом вопросе не все так однозначно. Например, вклад разработчика, «связавшего» множество компонентов с открытым исходным кодом в один продукт, используя стандартные средства обеспечения совместимости (interoperability) библиотек, вряд ли будет признан творческим. А значит, не такой разработчик не может считаться автором ПО.

Не могут признаваться авторами ПО лица, оказавшие его автору только техническое, консультационное, организационное или материальное содействие или помощь при создании ПО, либо только способствовавшие оформлению прав на ПО.

Также не являются авторами ПО лица, осуществлявшие контроль за выполнением соответствующих работ. В частности, суды подтверждают, что не могут признаваться авторами ПО лица, которые придумали идею ПО, но не участвовали в ее реализации (то есть непосредственно в создании кодовой базы), например, архитекторы, тестировщики и отладчики ПО.

Также, по мнению судов, не признается авторским вкладом согласование технического задания, функционала ПО, формирование бэклога, коммуникации с представителями бизнеса по вопросам коммерциализации ПО, организация бизнес-процессов, продумывание стратегии выхода на рынок, планирование развития ПО и его обновлений, создание презентаций, демонстрирующих свойства ПО, предполагаемые доходы инвесторов, отличия программы от ПО конкурентов и подобные активности.

Поэтому при необходимости доказывания авторства ПО следует внимательно оценить роль и личный вклад в создание ПО конкретных лиц.

{ "author_name": "Moscow Digital School", "author_type": "editor", "tags": [], "comments": 18, "likes": 4, "favorites": 20, "is_advertisement": false, "subsite_label": "legal", "id": 214946, "is_wide": false, "is_ugc": false, "date": "Mon, 01 Mar 2021 11:51:57 +0300", "is_special": false }
0
18 комментариев
Популярные
По порядку
Написать комментарий...
3

Коллеги, спасибо за упоминание дела! Хотелось бы дополнить, что несмотря на процитированную формулировку про подтверждение авторства (это просто цитата экспертов), суды всех инстанций это просто упомянули, но фактически в решениях называли меня автором, а произведение - НЕ служебным.

Главная загвоздка - и мне кажется, что это заслуживает упоминания - это два момента, связанные с библиотеками и открытыми лицензиями. Получилось длинновато, хотя это только верхушка айсберга.

1. Суд (не без помощи ответчиков) посчитал программу для ЭВМ, использующую библиотеки, составным произведением, т.е., фактически, приравнял ее к альбому или сборнику. Вы упоминаете в статье про "связующий код" - это почти дословно то, что придумали и ответчики, пытаясь уйти от ответственности.

Но одно дело, когда выпускается нечто наподобие сборника программ для учебы или лучших песен года, где автор-составитель только сделал оболочку с перечнем программ/фильмов/песен (и здесь нужно различать - написал он ее сам с нуля, или использовал чужой готовый продукт, если первое - то он еще и автор одного из составных элементов в дополнение к составительству). И при этом составление списка и расположения таких программ - это творческий процесс, прямо закрепленный статьями 1259 и 1260 ГК РФ. Результат - подбор и расположение, но никак не некий связующий код. При этом составные элементы представляют собой ценность и при их извлечении (например, при наличии запрета автора) теряется смысл произведения - это будет уже другой состав и расположение.

А другое дело - когда есть самостоятельная программа, а библиотеки только выполняют вспомогательные функции. Например, в моем продукте одна из двух библиотек под лицензией GNU GPL (про эту лицензию пункт 2) использовалась только для определения длины MP3-файла в секундах (что легко может быть сделано и самостоятельно, но с открытой библиотекой идея реализовалась за пару минут, а так пришлось бы вникать в формат заголовка MP3).

И тогда это программа для ЭВМ - статья 1261 ГК РФ. Эта статья специально для таких случаев содержит в качестве примера операционные системы - их без библиотек просто не бывает. Любая библиотека может быть заменена на другую либо переписана автором - и для пользователей программы, в целом, особенно ничего не изменится.

2. И самый главный момент - суд неправомерно применил копилефтные ограничения лицензии GNU GPL v2, потому что судебный эксперт исключительно в целях оценки использования отнес мою программу к "коробочным продуктам". Обратите внимание - не установил факт распространения (как мы знаем, копилефт триггерится только тогда, когда есть *распространение копий или публикация* модифицированного кода чужой библиотеки под GNU GPL v2), а просто зацепился за слово, которое вообще не имеет определения в законе и само по себе никакое распространение не означает (да и сам коробочный характер еще надо доказывать - в деле не было ни дистрибутива, ни коробки, ни документации - кроме написанных специально для экспертизы, потому что облачные продукты не предполагают распространения и, соответственно, user friendly документации - о чем сами же эксперты и написали в технической части).

При этом суд посчитал, что я предлагал программу за деньги, хотя должен был бесплатно, но в процессе досудебной переписки и обсуждения ситуации я в итоге прямо указал, что оплата - за поддержку, а сама программа - бесплатно. 

Хотя в любом случае копилефтные ограничения не могли применяться, поскольку в случае моего дела имел место перенос оригинала программы с моего облачного сервера на облачный сервер ответчика, т.е. по сути облачный сервер сменил хостинг, но не владельца. Копия не отчуждалась и не распространялась, а пользователи программы вообще не заметили изменения месторасположения программы.

Ответить
3

На основании этих двух заблуждений суд (неправомерно) решил, что, дескать, поскольку моя программа для ЭВМ - якобы составное произведение, а я в нарушение GNU GPL предложил использование программы за деньги, то на основании пункта 3 статьи 1260 ГК РФ я не имею права осуществлять свои авторские права, а поэтому отказал в иске. Под шумок - еще и в требовании признания автором, хотя в тексте решения меня автором называл, и вывод судебного эксперта в том, что в программе имеются указания на меня как на автора - не опроверг.

Также суд заявил, что я не предоставил доказательства наличия права использования ряда продуктов (до кучи докинув туда и те продукты, которые в программе никак не использовались - например, iSpring - отсутствие какой-либо связи с ним подтвердила и судебная экспертиза), хотя такие доказательства были неоднократно представлены.

Что мы имеем в итоге? Верховный суд (на текущий момент, у председателя ВС есть жалоба на формальную отписку одного из судей ВС РФ, но дальнейшее развитие непредсказуемо), подтвердив отказ в иске, фактически на высшем уровне утвердил следующее положение вещей:

1. Если кто-то нарушил права разработчика ПО, то нарушитель может затребовать предоставления доказательства права использования всех и каждой библиотек (а их может быть значиииительно больше), и в случае, если суду непредсказуемо (забавно, что 3-КАС сам заявлял о предсказуемости судебного процесса) не понравится хоть какое-то из них (или суд просто их проигнорирует), то *без привлечения правообладателей* и изучения их мнения (да и проверки наличия прав у них самих) суд может:
а) лишить разработчика ПО права использовать свой продукт ПОЛНОСТЬЮ, а не в части спорных библиотек, и, фактически, отнять авторские права, просто не признав их;
б) освободить нарушителя от какой-либо ответственности (не только за использование, но и за незаконную модификацию и циничное удаление знака охраны авторского права);
в) отнести на автора, защищающего свои нарушенные права, чьим произведением с грубейшим нарушением авторского права нарушители пользовались несколько лет, судебные расходы, полностью игнорируя тот факт, что нарушители сами лишились всех прав по GNU GPL v2, когда сначала присвоили себе имущественные права, а потом вообще вырезали указание на автора.

2. Если в вашем коде есть подключаемые библиотеки GNU GPL v2 (не обязательно переработанные, достаточно просто подлинковать, причем динамически, причем только при вызове этих функций), вы загружаете ваше веб-приложение на хостинг (очевидно, включая и репозитории, и даже онлайн-диски типа OneDrive/Яндекс.Диск), то хозяин хостинга сразу же получает все свободы на ваш продукт. Т.е., может забрать его себе и свободно использовать, начать его модифицировать и распространять, в том числе и за деньги (GNU GPL разрешает брать плату за предоставление копии, "хоть в миллиард долларов" - фонд так сам пишет), не спрашивая вашего разрешения.

Ответить
2

Ваши комментарии намного оползней самой статьи как по мне.

Ответить
1

Спасибо :) я попытался дополнить один важный аспект, который теперь нужно обязательно учитывать 

Ответить
0

Антон, так ты суд выиграл уже или еще судишься?

Ответить
0

Я уже проиграл :) 

Ответить
0

Хорошая статья и примеры из практики. Но я своим заказчика всегда задаю только один вопрос: оно вам надо вот это все когда петух клюнет в ж...у, и не проще ли дать делопроизводителю Маше заранее разработанные и согласованные формы документов по созданию служебных произведений и раз в месяц/квартал их подписывать по ключевым продуктам, точно так же как подписываются графики отпусков или приказы на приём в штат сотрудников.
Но мы хотим уйти от бумажного документооборота говорили они - ну нет проблем, только это не означает черную дыру в нем, а внедрение ЭДО и ЭЦП (простых). Совсем другие могут быть затраты.

Ответить
1

Достаточно использовать трекер/репозиторий (Jira/Git), прописать внутренние правила, что трекер - это официальное средство постановки служебных заданий, а репозиторий - это официальное хранилище и источник кода для продукта, раз в период делать резервные копии и каким-либо образом фиксировать SHA-256 хэш этого архива - по сути самый простой вариант цифрового отпечатка (подписывать протокол с командой разработки, заверять у нотариуса, загружать в Archive.org и т.п.) - тогда в любой момент времени можно показать динамику развития, если возникнет спорный вопрос. Никаких особенных затрат не будет, ведь эти продукты и так используются. 

Ответить
1

Да, это хорошая техническая реализация (она может быть различной). SHA хорошая история, сама ее использую в актах и договорах, когда нет возможности записать диск. Только это именно техническая реализация и ее НЕ достаточно самой по себе для обеспечения юридического оформления отношений по поводу создания и использования произведений (в том числе, служебных). Суду в случае спора вам придется продемонстрировать именно факт заключения сделки (договора) или факт оформления служебного произведения (и сопутствующие документы в рамках ТК РФ). Могут ли это быть исключительно электронные документы и записи - безусловно! Только для этого необходимо соответствующее соглашение об ЭДО с рабоником (или регламент в договоре с подрядчиком), ЭЦП (простой) и корреспондирующие с представленными соглашениями движения в электронных системах (то, что вы описали). Если вы имеете в виду это под "прописать внутренние правила" - ну да, это оно и будет. Либо, если все это делать не хочется, конкретные служебные задания и отчёты об их выполнении. В противном случае суду придется додумывать что же у вас там происходит и рассматривать просто отдельные доказательства - и к какому выводу он придет никому не известно.

Ответить
1

И обязательно прописанные обязанности по программированию в должностной инструкции, иначе сам факт служебных заданий на разработку библиотеки кода у, например, шеф-повара не означает создания служебного произведения. А то потом адвокаты работодателя будут кричать в суде: "когда мы человека на работу берем, мы же не знаем, чем он заниматься будет" :)

Ответить
1

Я согласна, что факт присутствия в должностной инструкции конкретных обязанностей - один из возможных маркеров, который оценивается судами при разрешении способов о служебном характере произведений. И да, про должностные обязанности прямо есть в п.1 1259 ГК. И я согласна, что мы в ТК найдем все касаемо трудовой функции, и о том, что выполнение работы не обозначенной ТД/ДИ не возможно без доп.соглашения и так далее (кстати никто не мешает оформлять служебное задание как часть доп соглашения к ТД о выполнении конкретной работы, что исклдчит вообще эту проблему). И, безусловно, всем своим заказчикам рекомендую для решения вопроса при оформлении служебных произведений не оставлять без рассмотрения вопросы ТК (содержание трудового договора как минимум, там тоже отлично все прописывается). В общем это комплексный вопрос просто. Ещё и авторское вознаграждение надо заплатить, отдельно от зарплаты в согласованном размере, ага))
Мы не знаем чем он заниматься будет - это конечно же детсад и кривое противоречие ТК

Ответить
1

+ начать использовать в течение 3 лет, иначе все вернется работнику :-)

Ответить
1

Ну конечно. Итого, то что я написала в первом комментарии: можно ли все оформлять электронно? Без б, только это потребует формализации огромного числа процессов на уровне локальных нормативных актов организации и приведение их в соответствие с реальными техническими процессами. Если это целесообразно (объем работы, время, цели, деньги) - все это можно родить. Если надо оформить права на несколько служебных произведений с известным количеством авторов - проще сделать формы (уточнить ТД при необходимости) и подписать их на бумаге ручками один раз (или ежеквартально) и не мучить одно место.

Ответить
0

Молодцы какие - автором ПО архитектор и автор идеи признан быть не может. А 2 джуна под управлением - получаются авторы. Прикольно так.
Поэтому на ПО надо делать документы на создание служебного произведения где явно прописывать авторов, а с "коммитерами" подписывается соглашение типа CLA.
Статья неоднозначная - больше юридическая, без привязки к реальности ИТ производства. Но полезная - для общего образования

Ответить
0

Честно говоря, я сомневаюсь, что архитектор не может быть признан соавтором. Архитектура ПО - это подготовительный материал, что прямо включено в состав программы для ЭВМ в статье 1261 ГК РФ.

А вот автор идеи действительно не может быть автором (это прямо указано в статье 1259 ГК РФ).

Если он придумал идею и организовал разработку ПО, то он - лицо, организовавшее создание сложного объекта, и его права защищаются статьей 1240 ГК РФ. Главное - оформить все правильно, чтобы никто не оспорил отчуждение исключительного права от авторов.

Если же он просто пришел и поделился идеей, и ничего в итоге не получил, то... это суровая действительность.

Ответить
0

Что значит идея ? Как понять что идея есть ? Какой артефакт с точки зрения ГК РФ может считаться идеей, а может не считаться ?
Если я внутрь репозитория GIT положу файлик с наименованием MAIN-IDEA.md - гд опишу основную идею то внезапно я соавтор произведения - потому как автор исходного кода.
А если я положу внутрь репозитория файлик с именем ARC42.md, а если я еще и ARD.md туда положу - то извините я главный автор. О остальные только сооавторы ;-)

Ответить
0

ИМХО, довольно просто:

1. Как только это что-то, выраженное на любом языке программирования (статья 1261 ГК РФ) - пусть даже батник или какой-то метаязык (даже древний Лого) - это объект авторского права и он защищается

2. Если идея оформлена в виде статьи, а кто-то возьмет и опубликует ее у себя на сайте в чистом или слегка измененном виде, да еще и без ссылки (хотя описание идеи вряд ли подпадает под исключения об использовании без согласия автора) - это нарушение. Но в данном случае защищается не сама идея, а ее литературная форма.

Интересный кейс был с очень известным американским фокусником Теллером (он еще известен как отец Эми в Теории большого взрыва). Фокусы не защищаются авторским правом, но он зарегистрировал сценарную постановку, и когда другой фокусник не просто разгадал секрет, а повторил весь сюжет - Теллер его и засудил.

Но если кто-то прочтет эту статью и реализует алгоритм полностью по-своему, то предъявить ему будет нечего.

3. Еще можно защитить реализацию конкретных интерфейсов, поскольку они являются порождаемыми аудиовизуальными материалами и входят в состав программы для ЭВМ (статья 1261). Даже набросок UI, если он сделан достаточно детально, можно попытаться использовать (попытаться - потому что в спорной ситуации степень сходства наброска и реализации будет решать суд или привлеченный им эксперт).

Ну и наконец, можно попробовать запатентовать программу. В чистом виде программы для ЭВМ не патентуются, но если придумать какое-то техническое решение, частью которого будет программа - тогда возможности есть.

Ответить
Читать все 18 комментариев
Как Яндекс забирает «хлеб» у рекламных агентств — алгоритмы Директа в B2B-тематике

Стоит ли использовать автостратегии Яндекс Директа при малом количестве конверсий, да еще в B2B-тематике? История про роботов, научившихся продавать подшипники. Кейс интернет-магазина PodTrade

ТМК и Агентство инноваций Москвы запустили акселерационную программу для московских стартапов

Трубная Металлургическая Компания (ТМК) и Агентство инноваций Москвы запустили акселерационную программу в рамках трека «Московского акселератора» PipeIndustryTech.

Опять сгорели дедлайны, хотя ты распланировал весь день?
Браузер Brave от сооснователя Mozilla запустил бета-версию собственного поисковика Статьи редакции

Он не отслеживает данные пользователей.

Главная страница
Кейс. Как увеличить конверсию приложения на 6,3% за счет графического ASO?

Показываем на примере приложения для занятий спортом, как с помощью качественной и продающей графики на странице в Google Play увеличить конверсию из просмотра в установку на 6,3%. Бонус: пять примеров конвертирующей графики.

В Москве запретят ходить в кафе без прививки, отрицательного теста на Covid-19 или антител: как это будет работать Статьи редакции

Проверять их будут по QR-кодам.

Декаданс венчурного капитала: как взращиваются современные «единороги»

DoorDash предлагал клиентам пиццу за $16 из ресторана, где она стоит $24. Сервис проката самокатов Bird терял $27 на каждые заработанные $10. Примеров компаний, предоставляющих субсидируемый инвесторами сервис, масса: Uber, WeWork, Airbnb и другие. Весь их «дисрапшн» — продажа доллара за полцены.

Независимая лаборатория не смогла найти тунец в сэндвиче с тунцом из Subway — NYT Статьи редакции

Журналисты отправили образец на независимую экспертизу, которая не смогла определить, мясо какой рыбы использовали в еде.

Уроки 2020 года или как мы выросли в два раза быстрее рынка

Прошедший год для всех стал настоящим испытанием. Мы расскажем вам о том, как мы прошли эту полосу препятствий, помогли преодолеть ее нашим клиентам и сотрудникам и какие уроки вынесли из 2020.

Лондонский хедж-фонд, ставивший на падение акций GameStop, объявил о закрытии Статьи редакции

Но бунт трейдеров с Reddit — это не основная причина закрытия фонда, который управлял активами на $440 млн.

Комментарии
null