**ATTORNEY-CLIENT PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT**
Bernard,
Per your request, I've completed my initial research survey on comparable disputes involving automotive embedded RTOS licensing. This summary is organized around the three principal areas most relevant to VMS's position under the Master Embedded Software License and Services Agreement dated June 21, 2022 (the "MESLSA"): (1) dormancy/suspension provisions and fee forfeiture; (2) "use-it-or-lose-it" milestone provisions; and (3) derivative works ownership in embedded software licensing contexts. I reviewed published arbitration awards (including from the Midwest Arbitration Institute and comparable regional forums), federal and state court decisions, and leading secondary sources on technology licensing.
The short version is that the comparable authority is generally supportive of VMS's positions, though the derivative works question will turn heavily on the technical characterization from Hargrove. Details below.
---
**I. Dormancy / Suspension Provisions and Fee Forfeiture**
As a threshold matter, dormancy clauses in enterprise embedded-software licenses are relatively uncommon — they appear more frequently in long-term SaaS and platform licensing arrangements. That said, I identified several analogous disputes from the automotive and industrial embedded software sectors that are instructive.
*A. Dormancy Tolling of Milestone Deadlines*
The most directly analogous authority I found is *Crestline Automotive Systems v. Veridian Software Corp.*, Midwest Regional Arbitration Panel, Award No. MRA-2019-0347 (2019). In *Crestline*, an automotive licensee suspended integration of an embedded operating system due to a program rescoping tied to a change in OEM platform requirements. The panel held that the licensee's invocation of a contractual dormancy provision tolled all milestone deadlines, including a clause functionally similar to our Section 4.3 "use-it-or-lose-it" requirement. The panel emphasized that the dormancy provision would be rendered illusory if milestone deadlines continued to run during a period when the licensee was contractually entitled to suspend performance.
One distinguishing factor worth noting: in *Crestline*, the licensee sent its dormancy notice approximately six weeks before the suspension period began, providing the licensor with substantial lead time. VMS sent its dormancy notice on July 14, 2023 — six days before the 120-day trigger date of July 20, 2023. That notice is still timely under Section 9.4's 10-business-day requirement, but the earlier notice in *Crestline* provided stronger footing. I don't think this distinction is fatal, but MeridianCode may try to argue that the compressed timeline suggests the dormancy invocation was pretextual. We should be prepared to address that with evidence of VMS's genuine business reasons for the suspension.
*B. Fee Forfeiture on Early Termination*
On the fee forfeiture question, I identified *Northland Fleet Technologies, Inc. v. Arcadian Embedded Solutions, LLC*, No. 1:19-cv-00842 (W.D. Mich. 2020), a federal district court decision applying Michigan law. The court addressed a termination-for-convenience clause with fee-forfeiture provisions in a commercial fleet software licensing agreement. The court held that forfeiture of prepaid fees substantially exceeding the licensor's actual damages could constitute an unenforceable penalty under Michigan common law, particularly where the licensee had substantially performed its integration obligations prior to suspension. The court applied the traditional Michigan test from *Curran v. Williams* and its progeny, examining whether the forfeiture amount bore a reasonable relationship to the licensor's anticipated or actual harm.
This is helpful for VMS. Forfeiture of $12,320,000 in prepaid fees — comprising the $8,000,000 upfront license fee, $2,400,000 in Year 1 maintenance and support, and $1,920,000 in integration services fees for Milestones 1–3 — would be disproportionate to MeridianCode's actual damages if VMS terminated prior to the June 21, 2024 24-month anniversary under Section 9.1. VMS has already received and utilized significant deliverables through Milestone 3 on Argonaut-A, so MeridianCode has not performed those services without compensation, but VMS can argue that the value already delivered is a sunk benefit to MeridianCode and that total forfeiture of all prepaid fees functions as a penalty rather than a reasonable estimate of harm.
*C. Maintenance Fee Abatement During Dormancy*
On the disputed $2,400,000 Year 2 Maintenance & Support Fee invoiced by MeridianCode on July 1, 2023, I found useful support in Harland & Meyers, *Technology Licensing Disputes* (3d ed. 2021), particularly §§ 8.14–8.17. The treatise discusses the well-established principle that maintenance and support fees should be proportional to the level of support actually provided. Where a dormancy clause reduces the licensor's support obligations to a critical-security-patch-only level — as Section 9.4 does here — licensees in several reported disputes have successfully argued for abatement or proration of maintenance fees to reflect the reduced service level. The treatise cites several unpublished arbitration awards reaching this result, as well as the general equitable principle against unjust enrichment.
The argument here is straightforward: MeridianCode cannot simultaneously acknowledge that its support obligations are reduced to critical-security-patch-only during dormancy and also demand full-rate maintenance fees as if it were providing comprehensive support.
---
**II. "Use-It-or-Lose-It" Clauses — Section 4.3**
Section 4.3 requires VMS to commence integration testing on at least 2 platforms within 18 months of the June 21, 2022 Effective Date — i.e., by December 21, 2023.
*A. VMS's Current Compliance Posture*
As things stand, Argonaut-A reached Milestone 3 (alpha integration testing passed February 28, 2023), which clearly constitutes "commencement of integration testing" for that platform. The question is Argonaut-C. Argonaut-C reached Milestone 2 (source-code customization delivered January 15, 2023), but integration testing is a subsequent milestone phase. Whether Milestone 2 constitutes "commencement of integration testing" is, at best, debatable — the more natural reading is that it does not, since customization is a prerequisite to, rather than a component of, integration testing.
*B. Analogous Authority on "Commence Integration" Language*
I identified *Reliant Powertrain Corp. v. Sentinel Code Systems, Inc.*, No. 341892 (Mich. Ct. App. 2018), where a Michigan appellate court interpreted a similar "commence integration" requirement in an embedded software license for powertrain control modules. The court adopted a broad reading, holding that preparatory customization work constituting a necessary predicate to integration testing satisfied the "commencement" requirement. The court reasoned that the clause's purpose was to ensure the licensee was making bona fide progress toward full deployment, not to impose a formalistic gate that could be used as a gotcha by the licensor.
This is helpful for VMS, but I want to flag a concern: the language in Section 4.3 is more specific than the clause at issue in *Reliant*. Section 4.3 says "commence integration testing," not simply "commence integration" or "commence deployment activities." MeridianCode will argue the narrower phrase requires actual testing, not merely preparatory customization. I think this argument has some traction.
*C. The Stronger Argument: Dormancy Tolling*
In my view, the stronger argument is that dormancy under Section 9.4 tolls all milestone deadlines, including the Section 4.3 deadline. The *Crestline* award discussed above supports this position directly. If dormancy tolls the December 21, 2023 deadline, VMS gains additional runway equal to the duration of the dormancy period. Upon reactivation, VMS would have time to advance Argonaut-C to Milestone 3 (or beyond) and satisfy Section 4.3 unambiguously. I'd recommend we lead with the tolling argument rather than the broad-interpretation argument on "commence integration testing."
---
**III. Derivative Works Ownership — DW-001, DW-002, DW-003**
This is the most complex and fact-dependent issue. The three disputed derivative works modules comprise approximately 47,000 lines of code, with an estimated value of $1,800,000–$2,500,000 per Dr. Samuel Beecroft's assessment at Hargrove Technical Consulting.
*A. The Contractual Framework*
Under Section 7.2 of the MESLSA, modifications, adaptations, or extensions to ATLAS-RT source code created by VMS engineers become jointly owned, with MeridianCode retaining a perpetual, royalty-free license to such derivative works. VMS's position is that DW-001, DW-002, and DW-003 are VMS-originated works — independently authored by VMS engineers — that should be solely owned by VMS and fall outside Section 7.2's joint-ownership provision.
*B. Federal Copyright Principles and Michigan Law*
Michigan follows general federal copyright principles for software. Under 17 U.S.C. § 101, joint authorship requires that (1) each author's contribution be independently copyrightable, and (2) the authors intend to create a joint work at the time of creation. VMS may argue that its engineers' contributions were independently created, were not derivative of ATLAS-RT source code, and that VMS engineers did not intend joint authorship with MeridianCode. However, Section 7.2 is a contractual allocation of IP rights that may override the default statutory framework — so the real question is what the contract says, not what the Copyright Act would provide in the absence of an agreement.
*C. Analogous Authority*
The most relevant case I found is *Trident Mobility Solutions, Inc. v. Oakhurst Technologies Corp.*, No. 2:20-cv-01156 (E.D. Mich. 2021). The court examined a joint-ownership clause in an embedded software license for autonomous vehicle sensor systems — factually quite close to our situation. The court held that the contractual definition of "Derivative Work" controlled over the copyright statute's definition, but critically, the court then applied the contractual definition strictly. Where the licensee's engineers wrote new modules that interfaced with but did not modify the licensor's source code, the court held those modules were not "modifications, adaptations, or extensions" within the meaning of the contract. The court drew a distinction between code that operates on top of or alongside the licensed software (interfacing) and code that alters the licensed software itself (modifying/extending).
This is potentially quite favorable for VMS — if we can demonstrate, through Dr. Beecroft's technical analysis, that DW-001, DW-002, and DW-003 interface with ATLAS-RT but do not modify its underlying source code.
*D. Anticipated Counterarguments*
I expect MeridianCode, through Redstone Whitaker, will argue that the contractual definition of "Derivative Work" in Exhibit C is broad enough to capture any code that builds upon or extends ATLAS-RT functionality, regardless of whether the underlying source code was directly modified. The Exhibit C definition does use the phrase "extensions of functionality," which is broader than "modifications to source code." If MeridianCode can show that DW-001, DW-002, or DW-003 extend ATLAS-RT's functional capabilities — even without touching the source code — they'll argue that falls within Section 7.2.
Bottom line: Dr. Beecroft's technical assessment will be critical. We need his analysis to clearly characterize whether VMS's modules modify or extend ATLAS-RT's source code and functionality, or whether they are independent works that merely interface with ATLAS-RT through published APIs or standard communication protocols. I'd recommend we coordinate with Hargrove on the specific questions we need addressed.
---
**IV. Antitrust Considerations (Cross-Reference)**
I am separately preparing the antitrust considerations memorandum regarding MeridianCode's market position in automotive RTOS licensing (Nasdaq: MCDT; approximately $310 million FY2022 revenue; approximately 1,400 employees). I wanted to flag the connection here: if MeridianCode's derivative works claims or restrictive license provisions (particularly Section 7.2's joint-ownership provision and Section 11.3's non-compete carve-out) have the practical effect of foreclosing VMS from using competing RTOS solutions, there may be antitrust leverage under Section 1 of the Sherman Act or Michigan's Antitrust Reform Act. I'll address this fully in the separate memo, but the licensing and antitrust analyses are interconnected, and I wanted to make sure we're tracking them together.
---
**V. Arbitration Considerations**
A brief procedural note: the MESLSA requires binding arbitration under the rules of the Midwest Arbitration Institute, seated in Detroit, MI, with a 3-arbitrator panel for disputes exceeding $1,000,000. All of the disputes at issue — fee forfeiture ($12,320,000), the Year 2 maintenance fee ($2,400,000), and derivative works ownership ($1,800,000–$2,500,000 estimated value) — individually or collectively exceed that threshold, so a 3-arbitrator panel would be required.
Worth noting: published MAI awards, including *Crestline*, suggest the forum tends to enforce contractual dormancy provisions according to their terms and is generally receptive to tolling arguments where the licensee acted in good faith and provided timely notice. That bodes well for VMS, assuming we can demonstrate the bona fides of the dormancy invocation.
---
**VI. Summary and Recommendations**
The comparable authority generally supports VMS's positions on three key fronts:
1. **Dormancy tolling:** Strong support for the argument that Section 9.4 dormancy tolls the Section 4.3 "use-it-or-lose-it" deadline and other milestone deadlines. *Crestline* is directly on point, and the MAI forum appears sympathetic to these arguments.
2. **Fee forfeiture as penalty:** Reasonable support under Michigan law for arguing that forfeiture of $12,320,000 in prepaid fees is an unenforceable penalty, particularly given VMS's substantial performance through Milestone 3 on Argonaut-A and Milestone 2 on Argonaut-C, and the approximately 14,200 engineering hours VMS has invested in the integration program to date. *Northland Fleet* provides the analytical framework.
3. **Derivative works ownership:** The outcome will likely turn on the technical characterization of DW-001, DW-002, and DW-003 — specifically, whether they modify or extend ATLAS-RT source code/functionality, or independently interface with it. *Trident Mobility Solutions* is favorable if we can establish the latter. Dr. Beecroft's assessment from Hargrove will be dispositive on this point.
One broader caveat: Michigan law is somewhat underdeveloped on embedded-software-specific licensing disputes. There is no directly controlling Michigan Supreme Court or Sixth Circuit authority on several of these issues. The analogous federal district court decisions and arbitration awards I've cited will carry significant persuasive weight, but we should be candid with the client that we're working in a space without bright-line precedent.
I'm happy to prepare a more formal memorandum on any of these areas if you'd like to share the analysis with Martin Cross or the broader VMS team. I can also compile the cited authorities into a research binder for the matter file. Just let me know how you'd like to proceed.
Available to discuss anytime.
Best regards,
Aaron Liu Associate Calderwood & Harkness LLP 600 Renaissance Center, Suite 3200 Detroit, MI 48243 T: (313) 441-7829 E: aliu@calderwoodharkness.com
**ATTORNEY-CLIENT PRIVILEGED & CONFIDENTIAL — ATTORNEY WORK PRODUCT** *This email and any attachments are privileged and confidential, prepared in anticipation of litigation and/or for the purpose of providing legal advice. Do not forward or distribute without authorization.*