The Data License That Kept Getting Resold Anyway

The situation

By the time Keisha called us, she and her co-shareholders had already tried to solve this problem once, on their own, and thought they had. Their company, built by Keisha and her fellow shareholder Niran out of a shared frustration with how little manufacturers understood about their own equipment, collected anonymized performance data from machines on factory floors across the Hamilton-Niagara region and licensed it to software developers building predictive-maintenance tools. Keisha had spent years as a millwright before the company existed and still had relationships across the region's plants; Niran, who led IT support at a mid-sized manufacturer before joining full time, had built the pipeline that collected and anonymized the data at scale; and Somchai, the company's third shareholder, handled relationships with the developers who licensed the data once it was ready to sell.

A little over a year earlier, Somchai had negotiated and signed a license for a large dataset with an AI developer, using a license agreement drafted from a template Somchai found online and adapted without a lawyer's review. Months later, one of their manufacturing clients mentioned, almost in passing, that a completely different software vendor had approached them with a tool clearly trained on data that looked like theirs. Keisha's team traced it back: the AI developer they had licensed to had resold the raw dataset onward to a third party, something none of them had believed the license permitted.

Rather than involve a lawyer at that point, the three shareholders handled it themselves. They wrote to the developer directly, the developer's team apologized and proposed a short settlement letter promising to stop the resale and pay a modest fee for the breach, and Somchai signed it on the company's behalf, relieved to have the matter closed without a costly dispute. For a few months, it seemed to work.

Then it happened again, about eight months later. A different third party surfaced, this time with a finished software tool that was unmistakably a derivative of the licensed data, and the developer's response was noticeably less apologetic than the first time. Their position was that the settlement letter had only addressed the earlier resale incident and said nothing about future products built from the data, which was, on a literal reading of what Somchai had signed, more or less accurate.

Keisha, Niran, and Somchai tried once more to resolve it the way they had before, with Somchai drafting a firmer email himself and asking for a bigger payment and a written promise this would not happen a third time. The developer's team pushed back on the request and pointed out, correctly, that nothing in either the original license or the settlement letter actually prohibited what they had done. That was when Keisha called us, carrying both documents and asking, plainly, where the earlier fix had actually failed and whether there was anything left to do about it.

What the documents showed

We started with the two documents Keisha brought in, and neither one held up well under close reading. The original license agreement, drafted from an online template never adapted to reflect how this particular data would actually be used, described the developer's rights in broad, generic language: a grant to use the data for 'internal product development and related commercial purposes.' It said nothing explicit about onward resale, sublicensing to third parties, or derivative products built from the licensed data being subject to the same restrictions as the original dataset. The developer's lawyers, when the first breach surfaced, had a plausible argument that reselling the raw data, and later licensing tools trained on it, fell within 'related commercial purposes' as broadly worded.

The settlement letter was worse. It ran to a page and a half, addressed the specific resale incident that had already happened, secured a payment and an apology, and stopped there. It did not amend the underlying license agreement, did not add an explicit resale restriction going forward, did not give Keisha's company any audit or reporting right to check on future compliance, and did not define what would happen if a similar breach occurred again. It read, because it was, a letter written by non-lawyers to close an uncomfortable conversation quickly rather than a document built to prevent the same problem from recurring.

Put together, the two documents explained exactly why the fix had not held. The settlement resolved a single past event without touching the contract that had allowed it, so the underlying ambiguity the developer had relied on the first time was still sitting there, unresolved, the second time the question came up. Nothing in either document actually forbade what the developer's second product represented: a new tool, trained on the licensed data, developed and offered to a different client without Keisha's company's involvement or consent.

This mattered for the negotiation ahead. Keisha's company was not simply pursuing a breach claim against a hostile counterparty; the developer still wanted continued access to fresh, ongoing data, since the earlier license had proven valuable to their product and their customers expected it to keep improving. That gave Keisha's side real leverage, but only if the next agreement closed the gaps the first one had left open, rather than repeating the same broad language in firmer tone.

It also told us how to approach the second breach. Because the settlement letter had never been incorporated into or referenced by the license agreement, we could argue the developer's derivative product breached the spirit of the original license's implicit limits, even though the settlement letter, narrowly read, did not cover it. That was a weaker argument than we would have liked, and we told Keisha so directly, but it was enough to bring the developer to a serious conversation rather than a dismissive one.

What we did

1. Reviewed the original license and settlement letter against what had actually happened. We read both documents closely against the timeline Keisha provided, identifying exactly which clauses the developer had relied on to justify the resale and the derivative product, which let us see precisely where the drafting had failed rather than assuming the developer was simply acting in bad faith.
2. Assessed whether the settlement letter had any binding effect on the new dispute. Because the settlement addressed only the first breach and never amended the underlying license, we concluded it gave Keisha's company little direct leverage over the second incident, which shaped our strategy: rather than arguing the settlement had been violated, we focused on the license's own ambiguity and the developer's ongoing need for data.
3. Sent a formal notice addressing both the license and the pattern of conduct. Instead of another informal email, we wrote to the developer's lawyers directly, laying out the two incidents, the ambiguity in the original license, and Keisha's company's position that any further use of the data or its derivatives without a properly restricted agreement would be treated as an ongoing breach.
4. Used the developer's need for continued access as negotiating leverage. Because the developer's product depended on fresh, ongoing data rather than a one-time dataset it could keep reusing indefinitely, we made clear that further access required a new agreement with explicit terms. That single fact gave Keisha's company real bargaining power despite the earlier drafting failures that had let the first two incidents happen, since the developer had far more to lose from losing access than Keisha's company had to lose from withholding it.
5. Negotiated a payment for the second breach. We sought and obtained a further payment covering the unauthorized derivative product, separate from and larger than the earlier settlement figure, reflecting that this was now a repeated pattern rather than an isolated lapse. We secured that payment before any new license terms were discussed, so it could not later be traded away as a concession inside the broader negotiation.
6. Drafted proposed terms for a restricted go-forward license. The new terms explicitly prohibited resale of raw data, prohibited sublicensing to any third party, required any derivative product to be separately licensed with its own royalty and audit terms, and gave Keisha's company the right to inspect the developer's use of the data periodically to confirm compliance, closing every gap the original template had left open.
7. Walked away when the developer would not agree to the resale limits. When it became clear during negotiation that the developer wanted continued flexibility to build and license derivative tools without the restrictions we had proposed, we advised Keisha's company that no license was better than one that repeated the same ambiguity, and the company declined to renew rather than accept another round of vague language.
8. Confirmed the developer's obligation to stop using existing data going forward. Because the relationship was ending rather than continuing under new terms, we obtained written confirmation that the developer would cease using Keisha's company's data in any new product development from that point on, covering both the raw dataset and anything derived from it, closing off the exact ambiguity that had let the earlier disputes happen in the first place.

The outcome

Keisha's company recovered a further payment for the second unauthorized use of its data, on top of the earlier settlement amount, bringing the total recovered across both incidents to a meaningful sum relative to the company's overall revenue, though still modest set against what a properly enforced multi-year license might have generated over the same period. The developer accepted the payment and the end of the relationship rather than contest the claim formally, which avoided a drawn-out dispute but also meant Keisha's company never obtained a clear written acknowledgment of exactly what had gone wrong on the developer's side or a commitment covering products already built.

The licensing relationship itself ended, and that was the concession side of the compromise. Keisha's company chose not to continue supplying data to a developer that would not commit to the restrictions the two earlier breaches had shown were necessary, giving up the ongoing licensing revenue that relationship had represented in exchange for closing off a source of recurring risk to its core asset. That was a real cost, not a hidden win dressed up as a clean outcome; the company lost a paying customer it had spent roughly two years building a relationship with, and had no immediate replacement lined up.

What the company gained was something it had never actually had before: a properly drafted license agreement, built around this specific dispute's lessons, ready to offer the next developer who wanted access to the data, along with a documented obligation from the departing developer to stop using the company's data in anything built going forward. Keisha's team also adopted a standing rule for anything touching the company's core asset, that no agreement involving the licensed data gets signed, amended, or settled without legal review first, a rule the original settlement letter existed only because nobody had followed it the first time around.

What you can learn from this