Your team spent six months fine-tuning a model on your own data. It now flags defects on the line before your best inspector catches them, or routes support tickets better than the vendor’s default ever did.
Who owns that improvement?
The instinct is that the answer is obvious. We built it, so it’s ours. But if the model sits on a licensed platform, a vendor API, or an open-source base, ownership gets murky fast. And the moment companies find out is usually the worst one available: during diligence for a sale, during a funding round, or in a disagreement with the vendor whose tool they built on.
Four documents decide the answer. None were written by your engineering team, and all but one were signed before anyone knew this feature would matter. Here’s how to read them.
1. The Vendor License Covers Their Model, Not Your Implementation
Licensing a third-party model is often the right call. It’s faster than building from scratch, and the base model usually isn’t something you need to own.
What you do need to own is the layer you built on top. The specific way you feed your data in. The sequencing of calls. The method for combining the model’s output with your own logic to solve a problem the vendor’s tool doesn’t solve on its own. That layer is frequently the most valuable thing your company built.
Whether you can protect it depends on what the license says. Three terms decide most of it:
- Does the agreement clearly separate the licensed model from your own implementation, or does it lump everything into one bucket the vendor could later claim rights to?
- Does it restrict what you can do with outputs, in a way that blocks protecting how those outputs get used?
- Does it require disclosing your implementation details back to the vendor, which can undercut a later patent application or a trade secret claim?
Reading a software license with those three questions in mind is its own skill. Elliott Alderman does that work for our clients: four decades in intellectual property and technology law, including software and content licensing, plus years as general counsel of a 200-person publishing company where the licensing terms were the business.
2. The Contractor Agreement Decides Who Owns the Code
Consider a company that raised a seed round, hired three engineers, and brought on two contractors to move faster. Eighteen months later, an acquirer shows interest. Diligence asks a simple question: who owns the model architecture, and can you prove it?
Nobody can answer cleanly. The contractor agreements never addressed assignment. The engineers signed offer letters covering salary and start dates. The deal doesn’t die, but the valuation takes a hit while everyone scrambles to fix paperwork that should have existed from day one.
An assignment clause is the difference between your company owning the architecture and a former contractor owning it. It’s one paragraph. It costs nothing to include at signing, and it’s close to impossible to add once the person has moved on and has no reason to sign anything.
3. The Operating Agreement Nobody Reads Twice
Entity structure gets set up early. IP strategy gets figured out later. By the time later arrives, the two have drifted apart.
Your operating agreement, your equity documents, and your board records describe who contributed what and who holds what. When the most valuable thing your company owns is a method rather than a machine, those documents become part of the ownership story a buyer’s counsel will read.
This is what we mean when we say legal structure has to protect two things at once: the business and the invention. They aren’t separate workstreams. The business paperwork is the foundation the IP claim stands on.
4. The Deal You Haven’t Signed Yet
The fourth document is the one still in front of you.
Say you’re approached to license, white-label, or commercialize what you built. Good news: revenue. The risk sits in the language. Commercialization contracts often assign “derivative works, improvements, and related technology” along with the license. It reads as routine. It isn’t.
That clause can reach the underlying method your software uses to solve the problem, not just the code you deliver. If something protectable is buried in how the tool works, a broadly worded agreement can hand it over before anyone realizes it was yours to keep.
Two things have to happen, in this order. First, figure out whether anything in your stack is worth protecting on its own. Second, negotiate what you’re actually assigning. Reversing that order is how a company sells a product and gives away the invention inside it.
How to Check Before Diligence Does
- Collect every agreement governing the tools your product depends on, and read them against the three license terms above.
- Confirm that everyone who wrote code, employee or contractor, signed an assignment.
- Check that your entity and equity documents match who actually contributed technical work.
- Before signing any outbound licensing or white-label deal, get an evaluation of what’s in the stack.
None of these steps resolve the harder question of whether a particular method qualifies for protection. That’s a judgment call that needs the details in front of it. What these steps do is make sure the answer is still yours to pursue.
I came into this work through mechanical and electromechanical inventions: automated packaging equipment, automotive components, medical devices. The discipline turns out to be the same for a processing method in software. Define what’s actually new, document it early, and make sure the business paperwork supports the claim that the company owns it. On the software side I’ve worked on casino operations software, medical accounting systems, education technology platforms, and computer network implementations, and it’s that question that decides those matters, not the technology underneath.
Know what you own before you need to prove it. If your product runs on a licensed model, or your team built something valuable on top of somebody else’s platform, bring us the vendor agreement and the contractor agreements. We’ll go through where the gaps are together. Call (410) 531-9853 or start at garcia-zamor.com.
If you want contracts that hold, IP that’s protected, and legal bills that don’t surprise you every month, let’s talk. Garcia-Zamor Law Firm delivers fractional in-house counsel with a unique advantage: business law PLUS IP expertise, brought to you by Ruy Garcia-Zamor, Elliott Alderman, Claudia Castillo, and Amulya Annasamudram. Passionately devoted to your success. Visit garcia-zamor.com or call (410) 531-9853.
