FLUX.1: choose the licence before choosing the model
The original FLUX.1 release offered three different routes. Choose model and output terms that fit the intended use before comparing quality or hosting.
By 
Paul. AI and agentic engineering
A team considering image generation should choose an eligible distribution and licence before spending time on image quality or hosting costs. FLUX.1 made that order particularly important: one family name covered an API service and two downloadable models with different terms. A good-looking sample could come from a route unsuitable for the product being planned.
Black Forest Labs dated its launch announcement 1 August 2024, inside the historical week beginning 31 July. Looking back in November 2026, the useful lesson is how to make that first selection. The comparison below concerns the original release, rather than recommending a 2024 model for a new deployment today.
Start with what the business will actually do
Write down who runs the model and who receives the images. An employee exploring a model away from production, a business publishing selected images and a service generating images for paying customers describe different activities. A licence question answered for one activity does not settle the others.
Separate three decisions. Access to weights means obtaining the model's learned parameters. Permission to operate or redistribute those weights determines what the team can build with them. Permission concerning outputs addresses the resulting images. With an API, the team also needs to examine the chosen service agreement. Having a working endpoint answers a technical question about access.
The original repository README makes the launch distinction concrete. It lists FLUX.1 [pro] as API-only, links dev weights to a non-commercial licence and links schnell weights to Apache 2.0. The model-specific links matter. A licence elsewhere in the repository is insufficient evidence for every weight file.
For pro, that source establishes the API route. It does not establish the original provider's promises about image rights, retention or customer contracts. A team choosing that route would need the service terms for its actual supplier before making commitments to customers.
Dev separated outputs from the model, with important limits
The original dev licence limits model rights to its defined non-commercial purposes. That definition includes certain business testing and evaluation in a non-production environment. Other model uses are directed to a separate BFL licence. Calling a deployment a pilot does not establish that it fits the definition.
Section 2(d) separately says outputs may be used commercially, subject to the document's prohibitions, including a restriction on training a competing model. BFL also disclaims ownership of outputs there. Neither statement establishes the user's copyright ownership, exclusivity or clearance of third-party rights.
The wording needs care: section 1(c) refers to payment arising from model use or its output, while section 4(a) extends restrictions to model-produced data and commercial or production purposes. This article does not resolve their interaction with section 2(d), or assure readers that operating a commercial inference service is permitted.
The launch dev model card also describes commercial output use by reference to the licence. That supports attributing the distinction to BFL. For a proposed paid image-generation feature, obtain terms addressing the actual operation before building the production system around dev weights.
Schnell offered a different starting point
The original schnell model card describes personal, scientific and commercial model use under Apache 2.0. For a team intending to operate downloaded weights commercially, that was a materially different starting point from dev's non-commercial model licence.
The model-specific Apache licence still has conditions. Redistribution can require supplying the licence, preserving relevant notices and marking changed files. Those considerations matter if the deliverable includes model files or modifications, rather than only access to an application.
That text does not contain dev's separate generated-output clause. It does not establish that every generated image carries Apache 2.0 or has unrestricted uses. Keep the model licence and the proposed publication of an image as separate review questions. The card also lists out-of-scope uses; this comparison does not settle their contractual relationship with the Apache terms.
Compare quality among routes the product can use
The strongest objection to this order is practical: a model with unsuitable output is worthless to the product, however convenient its licence. A short quality exploration can avoid weeks spent negotiating terms for a model that cannot do the job. Commercial teams also sometimes negotiate the rights they need after identifying a preferred model.
That is a good reason to allow a bounded evaluation under terms that permit it. Set the evaluation's limits and keep its result separate from production approval. The recommendation is to avoid treating a successful sample as a decision to deploy. It does not require completing every procurement discussion before looking at an image.
Once plausible routes remain, compare them against the actual task. For a proposed product-illustration feature, check whether an image invents details that could mislead the buyer. For images containing Romanian text, assess the required wording and accents. These are suggested acceptance checks, not results from a test conducted for this article.
The original cards contain BFL's quality claims and also warn that outputs may fail to match prompts. Vendor comparisons can motivate an evaluation; they cannot replace it. Enthusiasm from an investor is interested-party evidence too. No independent performance ranking follows from this licence comparison.
Hosting then becomes a question about a route the team can plausibly adopt. Estimate operating costs and responsibility for failures using the intended workload. An API may reduce infrastructure work, while operating weights may give the team more control. Neither choice removes the need to examine its own terms and operational constraints.
Leave a decision the next owner can understand
Record the precise variant, where it will run, the intended users and the documents supporting the decision. Preserve the source revision alongside the planned use. The launch citations here point to BFL's initial repository commit so readers can inspect the original documents without assuming a current licence page reproduces them.
This recommendation adds little when the team is only consuming finished images under an already reviewed supply agreement and never chooses or operates the model. It also does not replace a negotiated licence covering a specific deployment. In those cases, assess the agreement governing the work rather than applying a historical comparison mechanically.
For an AI feature you commission, ask the proposal to identify the distribution route and the terms to resolve before production. Compare quality and cost within that shortlist. The useful deliverable is a choice the business can explain and carry into operation, with unresolved permissions visible before they become promises to customers.