Open source, selected for the way your business operates

Our approach to technology starts with the operational requirement, not the product. Open source software gives us room to adapt a tool to that requirement instead of forcing the requirement into a product designed for a different purpose. The homepage describes this under technology shaped around your business.

It also fits how we run. Software we can inspect, configure, and operate on owned infrastructure gives us more control over deployment, data handling, and capacity than a subscription alone. That control is practical: we can decide how a workflow runs and where it runs, and we can explain both to your reviewers.

This is a working preference, not an ideology. We use commercial services where they fit, and most marketing operations depend on them: advertising platforms, analytics, call tracking, CRM, and email delivery. Open source is how we build the parts in between.

Before we adopt a component, it has to pass the same questions, whether it is a library, an application, or a model.

• Fit for the actual requirement. Does it do the job we need without a large amount of work around it?
• License and permitted use. Can we use it for commercial client work, modify it if needed, and integrate it with the rest of the stack, under terms we can meet?
• Maintenance and release history. Is it actively maintained, with a record of security fixes and a community or vendor behind it?
• Security posture. Dependency hygiene, update cadence, and known issues are reviewed before adoption and on a schedule afterward.
• Operability. Can we run it on infrastructure we control, monitor it, and update it without disrupting live workflows?
• Data handling. Does it send telemetry or data elsewhere by default? If so, can that be disabled, and is it?
• Exit path. Can we export data and replace the component if it is abandoned or no longer fits?

A component that fails any of these is not adopted, even if it is popular. A component that passes is recorded in the license register with its version, license, and the role it plays.

Every component we operate carries a license, and the license determines what we may do with it. We read the license before adoption and record it, rather than treating availability as permission.

The Open Source Initiative maintains the definition of open source and the list of OSI-approved licenses. Permissive licenses such as MIT, Apache 2.0, and the BSD family allow use, modification, and redistribution with attribution requirements. Copyleft licenses such as the GPL family add obligations when modified software is distributed. Source-available licenses that restrict commercial use or competition are not open source under the definition, and we treat them accordingly.

For client work, the practical questions are whether commercial use is permitted, whether our modifications create obligations, and whether any attribution or notice requirements apply to what the client receives. The license register for each engagement answers those questions, and we provide it to your reviewers on request.

Software and models are licensed differently, and the distinction matters when a vendor says its AI is open source.

An open-weight model is a model whose weights are available to download. Availability of the weights does not make the model open source. The Open Source Initiative's Open Source AI Definition requires the freedom to use, study, modify, and share the system, with enough information about the data and the training process to allow that. Many widely used open-weight models are released under their own licenses with acceptable-use policies, field-of-use restrictions, or commercial thresholds, and the OSI explains the difference in its note on open weights.

We say open-weight when that is what a model is, and we read the model license and the acceptable-use policy before use, the same way we read a software license. Where a model's terms do not permit the use we need, we do not use it for that purpose.

We distinguish software under OSI-approved licenses from open-weight models released under other terms because your reviewers will ask, and because the answer affects what we may build.

Adapting open source software rarely means rewriting it. It usually means configuration, integration between systems, instruction sets and approved reference material for a model, and a review interface that lets a person approve outputs. Those are the parts that make a tool fit your operation.

We avoid forks we cannot maintain. A customized copy of a project that drifts from its upstream becomes a liability at the next security update. Where a change is useful to others, contributing it upstream is usually the better path. Where it is specific to a client workflow, it lives in configuration we can carry forward across updates.

This is the same discipline described on our customizable AI page: a defined use case, approved data, an acceptance test, and change control, so the adaptation stays explainable.

Open source components and open-weight models are used for the supported workloads described on our local processing page: drafting from approved material, reporting preparation, data preparation for attribution, approved transcription or summarization, internal automation with human approval, and testing.

They are not used for clinical decisions, autonomous patient-facing actions, or any purpose outside the scope your reviewers approve. We do not train or fine-tune models on your data without written approval, and where a task uses an outside model provider instead of a model we run, the provider and the data list for that task are named in the plan.

Models produce text that reads as confident whether or not it is correct. We plan for that rather than hoping it does not happen.

• Fabrication. A model can state things that are not in the reference material. Workflows restrict drafts to approved content and require a person to approve before anything is sent or published.
• Stale knowledge. A model's training has a cutoff. Facts about your services, locations, and policies come from your approved material, not from the model.
• Bias and tone. Outputs are reviewed against your standards, and workflows that touch sensitive services are scoped with those standards in mind.
• Context limits. Long inputs can be truncated or misread. Workflows chunk and check inputs rather than assuming a model read everything.
• Variability. The same input can produce different outputs. Acceptance tests cover representative inputs and edge cases, and a failure path routes uncertain items to a person.

Our AI governance page describes the approval points, testing, monitoring, and rollback that sit around these limits.

Clients retain ownership of their data. Access to our services does not automatically transfer our technology, workflows, or configurations.

Where open source components are part of what you receive, their license obligations pass through, and we document them. The configurations, integration code, and instruction sets we build remain ours unless an agreement says otherwise. Our data sovereignty page explains how storage, processing, access, and outside providers are made explicit for your review.