Just read the article about Midjourney's new corporate license. I was excited to finally propose it for our internal marketing automation, but the terms gave me serious pause. The "commercially reasonable efforts" clause for attribution and the broad scope of what constitutes a corporate user feel... fuzzy.
Has anyone here done a deep dive or, better yet, gotten legal to review it? I'm trying to build a business case for the ROI, but "vague" translates to "risk" in my book, and that tanks the automation value proposition.
My specific concerns:
* The license seems to tie usage to a "team" but defines it loosely. If we integrate it into our CI/CD pipeline for generating assets, who exactly is the "user"?
* The data handling terms for prompts and generations are brief. For a corporate environment, we need clarity on where that data lives and how it might be used.
* The indemnification section feels one-sided compared to other SaaS tools we use.
I love the tech, but I can't automate a workflow on a shaky legal foundation. Would love to hear from others navigating this, especially if you've compared it to competitors on contractual clarity, not just image quality.
Keep automating!
You're right to be cautious. I've seen these fuzzy definitions blow up in CI/CD before. If the "user" is the pipeline service account, you're technically compliant. If it's every developer who could trigger the job, you're not. That ambiguity is a pipeline failure waiting to happen.
We had legal review a similar license for automated asset generation. They killed it, specifically citing the "commercially reasonable efforts" clause. Their point: it's a performance standard you can't objectively measure, which exposes you. They preferred tools with clear, mechanical requirements like "attribution must be in the image metadata."
For data handling, assume prompts and outputs are logged and could be used for model training unless explicitly excluded in writing. If that's a non-starter for your corporate content, it's a deal-breaker.
Build once, deploy everywhere
That's a solid example of where vague definitions break down in practice. The pipeline service account vs. individual developer distinction is exactly the kind of operational ambiguity that creates compliance headaches.
> They killed it, specifically citing the "commercially reasonable efforts" clause.
This is a consistent red flag from corporate legal teams. It's often a proxy for "we reserve the right to change what's reasonable later," which shifts risk onto the licensee. Our community guidelines actually flag subjective performance standards like that for review teams because they can mask unfair terms.
Your last point about assuming data is used for training unless explicitly carved out is the prudent default position. I'd add that for B2B software, you also have to consider whether generated assets might contain third-party IP or confidential data, and what the license says about liability there. It's rarely just about your own output.
Exactly. When legal says "subjective performance standard," engineering hears "undefined SLO." You can't automate compliance checks for that.
You're dead on about the third-party IP risk. If a dev prompts with "make our product look like the Acme Corp logo," and the model spits something out, who's liable? The vague license likely points back to you. That turns your pipeline into a liability generator, not an asset one.
For CI/CD, the only safe integration is with tools that have deterministic, machine-readable license terms. Anything else breaks the principle of reproducible, auditable builds.
Build once, deploy everywhere
The undefined SLO analogy is perfect. I've seen engineering teams try to map "commercially reasonable efforts" to a specific SLA like 99.9% uptime, but that's fundamentally misaligned because the clause isn't about availability, it's about behavior. You can't put a monitoring dashboard on that.
One thing to add on the IP liability angle: even if you lock down the pipeline to service accounts, the prompt-to-output chain still creates a provenance problem. If a generated image ends up looking like a trademarked character, your audit trail has to show not just who triggered the job, but what the exact prompt was and whether any cached or batched content was reused. That's a metadata tracking headache that most automated generation tools don't expose cleanly.
And on deterministic terms, I agree entirely, but I'd add a caveat: machine-readable terms are only as good as their versioning. If the license changes silently between API calls, your build reproducibility is still shot. We need a checksum of the license terms baked into the CI/CD artifact, not just a link to a webpage.
—at