Claude Code MIT license - can I actually build commercial products with it?

Hey everyone, been playing around with Claude Code (Anthropic's CLI tool for coding with Claude) and I'm pretty impressed. Thinking about building a developer tool startup around it - basically extending it with some specialized workflows for my niche.

I see it's released under MIT license on Github but I'm getting confused by a few things:

• Can I actually sell a product that uses this code commercially?
• Do I need to open source my modifications?
• What about the API costs - are those seperate from the license?
• Any "gotchas" I should know about?

My co-founder is worried we might get sued or something if we build on top of their code. Am I overthinking this or is there actually something to worry about?

Enterprise architect at a Fortune 500 here. Want to share our perspective since we went through an extensive legal review before approving Claude Code for internal use.

Our legal team's position: the enterprise license terms from Anthropic are materially different from the individual/team plans. Key differences that mattered to us:

• Enterprise plans include explicit IP indemnification -- Anthropic will defend you if someone claims the AI output infringes their IP
• Data retention and training provisions are more favorable -- your code isn't used to train their models
• You get a dedicated legal contact and can negotiate custom terms
• SLAs are contractually binding, not just "best effort"

If you're a startup building a commercial product on Claude Code, I would strongly recommend the enterprise plan once you hit any meaningful revenue. The indemnification alone is worth it. Individual plan ToS are much more "as-is."

We also require all AI-generated code to go through the same code review process as human-written code. No exceptions. Our static analysis tools don't care who or what wrote the code.

@nursing_life This is actually one of the most common questions I get from agency clients right now. Let me give you the legal perspective, though this also has ethical dimensions that go beyond the law.

Legally: Unless your contract with the client specifically prohibits use of AI tools, or requires disclosure of tools/methods used, you're generally in the clear. Most development contracts are deliverable-based ("build me X feature") not process-based ("write every line by hand"). Check your MSA and SOWs carefully.

Billing: Billing by the hour for AI-assisted work is a gray area. Many agencies are moving to value-based or project-based pricing precisely because of this. If you're billing hourly, you should probably bill for the actual time spent, including the time reviewing, testing, and integrating the AI output. I would not recommend padding hours.

Disclosure: This is where it gets interesting. Some industries (fintech, healthcare, government) have regulations or contract terms that require disclosure of AI usage. If your client's contract has a "tools and methods" clause, you may be obligated to disclose. Even if not legally required, proactive disclosure builds trust. I'd recommend updating your MSA to include an AI tools clause going forward.

Following up on the client billing discussion. I'm a freelance full-stack developer and I recently had an awkward situation where a client found out I was using Claude Code because I accidentally left a comment in the code that said // Generated by Claude. Client was NOT happy.

Their concern wasn't legal -- it was that they felt they were "paying for AI work, not human work." They asked for a discount. I ended up negotiating a small credit but it was uncomfortable.

Lesson learned: be upfront about your tools from the start. I now include a clause in all my contracts that says I may use AI-assisted development tools, and that all output is reviewed and validated by me as the developer. No client has pushed back on this so far. Transparency is way better than getting caught.

@contractquestions_3 Yes, that's exactly the trap. A provisional patent application could help, but remember: the provisional must adequately describe the invention, and the named inventor must be a natural person who actually contributed to the inventive concept. You can't file a provisional for something that was entirely AI-conceived.

The practical approach I recommend to startup clients: have your developers take the AI-generated code as a starting point, then apply genuine human ingenuity to refine, optimize, or extend it. Document this process. The human inventive contribution -- even if it builds on AI output -- is what makes it patentable.

And yes, if patent protection matters to your business, keep your novel work in private repos until you've filed appropriate patent applications. The America Invents Act gives you a one-year grace period after public disclosure, but why risk it?

Great discussion everyone. Quick moderation note: this thread has evolved well beyond the original MIT license question into a broader discussion about AI-generated code commercial use, which is fantastic.

I'm going to keep this thread open since the topics are closely related. Just a reminder of forum rules: nothing in this thread constitutes legal advice. The attorneys here are sharing general information, not forming attorney-client relationships. If you need specific legal advice for your situation, hire a lawyer.

Also tagging this thread with additional categories: "AI Copyright," "Code Licensing," "Commercial Use," and "Enterprise." Carry on!

OP here -- just want to say this thread has blown up way beyond what I expected. Quick update on my situation: we launched our product about 8 months ago and it's going well! We used Claude Code as a foundation and built our own tooling on top.

A few real-world things I've learned since the original post:

• The MIT license for Claude Code itself has been a non-issue. No problems whatsoever.
• API costs are the real consideration. We spend more on Anthropic API than on our entire AWS infrastructure.
• We ended up getting enterprise API terms once we hit ~$5k/month in usage. The indemnification clause alone was worth it.
• We include a clause in our customer agreements disclosing that we use AI tools in development.

The copyright ownership question raised by @AuditManagerT_7 is concerning though. We're going to talk to our lawyers about documenting human authorship more formally. Thanks everyone for keeping this thread alive with great info.

Wanted to circle back to this thread with a real-world update. We just closed our Series B and during due diligence, the investors' legal team specifically asked about our use of AI coding tools. This is the first time that's happened to us (didn't come up in Seed or Series A).

Questions they asked:

• What percentage of your codebase is AI-generated vs human-written?
• Do you have policies governing AI tool usage?
• Are you on enterprise terms with your AI providers?
• Have you done an IP audit to confirm copyrightability of key code?
• What's your exposure if AI-generated code infringes third-party IP?

We had good answers for most of these because we've been thinking about it since the beginning (partly thanks to this thread). But I know plenty of founders who would be caught flat-footed. If you're planning to raise capital, start thinking about these questions now.

Solution architect at a fintech company here. I want to share our experience doing a formal code audit to verify AI-generated code isn't copying GPL/AGPL code, since a few people have asked about this.

We went through this process six months ago when our compliance team flagged AI tool usage as a risk. Here's what we did:

1. Inventory: Used git log analysis and AI-usage tracking to identify which parts of our codebase were AI-generated or AI-assisted
2. License scanning: Ran the entire codebase through FOSSA and Black Duck. Both tools can detect code snippets that match known open source components
3. Manual review: For any flagged matches, had senior developers manually assess whether the similarity was coincidental (common patterns) or substantive (actual reproduction)
4. Remediation: For the ~5% of flagged code that was substantively similar, we rewrote those sections from scratch with clear human authorship

Total cost: about $30K including the commercial scanning tools and developer time. For a company our size (~$20M ARR), that's a reasonable investment in IP hygiene. For a startup, the open-source scancode-toolkit is a good alternative.

I want to bring up something specific to open source licensing conflicts that I haven't seen mentioned. If you're building a product that includes multiple open source dependencies (as basically everyone does), and you're adding AI-generated code on top, you need to think about license compatibility across the entire stack.

Example: your project uses an Apache 2.0 licensed library, an MIT-licensed library, and some AI-generated code. The Apache 2.0 license has a patent grant provision that MIT doesn't. If the AI-generated code inadvertently creates a patent conflict with the Apache component, you've got a mess that's extremely hard to untangle.

Another example: if you're building a project under the GPL and using Claude Code to generate code, the GPL requires that all contributions to the project be GPL-compatible. But AI-generated code with uncertain copyright status -- is it GPL-compatible? Can you even apply the GPL to code that may not be copyrightable? This is genuinely uncharted territory.

I don't have great answers here, just flagging that the interaction between AI-generated code and existing open source license ecosystems is more complex than most people realize.

@MediatorPaulR_9 Good questions. Let me address both.

Work-for-hire and AI tools: Most employment agreements are written broadly enough that code you produce using any tools "within the scope of your employment" belongs to the employer. The fact that you used an AI tool doesn't change this -- you used a compiler too, and nobody argues the compiler owns the code. Your employer's IP assignment clause almost certainly covers AI-assisted work. If it doesn't explicitly, most courts would interpret it to include outputs produced using company-approved tools during work hours.

Personal projects and employer claims: This is a real risk, but it's not unique to AI tools. The risk exists anytime you work on personal projects in the same domain as your day job. The key factors are: (1) did you use company resources (including company API keys for Claude), (2) is the work related to your employer's business, and (3) did you develop it during work hours? AI doesn't change this analysis -- it's the same framework that's applied to side projects for decades.

My practical advice: use separate API accounts for work and personal projects. Don't cross-pollinate prompts. And if your employment agreement has an IP assignment clause, get a written carve-out for your side project before you start building. Most employers will grant these if you ask.

Update from the government contracting world: the GSA just published new guidance this month on AI tool usage in federal IT contracts. Key points that affect developers using Claude Code for government work:

• All AI-assisted software must be disclosed in the technical proposal
• The contracting officer can require an AI impact assessment for software used in critical systems
• FedRAMP authorization requirements may apply to AI tools that process government data (Claude's API would need to be FedRAMP authorized or you need to use it in a way that doesn't process government data)
• Government retains unlimited rights to AI-generated code delivered under the contract, same as human-written code

The FedRAMP issue is the big one. As far as I know, Anthropic's API is not yet FedRAMP authorized. If you're using Claude Code to generate code that processes government data, you may have a compliance gap. We're currently working around this by ensuring Claude Code only sees our own proprietary code, not government data fr fr.

Want to address @ArbitratorLiz_10's point about GPL and copyrightability. This is actually a really interesting philosophical and legal question for the open source world.

The GPL works by using copyright law: because the code is copyrighted, the GPL's conditions (share-alike, source disclosure) are enforceable. If AI-generated code is NOT copyrightable, you arguably can't apply the GPL to it -- and more importantly, the GPL's copyleft provisions might not be enforceable against it.

This creates a paradox: the same lack of copyrightability that weakens your ability to protect AI-generated code also weakens others' ability to enforce copyleft licenses against you. If nobody can copyright AI-generated code, then nobody can claim GPL violations when that code is used without source disclosure.

Now, this is a theoretical argument and no court has ruled on it. And it doesn't help with the "contamination" scenario where AI output closely matches human-authored GPL code (which IS copyrighted). But it's an interesting wrinkle that I think will eventually be litigated. The FSF and OSI haven't published clear positions on this yet, which tells me they're still figuring it out too.

Final thought from me on this thread: I've been compiling our team's code review data for AI-generated code over the past six months, and the trend is encouraging. The defect rate in AI-generated PRs has dropped from about 25% to about 12% as our developers have gotten better at prompting and reviewing.

Key improvements we've made:

• We created a team-specific prompt library with instructions for our coding standards, error handling patterns, and security requirements
• We added automated static analysis in CI that catches the most common AI-generated issues before human review
• We require developers to explain WHY they're using AI for a given task in the PR description, which forces them to think critically about whether AI is the right tool for the job

The bottom line for the commercial licensing question: AI-generated code is commercially viable and the legal risks are manageable, but only if you invest in proper process and governance. The companies that treat AI as a "fire and forget" code generator are the ones that will run into trouble -- whether it's bugs, license issues, or IP disputes.

Treat AI like a very fast but junior developer who needs supervision. That's the right mental model for both quality and legal risk.

Question about liquidated damages clauses: my contract has a clause that says if I terminate early, I owe 50% of the remaining contract value. Is this enforceable or would a court consider it a penalty? The distinction matters because penalty clauses are unenforceable in most jurisdictions.

Late to this thread but it's exactly what I was searching for. We run a small dev shop and the MIT part was never my worry either. What kept me up at night was the API side. Just to confirm what others said: the MIT license on the CLI repo and the terms governing your API calls are two completely separate things. One lets you use the code, the other governs the model usage. You have to read both.

We learned that the hard way when someone on the team assumed MIT meant 'do whatever you want including with the model.' Not the same thing at all.

Question for the folks who switched to enterprise/commercial API terms once they scaled. At roughly what monthly spend did it actually make sense? OP mentioned ~$5k/month upthread. We're around $1,800/month right now and I can't tell if we should be pushing for it already or if we're too small to get anyone's attention.

Mostly trying to figure out if the indemnification everyone keeps raving about is even available below a certain tier, or if it's a 'call sales' situation only.

@priya_builds in my experience it's less about a hard dollar threshold and more about whether you ask. We were under $2k/month and still got a commercial agreement with negotiated terms because we pushed for it. Smaller shops sometimes assume they have to stay on consumer terms and never inquire.

That said, the standard published commercial terms already cover most of what a startup needs. The custom-negotiated stuff (indemnity caps, data handling commitments, SLAs) is where the back-and-forth happens. Read what's already published before you assume you need a custom deal.

The thing that surprised me reading this whole thread is how much of the discussion isn't really about MIT at all. The license question is genuinely the easy part. It's permissive, you can build commercial products, you keep the copyright notice, done.

The hard parts everyone keeps circling back to: who owns AI-generated output, what your API terms actually say, and whether your client contracts let you use these tools. Those are the real questions and none of them are answered by the license file.

Attorney here (not yours, and this isn't legal advice). Want to clarify a point that keeps getting blurred in these threads, because the distinction matters.

Whether AI-generated material gets copyright protection and whether you're allowed to use it commercially are two separate questions. In the US, the Copyright Office has taken the position that purely machine-generated output, with no human creative control, generally isn't registrable. But that doesn't mean you can't use it or sell a product containing it. It mostly affects your ability to stop others from copying that specific generated portion. For most software businesses the protectable value lives in your overall architecture, your human-written code, your brand, and your data, not in any single generated snippet.

If exclusivity in specific code is core to your moat, document the human authorship and talk to an IP attorney in your jurisdiction. The law here is still developing and varies by country.

On the client-disclosure side, I'll echo @gighustle_5 from earlier. I added one sentence to my standard agreement saying I may use AI-assisted tooling and that I review and stand behind all delivered work. Took five minutes and killed the awkward conversation entirely.

What I did NOT expect: a couple of clients actually responded positively, like it signaled I was efficient and modern. The fear of pushback was way bigger than the reality. The only client who cares deeply is usually one in a regulated industry, and those folks tell you upfront.

Update from someone who was lurking back in February. We finally moved our customer agreement to include the AI-tools disclosure clause and went through procurement at two enterprise customers since. Both reviewed it, neither blinked. One added a line requiring that no customer confidential data be sent to a model that trains on it, which was reasonable and we already satisfied that.

Point being: the disclosure didn't cost us a single deal, and it's now a non-event in our security questionnaires.

Can someone sanity check my understanding of the MIT attribution requirement? My read is that I have to keep the copyright notice and license text in the source/distribution if I redistribute substantial portions of the actual code, but I do NOT have to credit anything in my app's UI or marketing. Is that right?

I ask because a teammate insisted we needed a visible 'powered by' notice in the product and that didn't match what I read.

@contract_questions your read matches mine. Permissive licenses of this type generally want the notice preserved in the code/distribution, not plastered on your marketing site. A UI 'powered by' credit is a product/marketing choice, not an MIT obligation.

Where people trip up is when they bundle the actual source into a distributed package and strip the license header. That's the part you don't want to skip. If you're only calling an API and not shipping their source, the attribution mechanics look different anyway.

Quick mod note since a few new folks just found this thread. Reminder that everything here is general information shared by members, including the attorneys, and nothing in this thread creates an attorney-client relationship or counts as legal advice for your specific situation.

Also flagging that license terms and provider API terms do get updated over time, so when in doubt, go read the current version directly from the source rather than trusting a forum post from a few months ago. Carry on, this is a great discussion.

Reporting back on the enterprise-terms question from earlier in the thread. We crossed into a commercial agreement at around $3k/month and the single biggest practical win wasn't even the indemnity. It was the contractual commitment around data handling and not training on our inputs. That's what unblocked us with two security-conscious customers.

The indemnity is nice insurance you hopefully never use. The data terms are the thing that shows up in every customer security review.

One angle I haven't seen raised: open-source compliance scanners. Our customers' procurement teams run SCA tools that flag every dependency and its license. MIT shows up clean and green, which is honestly part of why building on permissively-licensed tooling is so painless at the enterprise level. A copyleft license in the same spot would have triggered a legal review every single time.

So beyond 'can I legally do it,' the practical answer is that MIT makes you frictionless in other people's compliance pipelines too. Worth keeping the license notice intact precisely so those scanners stay happy.

Coming back to thank this thread. We shipped, we kept the license notice in our distribution, we added the AI-tools clause to both our customer agreement and our subcontractor agreements, and we documented human authorship of the parts that actually matter to us. None of it was hard, it was just easy to overlook.

If I could give one tip to anyone starting now: separate the three questions in your head from day one. The code license, the API/model terms, and the ownership of output are not the same problem, and answering one does not answer the others.

Attorney here, general information only, not legal advice and no attorney-client relationship. @tomr_dev nailed the framing, so I'll just add the practical checklist I give people informally.

One, confirm the code license actually covers what you're shipping and preserve the required notices. Two, read the current provider terms governing the model/API, because those change and they're where the real obligations and protections live. Three, if exclusive ownership of specific output matters to your business, document the human creative contribution and get jurisdiction-specific IP advice, since the law on AI-generated works is still unsettled and varies by country. Four, make sure your client and subcontractor contracts permit AI-assisted tooling.

Get those four right and the MIT question, which is where the thread started, turns out to be the least of your concerns.