Сервис для музыкантов и авторское право: что под капотом у ultimate guitar

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Привет, Хабр! Меня зовут Павел Иванцов, я Head of Engineering Muse Group. Мы разрабатываем продукты для тех, кто любит музыку. Наша платформа Ultimate-guitar.com — один из крупнейших в мире сервисов для музыкантов. В нашей базе более полутора миллионов табулатур, права на которые лицензируются у разных правообладателей. 

Еще в 2007 году наша команда столкнулась с серьёзным вызовом, связанным с авторским правом. В то время, не зная, как вести бизнес в новом цифровом мире, издатели начали бороться с сайтами, где пользователи делились табами без разрешения правообладателей. Большинство подобных ресурсов закрылись, потому что не знали, как выйти на легальную операционную деятельность. Но команде Muse Group удалось тогда подписать одно из первых в мире лицензионных соглашений о цифровых табулатурах, а к 2010 году — заключить контракты с десятками музыкальных издателей. 

Итак, текст песни, ноты и даже просто использование имени артиста и его трека — всё это объекты авторского права. Без разрешения правообладателя использовать их нельзя: он может потребовать удалить контент, а за неисполнением требования могут последовать различные меры — от штрафа до удаления приложения из стора. Помимо этого нужно собирать и обрабатывать огромное количество статистики. Все это и множество других нюансов ложатся на плечи разработчиков. Этот пост — небольшой экскурс в то, как работать с музыкальным контентом законно.

Почему контракт — это ТЗ для ИТ-департамента? 

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

Вот что нам нужно для нормальной работы. 

  1. Подключаемся к правообладателям и получаем базу контента.

  2. Регулярно получаем от них списки песен и разрешения.

  3. Люди пользуются сервисом.

  4. Мы собираем статистику.

  5. Мы отчисляем деньги правообладателям.

С виду всё просто, но дьявол, как всегда, скрывается в деталях. Погружаемся дальше.

Что есть у нас

За годы работы мы собрали большую базу контента. У нас он бывает двух видов. 

  • UGC (user generated content) — пользователи присылают собственные подборы аккордов и табулатур, загружают guitar pro файлы.

  • PGC (professional generated content) — в этом случае табулатуры производит команда музыкантов Ultimate-guitar.

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

Прежде всего нужно получить разрешение на использование контента. Единого сервиса, с которым можно подписать договор и потом по API получать данные, нет. Нужно заключить контракт с каждым правообладателем. Права на многие аккорды и ноты принадлежат издателям, которые печатают нотные каталоги. Если ноты ещё не издавались, то нужно идти к музыкальному лейблу. Но ноты и аккорды — не их специализация. В итоге мы можем записать ноты сами и получить право их использовать. Таких контрактов с правообладателями может быть несколько сотен. Все они имеют ограниченный срок действия и постоянно перезаключаются. Чтобы это вовремя обрабатывать, у нас трудятся опытные юристы.

Подключаемся к правообладателям и получаем базу контента

И сразу мы сталкиваемся с первой интересной задачей — правообладатели по-разному подготовлены технически. У кого-то каталоги сделаны в XML формате (у некоторых даже полноценный DDEX), у кого-то — в бинарном CWR, а у некоторых — просто CSV-таблицы. Аналогично и с каналом передачи данных для нас: фид, ftp, а иногда нам самим приходится парсить сайт издателя. Для этого нам нужно реализовать парсеры нескольких форматов и научиться работать с разными каналами получения данных.

Теперь о содержимом каталогов правообладателей. Если обобщить, то внутри что-то в таком духе.

{
  “Title”: “Track 1”,
  “Performer”: “Performer 1”,
  “Restrictions”: {
  	“ALL”:false,
  	“FR”:“2021-01-01 00:00:00”,
	},
	//Дальше может идти разный набор из полей
	“ISMN”: “979-0-060-11561”,
	“ISRC”: “GBARL2001274”,
	“ReleaseDate”: “2003-11-21 00:00:00”
}

Самое простое и понятное — это Restrictions. Тут правообладатель указывает, в каких странах с какой даты доступен его контент. Или где он не доступен. Так как правообладатель не знает, когда продаст права на трек, то конечной даты, естественно, нет. Это нам ещё доставит проблем дальше.

Title и Performer — название трека и имя артиста. Хорошо, если данные приходят без опечаток и битой кодировки. Особенно этим грешат агрегаторы, через которые много маленьких лейблов распространяют свои треки. В итоге у нас в базе есть около 0,1% композиций, названия которых состоят только из вопросительных знаков. 

Как видите, в примере нет ID, но есть другие непонятные числа. Давайте разберемся, что это. Есть понятие ISMN — уникальный номер печатной музыки. Эти номера есть у издателей нот, но ведь вы помните — у нас есть аккорды, которые никто ещё не печатал. Тут мы снова идем к музыкальным лейблам, а у них есть только ISRC — идентификатор релиза (конкретная песня на конкретном альбоме в конкретной стране). То есть в разных странах у одного и того же трека ISRC могут быть разные. Вообще конечно, есть ISWC, который должен идентифицировать музыкальное произведение независимо от числа его переизданий, но на практике им мало кто пользуется. В итоге даже если эти магические идентификаторы есть, единственное, что более-менее надежно идентифицирует трек — это текстовая информация: исполнитель и название трека. Но пока мы находимся на этапе приема данных, нас это мало волнует.

Регулярно получаем от них списки песен и разрешения

Список контента мы забрали, а дальше нужно его обновлять и выполнять блокировки. Информацию про новые треки мы обычно получаем через тот же канал, откуда и начальный каталог. А вот с блокировками интереснее. У кого-то всё автоматизировано и информация о блокировках поступает тем же способом. Однако многие правообладатели по-прежнему пользуются старой доброй электронной почтой. Вместе с другими обращениями получается приличный поток. Его разбором занимается отдельная небольшая команда.

Структурируем контент

Вот мы и добрались до самого сложного момента, когда все то, что прислали правообладатели, нужно применить к материалам, присланным пользователями, чтобы определить, можно показывать табулатуру или нет. В нашем каталоге нет никаких юридических идентификаторов типа ISRC или ISWC. У нас есть внутренний song_id, title и performer. Получается матчить табулатуры нужно по title + performer, больше пересечений нет.

Запускаем текстовый поиск и… находим не более 50% совпадений. Причина — человеческий фактор. В каждом лейбле или издательстве базы заполняются менеджерами вручную. В итоге от разных правообладателей может прийти один и тот же трек, но артист будет написан по-разному. Например, Jay-Z, Jay Z и JayZ. С этим ничего не поделать, входные данные из фидов правообладатели не изменят.

Берем открытые базы музыки: MusicBrainz и Discogs, там есть всевозможные синонимы имен артистов. Пробуем еще раз. Стало сильно лучше, но все еще не идеально. Из того что осталось видим вещи типа:

  • Tom Morello, Bring Me the Horizon

  • Billie Eilish and Khalid

  • Papa Roach ft. FEVER 333

  • И прочие варианты написания коллабораций артистов.

Ладно. Вводим разделители и режем по артистам... и благополучно распиливаем коллектив Simon & Garfunkel на двух независимых артистов, что противоречит логике, ведь это название дуэта. Это примерно как разделить название Guns N' Roses — отдельно Guns, отдельно Roses. 

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

Потом выясняем следующую особенность. У некоторых песен в одной стране — два правообладателя, и один разрешает нам использовать табулатуры, а другой запрещает. Например, есть большой лейбл, который издает много треков на весь мир, и лейбл поменьше, который выпустил какой-нибудь сборник Best Pop Collection 2015. И последний в итоге имеет права на несколько отдельных песен. В этом случае побеждает прямой правообладатель, а проигрывают все последующие дистрибьюторы. Такие конфликты разрешаются вручную с помощью юристов. 

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

Сбор статистики

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

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

Отчисления

Здесь уже почти нет сложностей. В финансовый отдел нужно отправить статистику и добавить данные о том, какому правообладателю принадлежала табулатура при каждом показе пользователю (помним о том, что со временем владелец таба может меняться). На этом наша работа заканчивается. Дальше финансисты берут отчеты из App Store, Google Play и других платежных систем, приправляют это условиями контрактов и делают свою финансовую магию. Артисты получают деньги, сервис работает для пользователей, законы соблюдаются.

Итого 

Это была первая статья от Muse Group на Хабре. Задавайте вопросы в комментариях, делитесь своими решениями, спрашивайте то, что вам интересно узнать о музыкальных сервисах.

Источник: https://habr.com/ru/post/596881/


Интересные статьи

Интересные статьи

В статье рассматриваются часто встречающиеся проблемы операционной деятельности компаний, занятых в обслуживании различных систем безопасности: охранно-пожарной сигнализации, видеонаблюдения и контрол...
Организации переходят от монолитных приложений к микросервисам, используя преимущества идеально подходящей для этого архитектуры контейнеров. В результате возрастает ответственность за за...
В данной статье рассматривается пример реализации распределенной микросервисной авторизации доступа для множества пользователей к множеству ресурсов или операций. Уровень подготовки читат...
VUE.JS - это javascript фрэймворк, с версии 18.5 его добавили в ядро битрикса, поэтому можно его использовать из коробки.
С версии 12.0 в Bitrix Framework доступно создание резервных копий в автоматическом режиме. Задание параметров автоматического резервного копирования производится в Административной части на странице ...