Midjourney litigation 2026: vendor risk і fallback-маршрутизація bulk-зображень у Bubble

Чому це зараз

У публічному digest згадували Rule 12(c) hearing на 28.09.2026; актуальна дата з docket (Lead Case Dkt. 143, 23.07.2026): 26.10.2026, 8:30, Courtroom 10C, Judge Kronstadt. Консолідована справа Disney Enterprises Inc. et al. v. Midjourney Inc., 2:25-cv-05275 (CACD), після позовів Disney/Universal (11.06.2025) і Warner Bros. Entertainment Inc. et al. (04.09.2025, Reuters). Для команд, які тягнуть сотні/тисячі зображень через API у Bubble, це не про «яка модель краще малює», а про операційну невизначеність: політики сервісу, guardrails, доступ API, continuity — поки litigation активна (discovery триває, напр. magistrate order Dkt. 88, 15.06.2026). Про це окремо: Китай ВПС і downstream liability. Про це окремо: Китай ВПС і downstream liability.

Це не юридична порада. Судові матеріали — це allegations; liability Midjourney або її клієнтів публічно не встановлена. Fallback-маршрути — resilience, не compliance guarantee.

Факти, на які спирається текст

• Позови major U.S. studios за direct і secondary copyright infringement (17 U.S.C. § 501); consolidation 05.11.2025, lead docket 2:25-cv-05275.
• Midjourney подала Rule 12(c) motion на partial dismissal contributory infringement у «Second Claim for Relief», посилаючись на Cox Communications v. Sony Music Entertainment, 24-171 (U.S. 25.03.2026): contributory liability потребує intent, що сервіс використовують для infringement — через inducement або сервіс, tailored до infringement.
• Plaintiffs у opposition: secondary theories альтернативно — inducement і vicarious liability; оспорюють, що motion не може зняти весь secondary claim, якщо б’є лише по inducement.
• Briefing deadlines (Dkt. 143): opposition до 11.08.2026, reply до 25.08.2026.

Операційний план для Bubble (bulk images)

1. Primary / secondary маршрути

Зафіксуйте в workflow два незалежні шляхи генерації зображень:

Роль	Призначення
Primary	Звичний vendor (напр. Midjourney через ваш connector/API workflow) для happy path
Secondary	Інший провайдер або інша модель через окремий API call / plugin — увімкнений до інциденту

Практика в Bubble:

• Один Backend workflow «Generate image» з параметром route: primary | secondary | auto-failover.
• Auto-failover: якщо primary повертає timeout, 429, 5xx або policy error — один retry на secondary; логуйте причину switch (не silent fallback).
• Уникайте hardcode «лише Midjourney» у Repeating Group, email templates і scheduled bulk jobs — винесіть provider config у Option set або custom type ImageProvider (name, endpoint, api_version, enabled). Поруч із цим: ByteDance–MPA guardrails на Seedream/Seedance: yield. Про це окремо: Mixboard offline 28.09: експорт промптів.

2. Документування джерела моделі на кожен output

Кожен згенерований asset у вашій БД (або DAM) має мати immutable metadata (хоча б на момент запису):

• vendor (legal entity / product name)
• model_or_plan (як named у API)
• api_version / endpoint id
• generated_at (UTC)
• workflow_run_id / Bubble unique id
• route_used (primary | secondary | failover)
• prompt_hash або truncated prompt policy (якщо зберігаєте prompts — узгодьте з retention policy) Схожий розбір: Qwen-Image-2.1 vs closed models: vendor. Схожий розбір: Qwen-Image-2.1 vs closed models: vendor.

Навіщо: при зміні ToS, takedown internal review або re-generation batch ви знаєте, що саме prod’юсило asset — без reverse-engineering з URL.

3. Multi-provider оркестрація (BIAIG як патерн)

У editorial plan згадано внутрішню BIAIG multi-provider оркестрацію. Публічні court sources не документують можливості BIAIG — тут лише архітектурний патерн, який варто перевірити внутрішньо:

• Router layer (API Connector або dedicated backend): нормалізує request (aspect ratio, size, safety flags) і мапить на provider-specific payload.
• Єдиний response shape у Bubble (url, id, provider_ref) — UI не знає про vendor.
• Feature flag «disable vendor X» без redeploy усіх сторінок.
• Cost / quota counters per provider — щоб secondary не став дорожчим default без рішення.

Це зменшує vendor lock-in і час switch; це не «юридична безпека» і не замінює counsel щодо використання character-like prompts або studio IP.

4. Що свідомо не обіцяти

• Cox не закриває direct infringement, fair use, training-data claims, inducement/vicarious theories у complaints.
• Rule 12(c) outcome невідомий (open questions у research packet).
• Routing fallback не робить outputs «licensed» або «safe for commercial character use».

Checklist перед наступним bulk-run

1. Secondary route протестований на staging з тим самим нормалізованим payload.

• Metadata fields пишуться на create, не post-hoc.
• Runbook: хто вимикає primary за 15 хвилин при outage/policy change.
• Calendar note: 26.10.2026 hearing — не panic deploy; але перегляньте vendor mix, якщо давно не оновлювали.

Джерела (public)

CourtListener dockets 2:25-cv-05275 / 2:25-cv-08376; Dkt. 143 (hearing reset); Midjourney Rule 12(c) motion and plaintiffs’ opposition (RECAP); Cox slip opinion (supremecourt.gov); Reuters 11.06.2025 та 04.09.2025; magistrate order Dkt. 88.