Язык выражения прав

А права Expression Language или REL является машинно-обрабатываемый язык , используемый для выражения прав интеллектуальной собственности (например, авторское право) и другие условия для использования по содержанию. REL могут использоваться как отдельные выражения (т. Е. Метаданные, используемые для поиска, отслеживания совместимости) или в системе DRM .

REL могут быть выражены на машинном языке (таком как XML , RDF , RDF Schema и JSON). Хотя REL могут обрабатываться напрямую, они также могут встречаться при внедрении в качестве метаданных в другие документы, такие как электронные книги , изображения , аудио или видео файлы.

Известные REL [ править ]

Известные RELs включают:

ccREL

Схема RDF, используемая проектом Creative Commons для выражения своих лицензий . ^{[1] [2]}

Этот же словарь был принят проектом GNU для выражения своей Стандартной общественной лицензии (GPL) в машиночитаемой форме. ^{[3] [4]}

Открытый язык цифровых прав W3C ODRL

Рабочая группа W3C по выражению разрешений и обязательств (POE) разработала рекомендации ODRL для выражения заявлений о разрешениях и обязательствах для цифрового контента. ^[5]

Информационная модель W3C ODRL предлагает основу для базовых концепций, сущностей и отношений, которые образуют фундаментальную основу для семантики выражений ODRL. Целью информационной модели ODRL является поддержка гибких формулировок политики, позволяя автору включать как можно больше или меньше выразительных деталей об условиях использования Активов, участвующих Сторонах и обязательствах. ^[6]

Словарь и выражения W3C ODRL описывает потенциальные термины, используемые в выражениях политики ODRL, и способы их сериализации. Термины составляют часть онтологии ODRL и формализуют семантику. Широкий набор терминов в словаре обеспечивает поддержку сообществам в использовании ODRL в качестве основного языка для описания распространенных вариантов использования. ^[7]

XrML

XrML начался с работы в Xerox в 1990-х годах. ^[8] Пройдя через несколько версий и отдельных проектов, он позже лег в основу REL для MPEG-21 . ^[9]

MPEG-21

Часть 5 этого стандарта MPEG включает REL. ^[10]

METSRights

METSRights - это схема расширения стандарта метаданных упаковки METS . ^{[11] [12]}

Использование REL [ править ]

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

«Лицензия» здесь может означать:

• "Общеизвестная лицензия", такая как GFDL , Apache License или Creative Commons CC-by-sa-3.0 и т. Д.
• Предустановленная лицензия, похожая на эти, но не очень известная. Примерами могут служить проприетарные «термоусадочные» лицензии.
• Конкретная лицензия, созданная с индивидуальными условиями и положениями, для контента, передаваемого по лицензии от одной стороны к другой.

Известные лицензии [ править ]

Часто выбирают использование хорошо известной лицензии из-за ее однозначной простоты: GFDL означает одно и то же, независимо от того, кто ее использует. Использование существующих лицензий также позволяет избежать проблем, связанных с увеличением количества лицензий . Также практично использовать такую ​​лицензию и проверять, соответствует ли проект ей, не слишком понимая, какие детали она влечет за собой. Достаточно просто знать, что «GFDL приемлем для этого проекта» и «Все ресурсы в этом проекте используют GFDL». В этом смысле хорошо известные лицензии - это способ избежать необходимости использовать REL для моделирования деталей лицензии, достаточно его имени. ^[13]

Несмотря на это, REL может быть полезен с этими лицензиями. Он обеспечивает машинный способ идентификации используемой лицензии, избегая проблем с именованием и потенциальных двусмысленностей между «лицензией Apache» или «лицензией Apache 2.0». Авторам этих лицензий также требуются средства для описания своих внутренних данных.

Предустановленная лицензия [ править ]

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

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

При разработке программного обеспечения с открытым исходным кодом проекты также часто создают свою собственную лицензию под своим собственным названием проекта, но детали этой лицензии должны быть шаблонной копией известной лицензии или даже ссылкой на эту лицензию. ^[14] REL должен поддерживать это, предоставляя средства для определения лицензий путем разделения существующих лицензий на подклассы и, возможно, изменения их поведения. Многие из этих лицензий представляют собой не более чем « тщеславные» лицензии , хотя другие зависимые проекты должны иметь возможность работать с ними. ^[15]

Конкретные лицензии [ править ]

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

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

Структура REL [ править ]

REL может удобно использовать модель Entity-Attribute-Value , как и RDF , для структурирования своего описания модели прав. Такая модель ^[16] выражается в виде списков:

Сущности

Конкретные «вещи» или «классы», например:

• Работа / Актив

Товар лицензируется.

• Лицензия

Лицензия, особенно если это «хорошо известная» лицензия (где многие Работы будут использовать сопоставимую абстрактную лицензию, такую ​​как GFDL )

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

• Конечный пользователь / Стороны

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

• Юрисдикция

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

Атрибуты

«Свойства» или аспекты каждой из этих Сущностей, например, для Лицензии:

• ограничения

Действия, которые разрешены или запрещены

Некоторые REL ^[16] разделяют эти ограничения на группы, так как вероятные значения для каждого, как правило, являются непересекающимися наборами (действия, которые иногда могут быть запрещены, редко являются обязательными)

• разрешения
• запреты
• требования / обязательства (или обязанности)

Значения

Значения этих свойств из предопределенного словаря, например, Четыре свободы :

• Использование работы
• Изучение и изменение Работы
• Распространение копий
• Распространение измененных копий
• Распечатать актив

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

Затем с помощью REL могут быть сделаны утверждения (они будут вне самого REL), например:

<cc: License  rdf: about = "http://example.org/licenses/distribution/" >  <cc: licenseClass  rdf: resource = "https://creativecommons.org/license/" />  <dc: title> Лицензия FooCo на разрешенное распространение </ dc: title> <cc: permits  rdf: resource = "https://creativecommons.org/ns#Distribution" /> </ cc: License>

Это определяет новую абстрактную лицензию, разрешающую повторное распространение копий. Затем Works могут использовать эту Лицензию, ссылаясь на нее,

< Р > Эта веб - страница под лицензией < в  отн = «лицензия»  HREF = «http://example.org/licenses/distribution/»  > FooCo дистрибьюторская Разрешенные License </ > .

Обратите внимание, что хотя эта гипотетическая лицензия «Разрешено распространение» была выражена с использованием Creative Commons REL, она не является лицензией Creative Commons. Он просто использует понятия «Лицензия», «разрешение» и «Распространение». Хотя это не одна из лицензий Creative Commons, определенных в этом проекте, у нее есть точная общность для этих терминов: «Распространение» имеет точно такое же значение и юридическое определение между ними.

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

{  "@context" :  {  "odrl" :  "http://www.w3.org/ns/odrl/2/"  },  "@type" :  "odrl: соглашение" ,  "@id" :  "http: //example.com/policy:4444 " ,  " target " :  " http://example.com/asset:5555 " ,  " assigner " :  " http://example.com/MyPix:55 " ,  " разрешение " :  [{  "assignee" :  "http://example.com/guest:0001" ,  "action" :  "odrl: display"  }], "разрешение" :  [{  "правопреемник" : "http://example.com/guest:0002" ,  "action" :  "odrl: print"  }] }

Взаимодействие между лицензиями [ править ]

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

Самый простой подход - объединить контент только под одной и той же хорошо известной лицензией. Однако это чрезмерно ограничительно, и многие совместимые лицензии могут разрешать объединение их содержимого . Однако трудно судить об этом, разрешено ли это и как лицензировать полученный контент. ^[17] Могут быть тонкости, когда есть перекрывающиеся требования или проблемы с авторским левом . Примечательно, что «атрибуция-совместное использование» и «атрибуция-некоммерческое-равноценное использование» Creative Commons несовместимы. ^{[примечание 1] [17] [18] [19]}

Объединение лицензий проще, если все задействованные лицензии могут быть выражены через один и тот же REL. В этом случае легче увидеть, когда применяется разрешение или запрет, если они, по крайней мере, относятся к идентичному определению «Распространение». Очевидным примером этого являются лицензии Creative Commons , где все семейства лицензий определяются в терминах одного и того же REL .

Даже если разные лицензии изначально были определены через разные REL, можно одновременно перекодировать лицензию в другом совместно используемом REL, что сделает их сопоставимыми. GPL недавно была выражена в ccREL , что дало это преимущество. ^{[3] [4] [примечание 2]}

Трудности взаимодействия между лицензиями [ править ]

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

Семантика [ править ]

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

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

Неявные предварительные условия [ править ]

Менее очевидная проблема при сравнении REL - это когда у них разная базовая линия. ^{[20] [21]} Базовая линия определяет условия, подразумеваемые лицензией, когда в нее не включены явные заявления. Некоторые REL используют подход «Все, что не разрешено, запрещено», другие (например, ccREL) используют Бернскую конвенцию в качестве основы.

Ссылки [ править ]