Причем если вы не банк, то поддержка авторов может быть и pro-bono и в виде донатов на том же open collective.
Интересно, почему вы исключили банки из донатов, и второй вопрос в таком случае с чего вы взяли, что банк вам за ваши исходные коды не донатил на Open Collective (не афишируя, просто одно физ. лицо отправило пожертвование)? Или это другое и такие донаты не считаются, тогда вопрос почему вообще донаты должны считаться оплатой EE? Или они не считаются, тогда почему этот вариант вы считаете приемлимым, но в отношении банка намеренно игнорируете?
Я вообще не понимаю зачем и почему вы сюда притянули "наши"/"ваши"/"мы"/"вы"/"заграница"/"отечественное" и т.д. Тем более с учётом того, что я даже не вёл свою ветку относительно каких либо государств.
Моя ветка про то, что при выборе лицензии для своего исходного кода вам стоит более тщательно разобраться в вариантах. Иначе можно так опубликовать код, а потом узнать, что положив Unlicense вы отдали свои "человеко-часы" и деньги в общественное достояние и юридически не можете претендовать даже на упоминание авторства.
А впрочем знаете, пожалуй раз весь комментарий достаточно желчный и претензионный разберу ка каждый пункт и накидаю как говорится на вентилятор:
Люди почему-то считают, что публикация некоммерческих демо-версий софта - это наше ярмо, и мы должны стоя на коленях за бусы дарить все наши наработки любым враждебным, финансовым и принадлежащим иностранному капиталу корпорациями за спасибо и не бурчать.
Некоммерческая демо-версия софта это ваш исходный код я так понимаю? Тогда почему нигде больше об этом не указано и почему именно под лицензией явно разрешающей коммерческое применение?
Про ярмо и за бусы уж извините, но не нравится, не публикуйте свой исходный код. Возможно вы не доросли до понимания что из себя Open Source и зачем крупные компании в т.ч. Яндекс отдают свои тысячи человеко-часов в открытый доступ (Clickhouse & YDB). Наверное по тому, что сообщество способно подхватить ваш софт, улучшить и в целом превратить его из внутреннего инструмента в повсеместный инструмент (привет Kubernetes).
А уж про враждебность и влияние иностранного капитала тем более. Не нравится не используйте софт иностранных/враждебный компаний и не бурчите. У вас на серверах Windows? Аяяяй вы используете человеко-часы сотрудников Microsoft, Linux аяяяй вы ещё хуже делаете этоже человеко-часы сотрудников Microsoft, IBM, Intel, AMD, Red Hat, Amazon и т.д. ведь это Open Source.
Почему-то присутствует вера, что заграница нам поможет и что в мире добра все следуют всем лицензиям, и что это не аналог так называемого театра безопасности в аэропорту;
Про веру в заграницу, это вера далеко не в заграницу, а в международные отношения. Когда технологии развиваются по экспоненте настаёт время когда одна сторона просто не может быть "и швец, и жнец, и на трубе игрец". Что самое интересное и забавное это понимают в нашем МинПромТорге. Тот же Aurus это сборная солянка и результат работы десятка стран. А вообще за примерами далеко ходить не нужно, посмотрите на микроэлектронику.
Про мир добра и лицензии отдельная история. Лицензия это юридический документ, а юридические документы это бюрократический инструмент, которым вы себя пытаетесь защитить и от вас пытаются защититься. При разном объёме обмазывания юр. документами казалось бы простые вещи превращаются в недели согласований. Однако без этого никаких договорённости ни локальных ни внешних, ни обменов чем либо за что либо, ни компаний, ни даже государств не было бы.
Эти корпорации, сэкономив сколько-то человеко-месяцев работы (пусть даже на проверку несработавшей гипотезы, но за это надо платить тоже, внезапно) могут сказать, что это "ой, ну не коммерческое, ой не нужно больше" и продолжать плевать на всех остальных. А мы типа бабло на разработку из воздуха взяли. А почему-то отечественные разработки на деревьях как не раньше росли, так и не начали расти;
Неужели вам нужно объяснять, что основная цель бизнеса это зарабатывать? "не коммерческое" и не принесёт денег (нельзя использовать смежно) действительно нафиг нужно - только убытки.
Про ваше бабло на разработку из воздуха. Опять не нравится, не публикуйте свои работы, продавайте с самого начала под проприетарной лицензией, а ещё лучше получите патент и продавайте лицензию с разрешением использовать ваш патент. Однако вы пошли по другому "более лёгкому" пути как вам показалось.
Про отечественные разработки на деревьях снова уж извините, но есть достаточно разработок сделанных в РФ или основная часть в которых сделана в РФ. Однако они все "почему-то" в конечном счёте оказываются не отечественными. Действительно "почему"? Наверное по тому, что здесь никому эти разработки в действительности не нужны, только на бумаге для отчётности. А всякие Nginx и Clickhouse как вы в прошлых пунктах написали "вражеские" с "иностранным капиталом" в конечном счёте.
Среди популярных лицензий, которые все используют … нет ни одной явно некоммерческой (интересно почему). Я понимаю, что можно в файле LICENSE написать что-то в духе "non-commercial use only, lol", но тогда сразу найдутся и другие "отговорки". Это всегда напоминает наши международные переговоры (и многие переговоры с корпорациями и иностранными заказчиками). Где вся суть, если убрать расшаркивания сводится к тому, что тебя считают объектом отношений, а ты считаешь себя субъектом;
Не нравятся популярные лицензии, напишите свою с пунктом "non-commercial use only" и всё, однако вы выбрали достаточно известную и узнаваемую лицензию по тому, что это проще и не довольны её условиями.
Международные переговоры и переговоры между компаниями по своей сути одно и тоже - две стороны пытаются сойтись на своих желаниях от сотрудничества, при этом защитившись друг от друга на случай чего. А т.к. эти переговоры априори юридический элемент то всё та же бюрократия и удивляться этому мягко говоря странно. Вы разве только родились? Так ведь всегда было. Любая сторона считает себя объектом отношений, а противоположную сторону субъектом. Т.к. мы это мы, а там они (ваш же первый пункт собственно).
Ой … мы публично не кричим из каждого утюга как мы договариваемся с вменяемыми платящими клиентам, кто понимает суть общественного договора. Так это, почему ли мы должны свою кухню вообще выносить? Или надо жить в виртуальном мире, как некоторые недавно уволенные сотрудники компании компании на букву Я? Но нам почему-то не платят зарплату за 2 месяца тунеядства;
Пожалуйста, можете и не кричать, только не удивляйтесь почему в схеме условно вот товар, а цена "договорная" клиентов меньше, чем когда вы цену и хоть какие-то условия публикуете. Это про дружелюбность и открытость скорее.
Ну и раз вы так прям не собираетесь кричать из каждого утюга, надеюсь как только раскрутитесь всё так же не будете кричать из каждого утюга кто клиент? Или будете т.к. это своего рода составляющая имиджа и позиционирования?
А уже про тунеядство... мда... Если вы не видите как работает человек это не значит, что он не работает... Больше даже не буду по этой теме расписывать.
Ну и самое главное - если я что-то выложил в публичный доступ, то все, я сразу неудачник, прав у меня нет, гроб, стыд, позор;
Ещё раз посыл моей ветки про ознакомление с лицензией которую вы используете, вас она как выяснилось здесь и в посте HomeCredit не устраивает, так почему же вы её всё ещё используете?
Про права, ещё раз читайте именно текст лицензии и понимайте от каких прав вы отказываетесь или какие права отдаёте в неисключительном порядке. Иначе будет как я уже упомянул с Unlicense. А потом вопрос "почему у меня нет авторских прав и вообще я больше ничего не могу в исключительном порядке делать".
Пардон за прямоту, наши разработки и продукты - что хотим то и делаем.
Пожалуйста, но раз вы так с рвением хотите судиться с банком из-за того, что банк действовал в рамках вами же установленной лицензии. Как типичный патентный троль, то будьте готовы что с вами могут тоже судиться, причём в первую очередь нормальные/крупные EE клиенты или вовсе отказаться от ваших исходных кодов.
Если весь поток мыслей сократить до одной фразы - то мы просто находимся по разные стороны баррикад классовой борьбы.
Если оперировать более новыми цитатами - то вот это объект-субъектное перетягивание одеяла прекрасно иллюстрируется этой кино-цитатой
Я вам помогу, для этого перетягивания есть одно слово - бюрократия. И надо это понимать.
Извините меня конечно же за мою прямоту, и за то, что в этой ветке я тратил свои драгоценные часы на безуспешную помощь вам же.
Я вам привёл пример MongoDB, у которой схожая с желаемой вами моделью распространения. Так почему же не перелицензировать ваш исходный код под Server-Side Public License (SSPL) и радоваться жизни? Единственное всех благ от OSS вы не получите т.к. SSPL и AGPL сами по себе не самые открытые и желанные. По стопам Kubernetes, Clickhouse, YDB вы не пойдёте точно.
А в прочем не важно, главное не разочаровывайтесь в OSS, ведь это всё-таки "вражеское" с "иностранным капиталом" и вообще придумано не у нас. (На самом деле модель международных взаимоотношений с общей целью).
Это отдельный случай, обе лицензии открытые, в одном случае вы отказываетесь от авторского права (Unlicense), в другом случае сохраняете авторское право. Такой случай вполне допустим, т.к. указанный проект мультилицензирован из-за того, что Unlicense может не иметь юридической силы в некоторых юрисдикциях, однако обе лицензии не обязуют применять конкретную лицензию и в целом являются совместимыми. Хотя в этом случае имеется законодательное противоречие для юрисдикций воспринимающих Unlicense.
Вот если речь будет идти о двойном лицензировании AGPL и Unlicense, тогда это не возможно, ведь они не совместимы AGPL требует лицензирования всего исходного кода под ней же. Unlicense же не накладывает ограничений на лицензии сопутствующего исходного кода. Хотя код под Unlicense в общественном достоянии.
В этом плане мультилицензирование как я уже указал ещё более сложно т.к. оно может иметь разные цели, в случае автора статьи это коммерческие услуги автора статьи, в случае примера на StackExchange это юридический смысл общественного достояния. Ещё раз подчёркиваю во втором случае конфликта лицензий в целом нет. Но есть НО, в примере со StackExchange фактически поменять лицензию нельзя ведь Unlicense это общественное достояние и отказ от авторских и исключительных прав. Однако если бы применялось мультилицензирование из-за разных лицензий разных частей кода, то они бы могли в будущем сменить лицензию только у кода покрытого лицензией MIT, например на Apache-2.0, если вдруг появятся какие-то куски кода под патентами. Однако код под лицензией Unlicense навсегда остаётся под лицензией Unlicense.
В случае с примером со StackExchange на самом деле есть законодательное противоречие для юрисдикций, в которых будет работать лицензия. С одной стороны это общественное достояние, с другой стороны кто-то владеет исключительными правами, не смотря на то, что они указали о применимости любой из двух лицензий. В этом случае имело бы смысл сделать свою лицензию, которая будет работать в разных юрисдикциях примерно одинаково и не создавать такой коллизии.
Например, Apache-2.0 совершенно не обязует лицензировать производный код под Apache-2.0, однако новая лицензия не должна противоречить Apache-2.0 т.е. должна быть совместимой. Apache-2.0 это разрешительная лицензия. AGPL же наоборот она явно запрещает лицензировать производный код под любой другой лицензией, кроме AGPL. AGPL не разрешительная.
Опять таки подвох в деталях, лицензируя свой исходный код под AGPL вы не отказываетесь от своих авторских прав и других исключительных прав на свой исходный код. Но при этом вы явно в лицензии закрепили неисключительные права для использующих ваш исходный код. Т.к. вы всё ещё владелец исключительными правами вы можете сменить лицензию на любую другую, например Server-Side License, причём новая лицензия может быть диаметрально противоположной первой, однако она не имеет обратной силы. Использующие же ваш исходный код согласно лицензии AGPL не имеют возможности перелицензирования модификаций, Apache-2.0 не запрещает этого.
Т.е. коммиты под AGPL после перелицензирования всё ещё покрываются AGPL, а вот новые уже покрыты Server-Side License. И это не смотря на то, что в коде под Server-Side License имеется код под AGPL, вам как владельцу исключительными правами в виду "исключения" разрешено данное действие, вы же ведь врят ли будете сами на себя подавать в суд за использование своего же исходного года под другой лицензией. Простыми словами вы меняете правила игры для своих пользователей, но именно для последующей игры, а не "задним числом".
Пользователи использующие версию исходного кода под AGPL (до перелицензирования) всё ещё следуют лицензии AGPL. Пользователи перелецензированного исходного кода уже следуют новой лицензии. По своей сути перелицензирование вами как владельцем исключительными правами на исходный код можно сравнить с выпуском нового продукта, как вы в своём примере и указали.
Все кто модифицировал ваш код до перелицензирования всё ещё обязаны следовать AGPL, кто модифицировал после уже следуют новой. Если у них форк, синхронизирующийся с вашей основной веткой, получая перелицензированный код они следуют уже новой лицензии.
Причём лицензия лицензии рознь есть Public Domain лицензии, в которых вы отказываетесь от исключительных прав на исходный код, а в некоторых случаях даже от авторских прав. В таком случае вы уже не имеете право менять лицензию на своё усмотрение.
По этому важно что написано в лицензии, не просто так столько версий открытых лицензий и не счётное количество проприетарных лицензий.
Всё выше расписанное касается случая, когда в один момент времени применяется одна лицензия, когда у вас двойное лицензирование появляется больше дополнительных нюансов, как таже самая совместимость применяемых лицензий - они не должны добавлять коллизий относительно применимости пунктов этих лицензий.
Дело в том, что может да, но если лицензии явно не запрещают иное, AGPL именно такая лицензия, опять таки именно по этому у MongoDB появилась Server-Side License вместо ранее используемой AGPL. Иначе получается, что любая из лицензий может быть расценена как не действительная.
Лицензии это всё-таки юридический документ, который должен соответствовать своим целям, не противоречить законам и собственно говоря всем смежным юридическим документам, на которые она полагается. Иначе какая целесообразность такого документа, если он не исполняется или не исполним всеми сторонами - это просто текст, не более.
Пожалуй имеет смысл "поздравить" автора с тем, что он таки "добился" отказа от использования своего кода - Ответ в статье HomeCredit.
На что хочется обратить внимание... Имеет смысл открыть непосредственно оригинальный текст самой лицензии AGPL-3.0 и изучить пункты изложенные там, как преамбулу, так и все последующие пункты самой лицензии. Всевозможные пояснения в любых других местах на любых языках также не имеет смысла приводить как аргументацию по лицензии, в лицензии на самом деле всё и так ясно изложено и хорошо описано в преамбуле, двойных трактовок быть не должно.
Что касается двойного лицензирования исходного кода, у меня имеются огромные вопросы про юридическую силу EE лицензии автора (ввиду того, что я её публично не нашел). Первый и главный вопрос совместима ли их EE лицензия с AGPL т.к. AGPL предполагает коммерческое использование в себе. Второй вопрос основана ли она на тексте AGPL, если да, то сама лицензия EE нарушает права FOSS, ведь модификация лицензии AGPL явно запрещена, из-за чего к слову её совместимость с GPL отдельно явно прописана в обоих лицензиях.
Более того описанные на wiki CE и EE лицензии не соответствуют действительности. А именно лицензия AGPL предполагает дальнейшее развитие ПО и запрет на препятствие модификаций ПО опубликованного под AGPL. Это касается и любой модификации (кастомизация/адаптация) модели, а именно кастомизация и адаптация в таблице в wiki для лицензии CE (AGPL) отмечены как запрещенные.
Опять таки именно из-за несовместимости коммерческой лицензии с AGPL в MongoDB сделали свою Server-Side License.
Ну и главное подобные ходы в очередной раз заставляют задуматься об использовании подобного открытого кода, причём даже не конкретно этого, а любого лицензированного по AGPL т.к. почему-то AGPL не смотря на достаточную ясность умудряются по разному трактовать. Что ещё раз подчёркивает правильность AGPL Policy в Google.
Вероятнее всего в примере про бинарник as-is (пример относительно mongodb) имелось ввиду, про бинарник собранный из оригинального исходного кода (ровно тот же, что официально предоставляется на сайте).
Касательно примеров с судебными тяжбами - очень мутная история. Из текста ни в первом ни во втором случае не ясно применяли они оригинальный исходный код ghostscript или модифицировали его. И вообще был ли исходный код ghostscript или они вызывали уже собранный бинарник (пусть и поставляемый вместе с их программой). Вызов одной программой бинарника другой программы модификацией исходного кода другой программы не будет.
Единственное пожалуй на что могли бы Artifex Software, Inc ссылаться, это на двойное лицензирование, однако что-то мне подсказывает, что двойное лицензирование одного исходного кода в формате AGPL и другая лицензия для коммерческого пользования само по себе противоречит и нарушает AGPL лицензию. Да и в исках они ссылались именно на AGPL, а не лицензию для коммерческого использования, что странно.
Для начала Google очень перестраховывается, они имеют множество политик касаемых OSS (как для публикации, так и для использования). Например для своего OSS кода (может быть прямым продуктом или просто внутренним инструментом, которым они поделились) - Google использует либо BSD-3-Clause, либо Apache-2.0. Причём приоритет сейчас отдаётся больше Apache-2.0.
AGPL Policy логична тем, что во первых нужно использовать совместимые с AGPL лицензии для сопутствующих исходных кодов. А также любой закрытый/внутренний сервис Google в любой момент может стать либо продуктом для клиентов, либо OSS. В таком случае, AGPL заставит открыть исходный код всех инструментов по цепочке, что совсем не выгодно.
Относительно нарушения лицензии, как сказано в статье - ответ очевидно "нет не нарушили". И вот почему, давайте рассмотрим один из последних абзацев преамбулы лицензии AGPL:
The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.
У нас тут есть ровно два условия, которые должны быть выполнены одновременно:
Мы модифицировали исходный код.
Мы применяем исходный код не для личных целей (предоставляем кому-то ещё доступ к программе).
Т.е. мы можем применять модифицированный исходный код и не открывать его ровно до тех пор, пока мы используем его в личных целях. Если мы предоставляем сервис/услугу другим пользователям (тут нужно отметить - не важно каким внешним или внутренним), мы обязаны открыть этот исходный код этим самым пользователям (и вот это очень важно).
Получается, что даже если мы попали под обязанность открыть исходный код модифицированной версии это не значит, что мы открываем исходный код абсолютно всем:
Если мы сделали внутренний сервис, которым пользуются только сотрудники компании мы обязаны открыть исходный код сотрудникам, использующим этот сервис.
Если мы сделали закрытый сервис (например, предоставляем услуги за оплату), мы обязаны открыть исходный код нашим клиентам, имеющим доступ к сервису.
Если мы сделали публичный/широкодоступный сервис (может использовать вообще кто угодно), мы обязаны открыть исходный код всем потенциальным пользователям.
В целом название AGPL (GNU Affero), как бы намекает о наличии какого-то "предложения".
Ну... Нейронные сети по своей сути это тоже как таковой технологии 1960-1980гг. в новом исполнении.
А так в целом лучше увы не получается, для кого-то эти списки работаю, для кого-то они сильно бесполезны. Потом у любых рекомендаций всё-равно будет шум, даже если его намеренно не подмешивать. Про те же жанры всё тоже сложно. Тот же House пошел от Jazz и даже Blues и в ряде случаев House можно отнести к ним, хотя House тоже разный бывает. Так ещё есть и мифический жанр Pop влияющий на все жанры, ровно по тому, что Pop это фактически популярная музыка и она может быть по факту любого жанра. Причём Pop в постоянном движении, Pop 2000x совсем не совпадает с Pop 2020x. В целом жанры тоже не дискретны и имеют характер изменяться.
В общем с такими алгоритмами работает единственно верное решение - введение большего числа факторов, те же самые отметки "нравится"/"не нравится" ровно про расширение входных факторов, между которыми будут искаться наиболее сильные пересечения.
Ну тогда угрозу и опасения нужно распространять на абсолютно всех, даже на собственный внутренний продукт компании. Тётю Клаву может читать кто угодно, даже безопасники собственной компании и цель этого так же не известна. Перестать работать может тоже что угодно. Да и утечки с компрометациями тоже происходят. Так, что Zero Trust - ни кому верить нельзя. В общем странно, что может внезапно пропасть доверие при том, что раньше всё было ровным счётом так же. Ничего, кроме рисков цепочки поставки о которых забыли не произошло.
Из списка хоть как-то (очень-очень приблизительно!) похожи только 3 Doors Down. Остальные тут вообще не в том стиле, особенно далеки HIM и Theory of a Deadman.
Разве рекомендательные алгоритмы должны рекомендовать только "похожее" по жанру или звучанию? По моему как раз таки у Spotify алгоритмы намеренно подкидывают и другие жанры, но близкие по различным характеристикам, например по BPM и ключевой ноте. Или то, что коллективно слушает целевая группа этих исполнителей, тех же исполнителей с совместных работ. Просто, чтобы было не скучно сидеть в "пузыре" и можно было искать и находить другие направления.
Тем не менее есть и примеры по типу Cloudflare, которые продолжают работать, более того тестируют новые инструменты в регионе. Опять таки VMWare и HashiCorp это инфраструктура и их действия могут повлиять на целые бизнесы. HashiCorp как таковой на конкретно рынке РФ и не работали. Уже упомянутый Cloudflare имеет большее влияние, чем HashiCorp, однако они придерживаются противоположной точки зрения, причём этой же точки зрения придерживается на самом деле и правительство США. Т.е. компании решившие заблокировать, что называется "на опережение тренда" ошиблись с настроем. Ровно как некоторые наши провайдеры блокировали "на опережение" до попадания сайтов в список блокировки РКН, а потом оказывалось, что заблокированные сайты не попали под блокировку РКН, а пользователям этих провайдеров уже доставлены неудобства как минимум.
Spotify совсем из других степей, они в этом плане ни как повлиять не могут, ну уйдут и спрашивается что - ни горячо, ни холодно. Я бы даже сказал, что они наоборот пытаются расширять свой охват. Также не забываем, что Spotify в ЕС на статусе "импортозамещения" по отношению к стриминговым сервисам США.
Нужно всё-таки уметь различать компании по "влиянию" и по "целям/идеалам" их бизнеса. А то также про блокировку РФ можно сказать и относительно сервисов Pandora, Vevo или Disney+, на которые с российский IP адресов нельзя зайти (на самом деле туда нельзя зайти с любых IP адресов вне регионов обслуживания = лицензирования контента, даже если аккаунт из региона обслуживания).
Смысла блокировать этот способ доступа не видно никакого, кроме как политического.
Я не увидел предпосылок блокировки доступа в зарубежный аккаунт с территории РФ. Я понимаю, что вы вероятно зацепились за текст в FAQ разделе и скорее всего увидели в нём то, чего по факту нет. Честно я уверен, что специальных блокировок тем более движимых политически со стороны Spotify не будет, как минимум по тому, что блокировка доступа в иностранный аккаунт с территории РФ ударит по иностранным владельцам, которые по какой-либо причине находятся на территории РФ и пользуются сервисом. Я думаю они просто свернут сервера с ПД в наших ДЦ и вернутся к старому режиму, если правильно помню - изначально 2 недели доступа из любого другого региона, не совпадающего с регионом аккаунта для бесплатных аккаунтов.
Кого они собрались штрафовать и с кого собирать деньги?
Ну тем не менее применяемый инструмент, так сказать штраф в кредит, если решите после штрафа легализоваться (юр. лицо и всё остальное относительно локального рынка), будьте добры сначала закрыть штраф.
Так можно пойти и Байдена оштрафовать для прикола.
Так в целом индивидуальные экономические санкции против лиц не имеющих сбережений/имущества на территории стран вводящих эти самые санкции ровно тоже самое на самом деле.
Спотифай может спокойно уходить и продолжать трансилировать нам в страну подкасты с любыми фейками про ковид и прочую хрень, на мнение РФ им будет плевать.
Ну участник MAANG уже получил ограничения, не спорю, что существуют обходы и они пока законны, однако у подобных ограничений много интересных коллизий.
Ну и опять таки с учётом уже 3-х попыток выйти на рынок (8+ лет), одна из которых получилась, но не на долго (всего год с небольшим). Я не думаю, что они передумают возвращаться на рынок. Тут только вопрос сколько у них времени на это уйдёт, так что закрывать себе даже потенциальный шанс не имеет смысла. Всё-таки это бизнес, а задача бизнеса зарабатывать, тем более в целом этот год локально был достаточно успешным.
Если продолжат обслуживать оплаченные на год аккаунты лучше особо не станет, с учётом сильно меньшей дистрибуции в СНГ. Локальный каталог в лучшем случае продолжит пополняться, но меньшим числом релизов. В худшем - вовсе заморозится по состоянию на апрель 2022.
Тут уж смотря как вы используете сервис, если регулярно следите за релизами, то это явно скажется, если вам достаточно имеющегося каталога (права оплачены то тоже на год), то в целом "и так сойдёт".
Хочу напомнить про модель стриминговых сервисов, собственно почему либо оплата лично от пользователя, либо оплата от третьих сторон с показа рекламы.
Главный пункт без которого стриминговые сервисы не будут работать - это права на дистрибуцию конкретных релизов в конкретной стране, которые собственно покупаются. Причём покупаются заранее на квартал/год с учётом ожидаемого количества "копий"/прослушиваний. Оплата этих прав идёт либо с подписки либо с рекламы в зависимости от типа аккаунта.
~70% стоимости подписки уходит на покупку прав и выплаты правообладателям (это и лейблы и исполнители, авторы текста/музыки и т.д.), остальные ~30% уходят Spotify на зарплаты, сервера, R&D, различные медиа-проекты, кураторские плейлисты и т.д. К слову Spotify всё ещё работает в минус и хорошо, что этот минус закрывают инвесторы. А ~70% уходящие на выплаты в конечном счёте не устраивают исполнителей.
Касаемо мысли пусть работают, а проблемы оплаты переложат на пользователей - так не работает т.к. предоставление сервиса пользователям в кредит это риски, а с учётом предоплатной модели взаимодействия с правообладателями и нахождении в минусе по итогу финансового года (не одного) это ещё более высокий риск. Даже если бы они продолжили работать в таком режиме, есть другие проблемы, описанные далее.
Второй пункт влияющий на работу стриминговых сервисов это собственно связи с правообладателями и дистрибуторами. Напоминаю, что "Большая тройка" (Universal, Warner, Sony) также приостановили работу в РФ. По тем же банальным причинам - сложности в получении оплаты за лицензирование, перечислении отчислений/выплат + сложности в логистике. На Большую тройку приходится ~60-70% мировой дистрибуции с учётом всех дочек и взаимосвязей. Причём это влияет как на стриминговые площадки в РФ (Пятничные/Релизные плейлисты за последние 2-3 недели на 30-60% меньше аналогичных мировых), так и на исполнителей из РФ - дистрибуция через UWS сейчас просто не работает. Более того конкретно про приостановку работы UWS в РФ это влияет и на СНГ т.к. именно российские дочки тройки занимаются дистрибуцией из и в СНГ.
То, что вы получали доступ используя "обходные" способы и аккаунт в другой стране не значит, что они работали в РФ. Ну и соответственно аккаунту из другой страны запускается реклама из страны аккаунта, регулируемая по законам страны аккаунта, но ни как не РФ. А подписка имеет стоимость с учётом платёжеспособности страны аккаунта (для ЕС это €9.99, что к слову в 5 раз дороже подписки в РФ).
Также Spotify последние пару лет активно развивает направление подкастов, которое и так даётся имиджево не легко из-за высказываний/мнений, а с учётом новых законов РФ всё ещё сложнее относительно подкастов. Нарушение законов по любой причине показательно на Google имеет высокий риск в первую очередь экономический. Что касается утверждения про не нахождение в юрисдикции РФ - этот фактор не мешает штрафовать и судить компании вне юрисдикции, надеюсь нет смысла ссылаться на и так очевидные примеры среди крупных интернет компаний и сервисов. Можно самому уйти, а могут и выгнать.
На самом деле Spotify очень не везёт на рынке РФ, то сложности с договорами, то новые законы (сначала о ПД, теперь о фейках). Интересно на сколько они настойчивы и будут ли в 4-ый раз пытаться выйти на рынок РФ.
Dolby Atmos это по сути и есть формат объёмного звука, в котором каждому источнику выдаются координаты в пространстве относительно нулевой точки. И уже под конкретную конфигурацию спикеров сэмплируется звук с учётом физической модели распространения звука. Собственно один файл в формате Dolby Atmos можно воспроизвести как в стерео (но это не просто две дорожки), 5.1, 7.1, 11.2 и других конфигурациях. Записывается звук в Dolby Atmos тоже достаточно специфично, если только это не синтезированный звук (тут всё проще).
В целом @SADKO уже ответил по этому поводу. В случае пары микрофонов у нас фиксированные акустические характеристики, в случае пространственных форматов эти характеристики можно менять. Пространственные форматы очень хорошо прижились в кино и театрах это правда, но и в музыке они вполне используются не так часто конечно, но всё-таки. Есть конкретные музыкальные релизы специально собранные в 3D ровно так же как это делается и для кино, чего уж тут - есть звукозаписывающие студии (именно музыкальные) с полноценными залами Dolby Atmos (всё тоже самое, что используется для кино). Единственное только НО - на стриминговых площадках в основном пространственного формата нет, даже не везде где заявлен Dolby Atmos и в мастере там реальный формат Dolby (Dolby Digital Plus (E-AC3); Dolby TrueHD; Dolby AC-4) в дистрибуции это в основном AAC. А там где формат Dolby всё-таки используется в дистрибуции требуется Dolby Atmos в железе или хотя бы в софте, чтобы собственно использовать дорожки и метаданные к ним.
Вопрос ради вопроса? Если сегодня жесткие диски или SSD не дефицит это ещё не значит, что завтра они не станут дефицитом. Тем более хорошие NVMe в июне прошлого года из-за майнеров уже стоили больше, а некоторые модели были в дефиците. Опять таки я описывал относительно Китая, у него своя экономика своя долгосрочная политика, свои тёрки с США. Враг моего врага это всё конечно хорошо, только вот это тоже быстро завершается, если взгляды расходятся. Всё динамично, нельзя вести долгосрочное планирование исходя только из краткосрочной обозримой перспективы. И естественно каждый в первую очередь заинтересован собой.
Тут проблема в том, что мало повышать зарплаты сотрудникам, нужно сами компании экономически поддерживать ведь опять таки инфраструктура и т.д. Пусть то же уменьшение налогов (хотя это не прям сильно поможет в целом IT).
И вот в купе с этим влияние на инфляцию пусть и не прямое всё же будет. Опять таки не забываем, что шатать будет (местами уже) не только IT. Повышение ключевой ставки тоже повлияет на инфляцию. Да и сама инфляция в разных регионах имеет разные реальные значения.
Так, что товарищ@novoselovне особо то и притянул за уши повышение зарплат. Только если рассматривать IT в вакууме можно говорить о притягивании "за уши", но вот сама система имеет динамику и не находится в замороженном состоянии.
На вскидку для того же Spotify по открытой информации за разные периоды и с разной точностью Z ~= 9-10. Но это слишком с допущениями как на самом деле известно только самому Spotify. У сервисов такого типа Z > 4-5 чисто по тому, что основные расходы на лицензирование контента, хранение его оригинальных копий и копий для доставки (5-10 в разных разрешениях, кодеках и с разным весом для одного оригинала), доставка контента и собственно оставшийся функционал сервиса (базы данных, рекомендательные системы и т.д.).
Интересно, почему вы исключили банки из донатов, и второй вопрос в таком случае с чего вы взяли, что банк вам за ваши исходные коды не донатил на Open Collective (не афишируя, просто одно физ. лицо отправило пожертвование)? Или это другое и такие донаты не считаются, тогда вопрос почему вообще донаты должны считаться оплатой EE? Или они не считаются, тогда почему этот вариант вы считаете приемлимым, но в отношении банка намеренно игнорируете?
Я вообще не понимаю зачем и почему вы сюда притянули "наши"/"ваши"/"мы"/"вы"/"заграница"/"отечественное" и т.д. Тем более с учётом того, что я даже не вёл свою ветку относительно каких либо государств.
Моя ветка про то, что при выборе лицензии для своего исходного кода вам стоит более тщательно разобраться в вариантах. Иначе можно так опубликовать код, а потом узнать, что положив Unlicense вы отдали свои "человеко-часы" и деньги в общественное достояние и юридически не можете претендовать даже на упоминание авторства.
А впрочем знаете, пожалуй раз весь комментарий достаточно желчный и претензионный разберу ка каждый пункт и накидаю как говорится на вентилятор:
Некоммерческая демо-версия софта это ваш исходный код я так понимаю? Тогда почему нигде больше об этом не указано и почему именно под лицензией явно разрешающей коммерческое применение?
Про ярмо и за бусы уж извините, но не нравится, не публикуйте свой исходный код. Возможно вы не доросли до понимания что из себя Open Source и зачем крупные компании в т.ч. Яндекс отдают свои тысячи человеко-часов в открытый доступ (Clickhouse & YDB). Наверное по тому, что сообщество способно подхватить ваш софт, улучшить и в целом превратить его из внутреннего инструмента в повсеместный инструмент (привет Kubernetes).
А уж про враждебность и влияние иностранного капитала тем более. Не нравится не используйте софт иностранных/враждебный компаний и не бурчите. У вас на серверах Windows? Аяяяй вы используете человеко-часы сотрудников Microsoft, Linux аяяяй вы ещё хуже делаете этоже человеко-часы сотрудников Microsoft, IBM, Intel, AMD, Red Hat, Amazon и т.д. ведь это Open Source.
Про веру в заграницу, это вера далеко не в заграницу, а в международные отношения. Когда технологии развиваются по экспоненте настаёт время когда одна сторона просто не может быть "и швец, и жнец, и на трубе игрец". Что самое интересное и забавное это понимают в нашем МинПромТорге. Тот же Aurus это сборная солянка и результат работы десятка стран. А вообще за примерами далеко ходить не нужно, посмотрите на микроэлектронику.
Про мир добра и лицензии отдельная история. Лицензия это юридический документ, а юридические документы это бюрократический инструмент, которым вы себя пытаетесь защитить и от вас пытаются защититься. При разном объёме обмазывания юр. документами казалось бы простые вещи превращаются в недели согласований. Однако без этого никаких договорённости ни локальных ни внешних, ни обменов чем либо за что либо, ни компаний, ни даже государств не было бы.
Неужели вам нужно объяснять, что основная цель бизнеса это зарабатывать? "не коммерческое" и не принесёт денег (нельзя использовать смежно) действительно нафиг нужно - только убытки.
Про ваше бабло на разработку из воздуха. Опять не нравится, не публикуйте свои работы, продавайте с самого начала под проприетарной лицензией, а ещё лучше получите патент и продавайте лицензию с разрешением использовать ваш патент. Однако вы пошли по другому "более лёгкому" пути как вам показалось.
Про отечественные разработки на деревьях снова уж извините, но есть достаточно разработок сделанных в РФ или основная часть в которых сделана в РФ. Однако они все "почему-то" в конечном счёте оказываются не отечественными. Действительно "почему"? Наверное по тому, что здесь никому эти разработки в действительности не нужны, только на бумаге для отчётности. А всякие Nginx и Clickhouse как вы в прошлых пунктах написали "вражеские" с "иностранным капиталом" в конечном счёте.
Не нравятся популярные лицензии, напишите свою с пунктом "non-commercial use only" и всё, однако вы выбрали достаточно известную и узнаваемую лицензию по тому, что это проще и не довольны её условиями.
Международные переговоры и переговоры между компаниями по своей сути одно и тоже - две стороны пытаются сойтись на своих желаниях от сотрудничества, при этом защитившись друг от друга на случай чего. А т.к. эти переговоры априори юридический элемент то всё та же бюрократия и удивляться этому мягко говоря странно. Вы разве только родились? Так ведь всегда было. Любая сторона считает себя объектом отношений, а противоположную сторону субъектом. Т.к. мы это мы, а там они (ваш же первый пункт собственно).
Пожалуйста, можете и не кричать, только не удивляйтесь почему в схеме условно вот товар, а цена "договорная" клиентов меньше, чем когда вы цену и хоть какие-то условия публикуете. Это про дружелюбность и открытость скорее.
Ну и раз вы так прям не собираетесь кричать из каждого утюга, надеюсь как только раскрутитесь всё так же не будете кричать из каждого утюга кто клиент? Или будете т.к. это своего рода составляющая имиджа и позиционирования?
А уже про тунеядство... мда... Если вы не видите как работает человек это не значит, что он не работает... Больше даже не буду по этой теме расписывать.
Ещё раз посыл моей ветки про ознакомление с лицензией которую вы используете, вас она как выяснилось здесь и в посте HomeCredit не устраивает, так почему же вы её всё ещё используете?
Про права, ещё раз читайте именно текст лицензии и понимайте от каких прав вы отказываетесь или какие права отдаёте в неисключительном порядке. Иначе будет как я уже упомянул с Unlicense. А потом вопрос "почему у меня нет авторских прав и вообще я больше ничего не могу в исключительном порядке делать".
Пожалуйста, но раз вы так с рвением хотите судиться с банком из-за того, что банк действовал в рамках вами же установленной лицензии. Как типичный патентный троль, то будьте готовы что с вами могут тоже судиться, причём в первую очередь нормальные/крупные EE клиенты или вовсе отказаться от ваших исходных кодов.
Я вам помогу, для этого перетягивания есть одно слово - бюрократия. И надо это понимать.
Извините меня конечно же за мою прямоту, и за то, что в этой ветке я тратил свои драгоценные часы на безуспешную помощь вам же.
Я вам привёл пример MongoDB, у которой схожая с желаемой вами моделью распространения. Так почему же не перелицензировать ваш исходный код под Server-Side Public License (SSPL) и радоваться жизни? Единственное всех благ от OSS вы не получите т.к. SSPL и AGPL сами по себе не самые открытые и желанные. По стопам Kubernetes, Clickhouse, YDB вы не пойдёте точно.
А в прочем не важно, главное не разочаровывайтесь в OSS, ведь это всё-таки "вражеское" с "иностранным капиталом" и вообще придумано не у нас. (На самом деле модель международных взаимоотношений с общей целью).
Это отдельный случай, обе лицензии открытые, в одном случае вы отказываетесь от авторского права (Unlicense), в другом случае сохраняете авторское право. Такой случай вполне допустим, т.к. указанный проект мультилицензирован из-за того, что Unlicense может не иметь юридической силы в некоторых юрисдикциях, однако обе лицензии не обязуют применять конкретную лицензию и в целом являются совместимыми. Хотя в этом случае имеется законодательное противоречие для юрисдикций воспринимающих Unlicense.
Вот если речь будет идти о двойном лицензировании AGPL и Unlicense, тогда это не возможно, ведь они не совместимы AGPL требует лицензирования всего исходного кода под ней же. Unlicense же не накладывает ограничений на лицензии сопутствующего исходного кода. Хотя код под Unlicense в общественном достоянии.
В этом плане мультилицензирование как я уже указал ещё более сложно т.к. оно может иметь разные цели, в случае автора статьи это коммерческие услуги автора статьи, в случае примера на StackExchange это юридический смысл общественного достояния. Ещё раз подчёркиваю во втором случае конфликта лицензий в целом нет. Но есть НО, в примере со StackExchange фактически поменять лицензию нельзя ведь Unlicense это общественное достояние и отказ от авторских и исключительных прав. Однако если бы применялось мультилицензирование из-за разных лицензий разных частей кода, то они бы могли в будущем сменить лицензию только у кода покрытого лицензией MIT, например на Apache-2.0, если вдруг появятся какие-то куски кода под патентами. Однако код под лицензией Unlicense навсегда остаётся под лицензией Unlicense.
В случае с примером со StackExchange на самом деле есть законодательное противоречие для юрисдикций, в которых будет работать лицензия. С одной стороны это общественное достояние, с другой стороны кто-то владеет исключительными правами, не смотря на то, что они указали о применимости любой из двух лицензий. В этом случае имело бы смысл сделать свою лицензию, которая будет работать в разных юрисдикциях примерно одинаково и не создавать такой коллизии.
Тут подвох в деталях.
Например, Apache-2.0 совершенно не обязует лицензировать производный код под Apache-2.0, однако новая лицензия не должна противоречить Apache-2.0 т.е. должна быть совместимой. Apache-2.0 это разрешительная лицензия. AGPL же наоборот она явно запрещает лицензировать производный код под любой другой лицензией, кроме AGPL. AGPL не разрешительная.
Опять таки подвох в деталях, лицензируя свой исходный код под AGPL вы не отказываетесь от своих авторских прав и других исключительных прав на свой исходный код. Но при этом вы явно в лицензии закрепили неисключительные права для использующих ваш исходный код. Т.к. вы всё ещё владелец исключительными правами вы можете сменить лицензию на любую другую, например Server-Side License, причём новая лицензия может быть диаметрально противоположной первой, однако она не имеет обратной силы. Использующие же ваш исходный код согласно лицензии AGPL не имеют возможности перелицензирования модификаций, Apache-2.0 не запрещает этого.
Т.е. коммиты под AGPL после перелицензирования всё ещё покрываются AGPL, а вот новые уже покрыты Server-Side License. И это не смотря на то, что в коде под Server-Side License имеется код под AGPL, вам как владельцу исключительными правами в виду "исключения" разрешено данное действие, вы же ведь врят ли будете сами на себя подавать в суд за использование своего же исходного года под другой лицензией. Простыми словами вы меняете правила игры для своих пользователей, но именно для последующей игры, а не "задним числом".
Пользователи использующие версию исходного кода под AGPL (до перелицензирования) всё ещё следуют лицензии AGPL. Пользователи перелецензированного исходного кода уже следуют новой лицензии. По своей сути перелицензирование вами как владельцем исключительными правами на исходный код можно сравнить с выпуском нового продукта, как вы в своём примере и указали.
Все кто модифицировал ваш код до перелицензирования всё ещё обязаны следовать AGPL, кто модифицировал после уже следуют новой. Если у них форк, синхронизирующийся с вашей основной веткой, получая перелицензированный код они следуют уже новой лицензии.
Причём лицензия лицензии рознь есть Public Domain лицензии, в которых вы отказываетесь от исключительных прав на исходный код, а в некоторых случаях даже от авторских прав. В таком случае вы уже не имеете право менять лицензию на своё усмотрение.
По этому важно что написано в лицензии, не просто так столько версий открытых лицензий и не счётное количество проприетарных лицензий.
Всё выше расписанное касается случая, когда в один момент времени применяется одна лицензия, когда у вас двойное лицензирование появляется больше дополнительных нюансов, как таже самая совместимость применяемых лицензий - они не должны добавлять коллизий относительно применимости пунктов этих лицензий.
Дело в том, что может да, но если лицензии явно не запрещают иное, AGPL именно такая лицензия, опять таки именно по этому у MongoDB появилась Server-Side License вместо ранее используемой AGPL. Иначе получается, что любая из лицензий может быть расценена как не действительная.
Лицензии это всё-таки юридический документ, который должен соответствовать своим целям, не противоречить законам и собственно говоря всем смежным юридическим документам, на которые она полагается. Иначе какая целесообразность такого документа, если он не исполняется или не исполним всеми сторонами - это просто текст, не более.
Пожалуй имеет смысл "поздравить" автора с тем, что он таки "добился" отказа от использования своего кода - Ответ в статье HomeCredit.
На что хочется обратить внимание... Имеет смысл открыть непосредственно оригинальный текст самой лицензии AGPL-3.0 и изучить пункты изложенные там, как преамбулу, так и все последующие пункты самой лицензии. Всевозможные пояснения в любых других местах на любых языках также не имеет смысла приводить как аргументацию по лицензии, в лицензии на самом деле всё и так ясно изложено и хорошо описано в преамбуле, двойных трактовок быть не должно.
Что касается двойного лицензирования исходного кода, у меня имеются огромные вопросы про юридическую силу EE лицензии автора (ввиду того, что я её публично не нашел). Первый и главный вопрос совместима ли их EE лицензия с AGPL т.к. AGPL предполагает коммерческое использование в себе. Второй вопрос основана ли она на тексте AGPL, если да, то сама лицензия EE нарушает права FOSS, ведь модификация лицензии AGPL явно запрещена, из-за чего к слову её совместимость с GPL отдельно явно прописана в обоих лицензиях.
Более того описанные на wiki CE и EE лицензии не соответствуют действительности. А именно лицензия AGPL предполагает дальнейшее развитие ПО и запрет на препятствие модификаций ПО опубликованного под AGPL. Это касается и любой модификации (кастомизация/адаптация) модели, а именно кастомизация и адаптация в таблице в wiki для лицензии CE (AGPL) отмечены как запрещенные.
Опять таки именно из-за несовместимости коммерческой лицензии с AGPL в MongoDB сделали свою Server-Side License.
Ну и главное подобные ходы в очередной раз заставляют задуматься об использовании подобного открытого кода, причём даже не конкретно этого, а любого лицензированного по AGPL т.к. почему-то AGPL не смотря на достаточную ясность умудряются по разному трактовать. Что ещё раз подчёркивает правильность AGPL Policy в Google.
Вероятнее всего в примере про бинарник as-is (пример относительно mongodb) имелось ввиду, про бинарник собранный из оригинального исходного кода (ровно тот же, что официально предоставляется на сайте).
Касательно примеров с судебными тяжбами - очень мутная история. Из текста ни в первом ни во втором случае не ясно применяли они оригинальный исходный код ghostscript или модифицировали его. И вообще был ли исходный код ghostscript или они вызывали уже собранный бинарник (пусть и поставляемый вместе с их программой). Вызов одной программой бинарника другой программы модификацией исходного кода другой программы не будет.
Единственное пожалуй на что могли бы Artifex Software, Inc ссылаться, это на двойное лицензирование, однако что-то мне подсказывает, что двойное лицензирование одного исходного кода в формате AGPL и другая лицензия для коммерческого пользования само по себе противоречит и нарушает AGPL лицензию. Да и в исках они ссылались именно на AGPL, а не лицензию для коммерческого использования, что странно.
Для начала Google очень перестраховывается, они имеют множество политик касаемых OSS (как для публикации, так и для использования). Например для своего OSS кода (может быть прямым продуктом или просто внутренним инструментом, которым они поделились) - Google использует либо BSD-3-Clause, либо Apache-2.0. Причём приоритет сейчас отдаётся больше Apache-2.0.
AGPL Policy логична тем, что во первых нужно использовать совместимые с AGPL лицензии для сопутствующих исходных кодов. А также любой закрытый/внутренний сервис Google в любой момент может стать либо продуктом для клиентов, либо OSS. В таком случае, AGPL заставит открыть исходный код всех инструментов по цепочке, что совсем не выгодно.
Относительно нарушения лицензии, как сказано в статье - ответ очевидно "нет не нарушили". И вот почему, давайте рассмотрим один из последних абзацев преамбулы лицензии AGPL:
У нас тут есть ровно два условия, которые должны быть выполнены одновременно:
Мы модифицировали исходный код.
Мы применяем исходный код не для личных целей (предоставляем кому-то ещё доступ к программе).
Т.е. мы можем применять модифицированный исходный код и не открывать его ровно до тех пор, пока мы используем его в личных целях. Если мы предоставляем сервис/услугу другим пользователям (тут нужно отметить - не важно каким внешним или внутренним), мы обязаны открыть этот исходный код этим самым пользователям (и вот это очень важно).
Получается, что даже если мы попали под обязанность открыть исходный код модифицированной версии это не значит, что мы открываем исходный код абсолютно всем:
Если мы сделали внутренний сервис, которым пользуются только сотрудники компании мы обязаны открыть исходный код сотрудникам, использующим этот сервис.
Если мы сделали закрытый сервис (например, предоставляем услуги за оплату), мы обязаны открыть исходный код нашим клиентам, имеющим доступ к сервису.
Если мы сделали публичный/широкодоступный сервис (может использовать вообще кто угодно), мы обязаны открыть исходный код всем потенциальным пользователям.
В целом название AGPL (GNU Affero), как бы намекает о наличии какого-то "предложения".
Ну... Нейронные сети по своей сути это тоже как таковой технологии 1960-1980гг. в новом исполнении.
А так в целом лучше увы не получается, для кого-то эти списки работаю, для кого-то они сильно бесполезны. Потом у любых рекомендаций всё-равно будет шум, даже если его намеренно не подмешивать. Про те же жанры всё тоже сложно. Тот же House пошел от Jazz и даже Blues и в ряде случаев House можно отнести к ним, хотя House тоже разный бывает. Так ещё есть и мифический жанр Pop влияющий на все жанры, ровно по тому, что Pop это фактически популярная музыка и она может быть по факту любого жанра. Причём Pop в постоянном движении, Pop 2000x совсем не совпадает с Pop 2020x. В целом жанры тоже не дискретны и имеют характер изменяться.
В общем с такими алгоритмами работает единственно верное решение - введение большего числа факторов, те же самые отметки "нравится"/"не нравится" ровно про расширение входных факторов, между которыми будут искаться наиболее сильные пересечения.
Ну тогда угрозу и опасения нужно распространять на абсолютно всех, даже на собственный внутренний продукт компании. Тётю Клаву может читать кто угодно, даже безопасники собственной компании и цель этого так же не известна. Перестать работать может тоже что угодно. Да и утечки с компрометациями тоже происходят. Так, что Zero Trust - ни кому верить нельзя. В общем странно, что может внезапно пропасть доверие при том, что раньше всё было ровным счётом так же. Ничего, кроме рисков цепочки поставки о которых забыли не произошло.
Разве рекомендательные алгоритмы должны рекомендовать только "похожее" по жанру или звучанию? По моему как раз таки у Spotify алгоритмы намеренно подкидывают и другие жанры, но близкие по различным характеристикам, например по BPM и ключевой ноте. Или то, что коллективно слушает целевая группа этих исполнителей, тех же исполнителей с совместных работ. Просто, чтобы было не скучно сидеть в "пузыре" и можно было искать и находить другие направления.
Тем не менее есть и примеры по типу Cloudflare, которые продолжают работать, более того тестируют новые инструменты в регионе. Опять таки VMWare и HashiCorp это инфраструктура и их действия могут повлиять на целые бизнесы. HashiCorp как таковой на конкретно рынке РФ и не работали. Уже упомянутый Cloudflare имеет большее влияние, чем HashiCorp, однако они придерживаются противоположной точки зрения, причём этой же точки зрения придерживается на самом деле и правительство США. Т.е. компании решившие заблокировать, что называется "на опережение тренда" ошиблись с настроем. Ровно как некоторые наши провайдеры блокировали "на опережение" до попадания сайтов в список блокировки РКН, а потом оказывалось, что заблокированные сайты не попали под блокировку РКН, а пользователям этих провайдеров уже доставлены неудобства как минимум.
Spotify совсем из других степей, они в этом плане ни как повлиять не могут, ну уйдут и спрашивается что - ни горячо, ни холодно. Я бы даже сказал, что они наоборот пытаются расширять свой охват. Также не забываем, что Spotify в ЕС на статусе "импортозамещения" по отношению к стриминговым сервисам США.
Нужно всё-таки уметь различать компании по "влиянию" и по "целям/идеалам" их бизнеса. А то также про блокировку РФ можно сказать и относительно сервисов Pandora, Vevo или Disney+, на которые с российский IP адресов нельзя зайти (на самом деле туда нельзя зайти с любых IP адресов вне регионов обслуживания = лицензирования контента, даже если аккаунт из региона обслуживания).
Я не увидел предпосылок блокировки доступа в зарубежный аккаунт с территории РФ. Я понимаю, что вы вероятно зацепились за текст в FAQ разделе и скорее всего увидели в нём то, чего по факту нет. Честно я уверен, что специальных блокировок тем более движимых политически со стороны Spotify не будет, как минимум по тому, что блокировка доступа в иностранный аккаунт с территории РФ ударит по иностранным владельцам, которые по какой-либо причине находятся на территории РФ и пользуются сервисом. Я думаю они просто свернут сервера с ПД в наших ДЦ и вернутся к старому режиму, если правильно помню - изначально 2 недели доступа из любого другого региона, не совпадающего с регионом аккаунта для бесплатных аккаунтов.
Ну тем не менее применяемый инструмент, так сказать штраф в кредит, если решите после штрафа легализоваться (юр. лицо и всё остальное относительно локального рынка), будьте добры сначала закрыть штраф.
Так в целом индивидуальные экономические санкции против лиц не имеющих сбережений/имущества на территории стран вводящих эти самые санкции ровно тоже самое на самом деле.
Ну участник MAANG уже получил ограничения, не спорю, что существуют обходы и они пока законны, однако у подобных ограничений много интересных коллизий.
Ну и опять таки с учётом уже 3-х попыток выйти на рынок (8+ лет), одна из которых получилась, но не на долго (всего год с небольшим). Я не думаю, что они передумают возвращаться на рынок. Тут только вопрос сколько у них времени на это уйдёт, так что закрывать себе даже потенциальный шанс не имеет смысла. Всё-таки это бизнес, а задача бизнеса зарабатывать, тем более в целом этот год локально был достаточно успешным.
Если продолжат обслуживать оплаченные на год аккаунты лучше особо не станет, с учётом сильно меньшей дистрибуции в СНГ. Локальный каталог в лучшем случае продолжит пополняться, но меньшим числом релизов. В худшем - вовсе заморозится по состоянию на апрель 2022.
Тут уж смотря как вы используете сервис, если регулярно следите за релизами, то это явно скажется, если вам достаточно имеющегося каталога (права оплачены то тоже на год), то в целом "и так сойдёт".
Наверное лучше тогда в ogg opus
Хочу напомнить про модель стриминговых сервисов, собственно почему либо оплата лично от пользователя, либо оплата от третьих сторон с показа рекламы.
Главный пункт без которого стриминговые сервисы не будут работать - это права на дистрибуцию конкретных релизов в конкретной стране, которые собственно покупаются. Причём покупаются заранее на квартал/год с учётом ожидаемого количества "копий"/прослушиваний. Оплата этих прав идёт либо с подписки либо с рекламы в зависимости от типа аккаунта.
~70% стоимости подписки уходит на покупку прав и выплаты правообладателям (это и лейблы и исполнители, авторы текста/музыки и т.д.), остальные ~30% уходят Spotify на зарплаты, сервера, R&D, различные медиа-проекты, кураторские плейлисты и т.д. К слову Spotify всё ещё работает в минус и хорошо, что этот минус закрывают инвесторы. А ~70% уходящие на выплаты в конечном счёте не устраивают исполнителей.
Касаемо мысли пусть работают, а проблемы оплаты переложат на пользователей - так не работает т.к. предоставление сервиса пользователям в кредит это риски, а с учётом предоплатной модели взаимодействия с правообладателями и нахождении в минусе по итогу финансового года (не одного) это ещё более высокий риск. Даже если бы они продолжили работать в таком режиме, есть другие проблемы, описанные далее.
Второй пункт влияющий на работу стриминговых сервисов это собственно связи с правообладателями и дистрибуторами. Напоминаю, что "Большая тройка" (Universal, Warner, Sony) также приостановили работу в РФ. По тем же банальным причинам - сложности в получении оплаты за лицензирование, перечислении отчислений/выплат + сложности в логистике. На Большую тройку приходится ~60-70% мировой дистрибуции с учётом всех дочек и взаимосвязей. Причём это влияет как на стриминговые площадки в РФ (Пятничные/Релизные плейлисты за последние 2-3 недели на 30-60% меньше аналогичных мировых), так и на исполнителей из РФ - дистрибуция через UWS сейчас просто не работает. Более того конкретно про приостановку работы UWS в РФ это влияет и на СНГ т.к. именно российские дочки тройки занимаются дистрибуцией из и в СНГ.
То, что вы получали доступ используя "обходные" способы и аккаунт в другой стране не значит, что они работали в РФ. Ну и соответственно аккаунту из другой страны запускается реклама из страны аккаунта, регулируемая по законам страны аккаунта, но ни как не РФ. А подписка имеет стоимость с учётом платёжеспособности страны аккаунта (для ЕС это €9.99, что к слову в 5 раз дороже подписки в РФ).
Также Spotify последние пару лет активно развивает направление подкастов, которое и так даётся имиджево не легко из-за высказываний/мнений, а с учётом новых законов РФ всё ещё сложнее относительно подкастов. Нарушение законов по любой причине показательно на Google имеет высокий риск в первую очередь экономический. Что касается утверждения про не нахождение в юрисдикции РФ - этот фактор не мешает штрафовать и судить компании вне юрисдикции, надеюсь нет смысла ссылаться на и так очевидные примеры среди крупных интернет компаний и сервисов. Можно самому уйти, а могут и выгнать.
На самом деле Spotify очень не везёт на рынке РФ, то сложности с договорами, то новые законы (сначала о ПД, теперь о фейках). Интересно на сколько они настойчивы и будут ли в 4-ый раз пытаться выйти на рынок РФ.
Dolby Atmos это по сути и есть формат объёмного звука, в котором каждому источнику выдаются координаты в пространстве относительно нулевой точки. И уже под конкретную конфигурацию спикеров сэмплируется звук с учётом физической модели распространения звука. Собственно один файл в формате Dolby Atmos можно воспроизвести как в стерео (но это не просто две дорожки), 5.1, 7.1, 11.2 и других конфигурациях. Записывается звук в Dolby Atmos тоже достаточно специфично, если только это не синтезированный звук (тут всё проще).
В целом @SADKO уже ответил по этому поводу. В случае пары микрофонов у нас фиксированные акустические характеристики, в случае пространственных форматов эти характеристики можно менять. Пространственные форматы очень хорошо прижились в кино и театрах это правда, но и в музыке они вполне используются не так часто конечно, но всё-таки. Есть конкретные музыкальные релизы специально собранные в 3D ровно так же как это делается и для кино, чего уж тут - есть звукозаписывающие студии (именно музыкальные) с полноценными залами Dolby Atmos (всё тоже самое, что используется для кино). Единственное только НО - на стриминговых площадках в основном пространственного формата нет, даже не везде где заявлен Dolby Atmos и в мастере там реальный формат Dolby (Dolby Digital Plus (E-AC3); Dolby TrueHD; Dolby AC-4) в дистрибуции это в основном AAC. А там где формат Dolby всё-таки используется в дистрибуции требуется Dolby Atmos в железе или хотя бы в софте, чтобы собственно использовать дорожки и метаданные к ним.
Вопрос ради вопроса? Если сегодня жесткие диски или SSD не дефицит это ещё не значит, что завтра они не станут дефицитом. Тем более хорошие NVMe в июне прошлого года из-за майнеров уже стоили больше, а некоторые модели были в дефиците. Опять таки я описывал относительно Китая, у него своя экономика своя долгосрочная политика, свои тёрки с США. Враг моего врага это всё конечно хорошо, только вот это тоже быстро завершается, если взгляды расходятся. Всё динамично, нельзя вести долгосрочное планирование исходя только из краткосрочной обозримой перспективы. И естественно каждый в первую очередь заинтересован собой.
Тут проблема в том, что мало повышать зарплаты сотрудникам, нужно сами компании экономически поддерживать ведь опять таки инфраструктура и т.д. Пусть то же уменьшение налогов (хотя это не прям сильно поможет в целом IT).
И вот в купе с этим влияние на инфляцию пусть и не прямое всё же будет. Опять таки не забываем, что шатать будет (местами уже) не только IT. Повышение ключевой ставки тоже повлияет на инфляцию. Да и сама инфляция в разных регионах имеет разные реальные значения.
Так, что товарищ@novoselovне особо то и притянул за уши повышение зарплат. Только если рассматривать IT в вакууме можно говорить о притягивании "за уши", но вот сама система имеет динамику и не находится в замороженном состоянии.
На вскидку для того же Spotify по открытой информации за разные периоды и с разной точностью Z ~= 9-10. Но это слишком с допущениями как на самом деле известно только самому Spotify. У сервисов такого типа Z > 4-5 чисто по тому, что основные расходы на лицензирование контента, хранение его оригинальных копий и копий для доставки (5-10 в разных разрешениях, кодеках и с разным весом для одного оригинала), доставка контента и собственно оставшийся функционал сервиса (базы данных, рекомендательные системы и т.д.).