1007-00008 · Vantage Mobility Systems Corp · Memoranda

dormancy-clause-interpretation-memo.docx DOCUMENT IP / Technology

19 / 35 ← → ✕

Contract analysis Extract to table

PRIVILEGED AND CONFIDENTIAL — ATTORNEY-CLIENT COMMUNICATION

CALDERWOOD & HARKNESS LLP 600 Renaissance Center, Suite 3200 Detroit, Michigan 48243

MEMORANDUM

Matter No.: 1007-00008

July 18, 2023

TO: Bernard Crawford, Responsible Partner Conrad Ashby, Billing Partner

FROM: Gabrielle Moss, Lead Associate

RE: Dormancy Clause Interpretation and Vantage Mobility Systems Corp. Rights Under Section 9.4 of the Master Embedded Software License and Services Agreement with Meridian Code Technologies, Inc.

This memorandum is protected by the attorney-client privilege and the work product doctrine. It is prepared in connection with Calderwood & Harkness LLP's representation of Vantage Mobility Systems Corp. and should not be disclosed to any third party without prior authorization. This memorandum contains mental impressions, conclusions, opinions, and legal theories of attorneys and is entitled to heightened protection as opinion work product under Hickman v. Taylor, 329 U.S. 495 (1947), and its progeny.

Right-click to update Table of Contents

I. Executive Summary

The purpose of this memorandum is to analyze the rights and obligations of our client, Vantage Mobility Systems Corp. ("VMS"), under Section 9.4 (Dormancy) of the Master Embedded Software License and Services Agreement dated June 21, 2022 (the "MESLSA"), entered into between VMS and Meridian Code Technologies, Inc. ("MeridianCode"). This analysis is necessitated by VMS's suspension of active integration work on Project Argonaut on March 22, 2023, and VMS's subsequent issuance of a formal dormancy notice on July 14, 2023.

The suspension of integration work followed the VMS Board of Directors' March 14, 2023 resolution to rescope the Project Argonaut program from its original five-vehicle-platform scope (Argonaut-A through Argonaut-E) to only two platforms (Argonaut-A and Argonaut-C). That rescoping decision was driven by a confluence of factors, including persistent semiconductor supply-chain disruptions, a portfolio-wide capital expenditure reduction directive from VMS's private equity sponsor, Kestrel Capital Partners, LP, and a strategic pivot to prioritize internal combustion engine ("ICE") platform fleet vehicles over electric vehicle ("EV") platforms.

Our principal conclusion is that VMS's dormancy notice dated July 14, 2023 — sent six calendar days before the 120-day trigger date of July 20, 2023 — was timely under Section 9.4 and preserves VMS's contractual position, including the tolling of milestone deadlines. This is a favorable outcome for VMS, and VMS should take several immediate and near-term steps to solidify its position.

The key findings supporting this conclusion are as follows:

• Timeliness of Notice. The 120-day dormancy trigger is calculated from March 22, 2023 (the date integration work was suspended), yielding a trigger date of July 20, 2023. VMS's written notice was sent on July 14, 2023 — six days before the trigger date — and was therefore timely. By providing written notice before the 120-day period elapsed, VMS affirmatively invoked Dormancy Status and prevented MeridianCode from exercising its unilateral right to convert the license to Dormancy Status on terms potentially less favorable to VMS.

• Support Reduction. Dormancy Status, once effective, reduces MeridianCode's support obligation under the MESLSA to a critical-security-patch-only level. This reduction is significant because MeridianCode has invoiced VMS $2,400,000 for Year 2 Annual Maintenance and Support, a fee that contemplates a comprehensive support package. VMS has a strong basis for withholding or abating this fee.

• Tolling of Milestone Deadlines. Section 9.4 expressly provides that dormancy tolls "all milestone deadlines" under the MESLSA. This language is broad and should encompass not only the integration services milestones under Statement of Work No. 1 ("SOW No. 1") but also, under our best reading, the Section 4.3 Use-It-or-Lose-It deadline. The tolling argument for Section 4.3 is not without risk, however, and will be addressed in a separate memorandum.

• 12-Month Dormancy Cap. Section 9.4 imposes a 12-month cap on the dormancy period, running from the date of MeridianCode's acknowledgment. We anticipate MeridianCode's acknowledgment in August 2023, which would place the cap expiration at approximately August 2024. At the expiration of the cap, the parties must enter mandatory renegotiation of the MESLSA terms, or either party may terminate the agreement.

• Favorable Timeline Alignment. The 12-month dormancy cap (anticipated approximately August 3, 2024) falls after the 24-month anniversary of the MESLSA (June 21, 2024). This is significant because Section 9.1 provides that if VMS terminates the MESLSA for convenience prior to the 24-month anniversary, all prepaid fees ($12,320,000) are forfeited. By maintaining dormancy through the 24-month anniversary and then exercising termination rights at or after the dormancy cap expiration, VMS should avoid the fee-forfeiture trigger while preserving full optionality for reactivation, renegotiation, or managed termination.

• Interacting Deadlines. VMS must carefully manage several interacting contractual deadlines during the dormancy period. These include the Section 4.3 Use-It-or-Lose-It clause deadline (December 21, 2023, if not tolled), the Section 9.1 termination-for-convenience fee-forfeiture threshold (June 21, 2024), and the 12-month dormancy cap itself. We recommend calendaring all of these deadlines and developing contingency plans for each scenario.

The balance of this memorandum sets forth the factual background, the detailed analysis of Section 9.4 and its interaction with other key MESLSA provisions, a risk assessment, and our recommendations.

II. Factual Background

A. The MESLSA and Project Argonaut

On June 21, 2022, VMS and MeridianCode executed the Master Embedded Software License and Services Agreement (the "MESLSA"), a comprehensive agreement governing the licensing, integration, and support of MeridianCode's proprietary embedded real-time operating system, ATLAS-RT™, Version 4.2 (which was subsequently updated to Version 4.2.3 through a maintenance release delivered in November 2022). The MESLSA has a total deal value of approximately $20,000,000.

MeridianCode is a California corporation publicly traded on the Nasdaq exchange under the ticker symbol MCDT, with its principal offices located at 2750 Orchard Blvd., Suite 400, Santa Clara, California 95054. MeridianCode specializes in embedded software solutions for mobility and autonomous systems applications, and ATLAS-RT is its flagship product for the adaptive vehicle platform market.

VMS is a Delaware corporation headquartered at 4100 Industrial Parkway, Sterling Heights, Michigan 48312. VMS designs, manufactures, and markets adaptive vehicle platforms for fleet customers, including commercial, government, and military end users. VMS was acquired by Kestrel Capital Partners, LP in 2019 for approximately $380,000,000 in a leveraged buyout transaction.

The purpose of the MESLSA is to integrate ATLAS-RT as the core real-time operating system ("RTOS") layer into VMS's next-generation adaptive vehicle platform program, which VMS internally designated as "Project Argonaut." As originally scoped, Project Argonaut encompassed five distinct vehicle platform configurations, designated Argonaut-A through Argonaut-E. Each platform was intended to serve a different end-use segment, with Argonaut-A and Argonaut-B targeting ICE fleet vehicles, Argonaut-C targeting hybrid platforms, and Argonaut-D and Argonaut-E targeting fully electric vehicle configurations.

The MESLSA has a five-year term running from June 21, 2022 through June 20, 2027. The agreement is governed by the laws of the State of Michigan. Disputes arising under the MESLSA are subject to binding arbitration under the rules of the Midwest Arbitration Institute ("MAI"), seated in Detroit, Michigan. For disputes exceeding $1,000,000 in value, the parties agreed to a three-arbitrator panel, selected in accordance with MAI procedures.

B. Fee Structure

The MESLSA establishes a multi-component fee structure reflecting the breadth of the commercial arrangement. The components are as follows:

Upfront License Fee. VMS paid an upfront license fee of $8,000,000 at signing on June 21, 2022. This fee grants VMS a non-exclusive, non-transferable license to use ATLAS-RT for integration into VMS vehicle platforms as described in the MESLSA and applicable statements of work.

Annual Maintenance and Support Fees. The MESLSA provides for annual maintenance and support fees of $2,400,000 per year. The Year 1 Annual Maintenance and Support Fee was paid on July 15, 2022. The Year 2 Annual Maintenance and Support Fee was invoiced by MeridianCode on July 1, 2023, but payment has been disputed and deferred by VMS in light of the dormancy status and the accompanying reduction in MeridianCode's support obligations.

Integration Services Fee. The integration services fee totals $3,200,000, payable on a milestone basis across five integration milestones as defined in SOW No. 1. Each milestone carries an equal payment of $640,000. As of the suspension of integration work, VMS has completed and paid for Milestones 1 through 3, representing $1,920,000 in milestone payments. Milestones 4 and 5 remain uncompleted and unpaid, with $1,280,000 in remaining milestone fees.

Per-Unit Runtime Royalties. The MESLSA provides for per-unit runtime royalties of $80 per unit for each VMS vehicle platform shipped with ATLAS-RT integrated, subject to a volume cap of 50,000 units and an aggregate royalty cap of $4,000,000. Because no VMS vehicle platforms incorporating ATLAS-RT have been shipped to date, $0 in runtime royalties has been incurred.

Summary of Fees Paid and Remaining. As of the date of the dormancy notice, VMS has paid a total of $12,320,000 under the MESLSA, comprising the $8,000,000 upfront license fee, the $2,400,000 Year 1 maintenance fee, and $1,920,000 in milestone payments. Total remaining contractual commitment, assuming the MESLSA continues unmodified through its full term, is $7,680,000, comprising the $2,400,000 Year 2 maintenance fee (invoiced but unpaid), $1,280,000 in remaining milestone fees, and up to $4,000,000 in aggregate runtime royalties.

C. Project Argonaut Rescoping and Suspension

On March 14, 2023, the VMS Board of Directors adopted a resolution to rescope Project Argonaut from its original five-platform configuration to two platforms only — Argonaut-A and Argonaut-C. The Board further resolved that the electrification-focused integration work contemplated for Argonaut-D and Argonaut-E would be deferred to a potential Phase II of the program, with no firm date established for Phase II commencement.

The Board's decision was driven by three primary factors. First, persistent supply-chain delays in semiconductor procurement had disrupted VMS's production timelines and created uncertainty regarding the availability of critical electronic components required for the EV-focused platforms. Second, Kestrel Capital Partners, LP, VMS's private equity sponsor, had issued a portfolio-wide capital expenditure reduction directive in February 2023, requiring all Ashgrove Equity Partners portfolio companies to reduce discretionary capital spending by at least 15% for fiscal year 2023. Third, VMS management made a strategic decision to prioritize ICE-platform fleet vehicles over EV platforms, reflecting near-term market demand and customer order backlog data indicating stronger commercial prospects for the ICE and hybrid configurations.

At the time integration work was suspended on March 22, 2023, the status of each platform configuration was as follows:

• Argonaut-A: Milestone 3 of 5 completed. Alpha integration testing was passed on February 28, 2023. This represents the most advanced integration state among the five platforms and is significant for purposes of the Section 4.3 Use-It-or-Lose-It analysis.

• Argonaut-B: Milestone 1 only completed. The requirements specification had been approved, but no code integration work had commenced. Argonaut-B was a second-priority ICE platform and had been deprioritized even before the Board resolution.

• Argonaut-C: Milestone 2 of 5 completed. Source-code customization was delivered by MeridianCode on January 15, 2023, but the integration testing phase had not yet commenced.

• Argonaut-D and Argonaut-E: Not commenced. These EV-focused platforms were in the preliminary requirements-gathering stage and no integration milestones had been initiated.

All integration work across all five platform configurations was formally suspended on March 22, 2023, pursuant to a directive from VMS Chief Technology Officer, Richard Walden. Through the suspension date, VMS engineering teams had invested approximately 14,200 hours of internal engineering time across the Project Argonaut program, representing a significant investment of human capital independent of the fees paid to MeridianCode.

D. Dormancy Notice

On July 14, 2023, VMS, acting through its General Counsel, Martin G. Cross, sent a formal written dormancy notice to MeridianCode, addressed to Priya Ramaswamy, MeridianCode's General Counsel and Corporate Secretary, invoking Section 9.4 of the MESLSA. The notice was sent via overnight courier with return receipt requested and simultaneously transmitted by email to Ms. Ramaswamy's business email address, consistent with the MESLSA's notice provisions in Section 12.1.

The notice was sent six calendar days before the 120-day dormancy trigger date of July 20, 2023. As discussed in detail in Part III below, this timing is critical because it determines which party — VMS or MeridianCode — controls the invocation of Dormancy Status.

As of the date of this memorandum (July 18, 2023), MeridianCode has not yet formally acknowledged Dormancy Status. Based on past practice and the MESLSA's internal processing requirements, we anticipate that MeridianCode's acknowledgment will be issued in August 2023, likely within two to three weeks of receipt of VMS's notice. The timing of MeridianCode's acknowledgment is relevant to the calculation of the 12-month dormancy cap, as discussed below.

III. Analysis of Section 9.4 — Dormancy Provisions

A. Text of Section 9.4

Section 9.4 of the MESLSA, captioned "Dormancy," is the operative provision governing the parties' rights and obligations when active integration work is suspended for an extended period. The key operative language of Section 9.4 provides, in relevant part:

If Licensee suspends active integration of the Licensed Software for a period exceeding one hundred twenty (120) consecutive days without providing Licensor with written notice of such suspension, Licensor may, at its sole discretion, convert the license granted hereunder to "Dormancy Status." Alternatively, if Licensee provides Licensor with written notice of suspension prior to the expiration of such one-hundred-twenty-day period, Licensee may itself invoke Dormancy Status. Upon the effective date of Dormancy Status: (a) Licensor's support obligations shall be reduced to critical-security-patch-only level; (b) all milestone deadlines under this Agreement and any applicable Statement of Work shall be tolled for the duration of the dormancy period; and (c) Licensee's obligations to make milestone-based payments shall be suspended until reactivation. Dormancy Status shall not exceed twelve (12) months from the date of Licensor's written acknowledgment thereof, after which the parties shall enter mandatory good-faith renegotiation of the terms of this Agreement, or either party may terminate this Agreement upon thirty (30) days' written notice. During Dormancy Status, Licensee shall not sublicense the Licensed Software, permit third-party access to Licensed Software source code, or claim that Dormancy Status constitutes constructive termination of this Agreement. Licensee may reactivate the license at any time during the dormancy period by providing written notice to Licensor, whereupon Licensor shall resume full support obligations within a commercially reasonable time and all tolled deadlines shall resume.

Several aspects of this provision warrant close analysis, which is provided in the subsections below.

B. The 120-Day Trigger Calculation

The threshold question under Section 9.4 is whether VMS's dormancy notice was timely — that is, whether VMS provided written notice of its suspension of integration work before the 120-day period elapsed.

The calculation is straightforward:

• Date integration work was suspended: March 22, 2023.

• 120 consecutive calendar days from March 22, 2023: July 20, 2023.

• Date of VMS's dormancy notice: July 14, 2023.

• Margin: Six calendar days before the trigger date.

VMS's notice was therefore timely. By providing written notice of the suspension before the 120-day period expired, VMS exercised its right under the second sentence of Section 9.4 to affirmatively invoke Dormancy Status. This is the more favorable procedural posture for VMS, as compared to the alternative scenario in which the 120-day period expires without notice, leaving MeridianCode with unilateral discretion to convert the license to Dormancy Status (and, implicitly, to set terms for such conversion that may be less favorable to VMS).

The significance of this distinction cannot be overstated. Under the first sentence of Section 9.4, if VMS had failed to provide notice and the 120-day period had expired, MeridianCode would have been empowered to convert the license to Dormancy Status "at its sole discretion." While the contractual consequences of dormancy are prescribed by the remainder of Section 9.4 regardless of which party triggers the conversion, the practical implications of a licensor-initiated dormancy — including the licensor's ability to characterize the suspension as licensee non-performance and to assert leverage in subsequent negotiations — are materially different from a licensee-initiated dormancy. VMS's timely notice ensures that the dormancy is properly characterized as a deliberate, licensee-controlled exercise of contractual rights rather than a licensor-imposed consequence of inactivity.

We note that VMS's notice was sent on the sixth day before the trigger date, which is well within the required window. There is no minimum advance-notice period specified in Section 9.4 — the provision requires only that notice be provided "prior to the expiration of such one-hundred-twenty-day period." Even notice provided one day before the trigger date would have been timely. Nonetheless, VMS's six-day margin provides comfortable coverage against any argument that the notice was untimely due to computational disputes (e.g., whether the 120-day period is calculated inclusively or exclusively of the suspension date itself).

C. Effective Date of Dormancy Status

A question of significant practical importance is the effective date of Dormancy Status. Section 9.4 does not expressly specify whether Dormancy Status becomes effective on (a) the date of VMS's notice, (b) the 120-day trigger date, or (c) the date of MeridianCode's written acknowledgment. Each possible effective date has distinct implications for the calculation of the 12-month dormancy cap, the tolling of milestone deadlines, and the maintenance fee obligation.

We analyze each possibility in turn:

Option (a): July 14, 2023 (date of VMS's notice). Under this reading, Dormancy Status would be effective immediately upon VMS's transmittal of its written notice. While this interpretation would give VMS the earliest possible effective date and the longest dormancy period, it creates a textual anomaly: as of July 14, 2023, VMS had suspended integration work for only 114 consecutive days, and the Section 9.4 dormancy mechanism is expressly predicated on a suspension of "more than one hundred twenty (120) consecutive days." It is difficult to reconcile an effective date that precedes the satisfaction of the triggering condition. Moreover, this interpretation could be viewed as an attempt by VMS to artificially extend the dormancy period and advance the tolling of deadlines, which MeridianCode would likely resist.

Option (b): July 20, 2023 (120-day trigger date). This interpretation is the most textually consistent with the structure of Section 9.4. The clause presupposes that 120 consecutive days of suspended integration have elapsed before Dormancy Status can take effect. The licensee's pre-trigger written notice serves as the mechanism by which the licensee (rather than the licensor) controls the conversion, but the conversion itself logically cannot occur until the triggering condition — 120 days of suspended integration — is satisfied. Under this reading, VMS's July 14, 2023 notice is the operative act that preserves VMS's right to invoke dormancy, but the effective date of Dormancy Status is July 20, 2023, the date on which the 120-day suspension threshold is met.

Option (c): Date of MeridianCode's acknowledgment (anticipated August 2023). Under this interpretation, Dormancy Status would not become effective until MeridianCode formally acknowledges the dormancy in writing. This reading finds some support in the dormancy-cap language of Section 9.4, which states that dormancy "shall not exceed twelve (12) months from the date of Licensor's written acknowledgment thereof." However, adopting the acknowledgment date as the effective date of Dormancy Status — as opposed to merely the commencement date of the 12-month cap — would give MeridianCode unilateral ability to delay the effective date of dormancy by withholding or delaying its acknowledgment. This result is inconsistent with the overall structure of Section 9.4, which envisions that the licensee's timely notice should determine the timing of dormancy when the licensee acts before the trigger date. We do not believe this interpretation is correct with respect to the general effective date of Dormancy Status, although we acknowledge that the 12-month cap may run from the acknowledgment date.

Recommended Position. We recommend that VMS take the position that Dormancy Status is effective as of July 20, 2023 (the 120-day trigger date), with VMS's July 14, 2023 notice serving as the requisite written notice that prevents MeridianCode from exercising its unilateral conversion authority. This position is textually sound, avoids the anomalies associated with an effective date that precedes the triggering condition, and does not cede control to MeridianCode by tying the effective date to MeridianCode's acknowledgment.

We note, however, that the precise effective date matters primarily for two purposes: (1) calculating the 12-month dormancy cap, and (2) determining the commencement of the tolling period for milestone deadlines. As to the dormancy cap, the Section 9.4 text specifically references "the date of Licensor's written acknowledgment," which suggests that the 12-month cap may run from MeridianCode's acknowledgment date regardless of the general effective date of Dormancy Status. As to tolling, VMS benefits from an earlier effective date, since the earlier tolling commences, the longer the milestone deadlines are extended. For planning purposes, we will use the MeridianCode acknowledgment date for the 12-month cap calculation once that date is known, while maintaining that the general effective date of Dormancy Status is July 20, 2023.

D. Tolling of Milestone Deadlines

Section 9.4 expressly provides that upon the effective date of Dormancy Status, "all milestone deadlines under this Agreement and any applicable Statement of Work shall be tolled for the duration of the dormancy period." This is one of the most important consequences of dormancy for VMS, and the scope of the tolling language requires careful analysis.

The tolling provision plainly applies to the milestone deadlines set forth in SOW No. 1, which establishes the integration services milestone schedule for Project Argonaut. Milestones 4 and 5 — the two remaining uncompleted milestones — each have contractual deadlines that would otherwise require VMS to complete specified integration deliverables by specified dates. During dormancy, those deadlines are tolled, meaning VMS is not in breach for failing to complete the remaining milestones and the associated $1,280,000 in milestone payments is suspended.

The more difficult question is whether the tolling language extends to the Section 4.3 Use-It-or-Lose-It clause. Section 4.3 requires VMS to commence integration testing on at least two vehicle platforms within 18 months of the MESLSA Effective Date — i.e., by December 21, 2023. If this deadline is not met, MeridianCode has the right to reduce the scope of the license to a single platform and to require renegotiation of the license fee.

The question is whether Section 4.3's 18-month deadline qualifies as a "milestone deadline" within the meaning of Section 9.4. We identify arguments on both sides:

Arguments favoring tolling of Section 4.3:

First, Section 4.3 functions as a performance milestone in substance, even if it is not formally denominated as such. The provision establishes a time-bound requirement for VMS to achieve a specified level of integration activity (commencement of integration testing on at least two platforms), with defined consequences for non-compliance. This is functionally indistinguishable from a milestone deadline.

Second, the tolling language in Section 9.4 is broad: "all milestone deadlines under this Agreement and any applicable Statement of Work." The use of the phrase "under this Agreement" — as opposed to "under any applicable Statement of Work" alone — indicates that the tolling extends beyond SOW milestones to encompass milestone-type deadlines found elsewhere in the MESLSA.

Third, reading Section 4.3 as exempt from tolling would undermine the fundamental purpose of the dormancy provision, which is to preserve the licensee's rights during a period of justified suspension. If VMS exercises its contractual right to invoke dormancy but remains subject to the Section 4.3 deadline, VMS could lose license scope simply for availing itself of a contractual mechanism designed to protect it during periods of inactivity. This result would render the dormancy provision largely illusory.

Arguments against tolling of Section 4.3:

First, Section 4.3 is a standalone provision in Article 4 (Grant of License) of the MESLSA, not a milestone designated in any SOW. The term "milestone deadlines" may have a specific, limited meaning in the context of the MESLSA, referring only to the sequenced integration milestones established in statements of work.

Second, the MESLSA does not define the term "milestone deadline," and in the absence of a definition, MeridianCode may argue that the term should be construed narrowly to refer only to milestones that are expressly denominated as such. Section 4.3 uses the term "commencement" rather than "milestone," which could support a distinction.

Third, MeridianCode may argue that Section 4.3 serves a different purpose than integration milestones — it is a use-it-or-lose-it provision designed to ensure that VMS actively pursues integration across multiple platforms, not merely a scheduling tool. As such, MeridianCode may contend that Section 4.3 should be treated as a condition to the scope of the license grant rather than a milestone subject to tolling.

VMS's Best Position. We believe VMS has the stronger argument that the tolling language is broad enough to encompass Section 4.3. The textual argument based on "all milestone deadlines under this Agreement" is compelling, and the purposive argument — that exempting Section 4.3 from tolling would undermine the dormancy provision — provides strong reinforcement. Moreover, even if the tolling argument does not prevail, VMS may be able to demonstrate substantial compliance with Section 4.3 independent of tolling: VMS has already completed Milestone 3 (alpha integration testing) on Argonaut-A and Milestone 2 (source-code customization) on Argonaut-C, which arguably constitutes commencement of integration testing on two platforms.

We recommend that VMS assert the tolling argument as its primary position and substantial compliance as its fallback position. This issue will be analyzed in greater depth in a separate memorandum addressing Section 4.3 compliance options and tolling arguments.

E. Support Reduction During Dormancy

Section 9.4 specifies that during Dormancy Status, MeridianCode's support obligations are "reduced to critical-security-patch-only level." This language is unambiguous: during dormancy, MeridianCode is obligated only to provide patches for critical security vulnerabilities in the ATLAS-RT software. MeridianCode has no obligation during dormancy to provide feature updates, non-security bug fixes, general technical support, or integration assistance. The comprehensive support package contemplated by the MESLSA's maintenance and support provisions — including regular software updates, bug fixes of all severity levels, dedicated technical support staffing, and integration engineering assistance — is contractually suspended during the dormancy period.

This support reduction has immediate and significant financial implications. On July 1, 2023, MeridianCode invoiced VMS for the Year 2 Annual Maintenance and Support Fee in the amount of $2,400,000. This fee is calculated on the basis of MeridianCode's provision of the full, comprehensive support package described above. If, however, MeridianCode's support obligation is contractually reduced to critical-security-patch-only level — as it is during Dormancy Status — VMS has a strong argument that the full $2,400,000 maintenance fee should not be payable. At a minimum, VMS should be entitled to abatement or proration of the fee to reflect the materially reduced scope of services that MeridianCode is obligated (and permitted) to provide during the dormancy period.

The contractual basis for this argument rests on fundamental principles of consideration and proportionality. The $2,400,000 annual maintenance fee was negotiated in the context of MeridianCode providing a comprehensive suite of support services. A reduction of that suite to a single, narrow category of services — critical security patches only — represents a fundamental change in the value exchanged. Under Michigan law, which governs the MESLSA, a party is generally not required to pay full consideration for services that the counterparty is not contractually obligated to perform. See Bandit Indus., Inc. v. Hobbs Int'l, Inc., 463 Mich. 504, 511 (2001) (discussing mutuality of obligation and the relationship between performance obligations and payment obligations in commercial agreements).

We note that the MESLSA does not contain an express fee-abatement provision applicable to dormancy, nor does it specify the amount (if any) of maintenance fee payable during a dormancy period. This gap in the contract creates some uncertainty and will require careful analysis and, potentially, negotiation with MeridianCode. This issue will be treated comprehensively in a separate memorandum on the Year 2 Maintenance Fee obligation.

Current Recommendation. VMS should withhold payment of the $2,400,000 Year 2 Maintenance Fee pending resolution of the dormancy fee-abatement question. This position is supportable under Section 9.4 and VMS should not create a fait accompli by paying a fee that may not be owed in full. VMS's counsel should communicate VMS's position to MeridianCode's counsel in a manner that does not constitute a repudiation of the MESLSA but clearly preserves VMS's right to contest the fee.

F. The 12-Month Dormancy Cap

Section 9.4 provides that Dormancy Status "shall not exceed twelve (12) months from the date of Licensor's written acknowledgment thereof, after which the parties shall enter mandatory good-faith renegotiation of the terms of this Agreement, or either party may terminate this Agreement upon thirty (30) days' written notice."

This provision establishes an outer limit on the duration of dormancy. The 12-month cap is measured from the date of MeridianCode's written acknowledgment of Dormancy Status, which, as noted above, has not yet been received. Based on our experience with MeridianCode's administrative processes and the MESLSA's internal workflow requirements, we anticipate that MeridianCode's acknowledgment will be issued in August 2023. For planning purposes, we use an assumed acknowledgment date of August 3, 2023.

The calculation of the 12-month cap expiration under various scenarios is as follows:

• If Dormancy Status is effective July 20, 2023 (our recommended position for general effective date), but the 12-month cap runs from the date of MeridianCode's acknowledgment: The cap would expire on the date 12 months after MeridianCode's acknowledgment. If the acknowledgment is dated August 3, 2023, the cap expires August 3, 2024.

• If the 12-month cap is measured from July 20, 2023 (the general effective date of Dormancy Status): The cap would expire July 20, 2024. However, this reading is less textually supportable because Section 9.4 specifically references "the date of Licensor's written acknowledgment thereof" as the measuring date for the 12-month cap.

• If MeridianCode's acknowledgment is delayed beyond August 2023: The cap would be correspondingly extended. VMS should monitor for any delay by MeridianCode in issuing its acknowledgment, as such delay could affect the timing of the mandatory renegotiation or termination right.

Consequences of the 12-Month Cap Expiration. At the expiration of the 12-month cap, two alternatives arise: (1) the parties enter mandatory good-faith renegotiation of the MESLSA terms, or (2) either party may terminate the MESLSA upon 30 days' written notice. If the parties enter renegotiation but fail to reach agreement, the MESLSA's existing terms would presumably remain in effect during the negotiation period, subject to the dormancy restrictions; ultimately, if no agreement is reached, either party could exercise its termination right.

If termination occurs at or after the 12-month cap expiration, the interaction with Section 9.1's fee-forfeiture provision becomes critical. As discussed in Part IV.B below, Section 9.1 provides that all prepaid fees are forfeited if VMS terminates for convenience prior to the 24-month anniversary of the MESLSA (June 21, 2024). The timing alignment between the dormancy cap and the fee-forfeiture threshold is therefore of paramount strategic importance.

Strategic Observation. The 12-month dormancy cap — anticipated to expire approximately August 3, 2024, based on an assumed acknowledgment date of August 3, 2023 — falls after the 24-month anniversary of the MESLSA on June 21, 2024. This means that if VMS allows dormancy to run its full 12-month course and then exercises its termination right (or allows the MESLSA to terminate by operation of the dormancy cap), the fee-forfeiture trigger under Section 9.1 should not apply, because the 24-month anniversary will have already passed.

This timing alignment is highly favorable to VMS. It means that VMS can maintain dormancy through the critical June 21, 2024 fee-forfeiture threshold and then make a fully informed strategic decision — to renegotiate, reactivate, or terminate — without the $12,320,000 fee-forfeiture penalty hanging over VMS's decision-making. This alignment should be a central element of VMS's strategic planning and should be communicated to VMS management and, as appropriate, to Kestrel Capital Partners, LP.

G. Restrictions on VMS During Dormancy

Section 9.4 imposes certain restrictions on VMS during the dormancy period. These restrictions are designed to preserve MeridianCode's intellectual property rights and to prevent VMS from using dormancy as a mechanism to circumvent the MESLSA's licensing restrictions. Specifically, during Dormancy Status, VMS may not:

(a) Sublicense the ATLAS-RT software. This restriction is consistent with the general license restrictions under Section 3.2 of the MESLSA, which prohibit sublicensing in all circumstances absent MeridianCode's prior written consent. The dormancy provision reaffirms this prohibition.

(b) Permit third-party access to ATLAS-RT source code. VMS must ensure that no third party — including VMS subcontractors, consultants, or affiliated entities — has access to ATLAS-RT source code during the dormancy period. VMS engineering teams should be instructed to maintain the source code in secure, access-controlled environments and to document all access events.

(c) Claim that Dormancy Status constitutes constructive termination. This is a notable restriction that prevents VMS from arguing that the MESLSA has been constructively terminated by reason of the dormancy and from using such an argument as a basis to retain the ATLAS-RT software without ongoing obligations to MeridianCode. VMS must treat the MESLSA as an active, continuing agreement during the dormancy period.

Conversely, Section 9.4 preserves certain affirmative rights for VMS during dormancy. VMS may:

(a) Continue to possess and maintain copies of ATLAS-RT software in secure environments, consistent with the general license terms and the source-code access restrictions described above.

(b) Continue internal research and evaluation activities related to ATLAS-RT, subject to the general license terms. This includes testing, benchmarking, and feasibility analysis for potential future integration activities.

(c) Develop independent software modules that do not incorporate ATLAS-RT code. VMS engineering teams may continue working on proprietary software development for Project Argonaut or other programs, provided that such development does not involve the use or incorporation of ATLAS-RT source code or derivative works thereof.

(d) Prepare for reactivation at any time during the dormancy period. VMS may take all preparatory steps necessary to resume active integration work, including resource planning, staffing, and procurement of hardware and components.

These permissions provide VMS with meaningful flexibility during the dormancy period and ensure that VMS's internal engineering programs are not frozen simply because ATLAS-RT integration is on hold.

H. Reactivation Rights

Section 9.4 preserves VMS's right to reactivate the license at any time during the 12-month dormancy period. Reactivation is accomplished through a straightforward mechanism: VMS provides written notice of reactivation to MeridianCode, and MeridianCode is obligated to resume full support obligations within "a commercially reasonable time." The MESLSA does not define "commercially reasonable time" in this context, which introduces some ambiguity, but the standard industry interpretation would likely contemplate a period of 30 to 60 days for MeridianCode to reconstitute its support team, resume maintenance release cycles, and re-engage integration engineering resources.

Upon reactivation, the following consequences ensue:

(a) Previously tolled milestone deadlines resume. The remaining milestone deadlines under SOW No. 1 (Milestones 4 and 5) would resume from the point at which they were tolled, with the tolled period added to the original deadlines.

(b) Full maintenance and support obligations resume. MeridianCode would be required to provide the comprehensive suite of maintenance and support services contemplated by the MESLSA, including regular software updates, bug fixes, technical support, and integration assistance. Correspondingly, VMS's obligation to pay the full annual maintenance fee would resume.

(c) The Section 4.3 Use-It-or-Lose-It clock resumes (if tolled). If VMS's tolling argument with respect to Section 4.3 is sustained, the Use-It-or-Lose-It deadline would resume running from the point of reactivation, with the tolled period added to the original 18-month deadline.

VMS retains full optionality to reactivate if business conditions change. If, for example, semiconductor supply-chain issues resolve, VMS's Board reverses its rescoping decision, or Kestrel Capital Partners lifts its capital expenditure reduction directive, VMS can reactivate the MESLSA and resume Project Argonaut integration on Argonaut-A and Argonaut-C (or, subject to amendment of the MESLSA, on additional platforms). This optionality is a valuable feature of the dormancy provision and counsels in favor of maintaining dormancy rather than terminating the MESLSA at this time.

IV. Interaction with Other Key MESLSA Provisions

Section 9.4 does not operate in isolation. Several other provisions of the MESLSA interact with the dormancy provision in ways that affect VMS's rights, obligations, and strategic options. We analyze the most significant interactions below.

A. Section 4.3 — Use-It-or-Lose-It Clause

Section 4.3 of the MESLSA provides that VMS must commence integration testing on at least two vehicle platforms within 18 months of the Effective Date. The Effective Date is June 21, 2022, which yields a Section 4.3 deadline of December 21, 2023. If VMS fails to meet this deadline, MeridianCode has the right to reduce the scope of VMS's license to a single platform and to require renegotiation of the license fee to reflect the reduced scope.

As discussed in Part III.D above, VMS has a strong argument that the Section 4.3 deadline is tolled by the dormancy provision. If tolled, the deadline would be pushed out by the duration of the dormancy period. Assuming a dormancy period of approximately 12 months (from July 20, 2023 through approximately July 20, 2024), the tolled Section 4.3 deadline would fall in approximately December 2024 or later, depending on the precise calculation methodology.

Even if tolling is not sustained, VMS may be in substantial compliance with Section 4.3 based on the integration work already completed:

• Argonaut-A has passed alpha integration testing (Milestone 3, completed February 28, 2023). This constitutes commencement — and indeed substantial completion — of integration testing on one platform.

• Argonaut-C has completed source-code customization (Milestone 2, completed January 15, 2023). The question is whether Milestone 2 constitutes "commencement of integration testing" within the meaning of Section 4.3. Source-code customization is a necessary precursor to integration testing but may not itself constitute "integration testing" in the technical sense. MeridianCode may argue that Argonaut-C has not yet reached the integration testing stage and that only Argonaut-A qualifies.

If MeridianCode prevails on the argument that Argonaut-C has not yet commenced integration testing, VMS would have demonstrated commencement on only one platform (Argonaut-A), which would fall short of the two-platform requirement. In that scenario, VMS would need to rely on the tolling argument or face a potential scope reduction and fee renegotiation.

This issue requires detailed analysis that is beyond the scope of this memorandum. We will address Section 4.3 compliance options and tolling arguments in a separate, dedicated memorandum.

B. Section 9.1 — Termination for Convenience and Fee Forfeiture

Section 9.1 of the MESLSA provides that either party may terminate the agreement for convenience upon 180 days' prior written notice. However, Section 9.1 also includes a fee-forfeiture provision: if VMS (as licensee) terminates the MESLSA for convenience prior to the 24-month anniversary of the Effective Date (i.e., prior to June 21, 2024), all prepaid fees are forfeited to MeridianCode. The total prepaid fees as of the dormancy date are $12,320,000.

The interaction between the dormancy provision and Section 9.1 is critically important. If VMS maintains Dormancy Status through the 24-month anniversary of the MESLSA (June 21, 2024) without terminating, the fee-forfeiture provision ceases to apply. VMS would then be free to terminate the MESLSA for convenience at any time after June 21, 2024 — including at the expiration of the 12-month dormancy cap — without forfeiting prepaid fees.

The critical timeline alignment is as follows:

• 24-month anniversary of the MESLSA: June 21, 2024. After this date, fee forfeiture no longer applies to a termination for convenience by VMS.

• 12-month dormancy cap (from anticipated August 3, 2023 acknowledgment): August 3, 2024. At this date, the parties must enter mandatory renegotiation or either party may terminate upon 30 days' notice.

Because the dormancy cap expiration (approximately August 3, 2024) falls after the fee-forfeiture threshold (June 21, 2024), VMS can allow dormancy to run its full course and then exercise termination rights without exposure to fee forfeiture. This is a highly favorable alignment for VMS and should be a central element of VMS's strategic planning.

We note, however, that if VMS seeks to terminate for convenience during the dormancy period — before the 24-month anniversary — the fee-forfeiture provision would apply. VMS should not take any action during dormancy that could be characterized as a termination for convenience prior to June 21, 2024. In particular, VMS should be careful not to allow its withholding of the Year 2 Maintenance Fee to be characterized by MeridianCode as a repudiation or constructive termination, which could trigger fee forfeiture under a theory that VMS effectively terminated the MESLSA prior to the 24-month anniversary.

A separate fee-forfeiture risk analysis memorandum will address this issue in detail.

C. Section 7.2 — Derivative Works

During the integration phase of Project Argonaut, VMS engineering teams created three derivative work modules based on or incorporating elements of the ATLAS-RT software. These derivative works are designated DW-001, DW-002, and DW-003, and together comprise approximately 47,000 lines of code. The derivative works represent significant intellectual property, with an estimated commercial value of $1,800,000 to $2,500,000 according to a preliminary assessment conducted by Hargrove Technical Consulting, LLC.

Section 7.2 of the MESLSA addresses ownership of derivative works created during the integration process. The provision states that derivative works are "jointly owned" by VMS and MeridianCode, with MeridianCode retaining "a perpetual, royalty-free license to use, modify, and distribute" such derivative works. This provision is unfavorable to VMS, which invested substantial engineering resources in creating the derivative works and believes they should be solely owned by VMS.

VMS's position is that the derivative works — DW-001, DW-002, and DW-003 — are VMS-originated works that incorporate only de minimis elements of ATLAS-RT and are therefore not properly classified as "derivative works" within the meaning of Section 7.2. VMS contends that these modules are independent works of authorship that should be solely owned by VMS, with no license rights accruing to MeridianCode. This position will need to be supported by a detailed technical analysis of the code base, including a line-by-line assessment of the extent to which ATLAS-RT code is incorporated into the derivative work modules.

The interaction between the derivative works issue and dormancy is limited but worth noting. The derivative works that have already been created (DW-001, DW-002, and DW-003) are not affected by dormancy status — they exist and the ownership question must be resolved regardless of whether the MESLSA is in active status or dormancy. However, VMS should exercise caution during the dormancy period not to create additional derivative works, particularly given the ambiguity surrounding ownership. Any additional development work by VMS engineering teams during dormancy should be carefully structured to ensure that it does not incorporate ATLAS-RT code, thereby avoiding the creation of new derivative works whose ownership would be subject to the Section 7.2 joint-ownership provision.

A separate memorandum on derivative works ownership is forthcoming and will address VMS's arguments for sole ownership, the scope of the Section 7.2 definition, and strategies for resolving the ownership dispute.

D. Section 12.6 — Change of Control

Section 12.6 of the MESLSA provides that any assignment of the agreement in connection with a change of control of VMS requires MeridianCode's prior written consent, which "shall not be unreasonably withheld, conditioned, or delayed." This provision is standard in technology licensing agreements and reflects MeridianCode's interest in controlling the identity of its licensee.

The relevance of Section 12.6 during the dormancy period arises from VMS's ownership structure. VMS was acquired by Kestrel Capital Partners, LP in 2019, and Ashgrove Equity Partners serves as VMS's controlling private equity sponsor. If Ashgrove Equity Partners determines to exit its investment in VMS — whether through a sale, merger, IPO, or other liquidity event — such a transaction could constitute a "change of control" within the meaning of Section 12.6, triggering the consent requirement.

Dormancy status does not exempt VMS from the Section 12.6 consent requirement. If a change-of-control transaction is contemplated during the dormancy period, VMS would need to obtain MeridianCode's consent to the assignment of the MESLSA to the successor entity. While the consent standard — "not to be unreasonably withheld" — provides some protection against MeridianCode using the consent requirement as leverage, the practical reality is that obtaining licensor consent in the context of a time-pressured M&A transaction can be complicated and potentially costly.

We recommend monitoring this provision in connection with any Ashgrove Equity Partners portfolio-level strategic considerations. If Ashgrove Equity Partners is actively exploring exit options for VMS, VMS's management and counsel should be prepared to address the Section 12.6 consent requirement as part of the transaction planning process.

V. Risk Assessment

A. Risks to VMS if Dormancy Position Is Challenged

We have identified four principal risks to VMS's dormancy position, which we assess as follows:

Risk 1: MeridianCode argues that VMS's dormancy notice was late or deficient.

Assessment: Low risk. VMS's notice was dated July 14, 2023, six calendar days before the 120-day trigger date of July 20, 2023. The notice was sent to the correct counterparty representative (Priya Ramaswamy, MeridianCode's General Counsel and Corporate Secretary), using the delivery methods specified in the MESLSA's notice provision (Section 12.1). The notice expressly invoked Section 9.4 and identified the basis for the dormancy invocation. We are not aware of any procedural deficiency in the notice, and the six-day margin provides a comfortable buffer against computational disputes. Unless MeridianCode can identify a substantive defect in the notice — which we do not anticipate — this risk is low.

Risk 2: MeridianCode asserts that the 120-day trigger grants MeridianCode, not VMS, the right to determine dormancy terms.

Assessment: Moderate risk. The text of Section 9.4 draws a clear distinction between licensor-initiated dormancy (when the licensee fails to provide notice before the 120-day trigger) and licensee-initiated dormancy (when the licensee provides timely notice). However, the precise implications of this distinction are not fully elaborated in the MESLSA. MeridianCode may argue that the distinction affects only which party initiates the conversion and does not affect the substantive terms of dormancy (which are prescribed by the remainder of Section 9.4 regardless). Alternatively, MeridianCode may argue that VMS's notice was merely an acknowledgment of the impending trigger and did not constitute an affirmative invocation of dormancy by VMS. We believe VMS's position — that timely notice gives VMS control over the dormancy invocation — is the better reading of the text, but there is sufficient ambiguity to create moderate risk. VMS's affirmative, unambiguous language in the July 14 notice strengthens its position materially.

Risk 3: MeridianCode contends that Section 4.3's Use-It-or-Lose-It deadline is not tolled by dormancy.

Assessment: Moderate-to-high risk. As discussed in Part III.D, the tolling argument depends on whether Section 4.3's 18-month deadline qualifies as a "milestone deadline" within the meaning of Section 9.4. VMS has strong textual and purposive arguments in favor of tolling, but MeridianCode has a plausible counterargument that "milestone deadlines" refers only to SOW milestones. The resolution of this issue could turn on extrinsic evidence — including the parties' negotiation history and industry custom — which introduces uncertainty. If tolling is not sustained, VMS would need to rely on its fallback argument of substantial compliance, which itself carries risk (particularly with respect to whether Argonaut-C has commenced "integration testing"). This is the highest-risk issue in VMS's dormancy position and warrants careful preparation.

Risk 4: MeridianCode demands full Year 2 Maintenance Fee during dormancy despite support reduction.

Assessment: Moderate risk. VMS has a strong contractual argument that the maintenance fee should be abated or prorated to reflect the reduced scope of MeridianCode's support obligations during dormancy. However, the MESLSA does not contain an express fee-abatement provision applicable to dormancy, which creates a gap that MeridianCode will likely seek to exploit. MeridianCode may argue that the annual maintenance fee is a fixed, non-refundable fee that is payable regardless of the level of support actually provided, and that the dormancy provision reduces MeridianCode's obligations but does not correspondingly reduce VMS's payment obligations. This argument has some surface appeal but is ultimately inconsistent with the principles of mutuality and proportionality that animate Michigan contract law. VMS's position is defensible, but the absence of an express contractual mechanism for fee abatement introduces meaningful uncertainty.

B. Financial Exposure Summary

VMS's financial exposure in connection with the MESLSA and the dormancy is summarized as follows:

In addition to the direct financial exposure under the MESLSA, VMS must manage credit facility implications. VMS maintains a $175,000,000 revolving credit facility with Pinnacle National Bank, N.A. as administrative agent, with $92,000,000 currently outstanding. Section 6.12 of the credit agreement requires VMS to notify the administrative agent of any material contract disputes exceeding $5,000,000 in value. Given that VMS's potential financial exposure under the MESLSA exceeds $5,000,000, VMS must ensure compliance with Section 6.12 by providing prompt notification to Pinnacle National Bank, N.A. We recommend that this notification be directed to Howard Segal, Relationship Manager, and prepared in coordination with VMS's finance team and outside banking counsel.

Failure to provide timely notification under Section 6.12 could constitute an event of default under the credit facility, which would be a significantly more adverse outcome than the MESLSA dispute itself. This notification should be treated as a priority action item.

VI. Recommendations

A. Immediate Actions

Based on the foregoing analysis, we recommend that VMS take the following immediate actions:

1. Confirm delivery and receipt of the July 14, 2023 dormancy notice. VMS should confirm with its courier service that the notice was delivered to MeridianCode's offices at 2750 Orchard Blvd., Suite 400, Santa Clara, California 95054, and should obtain the signed return receipt. VMS should also confirm that the email transmission to Priya Ramaswamy was received and not bounced or filtered. Written confirmation of receipt — whether from MeridianCode's office, from the courier service, or from Ms. Ramaswamy directly — should be obtained and preserved in VMS's files. If there is any uncertainty regarding delivery, a duplicate notice should be transmitted immediately.

2. Track MeridianCode's formal acknowledgment of Dormancy Status. We anticipate that MeridianCode will issue a formal written acknowledgment of Dormancy Status in August 2023. Upon receipt, the acknowledgment should be immediately forwarded to this firm for analysis. We will review the acknowledgment for any departures from VMS's position regarding the effective date, scope, or terms of dormancy. If MeridianCode's acknowledgment contains conditions, reservations, or characterizations that are inconsistent with VMS's rights under Section 9.4, we will prepare a response letter promptly.

3. Withhold payment of the Year 2 Maintenance Fee. VMS should withhold payment of the $2,400,000 Year 2 Annual Maintenance and Support Fee invoiced by MeridianCode on July 1, 2023, pending resolution of the dormancy fee-abatement question. VMS's internal accounts payable system should be flagged to prevent inadvertent payment. VMS should prepare a written communication to MeridianCode (to be reviewed by this firm before transmission) explaining that the fee is being withheld pending clarification of VMS's payment obligations during Dormancy Status.

4. Prepare notification letter to Pinnacle National Bank, N.A. VMS must notify the administrative agent under its revolving credit facility of the MESLSA dormancy status as a material contract event exceeding $5,000,000. We recommend that this notification be directed to Howard Segal, Relationship Manager at Pinnacle National Bank, and prepared in coordination with VMS's Chief Financial Officer and outside banking counsel. The notification should describe the dormancy status in factual terms, identify the potential financial exposure, and affirm that VMS is managing the situation in accordance with its contractual rights. The notification should be transmitted promptly — ideally within one week of the date of this memorandum.

5. Institute document preservation protocols. VMS should implement formal document preservation protocols for all Project Argonaut integration records, milestone completion documentation, internal engineering logs, and communications with MeridianCode personnel. Key MeridianCode contacts whose communications should be preserved include Gregory L. Fisk (MeridianCode Integration Lead), Diana Cho (MeridianCode Project Manager), and Priya Ramaswamy (General Counsel). VMS should also preserve all Board of Directors minutes and resolutions related to the Project Argonaut rescoping, all communications with Kestrel Capital Partners regarding the capital expenditure reduction directive, and all internal VMS memoranda and analyses regarding the suspension of integration work. These records may be relevant in the event of future arbitration or negotiation with MeridianCode.

B. Near-Term Strategic Considerations

In addition to the immediate actions described above, we recommend that VMS pursue the following near-term strategic steps:

1. Calendar critical deadlines. VMS should calendar the following dates and establish internal monitoring procedures to ensure that no deadline is missed:

• 12-month dormancy cap deadline: anticipated August 3, 2024 (dependent on MeridianCode acknowledgment date)

• Section 9.1 24-month fee-forfeiture threshold: June 21, 2024

• Section 4.3 Use-It-or-Lose-It deadline: December 21, 2023 (if not tolled by dormancy)

• MESLSA expiration: June 20, 2027

2. Begin preparing for reactivation or structured renegotiation. Well before the 12-month dormancy cap expires, VMS should evaluate its strategic options and develop a plan for either reactivation (resuming integration work on Argonaut-A and Argonaut-C), structured renegotiation (amending the MESLSA to reflect the reduced scope of the program and to restructure fees accordingly), or managed termination (exerci

PRIVILEGED AND CONFIDENTIAL — ATTORNEY-CLIENT COMMUNICATION
CALDERWOOD & HARKNESS LLP 600 Renaissance Center, Suite 3200 Detroit, Michigan 48243
MEMORANDUM
Matter No.: 1007-00008
July 18, 2023
TO: Bernard Crawford, Responsible Partner Conrad Ashby, Billing Partner
FROM: Gabrielle Moss, Lead Associate
RE: Dormancy Clause Interpretation and Vantage Mobility Systems Corp. Rights Under Section 9.4 of the Master Embedded Software License and Services Agreement with Meridian Code Technologies, Inc.
This memorandum is protected by the attorney-client privilege and the work product doctrine. It is prepared in connection with Calderwood & Harkness LLP's representation of Vantage Mobility Systems Corp. and should not be disclosed to any third party without prior authorization. This memorandum contains mental impressions, conclusions, opinions, and legal theories of attorneys and is entitled to heightened protection as opinion work product under Hickman v. Taylor, 329 U.S. 495 (1947), and its progeny.
Right-click to update Table of Contents
I. Executive Summary
The purpose of this memorandum is to analyze the rights and obligations of our client, Vantage Mobility Systems Corp. ("VMS"), under Section 9.4 (Dormancy) of the Master Embedded Software License and Services Agreement dated June 21, 2022 (the "MESLSA"), entered into between VMS and Meridian Code Technologies, Inc. ("MeridianCode"). This analysis is necessitated by VMS's suspension of active integration work on Project Argonaut on March 22, 2023, and VMS's subsequent issuance of a formal dormancy notice on July 14, 2023.
The suspension of integration work followed the VMS Board of Directors' March 14, 2023 resolution to rescope the Project Argonaut program from its original five-vehicle-platform scope (Argonaut-A through Argonaut-E) to only two platforms (Argonaut-A and Argonaut-C). That rescoping decision was driven by a confluence of factors, including persistent semiconductor supply-chain disruptions, a portfolio-wide capital expenditure reduction directive from VMS's private equity sponsor, Kestrel Capital Partners, LP, and a strategic pivot to prioritize internal combustion engine ("ICE") platform fleet vehicles over electric vehicle ("EV") platforms.
Our principal conclusion is that VMS's dormancy notice dated July 14, 2023 — sent six calendar days before the 120-day trigger date of July 20, 2023 — was timely under Section 9.4 and preserves VMS's contractual position, including the tolling of milestone deadlines. This is a favorable outcome for VMS, and VMS should take several immediate and near-term steps to solidify its position.
The key findings supporting this conclusion are as follows:
• Timeliness of Notice. The 120-day dormancy trigger is calculated from March 22, 2023 (the date integration work was suspended), yielding a trigger date of July 20, 2023. VMS's written notice was sent on July 14, 2023 — six days before the trigger date — and was therefore timely. By providing written notice before the 120-day period elapsed, VMS affirmatively invoked Dormancy Status and prevented MeridianCode from exercising its unilateral right to convert the license to Dormancy Status on terms potentially less favorable to VMS.
• Support Reduction. Dormancy Status, once effective, reduces MeridianCode's support obligation under the MESLSA to a critical-security-patch-only level. This reduction is significant because MeridianCode has invoiced VMS $2,400,000 for Year 2 Annual Maintenance and Support, a fee that contemplates a comprehensive support package. VMS has a strong basis for withholding or abating this fee.
• Tolling of Milestone Deadlines. Section 9.4 expressly provides that dormancy tolls "all milestone deadlines" under the MESLSA. This language is broad and should encompass not only the integration services milestones under Statement of Work No. 1 ("SOW No. 1") but also, under our best reading, the Section 4.3 Use-It-or-Lose-It deadline. The tolling argument for Section 4.3 is not without risk, however, and will be addressed in a separate memorandum.
• 12-Month Dormancy Cap. Section 9.4 imposes a 12-month cap on the dormancy period, running from the date of MeridianCode's acknowledgment. We anticipate MeridianCode's acknowledgment in August 2023, which would place the cap expiration at approximately August 2024. At the expiration of the cap, the parties must enter mandatory renegotiation of the MESLSA terms, or either party may terminate the agreement.
• Favorable Timeline Alignment. The 12-month dormancy cap (anticipated approximately August 3, 2024) falls after the 24-month anniversary of the MESLSA (June 21, 2024). This is significant because Section 9.1 provides that if VMS terminates the MESLSA for convenience prior to the 24-month anniversary, all prepaid fees ($12,320,000) are forfeited. By maintaining dormancy through the 24-month anniversary and then exercising termination rights at or after the dormancy cap expiration, VMS should avoid the fee-forfeiture trigger while preserving full optionality for reactivation, renegotiation, or managed termination.
• Interacting Deadlines. VMS must carefully manage several interacting contractual deadlines during the dormancy period. These include the Section 4.3 Use-It-or-Lose-It clause deadline (December 21, 2023, if not tolled), the Section 9.1 termination-for-convenience fee-forfeiture threshold (June 21, 2024), and the 12-month dormancy cap itself. We recommend calendaring all of these deadlines and developing contingency plans for each scenario.
The balance of this memorandum sets forth the factual background, the detailed analysis of Section 9.4 and its interaction with other key MESLSA provisions, a risk assessment, and our recommendations.
II. Factual Background
A. The MESLSA and Project Argonaut
On June 21, 2022, VMS and MeridianCode executed the Master Embedded Software License and Services Agreement (the "MESLSA"), a comprehensive agreement governing the licensing, integration, and support of MeridianCode's proprietary embedded real-time operating system, ATLAS-RT™, Version 4.2 (which was subsequently updated to Version 4.2.3 through a maintenance release delivered in November 2022). The MESLSA has a total deal value of approximately $20,000,000.
MeridianCode is a California corporation publicly traded on the Nasdaq exchange under the ticker symbol MCDT, with its principal offices located at 2750 Orchard Blvd., Suite 400, Santa Clara, California 95054. MeridianCode specializes in embedded software solutions for mobility and autonomous systems applications, and ATLAS-RT is its flagship product for the adaptive vehicle platform market.
VMS is a Delaware corporation headquartered at 4100 Industrial Parkway, Sterling Heights, Michigan 48312. VMS designs, manufactures, and markets adaptive vehicle platforms for fleet customers, including commercial, government, and military end users. VMS was acquired by Kestrel Capital Partners, LP in 2019 for approximately $380,000,000 in a leveraged buyout transaction.
The purpose of the MESLSA is to integrate ATLAS-RT as the core real-time operating system ("RTOS") layer into VMS's next-generation adaptive vehicle platform program, which VMS internally designated as "Project Argonaut." As originally scoped, Project Argonaut encompassed five distinct vehicle platform configurations, designated Argonaut-A through Argonaut-E. Each platform was intended to serve a different end-use segment, with Argonaut-A and Argonaut-B targeting ICE fleet vehicles, Argonaut-C targeting hybrid platforms, and Argonaut-D and Argonaut-E targeting fully electric vehicle configurations.
The MESLSA has a five-year term running from June 21, 2022 through June 20, 2027. The agreement is governed by the laws of the State of Michigan. Disputes arising under the MESLSA are subject to binding arbitration under the rules of the Midwest Arbitration Institute ("MAI"), seated in Detroit, Michigan. For disputes exceeding $1,000,000 in value, the parties agreed to a three-arbitrator panel, selected in accordance with MAI procedures.
B. Fee Structure
The MESLSA establishes a multi-component fee structure reflecting the breadth of the commercial arrangement. The components are as follows:
Upfront License Fee. VMS paid an upfront license fee of $8,000,000 at signing on June 21, 2022. This fee grants VMS a non-exclusive, non-transferable license to use ATLAS-RT for integration into VMS vehicle platforms as described in the MESLSA and applicable statements of work.
Annual Maintenance and Support Fees. The MESLSA provides for annual maintenance and support fees of $2,400,000 per year. The Year 1 Annual Maintenance and Support Fee was paid on July 15, 2022. The Year 2 Annual Maintenance and Support Fee was invoiced by MeridianCode on July 1, 2023, but payment has been disputed and deferred by VMS in light of the dormancy status and the accompanying reduction in MeridianCode's support obligations.
Integration Services Fee. The integration services fee totals $3,200,000, payable on a milestone basis across five integration milestones as defined in SOW No. 1. Each milestone carries an equal payment of $640,000. As of the suspension of integration work, VMS has completed and paid for Milestones 1 through 3, representing $1,920,000 in milestone payments. Milestones 4 and 5 remain uncompleted and unpaid, with $1,280,000 in remaining milestone fees.
Per-Unit Runtime Royalties. The MESLSA provides for per-unit runtime royalties of $80 per unit for each VMS vehicle platform shipped with ATLAS-RT integrated, subject to a volume cap of 50,000 units and an aggregate royalty cap of $4,000,000. Because no VMS vehicle platforms incorporating ATLAS-RT have been shipped to date, $0 in runtime royalties has been incurred.
Summary of Fees Paid and Remaining. As of the date of the dormancy notice, VMS has paid a total of $12,320,000 under the MESLSA, comprising the $8,000,000 upfront license fee, the $2,400,000 Year 1 maintenance fee, and $1,920,000 in milestone payments. Total remaining contractual commitment, assuming the MESLSA continues unmodified through its full term, is $7,680,000, comprising the $2,400,000 Year 2 maintenance fee (invoiced but unpaid), $1,280,000 in remaining milestone fees, and up to $4,000,000 in aggregate runtime royalties.
C. Project Argonaut Rescoping and Suspension
On March 14, 2023, the VMS Board of Directors adopted a resolution to rescope Project Argonaut from its original five-platform configuration to two platforms only — Argonaut-A and Argonaut-C. The Board further resolved that the electrification-focused integration work contemplated for Argonaut-D and Argonaut-E would be deferred to a potential Phase II of the program, with no firm date established for Phase II commencement.
The Board's decision was driven by three primary factors. First, persistent supply-chain delays in semiconductor procurement had disrupted VMS's production timelines and created uncertainty regarding the availability of critical electronic components required for the EV-focused platforms. Second, Kestrel Capital Partners, LP, VMS's private equity sponsor, had issued a portfolio-wide capital expenditure reduction directive in February 2023, requiring all Ashgrove Equity Partners portfolio companies to reduce discretionary capital spending by at least 15% for fiscal year 2023. Third, VMS management made a strategic decision to prioritize ICE-platform fleet vehicles over EV platforms, reflecting near-term market demand and customer order backlog data indicating stronger commercial prospects for the ICE and hybrid configurations.
At the time integration work was suspended on March 22, 2023, the status of each platform configuration was as follows:
• Argonaut-A: Milestone 3 of 5 completed. Alpha integration testing was passed on February 28, 2023. This represents the most advanced integration state among the five platforms and is significant for purposes of the Section 4.3 Use-It-or-Lose-It analysis.
• Argonaut-B: Milestone 1 only completed. The requirements specification had been approved, but no code integration work had commenced. Argonaut-B was a second-priority ICE platform and had been deprioritized even before the Board resolution.
• Argonaut-C: Milestone 2 of 5 completed. Source-code customization was delivered by MeridianCode on January 15, 2023, but the integration testing phase had not yet commenced.
• Argonaut-D and Argonaut-E: Not commenced. These EV-focused platforms were in the preliminary requirements-gathering stage and no integration milestones had been initiated.
All integration work across all five platform configurations was formally suspended on March 22, 2023, pursuant to a directive from VMS Chief Technology Officer, Richard Walden. Through the suspension date, VMS engineering teams had invested approximately 14,200 hours of internal engineering time across the Project Argonaut program, representing a significant investment of human capital independent of the fees paid to MeridianCode.
D. Dormancy Notice
On July 14, 2023, VMS, acting through its General Counsel, Martin G. Cross, sent a formal written dormancy notice to MeridianCode, addressed to Priya Ramaswamy, MeridianCode's General Counsel and Corporate Secretary, invoking Section 9.4 of the MESLSA. The notice was sent via overnight courier with return receipt requested and simultaneously transmitted by email to Ms. Ramaswamy's business email address, consistent with the MESLSA's notice provisions in Section 12.1.
The notice was sent six calendar days before the 120-day dormancy trigger date of July 20, 2023. As discussed in detail in Part III below, this timing is critical because it determines which party — VMS or MeridianCode — controls the invocation of Dormancy Status.
As of the date of this memorandum (July 18, 2023), MeridianCode has not yet formally acknowledged Dormancy Status. Based on past practice and the MESLSA's internal processing requirements, we anticipate that MeridianCode's acknowledgment will be issued in August 2023, likely within two to three weeks of receipt of VMS's notice. The timing of MeridianCode's acknowledgment is relevant to the calculation of the 12-month dormancy cap, as discussed below.
III. Analysis of Section 9.4 — Dormancy Provisions
A. Text of Section 9.4
Section 9.4 of the MESLSA, captioned "Dormancy," is the operative provision governing the parties' rights and obligations when active integration work is suspended for an extended period. The key operative language of Section 9.4 provides, in relevant part:
If Licensee suspends active integration of the Licensed Software for a period exceeding one hundred twenty (120) consecutive days without providing Licensor with written notice of such suspension, Licensor may, at its sole discretion, convert the license granted hereunder to "Dormancy Status." Alternatively, if Licensee provides Licensor with written notice of suspension prior to the expiration of such one-hundred-twenty-day period, Licensee may itself invoke Dormancy Status. Upon the effective date of Dormancy Status: (a) Licensor's support obligations shall be reduced to critical-security-patch-only level; (b) all milestone deadlines under this Agreement and any applicable Statement of Work shall be tolled for the duration of the dormancy period; and (c) Licensee's obligations to make milestone-based payments shall be suspended until reactivation. Dormancy Status shall not exceed twelve (12) months from the date of Licensor's written acknowledgment thereof, after which the parties shall enter mandatory good-faith renegotiation of the terms of this Agreement, or either party may terminate this Agreement upon thirty (30) days' written notice. During Dormancy Status, Licensee shall not sublicense the Licensed Software, permit third-party access to Licensed Software source code, or claim that Dormancy Status constitutes constructive termination of this Agreement. Licensee may reactivate the license at any time during the dormancy period by providing written notice to Licensor, whereupon Licensor shall resume full support obligations within a commercially reasonable time and all tolled deadlines shall resume.
Several aspects of this provision warrant close analysis, which is provided in the subsections below.
B. The 120-Day Trigger Calculation
The threshold question under Section 9.4 is whether VMS's dormancy notice was timely — that is, whether VMS provided written notice of its suspension of integration work before the 120-day period elapsed.
The calculation is straightforward:
• Date integration work was suspended: March 22, 2023.
• 120 consecutive calendar days from March 22, 2023: July 20, 2023.
• Date of VMS's dormancy notice: July 14, 2023.
• Margin: Six calendar days before the trigger date.
VMS's notice was therefore timely. By providing written notice of the suspension before the 120-day period expired, VMS exercised its right under the second sentence of Section 9.4 to affirmatively invoke Dormancy Status. This is the more favorable procedural posture for VMS, as compared to the alternative scenario in which the 120-day period expires without notice, leaving MeridianCode with unilateral discretion to convert the license to Dormancy Status (and, implicitly, to set terms for such conversion that may be less favorable to VMS).
The significance of this distinction cannot be overstated. Under the first sentence of Section 9.4, if VMS had failed to provide notice and the 120-day period had expired, MeridianCode would have been empowered to convert the license to Dormancy Status "at its sole discretion." While the contractual consequences of dormancy are prescribed by the remainder of Section 9.4 regardless of which party triggers the conversion, the practical implications of a licensor-initiated dormancy — including the licensor's ability to characterize the suspension as licensee non-performance and to assert leverage in subsequent negotiations — are materially different from a licensee-initiated dormancy. VMS's timely notice ensures that the dormancy is properly characterized as a deliberate, licensee-controlled exercise of contractual rights rather than a licensor-imposed consequence of inactivity.
We note that VMS's notice was sent on the sixth day before the trigger date, which is well within the required window. There is no minimum advance-notice period specified in Section 9.4 — the provision requires only that notice be provided "prior to the expiration of such one-hundred-twenty-day period." Even notice provided one day before the trigger date would have been timely. Nonetheless, VMS's six-day margin provides comfortable coverage against any argument that the notice was untimely due to computational disputes (e.g., whether the 120-day period is calculated inclusively or exclusively of the suspension date itself).
C. Effective Date of Dormancy Status
A question of significant practical importance is the effective date of Dormancy Status. Section 9.4 does not expressly specify whether Dormancy Status becomes effective on (a) the date of VMS's notice, (b) the 120-day trigger date, or (c) the date of MeridianCode's written acknowledgment. Each possible effective date has distinct implications for the calculation of the 12-month dormancy cap, the tolling of milestone deadlines, and the maintenance fee obligation.
We analyze each possibility in turn:
Option (a): July 14, 2023 (date of VMS's notice). Under this reading, Dormancy Status would be effective immediately upon VMS's transmittal of its written notice. While this interpretation would give VMS the earliest possible effective date and the longest dormancy period, it creates a textual anomaly: as of July 14, 2023, VMS had suspended integration work for only 114 consecutive days, and the Section 9.4 dormancy mechanism is expressly predicated on a suspension of "more than one hundred twenty (120) consecutive days." It is difficult to reconcile an effective date that precedes the satisfaction of the triggering condition. Moreover, this interpretation could be viewed as an attempt by VMS to artificially extend the dormancy period and advance the tolling of deadlines, which MeridianCode would likely resist.
Option (b): July 20, 2023 (120-day trigger date). This interpretation is the most textually consistent with the structure of Section 9.4. The clause presupposes that 120 consecutive days of suspended integration have elapsed before Dormancy Status can take effect. The licensee's pre-trigger written notice serves as the mechanism by which the licensee (rather than the licensor) controls the conversion, but the conversion itself logically cannot occur until the triggering condition — 120 days of suspended integration — is satisfied. Under this reading, VMS's July 14, 2023 notice is the operative act that preserves VMS's right to invoke dormancy, but the effective date of Dormancy Status is July 20, 2023, the date on which the 120-day suspension threshold is met.
Option (c): Date of MeridianCode's acknowledgment (anticipated August 2023). Under this interpretation, Dormancy Status would not become effective until MeridianCode formally acknowledges the dormancy in writing. This reading finds some support in the dormancy-cap language of Section 9.4, which states that dormancy "shall not exceed twelve (12) months from the date of Licensor's written acknowledgment thereof." However, adopting the acknowledgment date as the effective date of Dormancy Status — as opposed to merely the commencement date of the 12-month cap — would give MeridianCode unilateral ability to delay the effective date of dormancy by withholding or delaying its acknowledgment. This result is inconsistent with the overall structure of Section 9.4, which envisions that the licensee's timely notice should determine the timing of dormancy when the licensee acts before the trigger date. We do not believe this interpretation is correct with respect to the general effective date of Dormancy Status, although we acknowledge that the 12-month cap may run from the acknowledgment date.
Recommended Position. We recommend that VMS take the position that Dormancy Status is effective as of July 20, 2023 (the 120-day trigger date), with VMS's July 14, 2023 notice serving as the requisite written notice that prevents MeridianCode from exercising its unilateral conversion authority. This position is textually sound, avoids the anomalies associated with an effective date that precedes the triggering condition, and does not cede control to MeridianCode by tying the effective date to MeridianCode's acknowledgment.
We note, however, that the precise effective date matters primarily for two purposes: (1) calculating the 12-month dormancy cap, and (2) determining the commencement of the tolling period for milestone deadlines. As to the dormancy cap, the Section 9.4 text specifically references "the date of Licensor's written acknowledgment," which suggests that the 12-month cap may run from MeridianCode's acknowledgment date regardless of the general effective date of Dormancy Status. As to tolling, VMS benefits from an earlier effective date, since the earlier tolling commences, the longer the milestone deadlines are extended. For planning purposes, we will use the MeridianCode acknowledgment date for the 12-month cap calculation once that date is known, while maintaining that the general effective date of Dormancy Status is July 20, 2023.
D. Tolling of Milestone Deadlines
Section 9.4 expressly provides that upon the effective date of Dormancy Status, "all milestone deadlines under this Agreement and any applicable Statement of Work shall be tolled for the duration of the dormancy period." This is one of the most important consequences of dormancy for VMS, and the scope of the tolling language requires careful analysis.
The tolling provision plainly applies to the milestone deadlines set forth in SOW No. 1, which establishes the integration services milestone schedule for Project Argonaut. Milestones 4 and 5 — the two remaining uncompleted milestones — each have contractual deadlines that would otherwise require VMS to complete specified integration deliverables by specified dates. During dormancy, those deadlines are tolled, meaning VMS is not in breach for failing to complete the remaining milestones and the associated $1,280,000 in milestone payments is suspended.
The more difficult question is whether the tolling language extends to the Section 4.3 Use-It-or-Lose-It clause. Section 4.3 requires VMS to commence integration testing on at least two vehicle platforms within 18 months of the MESLSA Effective Date — i.e., by December 21, 2023. If this deadline is not met, MeridianCode has the right to reduce the scope of the license to a single platform and to require renegotiation of the license fee.
The question is whether Section 4.3's 18-month deadline qualifies as a "milestone deadline" within the meaning of Section 9.4. We identify arguments on both sides:
Arguments favoring tolling of Section 4.3:
First, Section 4.3 functions as a performance milestone in substance, even if it is not formally denominated as such. The provision establishes a time-bound requirement for VMS to achieve a specified level of integration activity (commencement of integration testing on at least two platforms), with defined consequences for non-compliance. This is functionally indistinguishable from a milestone deadline.
Second, the tolling language in Section 9.4 is broad: "all milestone deadlines under this Agreement and any applicable Statement of Work." The use of the phrase "under this Agreement" — as opposed to "under any applicable Statement of Work" alone — indicates that the tolling extends beyond SOW milestones to encompass milestone-type deadlines found elsewhere in the MESLSA.
Third, reading Section 4.3 as exempt from tolling would undermine the fundamental purpose of the dormancy provision, which is to preserve the licensee's rights during a period of justified suspension. If VMS exercises its contractual right to invoke dormancy but remains subject to the Section 4.3 deadline, VMS could lose license scope simply for availing itself of a contractual mechanism designed to protect it during periods of inactivity. This result would render the dormancy provision largely illusory.
Arguments against tolling of Section 4.3:
First, Section 4.3 is a standalone provision in Article 4 (Grant of License) of the MESLSA, not a milestone designated in any SOW. The term "milestone deadlines" may have a specific, limited meaning in the context of the MESLSA, referring only to the sequenced integration milestones established in statements of work.
Second, the MESLSA does not define the term "milestone deadline," and in the absence of a definition, MeridianCode may argue that the term should be construed narrowly to refer only to milestones that are expressly denominated as such. Section 4.3 uses the term "commencement" rather than "milestone," which could support a distinction.
Third, MeridianCode may argue that Section 4.3 serves a different purpose than integration milestones — it is a use-it-or-lose-it provision designed to ensure that VMS actively pursues integration across multiple platforms, not merely a scheduling tool. As such, MeridianCode may contend that Section 4.3 should be treated as a condition to the scope of the license grant rather than a milestone subject to tolling.
VMS's Best Position. We believe VMS has the stronger argument that the tolling language is broad enough to encompass Section 4.3. The textual argument based on "all milestone deadlines under this Agreement" is compelling, and the purposive argument — that exempting Section 4.3 from tolling would undermine the dormancy provision — provides strong reinforcement. Moreover, even if the tolling argument does not prevail, VMS may be able to demonstrate substantial compliance with Section 4.3 independent of tolling: VMS has already completed Milestone 3 (alpha integration testing) on Argonaut-A and Milestone 2 (source-code customization) on Argonaut-C, which arguably constitutes commencement of integration testing on two platforms.
We recommend that VMS assert the tolling argument as its primary position and substantial compliance as its fallback position. This issue will be analyzed in greater depth in a separate memorandum addressing Section 4.3 compliance options and tolling arguments.
E. Support Reduction During Dormancy
Section 9.4 specifies that during Dormancy Status, MeridianCode's support obligations are "reduced to critical-security-patch-only level." This language is unambiguous: during dormancy, MeridianCode is obligated only to provide patches for critical security vulnerabilities in the ATLAS-RT software. MeridianCode has no obligation during dormancy to provide feature updates, non-security bug fixes, general technical support, or integration assistance. The comprehensive support package contemplated by the MESLSA's maintenance and support provisions — including regular software updates, bug fixes of all severity levels, dedicated technical support staffing, and integration engineering assistance — is contractually suspended during the dormancy period.
This support reduction has immediate and significant financial implications. On July 1, 2023, MeridianCode invoiced VMS for the Year 2 Annual Maintenance and Support Fee in the amount of $2,400,000. This fee is calculated on the basis of MeridianCode's provision of the full, comprehensive support package described above. If, however, MeridianCode's support obligation is contractually reduced to critical-security-patch-only level — as it is during Dormancy Status — VMS has a strong argument that the full $2,400,000 maintenance fee should not be payable. At a minimum, VMS should be entitled to abatement or proration of the fee to reflect the materially reduced scope of services that MeridianCode is obligated (and permitted) to provide during the dormancy period.
The contractual basis for this argument rests on fundamental principles of consideration and proportionality. The $2,400,000 annual maintenance fee was negotiated in the context of MeridianCode providing a comprehensive suite of support services. A reduction of that suite to a single, narrow category of services — critical security patches only — represents a fundamental change in the value exchanged. Under Michigan law, which governs the MESLSA, a party is generally not required to pay full consideration for services that the counterparty is not contractually obligated to perform. See Bandit Indus., Inc. v. Hobbs Int'l, Inc., 463 Mich. 504, 511 (2001) (discussing mutuality of obligation and the relationship between performance obligations and payment obligations in commercial agreements).
We note that the MESLSA does not contain an express fee-abatement provision applicable to dormancy, nor does it specify the amount (if any) of maintenance fee payable during a dormancy period. This gap in the contract creates some uncertainty and will require careful analysis and, potentially, negotiation with MeridianCode. This issue will be treated comprehensively in a separate memorandum on the Year 2 Maintenance Fee obligation.
Current Recommendation. VMS should withhold payment of the $2,400,000 Year 2 Maintenance Fee pending resolution of the dormancy fee-abatement question. This position is supportable under Section 9.4 and VMS should not create a fait accompli by paying a fee that may not be owed in full. VMS's counsel should communicate VMS's position to MeridianCode's counsel in a manner that does not constitute a repudiation of the MESLSA but clearly preserves VMS's right to contest the fee.
F. The 12-Month Dormancy Cap
Section 9.4 provides that Dormancy Status "shall not exceed twelve (12) months from the date of Licensor's written acknowledgment thereof, after which the parties shall enter mandatory good-faith renegotiation of the terms of this Agreement, or either party may terminate this Agreement upon thirty (30) days' written notice."
This provision establishes an outer limit on the duration of dormancy. The 12-month cap is measured from the date of MeridianCode's written acknowledgment of Dormancy Status, which, as noted above, has not yet been received. Based on our experience with MeridianCode's administrative processes and the MESLSA's internal workflow requirements, we anticipate that MeridianCode's acknowledgment will be issued in August 2023. For planning purposes, we use an assumed acknowledgment date of August 3, 2023.
The calculation of the 12-month cap expiration under various scenarios is as follows:
• If Dormancy Status is effective July 20, 2023 (our recommended position for general effective date), but the 12-month cap runs from the date of MeridianCode's acknowledgment: The cap would expire on the date 12 months after MeridianCode's acknowledgment. If the acknowledgment is dated August 3, 2023, the cap expires August 3, 2024.
• If the 12-month cap is measured from July 20, 2023 (the general effective date of Dormancy Status): The cap would expire July 20, 2024. However, this reading is less textually supportable because Section 9.4 specifically references "the date of Licensor's written acknowledgment thereof" as the measuring date for the 12-month cap.
• If MeridianCode's acknowledgment is delayed beyond August 2023: The cap would be correspondingly extended. VMS should monitor for any delay by MeridianCode in issuing its acknowledgment, as such delay could affect the timing of the mandatory renegotiation or termination right.
Consequences of the 12-Month Cap Expiration. At the expiration of the 12-month cap, two alternatives arise: (1) the parties enter mandatory good-faith renegotiation of the MESLSA terms, or (2) either party may terminate the MESLSA upon 30 days' written notice. If the parties enter renegotiation but fail to reach agreement, the MESLSA's existing terms would presumably remain in effect during the negotiation period, subject to the dormancy restrictions; ultimately, if no agreement is reached, either party could exercise its termination right.
If termination occurs at or after the 12-month cap expiration, the interaction with Section 9.1's fee-forfeiture provision becomes critical. As discussed in Part IV.B below, Section 9.1 provides that all prepaid fees are forfeited if VMS terminates for convenience prior to the 24-month anniversary of the MESLSA (June 21, 2024). The timing alignment between the dormancy cap and the fee-forfeiture threshold is therefore of paramount strategic importance.
Strategic Observation. The 12-month dormancy cap — anticipated to expire approximately August 3, 2024, based on an assumed acknowledgment date of August 3, 2023 — falls after the 24-month anniversary of the MESLSA on June 21, 2024. This means that if VMS allows dormancy to run its full 12-month course and then exercises its termination right (or allows the MESLSA to terminate by operation of the dormancy cap), the fee-forfeiture trigger under Section 9.1 should not apply, because the 24-month anniversary will have already passed.
This timing alignment is highly favorable to VMS. It means that VMS can maintain dormancy through the critical June 21, 2024 fee-forfeiture threshold and then make a fully informed strategic decision — to renegotiate, reactivate, or terminate — without the $12,320,000 fee-forfeiture penalty hanging over VMS's decision-making. This alignment should be a central element of VMS's strategic planning and should be communicated to VMS management and, as appropriate, to Kestrel Capital Partners, LP.
G. Restrictions on VMS During Dormancy
Section 9.4 imposes certain restrictions on VMS during the dormancy period. These restrictions are designed to preserve MeridianCode's intellectual property rights and to prevent VMS from using dormancy as a mechanism to circumvent the MESLSA's licensing restrictions. Specifically, during Dormancy Status, VMS may not:
(a) Sublicense the ATLAS-RT software. This restriction is consistent with the general license restrictions under Section 3.2 of the MESLSA, which prohibit sublicensing in all circumstances absent MeridianCode's prior written consent. The dormancy provision reaffirms this prohibition.
(b) Permit third-party access to ATLAS-RT source code. VMS must ensure that no third party — including VMS subcontractors, consultants, or affiliated entities — has access to ATLAS-RT source code during the dormancy period. VMS engineering teams should be instructed to maintain the source code in secure, access-controlled environments and to document all access events.
(c) Claim that Dormancy Status constitutes constructive termination. This is a notable restriction that prevents VMS from arguing that the MESLSA has been constructively terminated by reason of the dormancy and from using such an argument as a basis to retain the ATLAS-RT software without ongoing obligations to MeridianCode. VMS must treat the MESLSA as an active, continuing agreement during the dormancy period.
Conversely, Section 9.4 preserves certain affirmative rights for VMS during dormancy. VMS may:
(a) Continue to possess and maintain copies of ATLAS-RT software in secure environments, consistent with the general license terms and the source-code access restrictions described above.
(b) Continue internal research and evaluation activities related to ATLAS-RT, subject to the general license terms. This includes testing, benchmarking, and feasibility analysis for potential future integration activities.
(c) Develop independent software modules that do not incorporate ATLAS-RT code. VMS engineering teams may continue working on proprietary software development for Project Argonaut or other programs, provided that such development does not involve the use or incorporation of ATLAS-RT source code or derivative works thereof.
(d) Prepare for reactivation at any time during the dormancy period. VMS may take all preparatory steps necessary to resume active integration work, including resource planning, staffing, and procurement of hardware and components.
These permissions provide VMS with meaningful flexibility during the dormancy period and ensure that VMS's internal engineering programs are not frozen simply because ATLAS-RT integration is on hold.
H. Reactivation Rights
Section 9.4 preserves VMS's right to reactivate the license at any time during the 12-month dormancy period. Reactivation is accomplished through a straightforward mechanism: VMS provides written notice of reactivation to MeridianCode, and MeridianCode is obligated to resume full support obligations within "a commercially reasonable time." The MESLSA does not define "commercially reasonable time" in this context, which introduces some ambiguity, but the standard industry interpretation would likely contemplate a period of 30 to 60 days for MeridianCode to reconstitute its support team, resume maintenance release cycles, and re-engage integration engineering resources.
Upon reactivation, the following consequences ensue:
(a) Previously tolled milestone deadlines resume. The remaining milestone deadlines under SOW No. 1 (Milestones 4 and 5) would resume from the point at which they were tolled, with the tolled period added to the original deadlines.
(b) Full maintenance and support obligations resume. MeridianCode would be required to provide the comprehensive suite of maintenance and support services contemplated by the MESLSA, including regular software updates, bug fixes, technical support, and integration assistance. Correspondingly, VMS's obligation to pay the full annual maintenance fee would resume.
(c) The Section 4.3 Use-It-or-Lose-It clock resumes (if tolled). If VMS's tolling argument with respect to Section 4.3 is sustained, the Use-It-or-Lose-It deadline would resume running from the point of reactivation, with the tolled period added to the original 18-month deadline.
VMS retains full optionality to reactivate if business conditions change. If, for example, semiconductor supply-chain issues resolve, VMS's Board reverses its rescoping decision, or Kestrel Capital Partners lifts its capital expenditure reduction directive, VMS can reactivate the MESLSA and resume Project Argonaut integration on Argonaut-A and Argonaut-C (or, subject to amendment of the MESLSA, on additional platforms). This optionality is a valuable feature of the dormancy provision and counsels in favor of maintaining dormancy rather than terminating the MESLSA at this time.
IV. Interaction with Other Key MESLSA Provisions
Section 9.4 does not operate in isolation. Several other provisions of the MESLSA interact with the dormancy provision in ways that affect VMS's rights, obligations, and strategic options. We analyze the most significant interactions below.
A. Section 4.3 — Use-It-or-Lose-It Clause
Section 4.3 of the MESLSA provides that VMS must commence integration testing on at least two vehicle platforms within 18 months of the Effective Date. The Effective Date is June 21, 2022, which yields a Section 4.3 deadline of December 21, 2023. If VMS fails to meet this deadline, MeridianCode has the right to reduce the scope of VMS's license to a single platform and to require renegotiation of the license fee to reflect the reduced scope.
As discussed in Part III.D above, VMS has a strong argument that the Section 4.3 deadline is tolled by the dormancy provision. If tolled, the deadline would be pushed out by the duration of the dormancy period. Assuming a dormancy period of approximately 12 months (from July 20, 2023 through approximately July 20, 2024), the tolled Section 4.3 deadline would fall in approximately December 2024 or later, depending on the precise calculation methodology.
Even if tolling is not sustained, VMS may be in substantial compliance with Section 4.3 based on the integration work already completed:
• Argonaut-A has passed alpha integration testing (Milestone 3, completed February 28, 2023). This constitutes commencement — and indeed substantial completion — of integration testing on one platform.
• Argonaut-C has completed source-code customization (Milestone 2, completed January 15, 2023). The question is whether Milestone 2 constitutes "commencement of integration testing" within the meaning of Section 4.3. Source-code customization is a necessary precursor to integration testing but may not itself constitute "integration testing" in the technical sense. MeridianCode may argue that Argonaut-C has not yet reached the integration testing stage and that only Argonaut-A qualifies.
If MeridianCode prevails on the argument that Argonaut-C has not yet commenced integration testing, VMS would have demonstrated commencement on only one platform (Argonaut-A), which would fall short of the two-platform requirement. In that scenario, VMS would need to rely on the tolling argument or face a potential scope reduction and fee renegotiation.
This issue requires detailed analysis that is beyond the scope of this memorandum. We will address Section 4.3 compliance options and tolling arguments in a separate, dedicated memorandum.
B. Section 9.1 — Termination for Convenience and Fee Forfeiture
Section 9.1 of the MESLSA provides that either party may terminate the agreement for convenience upon 180 days' prior written notice. However, Section 9.1 also includes a fee-forfeiture provision: if VMS (as licensee) terminates the MESLSA for convenience prior to the 24-month anniversary of the Effective Date (i.e., prior to June 21, 2024), all prepaid fees are forfeited to MeridianCode. The total prepaid fees as of the dormancy date are $12,320,000.
The interaction between the dormancy provision and Section 9.1 is critically important. If VMS maintains Dormancy Status through the 24-month anniversary of the MESLSA (June 21, 2024) without terminating, the fee-forfeiture provision ceases to apply. VMS would then be free to terminate the MESLSA for convenience at any time after June 21, 2024 — including at the expiration of the 12-month dormancy cap — without forfeiting prepaid fees.
The critical timeline alignment is as follows:
• 24-month anniversary of the MESLSA: June 21, 2024. After this date, fee forfeiture no longer applies to a termination for convenience by VMS.
• 12-month dormancy cap (from anticipated August 3, 2023 acknowledgment): August 3, 2024. At this date, the parties must enter mandatory renegotiation or either party may terminate upon 30 days' notice.
Because the dormancy cap expiration (approximately August 3, 2024) falls after the fee-forfeiture threshold (June 21, 2024), VMS can allow dormancy to run its full course and then exercise termination rights without exposure to fee forfeiture. This is a highly favorable alignment for VMS and should be a central element of VMS's strategic planning.
We note, however, that if VMS seeks to terminate for convenience during the dormancy period — before the 24-month anniversary — the fee-forfeiture provision would apply. VMS should not take any action during dormancy that could be characterized as a termination for convenience prior to June 21, 2024. In particular, VMS should be careful not to allow its withholding of the Year 2 Maintenance Fee to be characterized by MeridianCode as a repudiation or constructive termination, which could trigger fee forfeiture under a theory that VMS effectively terminated the MESLSA prior to the 24-month anniversary.
A separate fee-forfeiture risk analysis memorandum will address this issue in detail.
C. Section 7.2 — Derivative Works
During the integration phase of Project Argonaut, VMS engineering teams created three derivative work modules based on or incorporating elements of the ATLAS-RT software. These derivative works are designated DW-001, DW-002, and DW-003, and together comprise approximately 47,000 lines of code. The derivative works represent significant intellectual property, with an estimated commercial value of $1,800,000 to $2,500,000 according to a preliminary assessment conducted by Hargrove Technical Consulting, LLC.
Section 7.2 of the MESLSA addresses ownership of derivative works created during the integration process. The provision states that derivative works are "jointly owned" by VMS and MeridianCode, with MeridianCode retaining "a perpetual, royalty-free license to use, modify, and distribute" such derivative works. This provision is unfavorable to VMS, which invested substantial engineering resources in creating the derivative works and believes they should be solely owned by VMS.
VMS's position is that the derivative works — DW-001, DW-002, and DW-003 — are VMS-originated works that incorporate only de minimis elements of ATLAS-RT and are therefore not properly classified as "derivative works" within the meaning of Section 7.2. VMS contends that these modules are independent works of authorship that should be solely owned by VMS, with no license rights accruing to MeridianCode. This position will need to be supported by a detailed technical analysis of the code base, including a line-by-line assessment of the extent to which ATLAS-RT code is incorporated into the derivative work modules.
The interaction between the derivative works issue and dormancy is limited but worth noting. The derivative works that have already been created (DW-001, DW-002, and DW-003) are not affected by dormancy status — they exist and the ownership question must be resolved regardless of whether the MESLSA is in active status or dormancy. However, VMS should exercise caution during the dormancy period not to create additional derivative works, particularly given the ambiguity surrounding ownership. Any additional development work by VMS engineering teams during dormancy should be carefully structured to ensure that it does not incorporate ATLAS-RT code, thereby avoiding the creation of new derivative works whose ownership would be subject to the Section 7.2 joint-ownership provision.
A separate memorandum on derivative works ownership is forthcoming and will address VMS's arguments for sole ownership, the scope of the Section 7.2 definition, and strategies for resolving the ownership dispute.
D. Section 12.6 — Change of Control
Section 12.6 of the MESLSA provides that any assignment of the agreement in connection with a change of control of VMS requires MeridianCode's prior written consent, which "shall not be unreasonably withheld, conditioned, or delayed." This provision is standard in technology licensing agreements and reflects MeridianCode's interest in controlling the identity of its licensee.
The relevance of Section 12.6 during the dormancy period arises from VMS's ownership structure. VMS was acquired by Kestrel Capital Partners, LP in 2019, and Ashgrove Equity Partners serves as VMS's controlling private equity sponsor. If Ashgrove Equity Partners determines to exit its investment in VMS — whether through a sale, merger, IPO, or other liquidity event — such a transaction could constitute a "change of control" within the meaning of Section 12.6, triggering the consent requirement.
Dormancy status does not exempt VMS from the Section 12.6 consent requirement. If a change-of-control transaction is contemplated during the dormancy period, VMS would need to obtain MeridianCode's consent to the assignment of the MESLSA to the successor entity. While the consent standard — "not to be unreasonably withheld" — provides some protection against MeridianCode using the consent requirement as leverage, the practical reality is that obtaining licensor consent in the context of a time-pressured M&A transaction can be complicated and potentially costly.
We recommend monitoring this provision in connection with any Ashgrove Equity Partners portfolio-level strategic considerations. If Ashgrove Equity Partners is actively exploring exit options for VMS, VMS's management and counsel should be prepared to address the Section 12.6 consent requirement as part of the transaction planning process.
V. Risk Assessment
A. Risks to VMS if Dormancy Position Is Challenged
We have identified four principal risks to VMS's dormancy position, which we assess as follows:
Risk 1: MeridianCode argues that VMS's dormancy notice was late or deficient.
Assessment: Low risk. VMS's notice was dated July 14, 2023, six calendar days before the 120-day trigger date of July 20, 2023. The notice was sent to the correct counterparty representative (Priya Ramaswamy, MeridianCode's General Counsel and Corporate Secretary), using the delivery methods specified in the MESLSA's notice provision (Section 12.1). The notice expressly invoked Section 9.4 and identified the basis for the dormancy invocation. We are not aware of any procedural deficiency in the notice, and the six-day margin provides a comfortable buffer against computational disputes. Unless MeridianCode can identify a substantive defect in the notice — which we do not anticipate — this risk is low.
Risk 2: MeridianCode asserts that the 120-day trigger grants MeridianCode, not VMS, the right to determine dormancy terms.
Assessment: Moderate risk. The text of Section 9.4 draws a clear distinction between licensor-initiated dormancy (when the licensee fails to provide notice before the 120-day trigger) and licensee-initiated dormancy (when the licensee provides timely notice). However, the precise implications of this distinction are not fully elaborated in the MESLSA. MeridianCode may argue that the distinction affects only which party initiates the conversion and does not affect the substantive terms of dormancy (which are prescribed by the remainder of Section 9.4 regardless). Alternatively, MeridianCode may argue that VMS's notice was merely an acknowledgment of the impending trigger and did not constitute an affirmative invocation of dormancy by VMS. We believe VMS's position — that timely notice gives VMS control over the dormancy invocation — is the better reading of the text, but there is sufficient ambiguity to create moderate risk. VMS's affirmative, unambiguous language in the July 14 notice strengthens its position materially.
Risk 3: MeridianCode contends that Section 4.3's Use-It-or-Lose-It deadline is not tolled by dormancy.
Assessment: Moderate-to-high risk. As discussed in Part III.D, the tolling argument depends on whether Section 4.3's 18-month deadline qualifies as a "milestone deadline" within the meaning of Section 9.4. VMS has strong textual and purposive arguments in favor of tolling, but MeridianCode has a plausible counterargument that "milestone deadlines" refers only to SOW milestones. The resolution of this issue could turn on extrinsic evidence — including the parties' negotiation history and industry custom — which introduces uncertainty. If tolling is not sustained, VMS would need to rely on its fallback argument of substantial compliance, which itself carries risk (particularly with respect to whether Argonaut-C has commenced "integration testing"). This is the highest-risk issue in VMS's dormancy position and warrants careful preparation.
Risk 4: MeridianCode demands full Year 2 Maintenance Fee during dormancy despite support reduction.
Assessment: Moderate risk. VMS has a strong contractual argument that the maintenance fee should be abated or prorated to reflect the reduced scope of MeridianCode's support obligations during dormancy. However, the MESLSA does not contain an express fee-abatement provision applicable to dormancy, which creates a gap that MeridianCode will likely seek to exploit. MeridianCode may argue that the annual maintenance fee is a fixed, non-refundable fee that is payable regardless of the level of support actually provided, and that the dormancy provision reduces MeridianCode's obligations but does not correspondingly reduce VMS's payment obligations. This argument has some surface appeal but is ultimately inconsistent with the principles of mutuality and proportionality that animate Michigan contract law. VMS's position is defensible, but the absence of an express contractual mechanism for fee abatement introduces meaningful uncertainty.
B. Financial Exposure Summary
VMS's financial exposure in connection with the MESLSA and the dormancy is summarized as follows:
In addition to the direct financial exposure under the MESLSA, VMS must manage credit facility implications. VMS maintains a $175,000,000 revolving credit facility with Pinnacle National Bank, N.A. as administrative agent, with $92,000,000 currently outstanding. Section 6.12 of the credit agreement requires VMS to notify the administrative agent of any material contract disputes exceeding $5,000,000 in value. Given that VMS's potential financial exposure under the MESLSA exceeds $5,000,000, VMS must ensure compliance with Section 6.12 by providing prompt notification to Pinnacle National Bank, N.A. We recommend that this notification be directed to Howard Segal, Relationship Manager, and prepared in coordination with VMS's finance team and outside banking counsel.
Failure to provide timely notification under Section 6.12 could constitute an event of default under the credit facility, which would be a significantly more adverse outcome than the MESLSA dispute itself. This notification should be treated as a priority action item.
VI. Recommendations
A. Immediate Actions
Based on the foregoing analysis, we recommend that VMS take the following immediate actions:
1. Confirm delivery and receipt of the July 14, 2023 dormancy notice. VMS should confirm with its courier service that the notice was delivered to MeridianCode's offices at 2750 Orchard Blvd., Suite 400, Santa Clara, California 95054, and should obtain the signed return receipt. VMS should also confirm that the email transmission to Priya Ramaswamy was received and not bounced or filtered. Written confirmation of receipt — whether from MeridianCode's office, from the courier service, or from Ms. Ramaswamy directly — should be obtained and preserved in VMS's files. If there is any uncertainty regarding delivery, a duplicate notice should be transmitted immediately.
2. Track MeridianCode's formal acknowledgment of Dormancy Status. We anticipate that MeridianCode will issue a formal written acknowledgment of Dormancy Status in August 2023. Upon receipt, the acknowledgment should be immediately forwarded to this firm for analysis. We will review the acknowledgment for any departures from VMS's position regarding the effective date, scope, or terms of dormancy. If MeridianCode's acknowledgment contains conditions, reservations, or characterizations that are inconsistent with VMS's rights under Section 9.4, we will prepare a response letter promptly.
3. Withhold payment of the Year 2 Maintenance Fee. VMS should withhold payment of the $2,400,000 Year 2 Annual Maintenance and Support Fee invoiced by MeridianCode on July 1, 2023, pending resolution of the dormancy fee-abatement question. VMS's internal accounts payable system should be flagged to prevent inadvertent payment. VMS should prepare a written communication to MeridianCode (to be reviewed by this firm before transmission) explaining that the fee is being withheld pending clarification of VMS's payment obligations during Dormancy Status.
4. Prepare notification letter to Pinnacle National Bank, N.A. VMS must notify the administrative agent under its revolving credit facility of the MESLSA dormancy status as a material contract event exceeding $5,000,000. We recommend that this notification be directed to Howard Segal, Relationship Manager at Pinnacle National Bank, and prepared in coordination with VMS's Chief Financial Officer and outside banking counsel. The notification should describe the dormancy status in factual terms, identify the potential financial exposure, and affirm that VMS is managing the situation in accordance with its contractual rights. The notification should be transmitted promptly — ideally within one week of the date of this memorandum.
5. Institute document preservation protocols. VMS should implement formal document preservation protocols for all Project Argonaut integration records, milestone completion documentation, internal engineering logs, and communications with MeridianCode personnel. Key MeridianCode contacts whose communications should be preserved include Gregory L. Fisk (MeridianCode Integration Lead), Diana Cho (MeridianCode Project Manager), and Priya Ramaswamy (General Counsel). VMS should also preserve all Board of Directors minutes and resolutions related to the Project Argonaut rescoping, all communications with Kestrel Capital Partners regarding the capital expenditure reduction directive, and all internal VMS memoranda and analyses regarding the suspension of integration work. These records may be relevant in the event of future arbitration or negotiation with MeridianCode.
B. Near-Term Strategic Considerations
In addition to the immediate actions described above, we recommend that VMS pursue the following near-term strategic steps:
1. Calendar critical deadlines. VMS should calendar the following dates and establish internal monitoring procedures to ensure that no deadline is missed:
• 12-month dormancy cap deadline: anticipated August 3, 2024 (dependent on MeridianCode acknowledgment date)
• Section 9.1 24-month fee-forfeiture threshold: June 21, 2024
• Section 4.3 Use-It-or-Lose-It deadline: December 21, 2023 (if not tolled by dormancy)
• MESLSA expiration: June 20, 2027
2. Begin preparing for reactivation or structured renegotiation. Well before the 12-month dormancy cap expires, VMS should evaluate its strategic options and develop a plan for either reactivation (resuming integration work on Argonaut-A and Argonaut-C), structured renegotiation (amending the MESLSA to reflect the reduced scope of the program and to restructure fees accordingly), or managed termination (exerci

PRIVILEGED AND CONFIDENTIAL — ATTORNEY-CLIENT COMMUNICATION

MEMORANDUM

Record

Parties

Dates

Amounts