К вопросу о совместимости свободных (открытых) лицензий и возможности их использования в технологии Blockchain (В. Нагродская, журнал "ИС. Авторское право и смежные права", N 11, ноябрь 2017 г.)

К вопросу о совместимости свободных (открытых) лицензий и возможности их использования в технологии Blockchain*(1)

В. Нагродская,

(г. Москва)

Журнал "ИС. Авторское право и смежные права", N 11, ноябрь 2017 г., с. 39-55.

Введение в Гражданский кодекс Российской Федерации (далее - ГК РФ; Кодекс) [1] статьи 1286.1 способствовало изменению многих традиционных подходов, связанных с распоряжением исключительным правом на произведение. Так, лицензионный договор, по которому автором или иным правообладателем (лицензиаром) предоставляется лицензиату простая (неисключительная) лицензия на использование произведения науки, литературы или искусства, может быть заключен в упрощенном порядке (открытая лицензия). Открытая лицензия является договором присоединения.

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

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

Совместимость (или также интероперабельность) открытых лицензий должна быть обеспечена абсолютной точностью в толковании условий лицензий.

Наибольшее количество вопросов может возникнуть при двойном лицензировании (использование результата интеллектуальной деятельности под двумя не исключающими друг друга лицензиями) и мультилицензировании (использование результата интеллектуальной деятельности под несколькими лицензиями одновременно).

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

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

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

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

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

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

Разработка совместимых открытых лицензий является одним из наиболее сложных вопросов. Если лицо использует контент*(2) на основании несовместимых лицензий, дальнейшее легальное распространение такого контента будет невозможно. Это приведет к блокировке создания производных произведений на основе оригинального произведения (например, на тех же условиях) или же к необоснованному игнорированию тех или иных условий лицензии.

Несовместимость лицензий также опасна тем, что соблюсти их условия станет невозможно, поскольку они будут взаимоисключать друг друга. Так, например, если в лицензии А сказано, что расширенные программы должны быть под лицензией А, а в лицензии Б сказано, что расширенные программы должны быть под лицензией Б, то это неустранимое разногласие; лицензия совмещенной программы должна быть лицензией А и она должна быть лицензией Б [2]. В ситуации с GPL ее распространение с BSD будет означать фактически паразитирующий, "вирусный" характер GPL, поскольку GPL потребует полного распространения результата интеллектуальной деятельности только на ее условиях.

Как указал Ричард Столлман*(3), несколько лицензий совместимы, если есть способ соединять программы под этими разными лицензиями, удовлетворяя им всем [2]. При возникновении спора суд примет во внимание буквальное значение содержащихся в договоре слов и выражений. Буквальное значение условий договора в случае его неясности устанавливается путем сопоставления с другими условиями и смыслом договора в целом. Однако если содержание договора не может быть определено, должна быть выяснена действительная общая воля сторон с учетом цели договора (статья 431 ГК РФ).

Совместимость лицензий должна рассматриваться с учетом особенной тех или иных свободных (открытых) лицензий. Говоря о лицензиях Creative Commons (CC), должен учитываться вид каждой конкретной лицензии.

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

Совместимость лицензий является ключевым вопросом, так как позиция "All rights reserved" заменяется на позицию "Some rights reserved", что недопустимо без согласия правообладателя. Согласно первой позиции, означающей "Все права защищены", автор сохраняет все права, при этом не действуя своей волей в частных и публичных интересах, направленных на развитие творчества и инноваций. Вторая позиция, в переводе означающая "Некоторые права защищены", указывает на то, что автор самостоятельно предоставляет право использования неограниченному кругу лиц на определенных им условиях, при этом изначально желая распространить контент как можно большему количеству лиц и не намереваясь осуществлять строгий контроль за последующим использованием произведения. Представляется, что во второй позиции правообладатель реализует свое право использовать произведение по своему усмотрению любым не противоречащим закону способом.

Тем не менее, возможность использования произведения с расширенным перечнем способов, как правило, безвозмездно, на территории всего мира, в течение всего срока действия исключительного права не может быть реализована без первоначального согласия самого правообладателя.

Особенно хотелось бы выделить ситуацию, связанную с так называемыми "свободными произведениями культуры" [3, с. 217-222]. На наш взгляд, предоставление права использования "свободных произведений культуры" возможно с помощью лицензий СС, а также иных лицензий, которые могут быть совместимы с данным контентом. Так, известны четыре свободы, которые должна предоставить лицензия для таких произведений, а именно*(4):

1) свобода использования и исполнения произведения;

2) свобода изучения произведения и применения информации;

3) свобода распространения копий;

4) свобода распространять производные произведения.

Для "свободных произведений культуры" необходимо не только наличие свободной лицензии, но и признание свободным самого произведения*(5). В 2006 году Эрик Меллер разработал определение "свободных произведений культуры", решив снять неоднозначность в словах "свободный контент" для проектов Википедии [4]. На тот момент существовали противоречия между понятиями "открытый контент" и "свободный контент".

Во многом на разработчиков лицензий "свободных произведений культуры" повлияли Критерии Debian для свободного программного обеспечения*(6). В связи с этим Э. Меллеру хотелось доказать, что основной ценностью является не открытый доступ к тому или иному произведению, а возможности, с помощью которых можно было бы продвигать творчество в новых, больших масштабах.

В итоге "свободные произведения культуры" были определены Э. Меллером в 2006 году как произведения, которые могут свободно изучаться и применяться, копироваться и/или изменяться кем угодно, для каких угодно целей. Ричард Столлман, Лоуренс Лессиг*(7), Анджела Бизли*(8) также принимали участие в разработке определения. С помощью создания данного определения окончились разночтения между понятиями "открытый контент" и "свободный контент", поскольку термин "открытый контент" не употреблялся в значении использования для любых целей, а также не обращал внимание потенциальных пользователей на важность сохранения значения свобод.

Дополнительными критериями для идентификации "свободных произведений культуры" являются такие, как, например, наличие исходных данных, использование свободного формата*(9), отсутствие технических ограничений, отсутствие в целом других ограничений и запретов*(10). Полагаем, что указание разработчиками на недопустимость нарушения права на неприкосновенность частной жизни, отсутствие договора*(11) не могут являться ограничениями априори: подобный либеральный подход, скорее, создаст условия для абсолютно неконтролируемого использования контента.

Следует указать на существование специальной лицензии Against DRM*(12), в которой прямо указано, что "лицензия несовместима с любой технологией, устройством или компонентом, который в обычном процессе эксплуатации предназначен для предотвращения или ограничения действий, которые разрешены или не разрешены лицензиаром: эта несовместимость приводит к неприменимости лицензии для работы"*(13).

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

Лицензии "свободных произведений культуры" стали известны в качестве таковых через специальный знак "Approved for free culture works". Из всех лицензий данной группы только две могут быть отнесены к лицензиям "свободных произведений культуры": Attribution и Attribution-ShareAlike. Во многом на это обстоятельство повлиял тот факт, что они являются свободными, в отличие от остальных, несвободных лицензий группы Creative Commons.

Разработчики "свободных произведений культуры" одобрили и другие лицензии, например, к ним могут также приравниваться Design Science License, Free Art License, MIT и другие. Так, с помощью отобранных ими критериев, например, таких, как наличие "вирусного" характера (через конструкцию копилефта), практической изменчивости, указания авторства, охраны смежных прав, запрета контроля доступа и всемирной применимости можно было определить, может ли та или иная лицензия сочетаться с другой. Разработчики находятся в постоянном поиске совместимых лицензий. Так, например, в конце октября 2014 года стало известно о том, что Free Art License 1.3 и CC Attribution-ShareAlike 4.0 совместимы*(14). В дальнейшем планируется разработка совместимых версий лицензий подвидов CC и GPL, что ранее представлялось практически невозможным.

На основании особенностей лицензий "свободных произведений культуры" нами предлагается перечень критериев, по которым та или иная лицензия может оцениваться в качестве лицензии "свободных произведений культуры":

1) прямое отнесение лицензий к числу свободных;

2) отсутствие технических средств защиты авторских прав;

3) наличие свободного формата;

4) действие на территории всего мира;

5) отсутствие ограничений, налагаемых на другие результаты интеллектуальной деятельности;

6) отсутствие ограничений, связанных со сферой и целью использования произведения.

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

На наш взгляд, необходимо полностью согласиться с точкой зрения К.М. Мешковой, по мнению которой отсутствие требования о совместимости свободных лицензий, а равно обязанности пользователя проверить программное обеспечение, планируемое к использованию по лицензии, на совместимость лицензий может привести к тому, что при разработке той или иной программы для ЭВМ будут совмещены фрагменты программного обеспечения, используемого на условиях, несовместимых друг с другом, которые, с учетом "вирусного" (наследуемого) характера свободных лицензий, должны будут одновременно применяться ко всему комплексу созданного программного обеспечения. К.М. Мешкова предлагает закрепить за пользователями, желающими использовать СПО (свободное программное обеспечение - прим. В.Н.), обязанность проверять совместимость условий свободной лицензии, на основании которой оно распространяется, с условиями других лицензий [5, с. 79]. Думается, что проверка совместимости лицензий должна являться обязательным требованием для всех пользователей, поскольку если лицо воспользуется произведением не в рамках лицензии, права автора (или иного правообладателя) будут нарушены. Более того, лицензиар размещает условия лицензии таким образом, чтобы лица ознакомились с ними перед началом использования соответствующего произведения. В этой связи презюмируется, что лицо осуществляет все необходимые действия по проверке совместимости лицензий, действуя при достаточной степени внимательности и осмотрительности. При этом разработчики лицензий должны принимать все меры к тому, чтобы лицензия была технологически нейтральной, то есть права, даваемые лицензией, не должны как-либо зависеть от особенностей технологий или стиля интерфейса [6, с. 111].

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

Обратимся к сравнению GPLv2 и GPLv3. Данные лицензии являются разными версиями хорошо известной всем General Public License (GPL). Однако две эти лицензии несовместимы. Как указывает Ричард Столлман, "нет законного способа сочетать тексты под GPLv2 с текстами под GPLv3 в единой программе. Это происходит потому, что как GPLv2, так и GPLv3 являются лицензиями с авторским левом: в каждой из них сказано: "Если вы включаете тексты под этой лицензией в более крупную программу, то эта более крупная программа тоже должна быть под этой лицензией"*(16). Проблема может возникнуть, если есть необходимость объединить код из двух различных программ в одну единую программу. GPLv3 решает вопрос тивоизации, просто запрещая ее. Как эмоционально высказывается Столлман, "адвокаты Microsoft - не глупые люди, и в следующий раз они могут избежать ошибок, но GPLv3 отвечает: "Следующего раза не будет"*(17).

Негативная оценка тивоизации последовала после того, как Microsoft пытался использовать новый механизм, ограничивающий для пользователя свободный запуск любых операционных систем на своем же оборудовании. Компания пыталась обязать всех независимых OEM-производителей компьютеров*(18) с предустановленной Windows 8 включить Secure Boot*(19) по умолчанию. При этом даже если отключение Secure Boot было возможно через BIOS*(20), система несколько раз уведомляла пользователей, что это "небезопасное решение", которое не рекомендуется использовать*(21). В рекомендациях Free Software Foundation указано о том, что дистрибьюторы ограниченных систем обращаются к проблемам безопасности, но на самом деле приходится защищаться от них самих. По мнению FSF, программное обеспечение, которое приводит в жизнь технологические ограничения, является вредоносным программным обеспечением. FSF прямо указало на то, что будет бороться с Microsoft, позволив пользователям установить операционные системы свободного программного обеспечения*(22).

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

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

Ричард Столлман уделял особое внимание проблеме совместимости лицензий, написав практическое руководство для разработчиков. Он выделил три группы лицензий: слабые, промежуточные и копилефт-лицензии, указав на то, что последние несовместимы, в связи с чем необходимо использовать формулировки, касающиеся применения GPL и ее поздних версий или же явно разрешить обновление до будущих версий [2]. Дэвид А. Уилер наглядно показал возможность комбинирования лицензий [7].

  Permissive     Weakly Protective  Strongly Protective     Network

                                                          Protective

 /-----------\    /-------------\   /------------------\

 |  Public   | /-|  LGPLv2.1   |--|      GPLv2       |

 |  Domain   | |  |             |   |                  |

 \-----------/ |  \---------------\ \------------------/

              |                 |          

 /-----------\ |  /-------------\ \-------------------\

 |  MIT/X11  | |-|  LGPLv2.1+  |--|      GPLv2+      |

 \-----------/ |  \-------------/   \------------------/

              |                            

 /-----------\ |  /-------------\   /------------------\   /---------\

 |  BSD-new  | |  |   LGPLv3    |   |      GPLv3       |   | Aff ero |

 |           |---| or LGPLv3+  |--|    or GPLv3+     |--|  GPLv3  |

/------------/    \-------------/   \------------------/   \---------/

|     

|/-----------\    /-------------\

||Apache 2.0 |---|   MPL 1.1   |

|\-----------/    \-------------/

|                     

\---------------------/

Рис. 1. Совместимость лицензий (Дэвид А. Уилер)

Так, по мнению Д.А. Уилера, разрешительные (permissive) лицензии, могут быть совместимы с режимом общественного достояния и рядом других разрешительных лицензий, поскольку фактически позволяют осуществлять любые действия с результатом интеллектуальной деятельности. Слабо защищающие (weakly protective) лицензии являются компромиссом между разрешительными и сильно защищающими (strongly protective) лицензиями*(23).

В отличие от GPL, с которой несовместимо довольно-таки большое количество лицензий, разрешительные лицензии в основном совместимы между собой, поскольку практически не содержат обязанностей*(24).

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

Общепринято, что лицензии для программного обеспечения (наподобие GPL, MPL) и других результатов интеллектуальной деятельности (например, лицензии Creative Commons) существуют отдельно друг от друга. Разработчики лицензий прямо указывают, что не рекомендуют использовать лицензии Creative Commons для программного обеспечения, поскольку последние не оговаривают вопросы, касающиеся объектного и исходного кода и не предназначены для ПО.

Хотя стоит отметить, что Creative Commons охватывает некоторые лицензии на свободное ПО и ПО с открытым исходным кодом посредством "человекочитаемых" описаний лицензий Creative Commons (Commons Deed) и машиночитаемых метаданных. Разработчики осуществили этот замысел с целью возможного использования преимуществ описаний и метаданных CC, но в конечном итоге все равно продолжали лицензировать контент на условиях лицензий на ПО*(25). Подобная техническая подоплека была воспринята достаточно спокойно, поскольку условия лицензий не нарушались и не изменялись*(26).

Министерство связи и массовых коммуникаций Российской Федерации разработало Методические рекомендации по использованию свободного программного обеспечения в деятельности федеральных органов исполнительной власти, где также указывается о несовместимости лицензий. В данном документе говорится, что для преодоления несовместимости лицензий правообладатели применяют кросс-лицензирование, разрешая использование программ на условиях как одной, так и нескольких свободных лицензий (нескольких версий лицензии), среди которых лицензиат выбирает нужную ему лицензию*(27).

Там же указано, что совместимость лицензий - это возможность создания программы для ЭВМ на основе двух программ, право использования которых было получено на основании разных лицензий, последующего распоряжения исключительным правом на созданную таким образом программу и ее использования при одновременном соблюдении условий обеих лицензий*(28).

Совместимость лицензий является важным вопросом, поэтому представляется, что лицензии должны быть соотнесены между собой по внутреннему коду, который бы позволял выяснить возможность взаимоисключения лицензий*(29). Одним из выходов видится дальнейшее лицензирование отдельных частей произведения под несколькими видами лицензий, среди которых имела бы место разрешительная лицензия, не накладывающая "вирусный" эффект к дальнейшему использованию произведения.

Резюмируя, думается, что основными тенденциями разработки совместимых свободных (открытых) лицензий должны стать:

1) усилия разработчиков по совмещению действия условий лицензии для программ для ЭВМ и иных объектов;

2) техническое тестирование возможности совмещения действия лицензий в зависимости от предоставляемых прав;

3) фильтрация контента по внутреннему коду для целей взаимоисключения несовместимых лицензий;

4) включение в текст лицензии требования, касающегося проверки совместимости лицензий.

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

Точки зрения относительно правовой природы смарт-контрактов не являются одинаковыми.

Так, в целом можно обозначить две противоположные общие позиции:

1) это технический способ исполнения договора. Например, в штате Аризона (США) смарт-контракт определили как программу, которая приводится в действие определенными событиями, отражает определенное состояние, выполняется на определенном, децентрализованном, находящемся в совместном доступе, тиражируемом реестре и способна контролировать активы, учтенные в таком реестре, а также инициировать их передачу*(30);

2) это сам договор. Так, например, известный юрист А.И. Савельев определил смарт-контракт как договор, существующий в форме программного кода, имплементированного на платформе Blockchain, который обеспечивает автономность и самоисполнимость такого договора по наступлении заранее определенного в нем обстоятельства [8].

Не ставя целью детальное рассмотрение определения смарт-контрактов, хотелось бы отметить, что технология Blockchain вполне может быть использована в сфере искусства. Контент, на который права предоставляются с помощью подобных лицензий, может автоматически привязываться через метаданные без необходимости осуществления отдельных дополнительных действий правообладателем. В случае если лицо изначально установит определенные пределы, до превышения которых не будут нарушаться его права, данные ограничения могут также автоматически привязываться к записи как условия использования произведения. Произведения, находящиеся в общественном достоянии, с помощью правового инструмента лицензий Qeative Commons Public Domain Mark, имеющих информационную функцию, в том числе могут быть технически привязаны к объектам через специальный HTML-код. Российская открытая лицензия, более того, не исключает возможности получения вознаграждения за распространение произведения. Однако любые платформы, использующие свободные (открытые) лицензии в смарт-контрактах должны работать на принципах равенства всех участников, открытости и прозрачности.

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

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

Необходимость абсолютной определенности условий смарт-контракта делает еще более привлекательным использование свободных лицензий, среди которых, в частности, выделяются лицензии Creative Commons, работающие со специальными значками, чтобы быть понятными всем пользователям. Более того, разработчики данных лицензий следят за однозначностью толкования условий.

Есть несколько проектов, использующих свободные лицензии. Например, можно выделить проект Mediachain, особенностью которого является специальная система цифровой идентификации и добавление в произведение метки времени. Сооснователи Mediachain Джесс Уолден и Денис Назаров высказали по этому поводу свою позицию: "Мы создали Mediachain не как реестр авторских прав, это, скорее, база данных, которая хранит информацию о создателях"*(31). Mediachain построен на открытом исходном коде и активно использует свободные лицензии Creative Commons. Представляется, что лицензия СС SA является наиболее подходящим способом распоряжения исключительным правом на произведение, поскольку с помощью нее сохраняется возможность автора (или иного правообладателя) осуществлять желаемый контроль над последующим использованием произведения. Подобная лицензия максимально верно "вписывается" в архитектуру Blockchain.

Другим проектом является французский Ascribe, использующий свободные лицензии Creative Commons. Преимущества лицензий позволяют сохранить указание авторства и метаданные в "облаке". Поделиться творением не составляет никакого труда, поскольку единый публичный URL позволяет видеть адрес работы, имеется ссылка для загрузки, данные о лицензии и метаданные (название, создатель, год). Загрузить в систему можно совершенно любой файл, как литературные, так и музыкальные, фотографические произведения, поскольку хэширование не зависит от видов произведений*(32).

Сторонником работы платформ, использующих свободные лицензии, является проект Creativechain, продвигающий распространение произведений на условиях Creative Commons. Данный проект отличает желание выразить идеи свободной культуры, заложенные Лоуренсом Лессигом*(33).

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

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

Проблема дублирования объектов интеллектуальных прав может иметь место в случае если он используется на разных платформах. Тем не менее, нельзя не оговориться о том, что использование объектов в разных платформах вполне законно, ведь каждая платформа имеет свою white paper, с условиями которой лицо соглашается. Ничто не мешает реестрам иметь функции безопасного поиска и фильтрации контента по внутреннему распознаванию. Система может быть связана с цифровыми отпечатками, образцами контента, которые загружаются самим правообладателем. Известно, что в Российской Федерации авторские права на произведение действуют без необходимости их регистрации, однако проблема в Blockchain-среде решаема посредством проверки цифровой идентичности. В рамках данной сферы могут иметь место получаемые автором (правообладателем) цифровые удостоверения, выставляемые звуковые отпечатки или водяные знаки. Вполне актуально применение и особых международных цифровых кодов: DOI, ISWC, ISRC и других.

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

Так, например, Mediachain запустили Attribution Engine, механизм поиска изображений, который распознает изображение, основываясь на том, как оно выглядит, и сравнивая его с метаданными, полученными изначально от автора (или иного правообладателя). С помощью этого механизма можно также напрямую обращаться к лицу и иметь с ним обратную связь*(35). Тем не менее, сказать о том, что одно и то же хэширование применяется к двум разным файлам, невозможно. Строка хэша будет являться идентификатором данного объекта. Таким образом, потенциально может быть решена проблема, связанная с защитой интеллектуальных прав при нарушении условий открытой лицензии или предоставлением такой лицензии неуполномоченным лицом.

Представляется, что во всех случаях использования технологии разработчики должны составлять White Paper и отдельные Terms, которые должны быть доведены до сведения каждого субъекта, присоединяющегося к такому договору. Использование смарт-контрактов с особенностями, накладываемыми свободными (открытыми) лицензиями, способствует наличию максимальной определенности условий договора.

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

В настоящее время действует консорциум Hyperledger, поддерживающий открытые технологические проекты с множеством участников. Известно недостижение договоренности между Ethereum C++ и Hyperledger, поскольку по правилам присоединения Hyperledger необходимо наличие свободной лицензии Apache 2.0, тогда как Ethereum C++ работал под GPL v. 3.0. Представители Hyperledger пояснили, что любой из участников консорциума сможет брать части кода партнеров, но недопустимо смешивать части кода, разработанные разными лицензиями*(36).

Не взирая на тот факт, что Blockchain должен во всех ситуациях поддерживать технологическую нейтральность, представляется, что данный вопрос пока что окончательно еще не решен. Так, в сентябре 2017 года говорилось о том, что будет создано специальное программное обеспечение, которое объединит множественные разные платформы в единую сеть*(37).

В этой связи представляется, что основные принципы и назначение платформ должны достигать единой цели.

Таким образом, вопрос совместимости свободных (открытых) лицензий между собой, как и возможности их совместимости с платформами, построенными в Blockchain-среде, не должен решаться быстро.

В свою очередь, смарт-контракт с использованием преимуществ подобных лицензий будут способствовать развитию творчества и инноваций в еще больших масштабах.

Литература:

1. Федеральный закон от 12 марта 2014 года N 35-ФЗ "О внесении изменений в части первую, вторую и четвертую Гражданского кодекса Российской Федерации и отдельные законодательные акты Российской Федерации" // Российская газета. 2014. N 59.

2. Столлман Р. Совместимость лицензий и перелицензирование GPLv3 [Электронный ресурс] // URL: https://www.gnu.org/licenses/license-compatibility.ru.html (дата последнего обращения 30.09.2017).

3. Нагродская В.Б. Правовые особенности лицензий "свободных произведений культуры" / В.Б. Нагродская // Правовая защита интеллектуальной собственности: проблемы теории и практики. Сборник материалов III Международного IP-форума. - М.: РГ-Пресс, 2015.

4. Institute of Network Cultures, Amsterdam, 2011. P. 359 [Электронный ресурс] // URL: http://networkcultures.org/_ uploads/%237reader_Wikipedia.pdf (дата последнего обращения 06.10.2017).

5. Мешкова К.М. Распоряжение исключительными интеллектуальными правами в сети Интернет: Дисс. ... канд. юрид. наук: 12.00.03 / Мешкова К.М. - М., 2014.

6. Трансформация авторского права в интернете: зарубежные тенденции, бизнес-модели, рекомендации для России / Под ред. И. Засурского и В. Харитонова. - М.: НП "Ассоциация интернет-издателей"; Кабинетный ученый, 2013.

7. Wheeler D.A. The Free-Libre / Open Source Software (FLOSS) License Slide [Электронный ресурс] // URL: https:// www.dwheeler.com/essays/floss-license-slide.html (дата последнего обращения 18.10.2017).

8. Савельев А.И. Договорное право 2.0: "Умные контракты как начало конца классического договорного права".

-------------------------------------------------------------------------

*(1) Исследование выполнено в рамках проведения научно-исследовательских работ РФФИ 2017 г. N 17-33-00005 по теме "Правовое обеспечение системы учета прав на результаты интеллектуальной деятельности в цифровой среде: перспективы развития".

*(2) Под контентом автор настоящей работы подразумевает собирательный термин, включающий в себя различные результаты интеллектуальной деятельности.

*(3) Основатель движения свободного программного обеспечения, проекта GNU, один из разработчиков GPL.

*(4) Определение свободных лицензий на произведения культуры [Электронный ресурс] // URL: http://freedomdefined.org/Defi nition/ru (дата последнего обращения 30.09.2017).

*(5) Как указывают разработчики "свободных произведений культуры", если пользователь не может использовать свои основные свободы, произведение не может считаться и не должно называться "свободным".

*(6) Общественный договор Debian [Электронный ресурс] // URL: http://www.debian.org/social_contract (дата последнего обращения 30.09.2017).

*(7) Основатель Creative Commons, идейный вдохновитель реформы авторского права в США, юрист, общественный деятель.

*(8) Интернет-предприниматель, входила с 2006 года в комитет по коммуникациям Фонда "Викимедиа".

*(9) Под свободным (открытым) форматом нами понимается общедоступная спецификация хранения цифровых данных. Свободный (открытый) формат не является идентичным со свободным (открытым) исходным кодом, что зачастую приводит к невозможности реализации вышеуказанных свобод, а также к сложности получения доступа к контенту.

*(10) From Defi nition of Free Cultural Works [Электронный ресурс] // URL: http://freedomdefi ned.org/Definition/Ru (дата последнего обращения 30.09.2017).

*(11) Разработчики не конкретизируют, о каком конкретно договоре идет речь. Но мы полагаем, что речь идет о лицензионном договоре.

*(12) Нарушение статьи 6 - об отсутствии DRM.

*(13) Against DRM 2.0 [Электронный ресурс] // URL: http://www.freecreations.org/Against_DRM2.html (дата последнего обращения 30.09.2017).

*(14) Big win for an interoperable commons: BY-SA and FAL now compatible [Электронный ресурс] // URL: http://creativecommons.org/weblog/entry/44030 (дата последнего обращения 30.09.2017 года).

*(15) Зачем переходить на GPLv3 [Электронный ресурс] // URL: https://www.gnu.org/licenses/rms-why-gplv3.ru.html (дата последнего обращения 30.09.2017).

*(16) Перевод статьи Ричарда Столлмана "Почему GPLV3?" [Электронный ресурс] // URL: http://xn--e1afffngyp.xn--p1ai/%D0%BB%D0%B8%D1%86%D0%B5%D0%BD%D0%B7%D0%B8 %D0%B8/%D0%B3%D0%BD%D1%83-%D0%B3%D0%BF%D0%BB/%D0%BF%D0%BE%D1%87%D0%B5%D0% BC%D1%83-%D0%B3%D0%BF%D0%BB3?query_start:int=0 (дата последнего обращения 30.09.2017).

*(17) Там же.

*(18) OEM (англ. original equipment manufacturer - "оригинальный производитель оборудования").

*(19) Secure boot - функция, которая защищает запуск неавторизованных операционных систем и программного обеспечения во время запуска компьютера.

*(20) BIOS (англ. basic input/output system - "базовая система ввода-вывода"). Позволяет провести настройку некоторых комплектующих, а также осуществить загрузку и настройку операционной системы и других параметров.

*(21) Тивоизация [Электронный ресурс] // URL: http://blogerator.ru/page/tivoizacija-uefi-bios-secure-boot-key-opisanie- otkljuchenie (дата последнего обращения 30.09.2017).

*(22) Free Software Foundation recommendations for free operating system distributions considering Secure Boot. John Sullivan, Executive Director. June 30, 2012 [Электронный ресурс] // URL: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper.pd f (дата последнего обращения 30.09.2017).

*(23) Возможность комбинирования отражена стрелками.

*(24) См. о совместимости также: Shemtov N., Walden I. Free and Open Source Software Policy, Law and Practice. Oxford University Press, 2013. P. 100-104.

*(25) Могу ли я лицензировать программное обеспечение, используя лицензии CC? [Электронный ресурс] // URL: http://creativecommons.ru/faq (дата последнего обращения 30.09.2017 года).

*(26) Примером подобной технической интеграции стали GNU GPL, GNU LGPL, BSD.

*(27) Приказ Министерства связи и массовых коммуникаций РФ "Об утверждении Методических рекомендаций по использованию свободного программного обеспечения в деятельности федеральных органов исполнительной власти, включая критерии определения государственных информационных систем, при создании которых необходимо использовать свободное программное обеспечение, в том числе государственных информационных систем, предназначенных для оказания государственных и муниципальных услуг в электронном виде" от 19 августа 2015 года N 305 [Электронный ресурс] Министерство связи и массовых коммуникаций [Офиц. сайт] // URL: http://minsvyaz.ru/ru/documents/4805/ (дата последнего обращения 30.09.2017).

*(28) Там же.

*(29) Существуют специальные анализирующие программы, например, Black duck software.

*(30) Текст документа [Электронный ресурс] // URL: https://apps.azleg.gov/BillStatus/BillOverview/69425 (дата последнего обращения 23.09.2017 год).

*(31) Blockchain-стартап Mediachain пополнил инвестиционный портфель Andreessen Horowitz [Электронный ресурс] URL: http://forklog.

*(32) Creative Commons France experiments with ascribe to support copyleft through the Blockchain [Электронный ресурс] URL: https://www.ascribe.io/our-radar/creative-commons-and-ascribe-enable-copy left-on-the-bitcoin-blockchain/ (дата последнего обращения 18.10.2017).

*(33) Blockchain Best for Creative Artists Seeking Recognition [Электронный ресурс] URL: https://cointelegraph.com/news/blockchain-best-forcreative-artists-seekin g-recognition (дата последнего обращения 18.10.2017).

*(34) См. более подробно: Creativechain. White paper [Электронный ресурс] URL: https://bravenewcoin.com/assets/Whitepapers/Whitepaper-Creativechain-1.2. pdf (дата последнего обращения 18.10.2017).23.09.2017 год).

*(35) A New Cryptocurrency to Reward Creative Commons Creators [Электронный ресурс] URL: https://blog.mediachain.io/a-new-cryptocurrency-toreward-creative-commons -creators-e41e1791c4c0 (дата последнего обращения 18.10.2017).

*(36) Лицензия на Blockchain: консорциум Hyperledger ставит условия разработчикам Эфириума [Электронный ресурс] URL:https://bits.media/news/litsenziya-na-blokcheyn-konsortsium-hyperledg er-stavit-usloviya-razrabotchikam-efiriuma/ (дата последнего обращения 18.10.2017).

*(37) Новое программное обеспечение объединит множественные Blockchainы в единую сеть и направит инвестиции в криптовалютную экосистему [Электронный ресурс] URL: http://bit-koine.ru/2017/09/28/novoe-programmnoe-obespechenie-obedinit-mn ozhestvennyeblokchejny-v-edinuyu-set-i-napravit-investicii-v-kriptovalyut nuyu-ekosistemu/ (дата последнего обращения 18.10.2017).