Open-source AI legal tools have crossed a threshold. A few years ago, "self-hosting your own legal AI" was a thought experiment. Today you can clone a working one in an afternoon. MikeOSS — an open-source AI legal document platform — is one of the more complete examples: it has a chat assistant that reads your contracts, a spreadsheet-style bulk document review feature, reusable workflows, document drafting and editing, and US case-law lookup. It is genuinely capable, and it is free to take.
So the obvious question lands on a lot of legal-ops desks: should we just fork it and run our own?
The honest answer is "maybe" — and the gap between the teams for whom this is a smart move and the teams for whom it's an expensive mistake is wide. This post walks through what you'd actually be getting, the one licensing fact that should shape the whole decision, the costs nobody puts in the pitch deck, and a practical way to decide.
What "forking it" actually gives you
Let's be precise about the thing on offer, because "free AI legal platform" sets expectations that the reality doesn't always meet.
Forking means copying the source code into your own repository so you can modify and run it yourself. What you get is a well-built, modern web application in two halves: a browser-facing app (built on Next.js and React) and a backend engine (built on Express). It's written almost entirely in TypeScript, which is a mainstream, maintainable choice — any competent web development team will recognize the stack immediately.
Out of the box, the platform does a lot:
- Document chat — upload PDFs and Word files and ask an AI questions grounded in their actual content.
- Projects — group documents by matter so the assistant reasons across a whole deal or case at once.
- Tabular review — point it at dozens of contracts and it builds a table where each row is a document and each column is a question you defined, filling in every cell automatically. This is the feature most teams will find genuinely valuable.
- Workflows — saved, repeatable prompts for recurring tasks, with built-in examples like credit agreement and shareholder agreement summaries.
- Drafting and editing — the assistant can generate new Word documents, edit existing ones, and track versions.
- US case-law research — citation verification and opinion lookup via CourtListener.
Crucially, what you don't get is a finished product. You get the application code. You still have to supply and pay for everything that makes it run: a database and authentication service (Supabase), file storage (Cloudflare R2 or similar), and — the big one — an AI model provider key from Anthropic, Google, or OpenAI. MikeOSS is the framework; the intelligence is rented from a model provider on your own account, and you pay per use. The repository is the recipe, not the meal.
The licensing fact that should drive your decision
Before anyone gets excited about features, your legal team needs to read the license. MikeOSS is released under AGPL-3.0 — the Affero General Public License — which is the most demanding of the widely used open-source licenses, and the irony of a legal team overlooking a license clause should not be lost on anyone.
Here is what makes AGPL different. Most open-source licenses only impose obligations when you distribute the software to others. The AGPL closes what its authors saw as a loophole for web applications: it treats running modified software as a network service that others can access as a trigger in its own right. In plain terms, if you take MikeOSS, modify it, and run it as a service that users reach over a network, you are generally required to make your complete modified source code available to those users under the same AGPL terms.
What this means in practice:
- Internal use by your own team, with no external users is the most comfortable scenario. Running it for your own lawyers, where you aren't offering it as a service to outside parties, generally keeps you within bounds and lets you keep your modifications private. Even here, "internal" can get blurry across a large organization, so it deserves a careful read.
- Anything client-facing or commercial is where AGPL bites. If you wrap it into a product for clients, offer it to a broader audience, or build a billable service around a modified version, you will typically have to publish your changes — including any clever customizations you considered a competitive advantage — under AGPL.
This is not a footnote. For a law firm thinking about a client-facing tool, or a legal-tech-curious in-house team imagining future commercialization, AGPL can be a deal-breaker or, at minimum, a board-level conversation. The right move is to have your own IP/licensing counsel review it against your specific intended use, and to consider contacting the author about whether a separate commercial license is available — many AGPL projects offer one. Treat the license as the first gate, not the last detail.
The costs that aren't in the README
"Free" software has a way of becoming the cheapest line item in an expensive project. The fork is free. Everything around it is not.
Engineering time, upfront. Standing up a working instance means setting up the database, storage, authentication, and model keys, running the schema setup, configuring environment variables correctly, and deploying both halves to hosting. A capable web developer can get a basic instance running in a few days. Customizing it to your firm's needs, branding, and integrations is a longer engagement measured in weeks.
Engineering time, forever. This is the cost teams chronically underestimate. The moment you fork, you own a software product. Dependencies need updating. Security patches need applying. The underlying AI models change and deprecate — the project already references a moving target of Claude, Gemini, and GPT models, and providers retire older ones. When the upstream project ships improvements, you have to merge them into your fork, and the more you've customized, the harder those merges get. A fork is a puppy, not a poster.
Running costs. Database hosting, file storage, and — most significantly — AI model usage are all metered. A document-heavy review workload sends a lot of text to the models, and those tokens add up. Budget for it as an ongoing operating expense, not a one-time setup.
Security and confidentiality work. This one is non-negotiable for legal data and deserves its own section.
The confidentiality question is sharper for legal teams than for anyone else
You are not running a to-do app. You are routing privileged, confidential, and often regulated client material through a system you are now responsible for securing.
Two things deserve real scrutiny. First, where your documents go. Self-hosting gives you control over your database and file storage — a genuine advantage over some SaaS tools. But the AI itself is not local. When the assistant reads a contract, that content is sent to whichever model provider you configured (Anthropic, Google, or OpenAI). You need to understand each provider's data-handling and retention terms, whether your account is on a zero-retention or enterprise tier, and whether that satisfies your client confidentiality obligations and any engagement-letter commitments. Self-hosting the app does not mean self-hosting the intelligence.
Second, you now own the security posture. Authentication, access controls, encryption, patching, logging, and incident response become your responsibility, not a vendor's. The MikeOSS code includes sensible security building blocks — multi-factor login, rate limiting, signed download links — but a codebase is not a security program. For a firm with professional-responsibility and possibly regulatory obligations (and for in-house teams, internal infosec and possibly client audit requirements), this is a serious commitment that typically needs your security team's blessing, not just a developer's enthusiasm.
Build-versus-buy, framed honestly
It helps to name what forking really is: a build decision wearing a buy decision's clothes. You're not buying a tool; you're adopting an open-source codebase and committing to operate it.
The case for forking is strongest when you value control and customization, want your data architecture under your own roof, have or can hire real engineering capacity, and your use is internal enough that AGPL is comfortable. You also avoid per-seat SaaS pricing, though you trade it for infrastructure and model costs plus salaries.
The case against is strongest when you want a supported product with a vendor on the hook for uptime, security, and compliance attestations; when you have no in-house engineering to maintain a fork; when your use is client-facing and AGPL is a problem; or when your real need is "a working tool next month," not "a platform we'll grow into." Commercial legal-AI vendors exist precisely to absorb the maintenance, security certifications, and support burden — that's much of what you're paying them for.
A frequently overlooked middle path: fork it as a pilot to learn what features your team actually uses and values, with no production data and no client material, then make the build-versus-buy call with real evidence instead of a demo's glow.
A practical decision checklist
Run through these before committing. If you're answering "no" or "not sure" to several, forking is probably premature.
- License fit — Has IP counsel confirmed AGPL works for your specific intended use (internal vs. client-facing)?
- Engineering capacity — Do you have a developer or team who can not just stand it up but maintain it for the foreseeable future?
- Security ownership — Will your security/infosec function own the deployment, and have they signed off?
- Confidentiality of AI calls — Have you vetted the model provider's data terms against your client obligations?
- Total cost clarity — Have you budgeted setup time, ongoing maintenance, hosting, and metered AI usage — not just "it's free"?
- Genuine need — Is the customization and control worth the operational burden, versus a supported product that works now?
- Exit path — If maintaining the fork becomes a drag in a year, what's your plan?
The bottom line
MikeOSS is an impressive, genuinely useful piece of open-source legal software, and the instinct to explore it is sound. For a legal team with real engineering support, an internal-only use case, a security function ready to own the deployment, and a clear-eyed read of the AGPL license, forking it can be a smart, cost-effective way to get a customizable AI platform under your own control.
For a team without those things — no developers to maintain it, a client-facing or commercial ambition that collides with AGPL, or an expectation that "open source" means "free and finished" — forking it will likely cost more time, money, and risk than licensing a supported product, and the savings will evaporate into salaries and surprises.
The reckless version of this decision is "it's free, let's fork it." The responsible version is "let's pilot it on non-sensitive data, get counsel's read on the license, and price out what running it really costs — then decide." The technology is the easy part. The license, the confidentiality of client data, and the long-term ownership burden are where this decision is actually won or lost.
This post is general information, not legal advice on your specific situation. Have your own counsel review the AGPL-3.0 license terms against your intended use before relying on them.