Model licences

1.Why this page exists

DocxIntel ships model weights to you. That is the whole point of the architecture — the models run on your hardware, so nothing needs to leave your network — but it creates an obligation that a hosted API never has to explain. When you receive weights, you receive licence terms with them, and you need to know what those terms let you do before you put the deployment into production.

Most buyers ask three questions in the same order. Can I use this commercially, in production, at volume? Can I keep using it if my connectivity is cut or the vendor disappears? And what exactly am I forbidden from doing with the weights sitting on my storage? This page answers all three at the level of principle, and tells you how to get the exact per-model answer for the release you are being offered.

One thing this page deliberately does not do is assert which licence applies to which named model. Model licences change between versions and publishers revise their terms, so a claim published on a website is a claim that will eventually be wrong. The authoritative statement for any release is the notice file inside that release.

BizfyLabs FZC LLC selects components for commercial, on-premise, air-gapped use and reviews the licence position of every component before it ships. Where a model cannot be used that way, it does not go in the bundle.

2.What ships in the deployment bundle

A deployment bundle is a single distributable artefact containing everything needed to run DocxIntel without reaching the internet. It contains two legally distinct classes of material, and keeping them distinct is what makes the licensing tractable.

Third-party open-weight models

The pretrained models that perform layout analysis, optical character recognition, handwriting recognition, table structure recognition, embedding and generation. These are published by third parties under their own licences. BizfyLabs distributes them; it does not own them and cannot grant you rights the publisher has not granted.

BizfyLabs components

The orchestration services, pipelines, pre- and post-processing, Arabic reading-order and bidirectional text handling, confidence calibration, field-level traceability, APIs, administrative tooling and any weights fine-tuned by BizfyLabs. These are licensed to you by BizfyLabs under your licence agreement.

Open-source dependencies

Inference runtimes, base container images, libraries and system packages, each under its own open-source licence — predominantly permissive licences, with copyleft components isolated so their obligations do not reach your own code.

Manifests and provenance artefacts

The notice and licence files, the per-model licence manifest, a software bill of materials, cryptographic digests for every image and weight file, and the version pins that let you reproduce exactly what you installed.

The bundle is versioned as a whole. A given DocxIntel release corresponds to a fixed set of model versions, digests and licence texts, so the question "what am I allowed to do with what I installed" has one answer per release rather than a moving one. The component inventory is described in more detail at docxintel.com/whats-in-the-box.

3.How open-weight model licences work

"Open weights" is not the same as "open source", and it is not one legal regime. It means the trained parameters are published for download. What you may then do with them depends entirely on the licence attached, and those licences fall into recognisable categories. Understanding the categories is more useful than memorising individual names.

Permissive licences

Licences in the Apache 2.0, MIT and BSD families. These typically permit commercial use, modification, redistribution and private deployment, with the main obligations being to retain the copyright notice and licence text and, in the Apache case, to state significant changes. Some include an explicit patent grant and a termination clause triggered by patent litigation. These impose the fewest constraints on an enterprise deployment.

Community and use-restricted licences

Licences published by a model developer under its own name, and responsible-AI licences of the OpenRAIL type. They typically permit commercial use and self-hosting, but add conditions: an acceptable-use annex prohibiting specified harmful applications, attribution or naming requirements, a restriction on using outputs to train a competing model, and sometimes a scale threshold — for instance a monthly active user count — above which separate permission from the publisher is required. Most enterprise deployments sit comfortably below such thresholds, but the condition is real and must be checked.

Copyleft and share-alike licences

Less common for weights than for code, and where they appear they can require derivative works or a modified model to be released under the same terms. Their significance for a deployment is scope: they may apply to a component without reaching your own applications, provided the boundary is respected. We isolate such components accordingly.

Non-commercial and research-only licences

Licences restricting use to research or non-commercial purposes, or making commercial use conditional on a separate agreement with the publisher. Weights under these terms are not shipped in a commercial DocxIntel deployment bundle. Where such a model is genuinely the best available for a capability, we say so and we do not include it.

Two practical notes. First, a licence attaches to the weights, so it travels with the copy in your storage and continues to apply after your DocxIntel licence ends — which is why the bundle must be deleted on termination. Second, several licences distinguish between using a model and using its outputs; where a licence restricts what outputs may be used for, that restriction is recorded in the per-model manifest.

4.What you may do with the models you receive

Subject to your licence agreement and to the specific terms of each component, the permissions below are the ones that make an on-premise deployment worth having. They are also the ones we check before a component enters the bundle.

• Run the models in production, for your own internal business purposes, across the deployments recorded in your order form.
• Run them fully air-gapped, with no outbound connectivity and no licence check that requires reaching us or a model publisher.
• Process unlimited document volume. There is no per-page, per-document or per-token charge, and no metering to reconcile at year end.
• Reprocess your entire archive as often as you like — after a model update, a schema change or a threshold adjustment — at no incremental licence cost.
• Retain, store, index and further use the outputs produced from your documents inside your own systems, subject to any output restriction recorded in the manifest for that component.
• Run the models on your choice of infrastructure: bare metal, your own data centre, your private cloud tenant or a sovereign cloud region.
• Copy the bundle for backup, disaster recovery and staging, and keep those copies for as long as your licence runs.
• Have your own security team inspect the artefacts, verify the digests and scan the images before installation.
• Continue operating the deployment you have installed for the remainder of your licence term, independently of our availability, because nothing about the runtime depends on us.

5.What you may not do

The restrictions below come from two sources: the licences granted to us by the model publishers, which we cannot exceed, and our own licence terms. Both are set out in full in the terms and conditions at docxintel.com/terms-conditions and the acceptable use policy at docxintel.com/acceptable-use.

• Do not redistribute the model weights. They may not be published, shared, uploaded to a public or private model hub, sold, sublicensed or passed to a third party outside your licence.
• Do not extract the weights from the deployment for use in a separate system, product or model, and do not distil, clone or attempt to reconstruct them.
• Do not reverse engineer the models or the software to derive architecture, parameters or training data, except where mandatory law expressly permits it.
• Do not remove, obscure or alter attribution, copyright notices, licence files or model identification, in the bundle or in a product built on it.
• Do not use the models or their outputs to train a competing model where the applicable component licence prohibits it.
• Do not use the deployment to provide a document-processing service to third parties unless a written reseller or service-provider addendum permits it.
• Do not use the models for a purpose prohibited by an acceptable-use annex in a component licence, or by the DocxIntel acceptable use policy.
• Do not exceed a scale threshold in a component licence without obtaining the permission that licence requires. Tell us if you expect to approach one and we will help you work out where you stand.
• Do not retain any part of the bundle after your licence ends. On termination the software and the weights must be removed and all copies destroyed.

6.Attribution and notice files

Every release ships with the attribution material its components require, assembled at build time from the components actually included rather than maintained by hand. That is deliberate: a notice file compiled from the build is accurate, and one edited manually eventually is not.

• A top-level NOTICE file listing every third-party component, its version, its publisher and its licence identifier.
• The full, unmodified licence text for each component, in a licences directory inside the bundle.
• A per-model manifest recording the model name, version, publisher, licence, licence URL, artefact digest and any use restriction or output restriction that applies.
• Attribution statements required by a component licence, in the form that licence prescribes.
• A record of any modification BizfyLabs has made to a component, where the licence requires significant changes to be stated.

These files must remain intact in your deployment. If you build a customer-facing product on top of DocxIntel and a component licence requires attribution to be passed on, the manifest tells you which notices to carry forward and in what form.

7.Model updates and licence changes between versions

Models improve, and publishers occasionally change their terms. Neither event should be a surprise you discover during an audit, so we treat a licence change as a release-blocking matter rather than a footnote in release notes.

• Every release is reviewed for component licence changes before it is published, and the manifest is regenerated from the build.
• Where an update changes the licence position of a component in a way that affects your permitted use — a new use restriction, a new threshold, a changed attribution requirement — we tell you before you upgrade, in the release notes and through your technical contacts.
• Where a publisher changes terms in a way we consider unacceptable for regulated, on-premise use, we look for a replacement component rather than pass the restriction on to you.
• You are never forced to upgrade to stay licensed. A release you have installed keeps the licence terms it shipped with, and an air-gapped deployment can stay on a known-good version indefinitely within your licence term.
• Upgrading is a decision with a validation cost, so we publish what changed at the model level, including which capabilities are affected, so you can decide what to re-validate.
• We recommend re-running your own accuracy validation after a model update rather than assuming parity across versions.

The version pins and digests in the manifest are what make this manageable. You can prove which weights you are running, and demonstrate that they are the ones whose licence you reviewed.

8.Commercial-use assurance and our indemnity position

A procurement team usually wants two things here: an assurance that the components are cleared for commercial use, and an indemnity if that assurance turns out to be wrong. Both are available, and it is worth being precise about their limits.

• Assurance: every component in a commercial deployment bundle is reviewed and selected for commercial, on-premise, air-gapped use before shipping. Non-commercial and research-only weights are excluded.
• Indemnity: our licence agreement includes an intellectual property indemnity covering the software as delivered by us and used in accordance with the documentation and the licence, and that indemnity extends to the model weights we distribute, to the extent of the rights our licensors grant us.
• Limits: the indemnity does not cover your modification of a component, combination with materials we did not supply, use outside the licence or the documentation, or continued use after we have provided a non-infringing alternative.
• Third-party terms prevail for third-party components. We cannot grant you rights the publisher has not granted, and no assurance from us overrides the text of a component licence.
• Remedies: if a claim arises, we may procure the right for you to continue, modify or replace the affected component, or terminate the affected licence and refund the fees for the unused remainder of the term.
• Scope of the indemnity, any cap that applies to it and the claims procedure are recorded in your executed agreement, not on this page.

We do not claim to hold any certification or attestation in relation to component licensing, and we will not imply one. What we provide is a documented review process, a manifest you can verify independently and a contractual indemnity you can point your auditor at.

9.SBOM and provenance artefacts

Everything above is only useful if you can verify it yourself. Each release ships with the artefacts a supply-chain review needs, so your assurance team can confirm what is in the bundle without taking our word for it.

• A software bill of materials in a standard machine-readable format, covering container images, system packages, language dependencies and model artefacts.
• Cryptographic digests for every container image and every weight file, so an installed deployment can be matched against the published release.
• Signatures on release artefacts, allowing you to verify origin and integrity before installation in an air-gapped environment.
• The per-model licence manifest, in both a human-readable and a machine-readable form, so it can be ingested by your own compliance tooling.
• Version pins and build metadata sufficient to reproduce the inventory of a given release.
• Vulnerability scan output for the release, and the advisory channel through which later findings and fixes are published to affected customers.

These artefacts travel inside the bundle, which matters for an air-gapped install: verification does not require reaching an external service, because everything needed to verify is already on the media you received.

10.How to get the full per-model licence manifest

The manifest is release-specific, because that is the only way it can be correct. There is no single list that describes every DocxIntel version, and we would rather give you the accurate document for the release in front of you.

• The manifest ships inside every deployment bundle, alongside the NOTICE file and the licences directory. If you have a bundle, you already have it.
• Before you receive a bundle, the manifest for a specific release is available on request through the contact page at https://bizfylabs.com/contact-us. Tell us the release you are evaluating, or ask for the current one.
• It is provided as part of the Proof of Value pack, so your legal and security teams can review the licence position during the engagement rather than after it.
• It is also provided during procurement for the release you would be deploying, so a licence review can complete before signature.
• Component-level technical documentation is published at https://docs.bizfylabs.com, and the inventory of what ships in a deployment is summarised at docxintel.com/whats-in-the-box.

If your organisation needs the manifest in a particular format for its own compliance tooling, ask. It is generated from the build, so producing an additional machine-readable form is usually straightforward.

11.The authoritative licence text

This page is a description written to help you evaluate the product. It is not a licence, it grants no rights, and it is not a substitute for the licence text itself.

For any DocxIntel release, the authoritative licence terms are the NOTICE file, the licences directory and the per-model manifest shipped inside that release. Where anything on this page differs from those files, those files govern. Where anything on this page differs from your executed licence agreement or order form, that agreement governs.

Model licensing is an area where reasonable lawyers reach different conclusions about the same text, particularly on output restrictions and scale thresholds. Please have your own counsel review the manifest for the release you intend to deploy, and tell us if you read a term differently from us — we would rather have that conversation before you install than after.