derivative-works-ownership-memo.docx

1007-00008 · Vantage Mobility Systems Corp · Memoranda

derivative-works-ownership-memo.docx DOCUMENT IP / Technology

17 / 35 ← → ✕

PRIVILEGED AND CONFIDENTIAL — ATTORNEY-CLIENT PRIVILEGE / ATTORNEY WORK PRODUCT This memorandum is protected from disclosure by the attorney-client privilege and the work product doctrine. It is intended solely for the use of the addressees and authorized personnel of Vantage Mobility Systems Corp. Any unauthorized review, dissemination, distribution, or copying of this memorandum is strictly prohibited.

CALDERWOOD & HARKNESS LLP Attorneys at Law 600 Renaissance Center, Suite 3200 Detroit, MI 48243 Telephone: (313) 555-2800 Facsimile: (313) 555-2801

MEMORANDUM

Matter No.: 1007-00008

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

From: Gabrielle Moss, Lead Associate Aaron Liu, Working Associate

Date: September 15, 2023

Re: Derivative Works Ownership Dispute — Analysis of Section 7.2 of the Master Embedded Software License and Services Agreement dated June 21, 2022, between Vantage Mobility Systems Corp. and Meridian Code Technologies, Inc.; Applicable Michigan intellectual Property Law

Client: Vantage Mobility Systems Corp. ("VMS")

Counterparty: Meridian Code Technologies, Inc. ("MeridianCode") (Nasdaq: MCDT)

Right-click to update Table of Contents

I. Executive Summary

This memorandum addresses a dispute between our client, Vantage Mobility Systems Corp. ("VMS"), and Meridian Code Technologies, Inc. ("MeridianCode"), concerning the ownership and exploitation rights in three derivative work software modules — designated DW-001, DW-002, and DW-003 — comprising approximately 47,000 lines of code. These modules were created by VMS software engineers during the integration of MeridianCode's ATLAS-RT™ embedded real-time operating system ("RTOS") (Version 4.2, subsequently updated to Version 4.2.3) into VMS's Project Argonaut adaptive vehicle platforms. The dispute arises under Section 7.2 of the Master Embedded Software License and Services Agreement dated June 21, 2022 (the "MESLSA"), between VMS and MeridianCode.

An independent assessment conducted by Hargrove Technical Consulting, LLC — under the direction of lead consultant Dr. Samuel Beecroft, Ph.D. (Embedded Systems) — estimates the commercial value of the three derivative work modules at between $1,800,000 and $2,500,000. The derivative works at issue are integral to the proprietary adaptive vehicle platform architecture that VMS has developed as part of Project Argonaut and represent a significant investment of VMS engineering resources.

VMS's Position. VMS, through its General Counsel, Martin G. Cross, and through this firm, maintains that the derivative works are solely VMS-originated intellectual property. VMS engineers independently conceived, designed, coded, and tested the modules using VMS resources, VMS proprietary know-how regarding adaptive vehicle systems, and VMS hardware specifications. VMS contends that the mere fact that these modules interact with and extend the ATLAS-RT embedded RTOS does not transform them into "jointly owned" works under Section 7.2 of the MESLSA, and that Section 7.2 should be narrowly construed.

MeridianCode's Position. MeridianCode, through its General Counsel, Priya Ramaswamy, and through its outside counsel at Redstone Whitaker LLP (Alan M. Briscoe, Lead Partner, and Natasha C. Ferraro, Senior Associate), asserts that Section 7.2 of the MESLSA plainly provides that "any modifications, adaptations, or extensions to ATLAS-RT source code created by [Licensee's] engineers during integration become jointly owned," and that MeridianCode retains a perpetual, royalty-free license to such derivative works. MeridianCode contends that all three modules fall squarely within this provision.

Redstone Whitaker LLP communicated MeridianCode's position in a letter dated August 28, 2023, directed to this firm, asserting joint ownership of all three derivative work modules and demanding that VMS acknowledge MeridianCode's rights thereunder. A response is expected by October 13, 2023.

This memorandum analyzes the relevant contractual provisions, applicable Michigan intellectual property law, federal copyright principles, and the strategic implications of the dispute. Based on our analysis, we conclude as follows:

1. VMS has colorable but not dispositive arguments for sole ownership of the derivative works, particularly with respect to modules DW-002 and DW-003, which exhibit varying degrees of separability from the ATLAS-RT source code.

2. MeridianCode has the stronger textual argument under Section 7.2 as applied to DW-001, which is deeply intertwined with the ATLAS-RT kernel and most naturally characterized as a "modification" of ATLAS-RT source code.

3. The dispute is not well-suited to an all-or-nothing resolution, and VMS's interests are best served by pursuing a negotiated, module-by-module carve-out as part of the broader dormancy extension and fee restructuring discussions currently underway with MeridianCode.

4. We recommend that VMS adopt a differentiated negotiating posture — conceding joint ownership with limitations on DW-001, asserting sole ownership with a limited license-back on DW-002, and asserting sole ownership with no license-back on DW-003 — while preserving a credible arbitration threat to maintain leverage.

The sections below set forth the detailed factual background, contractual analysis, legal analysis, technical assessment, strategic considerations, and specific recommendations supporting these conclusions.

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 MeridianCode's licensing of its ATLAS-RT™ embedded real-time operating system to VMS for integration into VMS's next-generation adaptive vehicle platforms. The total deal value of the MESLSA is approximately $20,000,000, inclusive of upfront license fees, maintenance and support fees, integration services fees, and per-unit runtime royalties.

The Licensed Product under the MESLSA is MeridianCode's ATLAS-RT™ embedded RTOS, initially licensed at Version 4.2. During the course of the integration engagement, MeridianCode released a maintenance update to Version 4.2.3, which was deployed by VMS in January 2023 pursuant to the update provisions of the MESLSA.

The license scope is perpetual in nature, subject to the terms of a five-year initial term running from June 21, 2022 through June 20, 2027. Under the license grant, VMS is authorized to integrate ATLAS-RT into up to five designated vehicle platform configurations under VMS's internal development program known as "Project Argonaut." These platform configurations are designated Argonaut-A through Argonaut-E and encompass a range of adaptive vehicle architectures spanning passenger vehicle, light commercial vehicle, and specialty mobility platforms.

Vantage Mobility Systems Corp. VMS is a Delaware corporation headquartered at 4100 Industrial Parkway, Sterling Heights, Michigan 48312. VMS is a portfolio company of Kestrel Capital Partners, LP, which acquired VMS in 2019 in a leveraged buyout valued at approximately $380 million. For the fiscal year ending December 31, 2022, VMS reported revenue of approximately $485 million, EBITDA of approximately $61 million, and employed approximately 2,200 personnel, including a software engineering division of approximately 140 engineers. VMS designs, manufactures, and distributes adaptive vehicle systems, including modified vehicle platforms for mobility-impaired individuals and commercial fleet operators requiring specialized vehicle configurations. Project Argonaut represents VMS's strategic initiative to integrate embedded RTOS technology into its adaptive vehicle platforms to enable real-time adaptive control, enhanced telemetry, and next-generation diagnostic capabilities.

Meridian Code Technologies, Inc. MeridianCode is a California corporation headquartered at 2750 Orchard Blvd., Suite 400, Santa Clara, California 95054. MeridianCode is publicly traded on the Nasdaq Global Market under the ticker symbol MCDT. For the fiscal year ending December 31, 2022, MeridianCode reported revenue of approximately $310 million and employed approximately 1,400 personnel. MeridianCode is a leading provider of embedded operating systems and middleware solutions for the automotive, industrial, and IoT sectors, with its ATLAS-RT platform commanding a significant share of the automotive-grade RTOS market.

Project Argonaut Rescoping. On March 14, 2023, the VMS Board of Directors adopted a resolution rescoping Project Argonaut from five vehicle platform configurations (Argonaut-A through Argonaut-E) to two (Argonaut-A and Argonaut-C only). The board resolution reflected a strategic decision to defer the electrification integration components of Argonaut-B, Argonaut-D, and Argonaut-E to a subsequent Phase II development cycle, driven by a combination of capital allocation constraints identified by Kestrel Capital Partners and delays in the availability of next-generation electrification hardware from VMS's Tier 1 suppliers. Integration work on all Argonaut platforms was suspended effective March 22, 2023.

Dormancy Status. Following the suspension of integration work, VMS exercised its right under Section 9.4 of the MESLSA to place the license in Dormancy Status. VMS's dormancy notice was transmitted to MeridianCode on July 14, 2023 — six days before the 120-day trigger date of July 20, 2023 (calculated from the March 22, 2023 suspension date), by which VMS was required under Section 9.4 to either reactivate the integration engagement or invoke Dormancy Status. MeridianCode acknowledged receipt of the dormancy notice on August 3, 2023. Under Section 9.4, Dormancy Status extends for a maximum of twelve months from the date of the licensor's acknowledgment (i.e., through August 3, 2024), after which the parties are required to engage in mandatory renegotiation of the integration timeline, fee structure, and scope of licensed platforms.

B. The Derivative Works at Issue

During the active integration phase of Project Argonaut, which ran from the execution of the MESLSA on June 21, 2022 through the suspension of integration work on March 22, 2023 — a period of approximately nine months — VMS software engineers created three discrete software modules that are the subject of the present dispute. These modules are designated DW-001, DW-002, and DW-003 in accordance with the internal naming conventions established under the MESLSA's Exhibit C derivative works documentation procedures.

The VMS engineering team responsible for developing these modules operated under the direction of Lena Petrova, Director of Software Integration Engineering within VMS's Advanced Technology Division. Ms. Petrova reported to Dennis J. Whitfield, VMS's Chief Technology Officer, who served as the executive sponsor for Project Argonaut. The integration team comprised a core group of twelve senior software engineers, supplemented by four junior engineers and three quality assurance specialists, all of whom were full-time employees of VMS.

The three modules were created as modifications, adaptations, and extensions to the ATLAS-RT source code to enable integration with VMS's proprietary adaptive vehicle platform architecture. The modules collectively comprise approximately 47,000 lines of code, representing a substantial body of software engineering work. VMS invested approximately 14,200 engineering hours across its internal teams on Project Argonaut overall, a significant but not precisely quantified portion of which was dedicated specifically to developing these derivative work modules. Based on VMS's fully loaded engineering cost rate of approximately $145 per hour, the internal labor investment in the derivative works is estimated at between $900,000 and $1,200,000, exclusive of overhead, management time, and opportunity costs.

An independent assessment of the derivative works was commissioned by this firm and performed by Hargrove Technical Consulting, LLC, of McLean, Virginia, under the direction of Dr. Samuel Beecroft, Ph.D. (Embedded Systems). Dr. Beecroft's assessment, delivered in draft form on September 1, 2023, estimates the commercial value of the three derivative work modules at between $1,800,000 and $2,500,000. This valuation reflects the estimated replacement cost of the engineering effort, the commercial utility of the modules in adaptive vehicle applications, and the potential licensing value of the intellectual property embodied in the modules.

C. Integration Status at Time of Suspension

At the time integration work was suspended on March 22, 2023, the five Project Argonaut vehicle platforms had reached the following integration milestones under the milestone-based integration services schedule set forth in Exhibit B to the MESLSA:

Argonaut-A: Milestone 3 of 5 completed. Alpha integration testing was passed on February 28, 2023, representing the successful completion of initial source-code integration, hardware interface validation, and first-phase functional testing. Argonaut-A was the most advanced platform and the primary focus of VMS's integration engineering resources during the active integration phase.

Argonaut-C: Milestone 2 of 5 completed. Source-code customization was delivered on January 15, 2023, representing the completion of the requirements specification, initial code baseline establishment, and platform-specific customization of the ATLAS-RT configuration parameters. Argonaut-C was the secondary focus of integration effort during the active phase.

Argonaut-B: Milestone 1 only. The requirements specification was approved on November 30, 2022, but no code integration work had commenced on the Argonaut-B platform prior to the suspension. Argonaut-B was subsequently deferred to Phase II as part of the board-level rescoping decision.

Argonaut-D and Argonaut-E: Not commenced. No integration work of any kind had been initiated on these platforms prior to suspension. Both were deferred to Phase II.

Integration Services Fees paid by VMS through Milestone 3 totaled $1,920,000 of the $3,200,000 total Integration Services budget established under Exhibit B. The remaining $1,280,000 corresponds to Milestones 4 and 5 (beta integration testing and production release certification) for the active platforms.

D. Parties' Competing Positions

The parties' competing positions on the ownership of the derivative works have been communicated through a series of formal correspondences between counsel, as summarized below.

VMS Position. VMS's position has been articulated by Martin G. Cross, General Counsel of VMS, in internal correspondence, and has been further developed by this firm in communications with MeridianCode's outside counsel. VMS maintains that DW-001, DW-002, and DW-003 represent independently originated VMS intellectual property. The core of VMS's position is as follows:

(a) VMS engineers conceived, designed, coded, and tested these modules using VMS resources, VMS proprietary know-how regarding adaptive vehicle systems, and VMS hardware specifications. The creative and engineering contributions embodied in the modules are attributable solely to VMS personnel working within the scope of their employment at VMS.

(b) The fact that these modules interact with and extend the ATLAS-RT embedded RTOS does not transform them into "jointly owned" works under the MESLSA. Any software application that interfaces with an operating system necessarily interacts with that OS at some level; this does not make every application a "modification, adaptation, or extension" of the operating system's source code.

(c) Section 7.2 of the MESLSA should be narrowly construed in accordance with Michigan contract interpretation principles, which disfavor broad transfers of intellectual property rights. The provision was intended to capture modifications to the ATLAS-RT codebase itself — changes to the kernel, scheduler, and core OS libraries — and not every piece of application-level software that a licensee might develop during the integration period.

(d) Certain of the derivative work modules, particularly DW-003, have independent functional utility that is separable from ATLAS-RT and could be adapted to operate on alternative RTOS platforms. These works are more properly characterized as independent, separable works of authorship rather than derivative works of ATLAS-RT.

MeridianCode Position. MeridianCode's position has been articulated by Priya Ramaswamy, General Counsel of MeridianCode, and communicated formally through MeridianCode's outside counsel at Redstone Whitaker LLP. Alan M. Briscoe, Lead Partner, and Natasha C. Ferraro, Senior Associate, transmitted MeridianCode's position to this firm in a letter dated August 28, 2023. MeridianCode's position is as follows:

(a) Section 7.2 of the MESLSA plainly and unambiguously provides that "any modifications, adaptations, or extensions to ATLAS-RT source code created by [Licensee's] engineers during integration become jointly owned," and that MeridianCode "retains a perpetual, royalty-free license to such derivative works."

(b) The three derivative work modules are, by their nature and function, modifications, adaptations, and extensions of the ATLAS-RT source code. Each module was created for the express purpose of adapting and extending ATLAS-RT to function within VMS's adaptive vehicle platform architecture. The modules directly modify ATLAS-RT scheduling algorithms, interface with ATLAS-RT kernel functions, and rely on ATLAS-RT APIs and libraries for their operation.

(c) The phrase "during integration" is a temporal marker identifying the period during which such works are created, and it plainly captures all modules created by VMS engineers that modify, adapt, or extend the ATLAS-RT source code during the active integration phase. There is no basis for reading a causal or purposive limitation into this language.

(d) MeridianCode contributed the ATLAS-RT source code, documentation, technical support, and integration guidance that formed the foundation upon which VMS's derivative works were built. The joint-ownership provision in Section 7.2 reflects the parties' negotiated allocation of rights in recognition of both parties' contributions to the integrated product.

III. Contractual Analysis — Section 7.2 of the MESLSA

A. Text of Section 7.2

The operative language of Section 7.2 of the MESLSA, titled "Derivative Works; Ownership and License-Back," provides in relevant part:

"7.2 Derivative Works. Any modifications, adaptations, or extensions to ATLAS-RT source code created by Licensee's engineers during the Integration Period (as defined in Exhibit B) shall be deemed jointly owned by Licensor and Licensee ('Derivative Works'). Notwithstanding the foregoing joint ownership, Licensor shall retain, and Licensee hereby grants to Licensor, a perpetual, irrevocable, worldwide, royalty-free, fully paid-up, non-exclusive license, with the right to sublicense through multiple tiers, to use, reproduce, modify, create derivative works of, distribute, display, and otherwise exploit such Derivative Works for any purpose, subject to the limitations set forth in Exhibit C. The parties shall cooperate in good faith to identify, document, and disclose all Derivative Works in accordance with the procedures set forth in Exhibit C."

Several features of this language merit attention. First, the provision uses the disjunctive "modifications, adaptations, or extensions," capturing three distinct categories of derivative works. Second, the triggering condition is that the works be "created by Licensee's engineers during the Integration Period," incorporating both an authorship requirement (Licensee's engineers) and a temporal limitation (the Integration Period). Third, the provision creates a joint-ownership framework combined with a broad license-back in favor of MeridianCode as Licensor. Fourth, the license-back is described in expansive terms: perpetual, irrevocable, worldwide, royalty-free, fully paid-up, non-exclusive, with sublicensing rights through multiple tiers, for "any purpose" — subject only to the limitations in Exhibit C.

Exhibit C to the MESLSA, titled "Derivative Works Ownership and License-Back Terms," further elaborates on Section 7.2. Exhibit C provides the contractual definition of "Derivative Work," specifies the identification, documentation, and disclosure procedures applicable to derivative works, and details the scope and limitations of MeridianCode's license-back right. We analyze the key provisions of Exhibit C in the sections below.

B. Definition of "Derivative Work" Under the MESLSA

Exhibit C, Section 1(a) of the MESLSA defines "Derivative Work" as follows:

"any work that is based upon, incorporates, modifies, adapts, extends, translates, abridges, condenses, or otherwise recasts, transforms, or adapts ATLAS-RT Source Code, ATLAS-RT object code, or ATLAS-RT documentation, in whole or in part, including without limitation any software module, library, algorithm, data structure, or interface specification that constitutes a modification, adaptation, or extension of ATLAS-RT Source Code within the meaning of Section 7.2."

This definition is notably broad. It encompasses not only modifications to the ATLAS-RT source code itself but also works that "incorporate" or are "based upon" ATLAS-RT source code, object code, or documentation. The enumeration of specific categories — "software module, library, algorithm, data structure, or interface specification" — further broadens the potential scope to include a wide range of engineering outputs.

Applying this definition to the three derivative work modules at issue requires a careful analysis of the nature and degree of each module's relationship to the ATLAS-RT codebase. We distinguish among three categories of derivative work activity:

(i) Modifications to existing ATLAS-RT source code. A modification involves direct alteration of the pre-existing ATLAS-RT source code — changing existing functions, algorithms, parameters, or data structures within the ATLAS-RT codebase. A modification in this sense results in a changed version of the underlying ATLAS-RT code.

(ii) Adaptations that reconfigure ATLAS-RT functionality. An adaptation involves reconfiguring or redeploying existing ATLAS-RT functionality for a new purpose or in a new context without necessarily altering the underlying source code. This may include configuration changes, parameter adjustments, or the selection and combination of existing ATLAS-RT modules for a platform-specific deployment.

(iii) Extensions that add new functionality built on top of ATLAS-RT APIs or libraries. An extension involves the creation of new code that adds functionality not present in the original ATLAS-RT distribution, building upon ATLAS-RT's application programming interfaces, libraries, or kernel services. Extensions may range from tightly coupled modules that directly invoke ATLAS-RT kernel functions to loosely coupled application-layer modules that interface with ATLAS-RT through standard, abstracted API calls.

As we discuss in Section V below, the three derivative work modules (DW-001, DW-002, and DW-003) represent different points on this spectrum. Not all three modules equally constitute "modifications, adaptations, or extensions to ATLAS-RT source code" within the meaning of Section 7.2 and the Exhibit C definition. VMS's strongest argument lies in contending that certain modules — particularly DW-003 — fall outside the contractual definition because they constitute independent, application-level works that merely interface with ATLAS-RT through standard APIs rather than modifying, adapting, or extending the ATLAS-RT source code.

However, we must acknowledge that the breadth of the Exhibit C definition, which captures works that "incorporate" or are "based upon" ATLAS-RT source code and expressly includes "interface specification[s]," significantly undermines this argument. The definition was drafted to be inclusive rather than restrictive, and a plain-text reading suggests that any software module that interacts with ATLAS-RT at the source-code level could potentially be captured.

C. "Created During Integration" — Temporal and Causal Scope

A critical interpretive question is whether the phrase "created by Licensee's engineers during the Integration Period" in Section 7.2 imposes a purely temporal limitation or whether it implies a causal or purposive requirement.

Temporal interpretation. Under a purely temporal reading, Section 7.2 captures any code that (a) constitutes a modification, adaptation, or extension of ATLAS-RT source code, and (b) was created by VMS engineers at any time during the Integration Period (defined in Exhibit B as the period commencing on the MESLSA effective date and continuing through the completion of all integration milestones or the earlier suspension or termination of integration services). Under this reading, the provision functions as a broad temporal net: any qualifying derivative work created during the defined period is subject to joint ownership, regardless of the specific purpose for which it was created.

Causal/purposive interpretation. Under a causal or purposive reading, Section 7.2 captures only code that was created for the purpose of integrating ATLAS-RT into VMS's vehicle platforms — that is, code whose creation was causally linked to the integration engagement. Under this reading, code that was written contemporaneously with the integration period but that serves VMS's broader adaptive vehicle platform architecture, and that has independent utility apart from the ATLAS-RT integration, would not be captured.

VMS's argument favors the causal/purposive interpretation. VMS contends that certain modules — particularly DW-002 (the hardware abstraction layer) and DW-003 (the diagnostic and telemetry module) — were conceived and developed to serve VMS's broader product architecture and have independent utility that extends well beyond the ATLAS-RT integration. Under VMS's view, the fact that these modules were created during the same timeframe as the ATLAS-RT integration is a coincidence of timing rather than an indication that the modules are derivative works of ATLAS-RT.

MeridianCode's argument favors the temporal interpretation. MeridianCode contends that the plain language of Section 7.2 refers to works "created ... during the Integration Period" without any qualifier suggesting a causal nexus. MeridianCode argues that the parties could have included language such as "created for the purpose of" or "created in connection with" the integration if they had intended a causal limitation, and that their failure to do so reflects a deliberate choice to adopt a temporal framework.

As a matter of Michigan contract interpretation, MeridianCode's temporal reading has the stronger textual foundation. The phrase "during the Integration Period" most naturally reads as a temporal marker. However, VMS can argue that the phrase "modifications, adaptations, or extensions to ATLAS-RT source code" itself imposes a substantive limitation that narrows the scope of the provision regardless of the temporal question — a module that does not modify, adapt, or extend ATLAS-RT source code is not captured by Section 7.2 even if it was created during the Integration Period.

D. Joint Ownership — Implications Under the MESLSA

Section 7.2 provides that qualifying derivative works "shall be deemed jointly owned by Licensor and Licensee." The MESLSA does not, however, define the specific rights and obligations of the parties as joint owners beyond the specification of MeridianCode's license-back right. Exhibit C elaborates on the license-back but does not address the broader framework of joint-ownership rights, including:

(a) Whether either party may independently license the jointly owned works to third parties without the consent of the other party;

(b) Whether either party has an obligation to account to the other for profits derived from exploitation of the jointly owned works;

(c) Whether either party may create further derivative works of the jointly owned works without the consent of the other party;

(d) How the jointly owned works are to be maintained, updated, and supported, and which party bears responsibility for such activities; and

(e) How disputes regarding the exploitation of the jointly owned works are to be resolved.

Absent further contractual specification on these points, the rights and obligations of joint owners default to applicable law. As discussed in Section IV below, the applicable legal frameworks — Michigan contract law and federal copyright law — provide different default rules for joint ownership, and the interaction between these frameworks creates additional complexity.

Of particular concern to VMS is the default rule under federal copyright law that joint owners of a copyrighted work may each independently exploit the work without the consent of the other, subject only to an obligation to account for profits. See 17 U.S.C. § 201(a); Thomson v. Larson, 147 F.3d 195, 199 (2d Cir. 1998). If the derivative works are deemed jointly owned, MeridianCode could — absent a contractual restriction — independently license the derivative works to VMS's competitors in the adaptive vehicle market. The license-back provision in Section 7.2 exacerbates this concern by expressly granting MeridianCode broad exploitation rights, including the right to sublicense "through multiple tiers" for "any purpose." The "any purpose" language is particularly problematic because it does not restrict MeridianCode's use to non-competitive applications.

E. Perpetual Royalty-Free License-Back

Even if VMS were to prevail on its argument for sole ownership of the derivative works, Section 7.2 purports to grant MeridianCode a perpetual, irrevocable, worldwide, royalty-free, fully paid-up, non-exclusive license to use, reproduce, modify, create derivative works of, distribute, display, and otherwise exploit the derivative works, with sublicensing rights through multiple tiers, for any purpose. This license-back is a significant encumbrance on VMS's intellectual property rights, regardless of whether VMS achieves sole ownership.

A critical question is whether MeridianCode's license-back survives termination or expiration of the MESLSA. Section 14.3 of the MESLSA (Survival) provides:

"14.3 Survival. The following provisions shall survive any termination or expiration of this Agreement: Sections 5 (Confidentiality), 7 (Intellectual Property), 8 (Representations and Warranties, solely with respect to Sections 8.1 through 8.4), 10 (Indemnification), 11 (Limitation of Liability), 12 (Dispute Resolution), 13 (Governing Law), and 14 (General Provisions)."

Because Section 7 (Intellectual Property), which includes Section 7.2, is expressly enumerated as a surviving provision, MeridianCode's license-back appears to persist beyond any termination or expiration of the MESLSA. This significantly affects VMS's negotiating position: even if VMS terminates the MESLSA or allows it to lapse during the dormancy period, MeridianCode's license-back rights in the derivative works would continue in perpetuity.

VMS might argue that the survival of Section 7 should be limited to the intellectual property ownership provisions (i.e., confirming who owns what after termination) and should not be read to perpetuate an ongoing license grant that was ancillary to the operative licensing relationship. However, this argument confronts the plain language of Section 14.3, which enumerates Section 7 without qualification or limitation. Michigan courts applying the plain-meaning rule would likely enforce the survival clause as written.

The practical implication is that VMS cannot use termination or lapse of the MESLSA as a mechanism to eliminate MeridianCode's license-back rights. Any modification of MeridianCode's license-back must be achieved through negotiation and formal amendment.

F. Preliminary Contract Interpretation Conclusions

Based on the foregoing analysis, we reach the following preliminary conclusions regarding the contractual framework:

First, under the plain text of Section 7.2 and the Exhibit C definition of "Derivative Work," MeridianCode has a strong textual argument that the derivative works fall within the joint-ownership provision. The language is broad, the definition is inclusive, and the temporal trigger ("during the Integration Period") encompasses the period in which all three modules were created.

Second, VMS's best contractual arguments are:

(i) Narrow construction of "modifications, adaptations, or extensions to ATLAS-RT source code." VMS can argue that this phrase should be limited to works that directly alter, reconfigure, or build upon the ATLAS-RT source code — the kernel, scheduler, core libraries, and OS-level components — and should not extend to application-level modules that merely interface with ATLAS-RT through standard API calls. Under this construction, modules with independent functional utility that could operate on alternative RTOS platforms are not "modifications, adaptations, or extensions" of ATLAS-RT source code.

(ii) Characterization of certain modules as interoperability layers or independent applications. VMS can argue that DW-002 (the hardware abstraction layer) and DW-003 (the diagnostic and telemetry module) are more properly characterized as independent, separable works that interface with ATLAS-RT rather than derivative works of ATLAS-RT. This argument draws support from the technical separability analysis in the Hargrove report (discussed in Section V below).

(iii) Challenge to the breadth of "during integration" as a temporal catch-all. VMS can argue that the phrase "during integration" should be read with a purposive limitation — requiring a causal connection between the integration engagement and the creation of the derivative work — rather than as an unrestricted temporal net.

Third, the strength of these arguments varies by module: VMS has the weakest argument for DW-001 (which directly modifies ATLAS-RT scheduling algorithms), a moderate argument for DW-002 (which could be characterized as either an extension of ATLAS-RT or an independent interoperability layer), and the strongest argument for DW-003 (which has substantial independent utility and interfaces with ATLAS-RT only through standard API calls).

Fourth, the license-back provision in Section 7.2 survives termination of the MESLSA, limiting VMS's ability to leverage termination as a strategy for eliminating MeridianCode's rights.

IV. Applicable Law — Michigan intellectual Property and Federal Copyright

A. Choice of Law — Michigan

Section 13.1 of the MESLSA contains a governing law provision selecting Michigan law as the law governing the interpretation and enforcement of the agreement. The provision reads:

"13.1 Governing Law. This Agreement shall be governed by and construed in accordance with the laws of the State of Michigan, without giving effect to any choice-of-law or conflict-of-law provisions or rules that would cause the application of the laws of any other jurisdiction."

Michigan law therefore governs the interpretation of Section 7.2 as a matter of contract. However, to the extent the derivative works dispute implicates federal copyright law — particularly questions of derivative work status, joint authorship, and ownership of copyrightable works — federal law applies under the Supremacy Clause. Federal copyright law, codified at 17 U.S.C. § 101 et seq., preempts certain state-law intellectual property claims (under the preemption provision of 17 U.S.C. § 301) but does not preempt contract-based claims regarding the allocation of ownership rights in copyrightable works. See ProCD, Inc. v. Zeidenberg, 86 F.3d 1447, 1454 (7th Cir. 1996); Architectronics, Inc. v. Control Sys., Inc., 935 F. Supp. 425, 439 (S.D.N.Y. 1996).

Accordingly, our analysis must address both: (a) Michigan contract interpretation principles as applied to the construction of Section 7.2, and (b) federal copyright law as it governs the threshold questions of derivative work status, joint authorship, and default ownership allocation, which inform the background against which the MESLSA was negotiated and should be interpreted.

B. Michigan Contract Interpretation Principles

Michigan follows the "plain meaning" rule for the interpretation of unambiguous contracts. Under this rule, if the language of a contract is clear and unambiguous, the court must enforce the contract as written and may not look beyond the four corners of the document to determine the parties' intent. Wilkie v. Auto-Owners Ins. Co., 469 Mich. 41, 51 (2003); Rory v. Continental Ins. Co., 473 Mich. 457, 468 (2005). Words and phrases are given their plain and ordinary meaning, and technical terms are given their technical meaning. Henderson v. State Farm Fire & Cas. Co., 460 Mich. 348, 354 (1999).

If a contract provision is ambiguous — that is, if it is reasonably susceptible to two or more interpretations — Michigan courts will consider extrinsic evidence of the parties' intent, including the circumstances surrounding the formation of the contract, the parties' course of dealing, and trade usage. Klapp v. United Ins. Grp. Agency, Inc., 468 Mich. 459, 469 (2003). Ambiguity is a question of law for the court. Id. at 468.

The question of whether Section 7.2 is ambiguous on the operative issues — specifically, what constitutes a "modification[], adaptation[], or extension[] to ATLAS-RT source code" and what is captured by the phrase "during the Integration Period" — is central to VMS's contractual arguments. If the court determines that Section 7.2 is unambiguous, MeridianCode's plain-text argument will likely prevail, and VMS will be unable to introduce extrinsic evidence regarding the parties' intent to narrow the scope of the provision. If, however, VMS can establish that Section 7.2 is ambiguous — for example, because the phrase "modifications, adaptations, or extensions to ATLAS-RT source code" is reasonably susceptible to both a broad interpretation (encompassing any software that interacts with ATLAS-RT) and a narrow interpretation (limited to direct modifications of the OS codebase) — VMS would be entitled to introduce extrinsic evidence in support of the narrower construction.

Critically, Michigan courts construe ambiguities in intellectual property assignments and licenses narrowly, in favor of the creator or grantor of the intellectual property. This principle reflects the Michigan courts' recognition that intellectual property rights are valuable assets that should not be presumed to have been conveyed absent clear and unambiguous language of conveyance. See Bliss v. Calhoun County, 262 Mich. 218, 222 (1933) (construing ambiguity in assignment in favor of assignor); cf. Cohen v. Paramount Pictures Corp., 845 F.2d 851, 854 (9th Cir. 1988) (noting the general principle that license grants are construed narrowly). This principle would support VMS's position that Section 7.2 should be narrowly construed, if the provision is determined to be ambiguous.

Additionally, Michigan courts apply the principle of contra proferentem — construing ambiguous provisions against the drafter — where the identity of the drafter is known. The MESLSA was drafted by MeridianCode's legal team (with input from both parties during negotiation), which would favor VMS in the event of ambiguity. However, the contra proferentem principle is typically reserved as a last resort and is less frequently applied in the context of negotiated commercial agreements between sophisticated parties. See Klapp, 468 Mich. at 471.

C. Federal Copyright Law — Derivative Works (17 U.S.C. § 103)

Under the Copyright Act, a "derivative work" is defined as:

"a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted."

17 U.S.C. § 101. A derivative work includes a work consisting of "editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship." Id.

Under 17 U.S.C. § 103(b), the copyright in a derivative work "extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work." The copyright in a derivative work is "independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material." Id.

Applying these principles to the present dispute: if VMS's modules constitute "derivative works" of ATLAS-RT within the meaning of the Copyright Act, VMS would own the copyright in the original expression contributed by its engineers — the new code, algorithms, and data structures created by VMS — but would not own any copyright in the underlying ATLAS-RT source code upon which the modules are built. MeridianCode would retain full ownership of the ATLAS-RT source code.

Importantly, a lawful licensee who creates a derivative work with the licensor's authorization — as VMS did here, under the express terms of the MESLSA — owns the copyright in the original expression contributed by the licensee, subject to any contractual provisions allocating ownership differently. See Stewart v. Abend, 495 U.S. 207, 223 (1990). The parties are free to contract around this default rule. Section 7.2 of the MESLSA purports to do exactly that: rather than allowing the default copyright rule to govern — under which VMS would own the copyright in its original contributions — the parties agreed to a joint-ownership framework with a license-back.

The question, therefore, is not whether VMS has a copyright interest in its original contributions (it does, under the default rule) but whether the contractual provision in Section 7.2 effectively reallocates that ownership to create a joint-ownership framework, and if so, which modules are captured by the provision.

D. Joint Authorship Under Federal Copyright Law (17 U.S.C. § 101)

Federal copyright law defines a "joint work" as "a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole." 17 U.S.C. § 101. Joint authors of a copyrighted work are co-owners of the copyright. 17 U.S.C. § 201(a).

The leading Sixth Circuit precedent on joint authorship — relevant because Michigan is within the Sixth Circuit — requires that each putative joint author (a) make independently copyrightable contributions to the work and (b) intend, at the time of creation, that the contributions be merged into inseparable or interdependent parts of a unitary whole. See Aalmuhammed v. Lee, 202 F.3d 1227, 1231 (9th Cir. 2000) (widely cited analysis); Childress v. Taylor, 945 F.2d 500, 505-08 (2d Cir. 1991) (establishing the intent requirement).

VMS could argue, as a factual matter, against a finding of joint authorship under these principles:

(a) Lack of intent to create a unitary whole. VMS engineers did not intend to merge their contributions with MeridianCode's ATLAS-RT into a single, unified work of joint authorship. The VMS modules were created as separate, identifiable software components designed to serve VMS's proprietary adaptive vehicle platform. While the modules interact with ATLAS-RT, VMS engineers did not conceive of the modules as inseparable parts of a unitary whole that would be jointly owned.

(b) Separability. The modules, particularly DW-002 and DW-003, are separable from the ATLAS-RT codebase. They can function independently of ATLAS-RT, or could be adapted with reasonable re-engineering effort to operate on alternative RTOS platforms. This separability weighs against a finding that the works are "inseparable or interdependent parts of a unitary whole."

(c) Absence of MeridianCode creative contribution to VMS modules. MeridianCode did not contribute original expression to the VMS modules. MeridianCode provided the ATLAS-RT platform and documentation, but the creative and engineering work embodied in DW-001, DW-002, and DW-003 was performed exclusively by VMS engineers. The provision of an underlying platform upon which derivative works are built does not make the platform owner a joint author of the derivative works.

However, the practical significance of this federal joint-authorship analysis is limited by the fact that Section 7.2 of the MESLSA contractually allocates joint ownership. As noted above, parties are free to contract around the default copyright ownership rules, and a contractual joint-ownership provision may supersede the factual joint-authorship analysis. If Section 7.2 applies to the derivative works, the contractual allocation controls regardless of whether MeridianCode would qualify as a joint author under federal copyright law.

The federal joint-authorship analysis remains relevant, however, to the extent VMS argues that Section 7.2 should be narrowly construed to avoid a result that contravenes the copyright default — i.e., that the parties should not be presumed to have intended an outcome (joint ownership of VMS-authored works by a non-authoring party) that departs from the background copyright principles without clear and specific language to that effect. This argument draws on the canon of construction that contracts should be interpreted, where possible, consistently with applicable default legal rules.

E. Michigan Law on IP Ownership in Employment/Contractor Context

VMS's software engineers who created the derivative work modules are full-time employees of VMS. Under the work-made-for-hire doctrine codified at 17 U.S.C. § 201(b), a work "prepared by an employee within the scope of his or her employment" is a "work made for hire," and "the employer ... is considered the author" and "owns all of the rights comprised in the copyright." The modules at issue were indisputably created by VMS employees within the scope of their employment — under the direction of VMS management (Lena Petrova and Dennis J. Whitfield), using VMS resources and equipment, during regular working hours, as part of their assigned duties on Project Argonaut.

Michigan does not have a specific statutory overlay that modifies the federal work-made-for-hire doctrine in the context of software development. Michigan has adopted the Uniform Trade Secrets Act (Michigan Compiled Laws § 445.1901 et seq.), which protects trade secrets including proprietary software, but this statute addresses misappropriation claims rather than ownership allocation. Michigan common law does not impose any additional requirements for employer ownership of employee-created intellectual property beyond those established by federal copyright law.

The issue in this dispute is therefore not whether VMS or its employees own the derivative works — VMS clearly owns them as works made for hire — but whether VMS's contractual agreement with MeridianCode, specifically Section 7.2 of the MESLSA, effectively conveys a co-ownership interest in VMS's employee-created works to MeridianCode, a third-party licensor.

VMS can argue that Section 7.2 should be narrowly construed to avoid an interpretation that automatically conveys ownership of employee works-for-hire to a third-party licensor. This argument rests on the principle that intellectual property ownership transfers should be construed strictly in favor of the owner/creator, and that a provision that effectively transfers half of VMS's ownership in works created by VMS employees should not be read more broadly than its plain terms require. While this argument does not invalidate Section 7.2 — the parties are clearly free to contract for such an arrangement — it supports a narrow interpretation of what constitutes a "modification[], adaptation[], or extension[] to ATLAS-RT source code" so as to minimize the scope of works captured by the joint-ownership provision.

F. Unconscionability and Public Policy Arguments

We have considered whether the breadth of Section 7.2 — which captures "any modifications, adaptations, or extensions to ATLAS-RT source code" created "during the Integration Period," with a perpetual, irrevocable, worldwide, royalty-free license-back for "any purpose" — could be challenged as unconscionable or contrary to Michigan public policy.

We conclude that such arguments are unlikely to succeed and should not be advanced as primary arguments. Michigan courts apply the unconscionability doctrine only in exceptional circumstances, and the doctrine requires a showing of both procedural unconscionability (unfairness in the bargaining process) and substantive unconscionability (unreasonably one-sided terms). Clark v. DaimlerChrysler Corp., 268 Mich. App. 138, 143 (2005).

Here, procedural unconscionability is virtually impossible to establish. VMS is a sophisticated commercial party with annual revenues of approximately $485 million, represented by experienced legal counsel. Calderwood & Harkness LLP reviewed the MESLSA prior to execution, as documented in the Preliminary Contract Review Memorandum dated June 14, 2022 (prepared by this firm, authored by senior associate Daniel R. Howell, reviewed by Bernard Crawford). That memorandum specifically identified the derivative works provisions of Section 7.2 and Exhibit C as a risk area and recommended that VMS negotiate for a narrower definition of "Derivative Work," a carve-out for application-level software with independent utility, and restrictions on MeridianCode's license-back to non-competitive applications. VMS's management, after consultation with Kestrel Capital Partners, elected to accept the terms of Section 7.2 as drafted, in the interest of closing the MESLSA transaction within the board-mandated timeline.

In light of this history, VMS cannot credibly claim that it was unaware of the risks posed by Section 7.2 or that it lacked the sophistication or bargaining power to negotiate different terms. An unconscionability challenge would likely be viewed by the arbitral panel as inconsistent with VMS's status as a sophisticated, counseled party that accepted the provision with full knowledge of its implications.

Public policy arguments are similarly weak. Michigan does not have a statutory prohibition against contractual provisions allocating joint ownership of derivative works created during a licensing engagement. While the breadth of the license-back is significant, it does not violate any recognized Michigan public policy.

We recommend that unconscionability and public policy arguments be held in reserve as secondary or fallback positions rather than featured as primary arguments in any submission.

V. Technical Assessment — Hargrove Technical Consulting Report

A. Scope of Engagement

Hargrove Technical Consulting, LLC, based in McLean, Virginia, was retained by Calderwood & Harkness LLP in July 2023 to perform an independent technical assessment of the ATLAS-RT integration work performed under Project Argonaut and the nature of the three derivative work modules (DW-001, DW-002, and DW-003). The engagement was structured under an expert consulting arrangement with Calderwood & Harkness as the retaining party, with all communications and work product protected by the attorney-client privilege and work product doctrine.

The lead consultant on the engagement is Dr. Samuel Beecroft, Ph.D. (Embedded Systems), a recognized authority in embedded RTOS architecture with over twenty years of experience in the automotive and aerospace embedded systems sectors. Dr. Beecroft holds a Ph.D. in Electrical Engineering and Computer Science from the University of Michigan (2001) and has served as an expert consultant in numerous software IP disputes involving embedded systems technology.

Hargrove's scope of work encompassed the following tasks:

(a) Review and analysis of the ATLAS-RT Version 4.2 and 4.2.3 source code, architecture documentation, and API specifications provided by MeridianCode under the MESLSA;

(b) Review and analysis of the source code, design documentation, and engineering records for DW-001, DW-002, and DW-003 provided by VMS;

(c) Assessment of the technical relationship between each derivative work module and the ATLAS-RT source code, including the degree of coupling, dependency, and interoperability;

(d) Evaluation of whether each module constitutes a modification, adaptation, or extension of the ATLAS-RT source code or an independent, separable work;

(e) Assessment of the separability of each module from the ATLAS-RT codebase — i.e., whether each module can function independently of ATLAS-RT or could be adapted to operate on alternative RTOS platforms with reasonable re-engineering effort; and

(f) Estimation of the commercial value of each module, both individually and in the aggregate.

Dr. Beecroft delivered his draft assessment to this firm on September 1, 2023. A final assessment incorporating additional VMS engineering documentation is expected by October 1, 2023.

B. Key Findings

Dr. Beecroft's assessment contains detailed technical findings for each of the three derivative work modules. The key findings are summarized below.

DW-001: ATLAS-RT Adaptive Scheduling Module. DW-001 is a software module that modifies the core scheduling algorithms within the ATLAS-RT kernel to enable adaptive vehicle real-time control. Specifically, DW-001 replaces portions of the ATLAS-RT priority-based preemptive scheduler with a custom adaptive scheduling algorithm developed by VMS engineers, which dynamically adjusts task priorities and scheduling parameters in response to real-time sensor inputs from VMS's adaptive vehicle control hardware. The module comprises approximately 12,400 lines of code, of which Dr. Beecroft estimates approximately 4,200 lines constitute direct modifications to existing ATLAS-RT kernel source files, while the remaining approximately 8,200 lines represent new code implementing the adaptive scheduling logic.

DW-001 is the module most tightly coupled to the ATLAS-RT source code. It directly modifies ATLAS-RT kernel functions, alters data structures within the ATLAS-RT scheduler, and relies on internal ATLAS-RT kernel APIs that are not part of the public API surface. Dr. Beecroft's assessment concludes that DW-001 is properly characterized as a "modification" of the ATLAS-RT source code within any reasonable interpretation of that term. The module cannot function without the ATLAS-RT kernel and is deeply intertwined with ATLAS-RT's core operating system architecture.

This represents the strongest case for MeridianCode's position that the module falls within the scope of Section 7.2.

DW-002: Adaptive Control Hardware Abstraction Layer. DW-002 is a hardware abstraction layer ("HAL") developed by VMS engineers to interface VMS's proprietary adaptive vehicle control hardware — including VMS's in-house designed motor controllers, sensor arrays, and actuator systems — with the ATLAS-RT operating system. The module comprises approximately 18,600 lines of code and implements a layered architecture with (i) a hardware-facing layer that communicates directly with VMS hardware components through VMS-proprietary driver interfaces, (ii) an abstraction layer that translates hardware-specific commands and data formats into platform-independent representations, and (iii) an RTOS-facing layer that interfaces with ATLAS-RT's device driver framework and I/O subsystem.

DW-002 occupies an intermediate position on the coupling spectrum. The RTOS-facing layer of DW-002 interfaces with ATLAS-RT's device driver APIs, and approximately 3,100 lines of code within DW-002 make direct calls to ATLAS-RT kernel services for interrupt handling, memory allocation, and timer management. However, the hardware-facing and abstraction layers — comprising approximately 15,500 lines of code — are VMS-proprietary and designed around VMS's unique hardware architecture. Dr. Beecroft characterizes DW-002 as potentially an "extension" of ATLAS-RT within the meaning of Section 7.2 — it adds new functionality built on top of ATLAS-RT's device driver framework — but notes that the module could also be characterized as an independent interoperability layer that bridges VMS hardware with the RTOS, rather than a derivative work of the RTOS itself.

Dr. Beecroft concludes that DW-002 could be adapted for alternative RTOS platforms with moderate re-engineering effort, estimated at approximately 1,200–1,800 engineering hours (roughly $175,000–$260,000 at VMS's fully loaded cost rate). The RTOS-facing layer would need to be rewritten to interface with the alternative platform's device driver framework, but the hardware-facing and abstraction layers would require only minor modifications.

DW-003: Adaptive Vehicle Diagnostic and Telemetry Module. DW-003 is a diagnostic and telemetry module that monitors adaptive vehicle systems, collects operational data, performs diagnostic analysis, and transmits telemetry data to VMS's cloud-based fleet management platform. The module comprises approximately 16,000 lines of code and implements a modular architecture with (i) a data collection layer that gathers operational data from vehicle subsystems, (ii) an analysis engine that performs real-time diagnostic computations, (iii) a telemetry transmission layer that communicates with VMS's cloud infrastructure via VMS's proprietary communication protocols, and (iv) an RTOS interface layer that uses ATLAS-RT API calls for task scheduling, inter-process communication, and memory management.

DW-003 has the loosest coupling to the ATLAS-RT source code of the three modules. The RTOS interface layer comprises approximately 1,800 lines of code and interfaces with ATLAS-RT exclusively through documented, public API calls — standard RTOS services for task creation, message passing, semaphore operations, and timer management. Dr. Beecroft notes that these API calls conform to a subset of the POSIX real-time extensions standard (IEEE Std 1003.1b), meaning that the RTOS interface layer could be redirected to any POSIX-compliant RTOS with minimal modification. The remaining approximately 14,200 lines of code are entirely VMS-proprietary, implement VMS's diagnostic algorithms and telemetry protocols, and have no dependency on ATLAS-RT source code or architecture.

Dr. Beecroft concludes that DW-003 is substantially separable from ATLAS-RT and could be ported to an alternative RTOS platform with relatively minor re-engineering effort, estimated at approximately 400–600 engineering hours (roughly $58,000–$87,000). He characterizes DW-003 as more properly an independent application that uses ATLAS-RT as a runtime platform rather than a work that modifies, adapts, or extends ATLAS-RT source code.

This represents the strongest case for VMS's sole-ownership position.

Aggregate Valuation. Dr. Beecroft estimates the aggregate commercial value of the three derivative work modules at between $1,800,000 and $2,500,000, broken down approximately as follows:

C. Separability Analysis

A central component of Dr. Beecroft's assessment is his analysis of the separability of each module from the ATLAS-RT codebase. Separability is relevant to both the copyright analysis (determining whether the modules constitute derivative works of ATLAS-RT or independent, separable works of authorship) and the contractual analysis (determining whether the modules constitute "modifications, adaptations, or extensions to ATLAS-RT source code" within the meaning of Section 7.2).

Dr. Beecroft's separability conclusions are summarized as follows:

DW-001: Likely inseparable. DW-001 directly modifies ATLAS-RT kernel source files and data structures.

PRIVILEGED AND CONFIDENTIAL — ATTORNEY-CLIENT PRIVILEGE / ATTORNEY WORK PRODUCT This memorandum is protected from disclosure by the attorney-client privilege and the work product doctrine. It is intended solely for the use of the addressees and authorized personnel of Vantage Mobility Systems Corp. Any unauthorized review, dissemination, distribution, or copying of this memorandum is strictly prohibited.
CALDERWOOD & HARKNESS LLP Attorneys at Law 600 Renaissance Center, Suite 3200 Detroit, MI 48243 Telephone: (313) 555-2800 Facsimile: (313) 555-2801
MEMORANDUM
Matter No.: 1007-00008
To: Bernard Crawford, Responsible Partner Conrad Ashby, Billing Partner
From: Gabrielle Moss, Lead Associate Aaron Liu, Working Associate
Date: September 15, 2023
Re: Derivative Works Ownership Dispute — Analysis of Section 7.2 of the Master Embedded Software License and Services Agreement dated June 21, 2022, between Vantage Mobility Systems Corp. and Meridian Code Technologies, Inc.; Applicable Michigan intellectual Property Law
Client: Vantage Mobility Systems Corp. ("VMS")
Counterparty: Meridian Code Technologies, Inc. ("MeridianCode") (Nasdaq: MCDT)
Right-click to update Table of Contents
I. Executive Summary
This memorandum addresses a dispute between our client, Vantage Mobility Systems Corp. ("VMS"), and Meridian Code Technologies, Inc. ("MeridianCode"), concerning the ownership and exploitation rights in three derivative work software modules — designated DW-001, DW-002, and DW-003 — comprising approximately 47,000 lines of code. These modules were created by VMS software engineers during the integration of MeridianCode's ATLAS-RT™ embedded real-time operating system ("RTOS") (Version 4.2, subsequently updated to Version 4.2.3) into VMS's Project Argonaut adaptive vehicle platforms. The dispute arises under Section 7.2 of the Master Embedded Software License and Services Agreement dated June 21, 2022 (the "MESLSA"), between VMS and MeridianCode.
An independent assessment conducted by Hargrove Technical Consulting, LLC — under the direction of lead consultant Dr. Samuel Beecroft, Ph.D. (Embedded Systems) — estimates the commercial value of the three derivative work modules at between $1,800,000 and $2,500,000. The derivative works at issue are integral to the proprietary adaptive vehicle platform architecture that VMS has developed as part of Project Argonaut and represent a significant investment of VMS engineering resources.
VMS's Position. VMS, through its General Counsel, Martin G. Cross, and through this firm, maintains that the derivative works are solely VMS-originated intellectual property. VMS engineers independently conceived, designed, coded, and tested the modules using VMS resources, VMS proprietary know-how regarding adaptive vehicle systems, and VMS hardware specifications. VMS contends that the mere fact that these modules interact with and extend the ATLAS-RT embedded RTOS does not transform them into "jointly owned" works under Section 7.2 of the MESLSA, and that Section 7.2 should be narrowly construed.
MeridianCode's Position. MeridianCode, through its General Counsel, Priya Ramaswamy, and through its outside counsel at Redstone Whitaker LLP (Alan M. Briscoe, Lead Partner, and Natasha C. Ferraro, Senior Associate), asserts that Section 7.2 of the MESLSA plainly provides that "any modifications, adaptations, or extensions to ATLAS-RT source code created by [Licensee's] engineers during integration become jointly owned," and that MeridianCode retains a perpetual, royalty-free license to such derivative works. MeridianCode contends that all three modules fall squarely within this provision.
Redstone Whitaker LLP communicated MeridianCode's position in a letter dated August 28, 2023, directed to this firm, asserting joint ownership of all three derivative work modules and demanding that VMS acknowledge MeridianCode's rights thereunder. A response is expected by October 13, 2023.
This memorandum analyzes the relevant contractual provisions, applicable Michigan intellectual property law, federal copyright principles, and the strategic implications of the dispute. Based on our analysis, we conclude as follows:
1.  VMS has colorable but not dispositive arguments for sole ownership of the derivative works, particularly with respect to modules DW-002 and DW-003, which exhibit varying degrees of separability from the ATLAS-RT source code.
2.  MeridianCode has the stronger textual argument under Section 7.2 as applied to DW-001, which is deeply intertwined with the ATLAS-RT kernel and most naturally characterized as a "modification" of ATLAS-RT source code.
3.  The dispute is not well-suited to an all-or-nothing resolution, and VMS's interests are best served by pursuing a negotiated, module-by-module carve-out as part of the broader dormancy extension and fee restructuring discussions currently underway with MeridianCode.
4.  We recommend that VMS adopt a differentiated negotiating posture — conceding joint ownership with limitations on DW-001, asserting sole ownership with a limited license-back on DW-002, and asserting sole ownership with no license-back on DW-003 — while preserving a credible arbitration threat to maintain leverage.
The sections below set forth the detailed factual background, contractual analysis, legal analysis, technical assessment, strategic considerations, and specific recommendations supporting these conclusions.
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 MeridianCode's licensing of its ATLAS-RT™ embedded real-time operating system to VMS for integration into VMS's next-generation adaptive vehicle platforms. The total deal value of the MESLSA is approximately $20,000,000, inclusive of upfront license fees, maintenance and support fees, integration services fees, and per-unit runtime royalties.
The Licensed Product under the MESLSA is MeridianCode's ATLAS-RT™ embedded RTOS, initially licensed at Version 4.2. During the course of the integration engagement, MeridianCode released a maintenance update to Version 4.2.3, which was deployed by VMS in January 2023 pursuant to the update provisions of the MESLSA.
The license scope is perpetual in nature, subject to the terms of a five-year initial term running from June 21, 2022 through June 20, 2027. Under the license grant, VMS is authorized to integrate ATLAS-RT into up to five designated vehicle platform configurations under VMS's internal development program known as "Project Argonaut." These platform configurations are designated Argonaut-A through Argonaut-E and encompass a range of adaptive vehicle architectures spanning passenger vehicle, light commercial vehicle, and specialty mobility platforms.
Vantage Mobility Systems Corp. VMS is a Delaware corporation headquartered at 4100 Industrial Parkway, Sterling Heights, Michigan 48312. VMS is a portfolio company of Kestrel Capital Partners, LP, which acquired VMS in 2019 in a leveraged buyout valued at approximately $380 million. For the fiscal year ending December 31, 2022, VMS reported revenue of approximately $485 million, EBITDA of approximately $61 million, and employed approximately 2,200 personnel, including a software engineering division of approximately 140 engineers. VMS designs, manufactures, and distributes adaptive vehicle systems, including modified vehicle platforms for mobility-impaired individuals and commercial fleet operators requiring specialized vehicle configurations. Project Argonaut represents VMS's strategic initiative to integrate embedded RTOS technology into its adaptive vehicle platforms to enable real-time adaptive control, enhanced telemetry, and next-generation diagnostic capabilities.
Meridian Code Technologies, Inc. MeridianCode is a California corporation headquartered at 2750 Orchard Blvd., Suite 400, Santa Clara, California 95054. MeridianCode is publicly traded on the Nasdaq Global Market under the ticker symbol MCDT. For the fiscal year ending December 31, 2022, MeridianCode reported revenue of approximately $310 million and employed approximately 1,400 personnel. MeridianCode is a leading provider of embedded operating systems and middleware solutions for the automotive, industrial, and IoT sectors, with its ATLAS-RT platform commanding a significant share of the automotive-grade RTOS market.
Project Argonaut Rescoping. On March 14, 2023, the VMS Board of Directors adopted a resolution rescoping Project Argonaut from five vehicle platform configurations (Argonaut-A through Argonaut-E) to two (Argonaut-A and Argonaut-C only). The board resolution reflected a strategic decision to defer the electrification integration components of Argonaut-B, Argonaut-D, and Argonaut-E to a subsequent Phase II development cycle, driven by a combination of capital allocation constraints identified by Kestrel Capital Partners and delays in the availability of next-generation electrification hardware from VMS's Tier 1 suppliers. Integration work on all Argonaut platforms was suspended effective March 22, 2023.
Dormancy Status. Following the suspension of integration work, VMS exercised its right under Section 9.4 of the MESLSA to place the license in Dormancy Status. VMS's dormancy notice was transmitted to MeridianCode on July 14, 2023 — six days before the 120-day trigger date of July 20, 2023 (calculated from the March 22, 2023 suspension date), by which VMS was required under Section 9.4 to either reactivate the integration engagement or invoke Dormancy Status. MeridianCode acknowledged receipt of the dormancy notice on August 3, 2023. Under Section 9.4, Dormancy Status extends for a maximum of twelve months from the date of the licensor's acknowledgment (i.e., through August 3, 2024), after which the parties are required to engage in mandatory renegotiation of the integration timeline, fee structure, and scope of licensed platforms.
B. The Derivative Works at Issue
During the active integration phase of Project Argonaut, which ran from the execution of the MESLSA on June 21, 2022 through the suspension of integration work on March 22, 2023 — a period of approximately nine months — VMS software engineers created three discrete software modules that are the subject of the present dispute. These modules are designated DW-001, DW-002, and DW-003 in accordance with the internal naming conventions established under the MESLSA's Exhibit C derivative works documentation procedures.
The VMS engineering team responsible for developing these modules operated under the direction of Lena Petrova, Director of Software Integration Engineering within VMS's Advanced Technology Division. Ms. Petrova reported to Dennis J. Whitfield, VMS's Chief Technology Officer, who served as the executive sponsor for Project Argonaut. The integration team comprised a core group of twelve senior software engineers, supplemented by four junior engineers and three quality assurance specialists, all of whom were full-time employees of VMS.
The three modules were created as modifications, adaptations, and extensions to the ATLAS-RT source code to enable integration with VMS's proprietary adaptive vehicle platform architecture. The modules collectively comprise approximately 47,000 lines of code, representing a substantial body of software engineering work. VMS invested approximately 14,200 engineering hours across its internal teams on Project Argonaut overall, a significant but not precisely quantified portion of which was dedicated specifically to developing these derivative work modules. Based on VMS's fully loaded engineering cost rate of approximately $145 per hour, the internal labor investment in the derivative works is estimated at between $900,000 and $1,200,000, exclusive of overhead, management time, and opportunity costs.
An independent assessment of the derivative works was commissioned by this firm and performed by Hargrove Technical Consulting, LLC, of McLean, Virginia, under the direction of Dr. Samuel Beecroft, Ph.D. (Embedded Systems). Dr. Beecroft's assessment, delivered in draft form on September 1, 2023, estimates the commercial value of the three derivative work modules at between $1,800,000 and $2,500,000. This valuation reflects the estimated replacement cost of the engineering effort, the commercial utility of the modules in adaptive vehicle applications, and the potential licensing value of the intellectual property embodied in the modules.
C. Integration Status at Time of Suspension
At the time integration work was suspended on March 22, 2023, the five Project Argonaut vehicle platforms had reached the following integration milestones under the milestone-based integration services schedule set forth in Exhibit B to the MESLSA:
Argonaut-A: Milestone 3 of 5 completed. Alpha integration testing was passed on February 28, 2023, representing the successful completion of initial source-code integration, hardware interface validation, and first-phase functional testing. Argonaut-A was the most advanced platform and the primary focus of VMS's integration engineering resources during the active integration phase.
Argonaut-C: Milestone 2 of 5 completed. Source-code customization was delivered on January 15, 2023, representing the completion of the requirements specification, initial code baseline establishment, and platform-specific customization of the ATLAS-RT configuration parameters. Argonaut-C was the secondary focus of integration effort during the active phase.
Argonaut-B: Milestone 1 only. The requirements specification was approved on November 30, 2022, but no code integration work had commenced on the Argonaut-B platform prior to the suspension. Argonaut-B was subsequently deferred to Phase II as part of the board-level rescoping decision.
Argonaut-D and Argonaut-E: Not commenced. No integration work of any kind had been initiated on these platforms prior to suspension. Both were deferred to Phase II.
Integration Services Fees paid by VMS through Milestone 3 totaled $1,920,000 of the $3,200,000 total Integration Services budget established under Exhibit B. The remaining $1,280,000 corresponds to Milestones 4 and 5 (beta integration testing and production release certification) for the active platforms.
D. Parties' Competing Positions
The parties' competing positions on the ownership of the derivative works have been communicated through a series of formal correspondences between counsel, as summarized below.
VMS Position. VMS's position has been articulated by Martin G. Cross, General Counsel of VMS, in internal correspondence, and has been further developed by this firm in communications with MeridianCode's outside counsel. VMS maintains that DW-001, DW-002, and DW-003 represent independently originated VMS intellectual property. The core of VMS's position is as follows:
(a) VMS engineers conceived, designed, coded, and tested these modules using VMS resources, VMS proprietary know-how regarding adaptive vehicle systems, and VMS hardware specifications. The creative and engineering contributions embodied in the modules are attributable solely to VMS personnel working within the scope of their employment at VMS.
(b) The fact that these modules interact with and extend the ATLAS-RT embedded RTOS does not transform them into "jointly owned" works under the MESLSA. Any software application that interfaces with an operating system necessarily interacts with that OS at some level; this does not make every application a "modification, adaptation, or extension" of the operating system's source code.
(c) Section 7.2 of the MESLSA should be narrowly construed in accordance with Michigan contract interpretation principles, which disfavor broad transfers of intellectual property rights. The provision was intended to capture modifications to the ATLAS-RT codebase itself — changes to the kernel, scheduler, and core OS libraries — and not every piece of application-level software that a licensee might develop during the integration period.
(d) Certain of the derivative work modules, particularly DW-003, have independent functional utility that is separable from ATLAS-RT and could be adapted to operate on alternative RTOS platforms. These works are more properly characterized as independent, separable works of authorship rather than derivative works of ATLAS-RT.
MeridianCode Position. MeridianCode's position has been articulated by Priya Ramaswamy, General Counsel of MeridianCode, and communicated formally through MeridianCode's outside counsel at Redstone Whitaker LLP. Alan M. Briscoe, Lead Partner, and Natasha C. Ferraro, Senior Associate, transmitted MeridianCode's position to this firm in a letter dated August 28, 2023. MeridianCode's position is as follows:
(a) Section 7.2 of the MESLSA plainly and unambiguously provides that "any modifications, adaptations, or extensions to ATLAS-RT source code created by [Licensee's] engineers during integration become jointly owned," and that MeridianCode "retains a perpetual, royalty-free license to such derivative works."
(b) The three derivative work modules are, by their nature and function, modifications, adaptations, and extensions of the ATLAS-RT source code. Each module was created for the express purpose of adapting and extending ATLAS-RT to function within VMS's adaptive vehicle platform architecture. The modules directly modify ATLAS-RT scheduling algorithms, interface with ATLAS-RT kernel functions, and rely on ATLAS-RT APIs and libraries for their operation.
(c) The phrase "during integration" is a temporal marker identifying the period during which such works are created, and it plainly captures all modules created by VMS engineers that modify, adapt, or extend the ATLAS-RT source code during the active integration phase. There is no basis for reading a causal or purposive limitation into this language.
(d) MeridianCode contributed the ATLAS-RT source code, documentation, technical support, and integration guidance that formed the foundation upon which VMS's derivative works were built. The joint-ownership provision in Section 7.2 reflects the parties' negotiated allocation of rights in recognition of both parties' contributions to the integrated product.
III. Contractual Analysis — Section 7.2 of the MESLSA
A. Text of Section 7.2
The operative language of Section 7.2 of the MESLSA, titled "Derivative Works; Ownership and License-Back," provides in relevant part:
"7.2 Derivative Works. Any modifications, adaptations, or extensions to ATLAS-RT source code created by Licensee's engineers during the Integration Period (as defined in Exhibit B) shall be deemed jointly owned by Licensor and Licensee ('Derivative Works'). Notwithstanding the foregoing joint ownership, Licensor shall retain, and Licensee hereby grants to Licensor, a perpetual, irrevocable, worldwide, royalty-free, fully paid-up, non-exclusive license, with the right to sublicense through multiple tiers, to use, reproduce, modify, create derivative works of, distribute, display, and otherwise exploit such Derivative Works for any purpose, subject to the limitations set forth in Exhibit C. The parties shall cooperate in good faith to identify, document, and disclose all Derivative Works in accordance with the procedures set forth in Exhibit C."
Several features of this language merit attention. First, the provision uses the disjunctive "modifications, adaptations, or extensions," capturing three distinct categories of derivative works. Second, the triggering condition is that the works be "created by Licensee's engineers during the Integration Period," incorporating both an authorship requirement (Licensee's engineers) and a temporal limitation (the Integration Period). Third, the provision creates a joint-ownership framework combined with a broad license-back in favor of MeridianCode as Licensor. Fourth, the license-back is described in expansive terms: perpetual, irrevocable, worldwide, royalty-free, fully paid-up, non-exclusive, with sublicensing rights through multiple tiers, for "any purpose" — subject only to the limitations in Exhibit C.
Exhibit C to the MESLSA, titled "Derivative Works Ownership and License-Back Terms," further elaborates on Section 7.2. Exhibit C provides the contractual definition of "Derivative Work," specifies the identification, documentation, and disclosure procedures applicable to derivative works, and details the scope and limitations of MeridianCode's license-back right. We analyze the key provisions of Exhibit C in the sections below.
B. Definition of "Derivative Work" Under the MESLSA
Exhibit C, Section 1(a) of the MESLSA defines "Derivative Work" as follows:
"any work that is based upon, incorporates, modifies, adapts, extends, translates, abridges, condenses, or otherwise recasts, transforms, or adapts ATLAS-RT Source Code, ATLAS-RT object code, or ATLAS-RT documentation, in whole or in part, including without limitation any software module, library, algorithm, data structure, or interface specification that constitutes a modification, adaptation, or extension of ATLAS-RT Source Code within the meaning of Section 7.2."
This definition is notably broad. It encompasses not only modifications to the ATLAS-RT source code itself but also works that "incorporate" or are "based upon" ATLAS-RT source code, object code, or documentation. The enumeration of specific categories — "software module, library, algorithm, data structure, or interface specification" — further broadens the potential scope to include a wide range of engineering outputs.
Applying this definition to the three derivative work modules at issue requires a careful analysis of the nature and degree of each module's relationship to the ATLAS-RT codebase. We distinguish among three categories of derivative work activity:
(i) Modifications to existing ATLAS-RT source code. A modification involves direct alteration of the pre-existing ATLAS-RT source code — changing existing functions, algorithms, parameters, or data structures within the ATLAS-RT codebase. A modification in this sense results in a changed version of the underlying ATLAS-RT code.
(ii) Adaptations that reconfigure ATLAS-RT functionality. An adaptation involves reconfiguring or redeploying existing ATLAS-RT functionality for a new purpose or in a new context without necessarily altering the underlying source code. This may include configuration changes, parameter adjustments, or the selection and combination of existing ATLAS-RT modules for a platform-specific deployment.
(iii) Extensions that add new functionality built on top of ATLAS-RT APIs or libraries. An extension involves the creation of new code that adds functionality not present in the original ATLAS-RT distribution, building upon ATLAS-RT's application programming interfaces, libraries, or kernel services. Extensions may range from tightly coupled modules that directly invoke ATLAS-RT kernel functions to loosely coupled application-layer modules that interface with ATLAS-RT through standard, abstracted API calls.
As we discuss in Section V below, the three derivative work modules (DW-001, DW-002, and DW-003) represent different points on this spectrum. Not all three modules equally constitute "modifications, adaptations, or extensions to ATLAS-RT source code" within the meaning of Section 7.2 and the Exhibit C definition. VMS's strongest argument lies in contending that certain modules — particularly DW-003 — fall outside the contractual definition because they constitute independent, application-level works that merely interface with ATLAS-RT through standard APIs rather than modifying, adapting, or extending the ATLAS-RT source code.
However, we must acknowledge that the breadth of the Exhibit C definition, which captures works that "incorporate" or are "based upon" ATLAS-RT source code and expressly includes "interface specification[s]," significantly undermines this argument. The definition was drafted to be inclusive rather than restrictive, and a plain-text reading suggests that any software module that interacts with ATLAS-RT at the source-code level could potentially be captured.
C. "Created During Integration" — Temporal and Causal Scope
A critical interpretive question is whether the phrase "created by Licensee's engineers during the Integration Period" in Section 7.2 imposes a purely temporal limitation or whether it implies a causal or purposive requirement.
Temporal interpretation. Under a purely temporal reading, Section 7.2 captures any code that (a) constitutes a modification, adaptation, or extension of ATLAS-RT source code, and (b) was created by VMS engineers at any time during the Integration Period (defined in Exhibit B as the period commencing on the MESLSA effective date and continuing through the completion of all integration milestones or the earlier suspension or termination of integration services). Under this reading, the provision functions as a broad temporal net: any qualifying derivative work created during the defined period is subject to joint ownership, regardless of the specific purpose for which it was created.
Causal/purposive interpretation. Under a causal or purposive reading, Section 7.2 captures only code that was created for the purpose of integrating ATLAS-RT into VMS's vehicle platforms — that is, code whose creation was causally linked to the integration engagement. Under this reading, code that was written contemporaneously with the integration period but that serves VMS's broader adaptive vehicle platform architecture, and that has independent utility apart from the ATLAS-RT integration, would not be captured.
VMS's argument favors the causal/purposive interpretation. VMS contends that certain modules — particularly DW-002 (the hardware abstraction layer) and DW-003 (the diagnostic and telemetry module) — were conceived and developed to serve VMS's broader product architecture and have independent utility that extends well beyond the ATLAS-RT integration. Under VMS's view, the fact that these modules were created during the same timeframe as the ATLAS-RT integration is a coincidence of timing rather than an indication that the modules are derivative works of ATLAS-RT.
MeridianCode's argument favors the temporal interpretation. MeridianCode contends that the plain language of Section 7.2 refers to works "created ... during the Integration Period" without any qualifier suggesting a causal nexus. MeridianCode argues that the parties could have included language such as "created for the purpose of" or "created in connection with" the integration if they had intended a causal limitation, and that their failure to do so reflects a deliberate choice to adopt a temporal framework.
As a matter of Michigan contract interpretation, MeridianCode's temporal reading has the stronger textual foundation. The phrase "during the Integration Period" most naturally reads as a temporal marker. However, VMS can argue that the phrase "modifications, adaptations, or extensions to ATLAS-RT source code" itself imposes a substantive limitation that narrows the scope of the provision regardless of the temporal question — a module that does not modify, adapt, or extend ATLAS-RT source code is not captured by Section 7.2 even if it was created during the Integration Period.
D. Joint Ownership — Implications Under the MESLSA
Section 7.2 provides that qualifying derivative works "shall be deemed jointly owned by Licensor and Licensee." The MESLSA does not, however, define the specific rights and obligations of the parties as joint owners beyond the specification of MeridianCode's license-back right. Exhibit C elaborates on the license-back but does not address the broader framework of joint-ownership rights, including:
(a) Whether either party may independently license the jointly owned works to third parties without the consent of the other party;
(b) Whether either party has an obligation to account to the other for profits derived from exploitation of the jointly owned works;
(c) Whether either party may create further derivative works of the jointly owned works without the consent of the other party;
(d) How the jointly owned works are to be maintained, updated, and supported, and which party bears responsibility for such activities; and
(e) How disputes regarding the exploitation of the jointly owned works are to be resolved.
Absent further contractual specification on these points, the rights and obligations of joint owners default to applicable law. As discussed in Section IV below, the applicable legal frameworks — Michigan contract law and federal copyright law — provide different default rules for joint ownership, and the interaction between these frameworks creates additional complexity.
Of particular concern to VMS is the default rule under federal copyright law that joint owners of a copyrighted work may each independently exploit the work without the consent of the other, subject only to an obligation to account for profits. See 17 U.S.C. § 201(a); Thomson v. Larson, 147 F.3d 195, 199 (2d Cir. 1998). If the derivative works are deemed jointly owned, MeridianCode could — absent a contractual restriction — independently license the derivative works to VMS's competitors in the adaptive vehicle market. The license-back provision in Section 7.2 exacerbates this concern by expressly granting MeridianCode broad exploitation rights, including the right to sublicense "through multiple tiers" for "any purpose." The "any purpose" language is particularly problematic because it does not restrict MeridianCode's use to non-competitive applications.
E. Perpetual Royalty-Free License-Back
Even if VMS were to prevail on its argument for sole ownership of the derivative works, Section 7.2 purports to grant MeridianCode a perpetual, irrevocable, worldwide, royalty-free, fully paid-up, non-exclusive license to use, reproduce, modify, create derivative works of, distribute, display, and otherwise exploit the derivative works, with sublicensing rights through multiple tiers, for any purpose. This license-back is a significant encumbrance on VMS's intellectual property rights, regardless of whether VMS achieves sole ownership.
A critical question is whether MeridianCode's license-back survives termination or expiration of the MESLSA. Section 14.3 of the MESLSA (Survival) provides:
"14.3 Survival. The following provisions shall survive any termination or expiration of this Agreement: Sections 5 (Confidentiality), 7 (Intellectual Property), 8 (Representations and Warranties, solely with respect to Sections 8.1 through 8.4), 10 (Indemnification), 11 (Limitation of Liability), 12 (Dispute Resolution), 13 (Governing Law), and 14 (General Provisions)."
Because Section 7 (Intellectual Property), which includes Section 7.2, is expressly enumerated as a surviving provision, MeridianCode's license-back appears to persist beyond any termination or expiration of the MESLSA. This significantly affects VMS's negotiating position: even if VMS terminates the MESLSA or allows it to lapse during the dormancy period, MeridianCode's license-back rights in the derivative works would continue in perpetuity.
VMS might argue that the survival of Section 7 should be limited to the intellectual property ownership provisions (i.e., confirming who owns what after termination) and should not be read to perpetuate an ongoing license grant that was ancillary to the operative licensing relationship. However, this argument confronts the plain language of Section 14.3, which enumerates Section 7 without qualification or limitation. Michigan courts applying the plain-meaning rule would likely enforce the survival clause as written.
The practical implication is that VMS cannot use termination or lapse of the MESLSA as a mechanism to eliminate MeridianCode's license-back rights. Any modification of MeridianCode's license-back must be achieved through negotiation and formal amendment.
F. Preliminary Contract Interpretation Conclusions
Based on the foregoing analysis, we reach the following preliminary conclusions regarding the contractual framework:
First, under the plain text of Section 7.2 and the Exhibit C definition of "Derivative Work," MeridianCode has a strong textual argument that the derivative works fall within the joint-ownership provision. The language is broad, the definition is inclusive, and the temporal trigger ("during the Integration Period") encompasses the period in which all three modules were created.
Second, VMS's best contractual arguments are:
(i) Narrow construction of "modifications, adaptations, or extensions to ATLAS-RT source code." VMS can argue that this phrase should be limited to works that directly alter, reconfigure, or build upon the ATLAS-RT source code — the kernel, scheduler, core libraries, and OS-level components — and should not extend to application-level modules that merely interface with ATLAS-RT through standard API calls. Under this construction, modules with independent functional utility that could operate on alternative RTOS platforms are not "modifications, adaptations, or extensions" of ATLAS-RT source code.
(ii) Characterization of certain modules as interoperability layers or independent applications. VMS can argue that DW-002 (the hardware abstraction layer) and DW-003 (the diagnostic and telemetry module) are more properly characterized as independent, separable works that interface with ATLAS-RT rather than derivative works of ATLAS-RT. This argument draws support from the technical separability analysis in the Hargrove report (discussed in Section V below).
(iii) Challenge to the breadth of "during integration" as a temporal catch-all. VMS can argue that the phrase "during integration" should be read with a purposive limitation — requiring a causal connection between the integration engagement and the creation of the derivative work — rather than as an unrestricted temporal net.
Third, the strength of these arguments varies by module: VMS has the weakest argument for DW-001 (which directly modifies ATLAS-RT scheduling algorithms), a moderate argument for DW-002 (which could be characterized as either an extension of ATLAS-RT or an independent interoperability layer), and the strongest argument for DW-003 (which has substantial independent utility and interfaces with ATLAS-RT only through standard API calls).
Fourth, the license-back provision in Section 7.2 survives termination of the MESLSA, limiting VMS's ability to leverage termination as a strategy for eliminating MeridianCode's rights.
IV. Applicable Law — Michigan intellectual Property and Federal Copyright
A. Choice of Law — Michigan
Section 13.1 of the MESLSA contains a governing law provision selecting Michigan law as the law governing the interpretation and enforcement of the agreement. The provision reads:
"13.1 Governing Law. This Agreement shall be governed by and construed in accordance with the laws of the State of Michigan, without giving effect to any choice-of-law or conflict-of-law provisions or rules that would cause the application of the laws of any other jurisdiction."
Michigan law therefore governs the interpretation of Section 7.2 as a matter of contract. However, to the extent the derivative works dispute implicates federal copyright law — particularly questions of derivative work status, joint authorship, and ownership of copyrightable works — federal law applies under the Supremacy Clause. Federal copyright law, codified at 17 U.S.C. § 101 et seq., preempts certain state-law intellectual property claims (under the preemption provision of 17 U.S.C. § 301) but does not preempt contract-based claims regarding the allocation of ownership rights in copyrightable works. See ProCD, Inc. v. Zeidenberg, 86 F.3d 1447, 1454 (7th Cir. 1996); Architectronics, Inc. v. Control Sys., Inc., 935 F. Supp. 425, 439 (S.D.N.Y. 1996).
Accordingly, our analysis must address both: (a) Michigan contract interpretation principles as applied to the construction of Section 7.2, and (b) federal copyright law as it governs the threshold questions of derivative work status, joint authorship, and default ownership allocation, which inform the background against which the MESLSA was negotiated and should be interpreted.
B. Michigan Contract Interpretation Principles
Michigan follows the "plain meaning" rule for the interpretation of unambiguous contracts. Under this rule, if the language of a contract is clear and unambiguous, the court must enforce the contract as written and may not look beyond the four corners of the document to determine the parties' intent. Wilkie v. Auto-Owners Ins. Co., 469 Mich. 41, 51 (2003); Rory v. Continental Ins. Co., 473 Mich. 457, 468 (2005). Words and phrases are given their plain and ordinary meaning, and technical terms are given their technical meaning. Henderson v. State Farm Fire & Cas. Co., 460 Mich. 348, 354 (1999).
If a contract provision is ambiguous — that is, if it is reasonably susceptible to two or more interpretations — Michigan courts will consider extrinsic evidence of the parties' intent, including the circumstances surrounding the formation of the contract, the parties' course of dealing, and trade usage. Klapp v. United Ins. Grp. Agency, Inc., 468 Mich. 459, 469 (2003). Ambiguity is a question of law for the court. Id. at 468.
The question of whether Section 7.2 is ambiguous on the operative issues — specifically, what constitutes a "modification[], adaptation[], or extension[] to ATLAS-RT source code" and what is captured by the phrase "during the Integration Period" — is central to VMS's contractual arguments. If the court determines that Section 7.2 is unambiguous, MeridianCode's plain-text argument will likely prevail, and VMS will be unable to introduce extrinsic evidence regarding the parties' intent to narrow the scope of the provision. If, however, VMS can establish that Section 7.2 is ambiguous — for example, because the phrase "modifications, adaptations, or extensions to ATLAS-RT source code" is reasonably susceptible to both a broad interpretation (encompassing any software that interacts with ATLAS-RT) and a narrow interpretation (limited to direct modifications of the OS codebase) — VMS would be entitled to introduce extrinsic evidence in support of the narrower construction.
Critically, Michigan courts construe ambiguities in intellectual property assignments and licenses narrowly, in favor of the creator or grantor of the intellectual property. This principle reflects the Michigan courts' recognition that intellectual property rights are valuable assets that should not be presumed to have been conveyed absent clear and unambiguous language of conveyance. See Bliss v. Calhoun County, 262 Mich. 218, 222 (1933) (construing ambiguity in assignment in favor of assignor); cf. Cohen v. Paramount Pictures Corp., 845 F.2d 851, 854 (9th Cir. 1988) (noting the general principle that license grants are construed narrowly). This principle would support VMS's position that Section 7.2 should be narrowly construed, if the provision is determined to be ambiguous.
Additionally, Michigan courts apply the principle of contra proferentem — construing ambiguous provisions against the drafter — where the identity of the drafter is known. The MESLSA was drafted by MeridianCode's legal team (with input from both parties during negotiation), which would favor VMS in the event of ambiguity. However, the contra proferentem principle is typically reserved as a last resort and is less frequently applied in the context of negotiated commercial agreements between sophisticated parties. See Klapp, 468 Mich. at 471.
C. Federal Copyright Law — Derivative Works (17 U.S.C. § 103)
Under the Copyright Act, a "derivative work" is defined as:
"a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted."
17 U.S.C. § 101. A derivative work includes a work consisting of "editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship." Id.
Under 17 U.S.C. § 103(b), the copyright in a derivative work "extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work." The copyright in a derivative work is "independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material." Id.
Applying these principles to the present dispute: if VMS's modules constitute "derivative works" of ATLAS-RT within the meaning of the Copyright Act, VMS would own the copyright in the original expression contributed by its engineers — the new code, algorithms, and data structures created by VMS — but would not own any copyright in the underlying ATLAS-RT source code upon which the modules are built. MeridianCode would retain full ownership of the ATLAS-RT source code.
Importantly, a lawful licensee who creates a derivative work with the licensor's authorization — as VMS did here, under the express terms of the MESLSA — owns the copyright in the original expression contributed by the licensee, subject to any contractual provisions allocating ownership differently. See Stewart v. Abend, 495 U.S. 207, 223 (1990). The parties are free to contract around this default rule. Section 7.2 of the MESLSA purports to do exactly that: rather than allowing the default copyright rule to govern — under which VMS would own the copyright in its original contributions — the parties agreed to a joint-ownership framework with a license-back.
The question, therefore, is not whether VMS has a copyright interest in its original contributions (it does, under the default rule) but whether the contractual provision in Section 7.2 effectively reallocates that ownership to create a joint-ownership framework, and if so, which modules are captured by the provision.
D. Joint Authorship Under Federal Copyright Law (17 U.S.C. § 101)
Federal copyright law defines a "joint work" as "a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole." 17 U.S.C. § 101. Joint authors of a copyrighted work are co-owners of the copyright. 17 U.S.C. § 201(a).
The leading Sixth Circuit precedent on joint authorship — relevant because Michigan is within the Sixth Circuit — requires that each putative joint author (a) make independently copyrightable contributions to the work and (b) intend, at the time of creation, that the contributions be merged into inseparable or interdependent parts of a unitary whole. See Aalmuhammed v. Lee, 202 F.3d 1227, 1231 (9th Cir. 2000) (widely cited analysis); Childress v. Taylor, 945 F.2d 500, 505-08 (2d Cir. 1991) (establishing the intent requirement).
VMS could argue, as a factual matter, against a finding of joint authorship under these principles:
(a) Lack of intent to create a unitary whole. VMS engineers did not intend to merge their contributions with MeridianCode's ATLAS-RT into a single, unified work of joint authorship. The VMS modules were created as separate, identifiable software components designed to serve VMS's proprietary adaptive vehicle platform. While the modules interact with ATLAS-RT, VMS engineers did not conceive of the modules as inseparable parts of a unitary whole that would be jointly owned.
(b) Separability. The modules, particularly DW-002 and DW-003, are separable from the ATLAS-RT codebase. They can function independently of ATLAS-RT, or could be adapted with reasonable re-engineering effort to operate on alternative RTOS platforms. This separability weighs against a finding that the works are "inseparable or interdependent parts of a unitary whole."
(c) Absence of MeridianCode creative contribution to VMS modules. MeridianCode did not contribute original expression to the VMS modules. MeridianCode provided the ATLAS-RT platform and documentation, but the creative and engineering work embodied in DW-001, DW-002, and DW-003 was performed exclusively by VMS engineers. The provision of an underlying platform upon which derivative works are built does not make the platform owner a joint author of the derivative works.
However, the practical significance of this federal joint-authorship analysis is limited by the fact that Section 7.2 of the MESLSA contractually allocates joint ownership. As noted above, parties are free to contract around the default copyright ownership rules, and a contractual joint-ownership provision may supersede the factual joint-authorship analysis. If Section 7.2 applies to the derivative works, the contractual allocation controls regardless of whether MeridianCode would qualify as a joint author under federal copyright law.
The federal joint-authorship analysis remains relevant, however, to the extent VMS argues that Section 7.2 should be narrowly construed to avoid a result that contravenes the copyright default — i.e., that the parties should not be presumed to have intended an outcome (joint ownership of VMS-authored works by a non-authoring party) that departs from the background copyright principles without clear and specific language to that effect. This argument draws on the canon of construction that contracts should be interpreted, where possible, consistently with applicable default legal rules.
E. Michigan Law on IP Ownership in Employment/Contractor Context
VMS's software engineers who created the derivative work modules are full-time employees of VMS. Under the work-made-for-hire doctrine codified at 17 U.S.C. § 201(b), a work "prepared by an employee within the scope of his or her employment" is a "work made for hire," and "the employer ... is considered the author" and "owns all of the rights comprised in the copyright." The modules at issue were indisputably created by VMS employees within the scope of their employment — under the direction of VMS management (Lena Petrova and Dennis J. Whitfield), using VMS resources and equipment, during regular working hours, as part of their assigned duties on Project Argonaut.
Michigan does not have a specific statutory overlay that modifies the federal work-made-for-hire doctrine in the context of software development. Michigan has adopted the Uniform Trade Secrets Act (Michigan Compiled Laws § 445.1901 et seq.), which protects trade secrets including proprietary software, but this statute addresses misappropriation claims rather than ownership allocation. Michigan common law does not impose any additional requirements for employer ownership of employee-created intellectual property beyond those established by federal copyright law.
The issue in this dispute is therefore not whether VMS or its employees own the derivative works — VMS clearly owns them as works made for hire — but whether VMS's contractual agreement with MeridianCode, specifically Section 7.2 of the MESLSA, effectively conveys a co-ownership interest in VMS's employee-created works to MeridianCode, a third-party licensor.
VMS can argue that Section 7.2 should be narrowly construed to avoid an interpretation that automatically conveys ownership of employee works-for-hire to a third-party licensor. This argument rests on the principle that intellectual property ownership transfers should be construed strictly in favor of the owner/creator, and that a provision that effectively transfers half of VMS's ownership in works created by VMS employees should not be read more broadly than its plain terms require. While this argument does not invalidate Section 7.2 — the parties are clearly free to contract for such an arrangement — it supports a narrow interpretation of what constitutes a "modification[], adaptation[], or extension[] to ATLAS-RT source code" so as to minimize the scope of works captured by the joint-ownership provision.
F. Unconscionability and Public Policy Arguments
We have considered whether the breadth of Section 7.2 — which captures "any modifications, adaptations, or extensions to ATLAS-RT source code" created "during the Integration Period," with a perpetual, irrevocable, worldwide, royalty-free license-back for "any purpose" — could be challenged as unconscionable or contrary to Michigan public policy.
We conclude that such arguments are unlikely to succeed and should not be advanced as primary arguments. Michigan courts apply the unconscionability doctrine only in exceptional circumstances, and the doctrine requires a showing of both procedural unconscionability (unfairness in the bargaining process) and substantive unconscionability (unreasonably one-sided terms). Clark v. DaimlerChrysler Corp., 268 Mich. App. 138, 143 (2005).
Here, procedural unconscionability is virtually impossible to establish. VMS is a sophisticated commercial party with annual revenues of approximately $485 million, represented by experienced legal counsel. Calderwood & Harkness LLP reviewed the MESLSA prior to execution, as documented in the Preliminary Contract Review Memorandum dated June 14, 2022 (prepared by this firm, authored by senior associate Daniel R. Howell, reviewed by Bernard Crawford). That memorandum specifically identified the derivative works provisions of Section 7.2 and Exhibit C as a risk area and recommended that VMS negotiate for a narrower definition of "Derivative Work," a carve-out for application-level software with independent utility, and restrictions on MeridianCode's license-back to non-competitive applications. VMS's management, after consultation with Kestrel Capital Partners, elected to accept the terms of Section 7.2 as drafted, in the interest of closing the MESLSA transaction within the board-mandated timeline.
In light of this history, VMS cannot credibly claim that it was unaware of the risks posed by Section 7.2 or that it lacked the sophistication or bargaining power to negotiate different terms. An unconscionability challenge would likely be viewed by the arbitral panel as inconsistent with VMS's status as a sophisticated, counseled party that accepted the provision with full knowledge of its implications.
Public policy arguments are similarly weak. Michigan does not have a statutory prohibition against contractual provisions allocating joint ownership of derivative works created during a licensing engagement. While the breadth of the license-back is significant, it does not violate any recognized Michigan public policy.
We recommend that unconscionability and public policy arguments be held in reserve as secondary or fallback positions rather than featured as primary arguments in any submission.
V. Technical Assessment — Hargrove Technical Consulting Report
A. Scope of Engagement
Hargrove Technical Consulting, LLC, based in McLean, Virginia, was retained by Calderwood & Harkness LLP in July 2023 to perform an independent technical assessment of the ATLAS-RT integration work performed under Project Argonaut and the nature of the three derivative work modules (DW-001, DW-002, and DW-003). The engagement was structured under an expert consulting arrangement with Calderwood & Harkness as the retaining party, with all communications and work product protected by the attorney-client privilege and work product doctrine.
The lead consultant on the engagement is Dr. Samuel Beecroft, Ph.D. (Embedded Systems), a recognized authority in embedded RTOS architecture with over twenty years of experience in the automotive and aerospace embedded systems sectors. Dr. Beecroft holds a Ph.D. in Electrical Engineering and Computer Science from the University of Michigan (2001) and has served as an expert consultant in numerous software IP disputes involving embedded systems technology.
Hargrove's scope of work encompassed the following tasks:
(a) Review and analysis of the ATLAS-RT Version 4.2 and 4.2.3 source code, architecture documentation, and API specifications provided by MeridianCode under the MESLSA;
(b) Review and analysis of the source code, design documentation, and engineering records for DW-001, DW-002, and DW-003 provided by VMS;
(c) Assessment of the technical relationship between each derivative work module and the ATLAS-RT source code, including the degree of coupling, dependency, and interoperability;
(d) Evaluation of whether each module constitutes a modification, adaptation, or extension of the ATLAS-RT source code or an independent, separable work;
(e) Assessment of the separability of each module from the ATLAS-RT codebase — i.e., whether each module can function independently of ATLAS-RT or could be adapted to operate on alternative RTOS platforms with reasonable re-engineering effort; and
(f) Estimation of the commercial value of each module, both individually and in the aggregate.
Dr. Beecroft delivered his draft assessment to this firm on September 1, 2023. A final assessment incorporating additional VMS engineering documentation is expected by October 1, 2023.
B. Key Findings
Dr. Beecroft's assessment contains detailed technical findings for each of the three derivative work modules. The key findings are summarized below.
DW-001: ATLAS-RT Adaptive Scheduling Module. DW-001 is a software module that modifies the core scheduling algorithms within the ATLAS-RT kernel to enable adaptive vehicle real-time control. Specifically, DW-001 replaces portions of the ATLAS-RT priority-based preemptive scheduler with a custom adaptive scheduling algorithm developed by VMS engineers, which dynamically adjusts task priorities and scheduling parameters in response to real-time sensor inputs from VMS's adaptive vehicle control hardware. The module comprises approximately 12,400 lines of code, of which Dr. Beecroft estimates approximately 4,200 lines constitute direct modifications to existing ATLAS-RT kernel source files, while the remaining approximately 8,200 lines represent new code implementing the adaptive scheduling logic.
DW-001 is the module most tightly coupled to the ATLAS-RT source code. It directly modifies ATLAS-RT kernel functions, alters data structures within the ATLAS-RT scheduler, and relies on internal ATLAS-RT kernel APIs that are not part of the public API surface. Dr. Beecroft's assessment concludes that DW-001 is properly characterized as a "modification" of the ATLAS-RT source code within any reasonable interpretation of that term. The module cannot function without the ATLAS-RT kernel and is deeply intertwined with ATLAS-RT's core operating system architecture.
This represents the strongest case for MeridianCode's position that the module falls within the scope of Section 7.2.
DW-002: Adaptive Control Hardware Abstraction Layer. DW-002 is a hardware abstraction layer ("HAL") developed by VMS engineers to interface VMS's proprietary adaptive vehicle control hardware — including VMS's in-house designed motor controllers, sensor arrays, and actuator systems — with the ATLAS-RT operating system. The module comprises approximately 18,600 lines of code and implements a layered architecture with (i) a hardware-facing layer that communicates directly with VMS hardware components through VMS-proprietary driver interfaces, (ii) an abstraction layer that translates hardware-specific commands and data formats into platform-independent representations, and (iii) an RTOS-facing layer that interfaces with ATLAS-RT's device driver framework and I/O subsystem.
DW-002 occupies an intermediate position on the coupling spectrum. The RTOS-facing layer of DW-002 interfaces with ATLAS-RT's device driver APIs, and approximately 3,100 lines of code within DW-002 make direct calls to ATLAS-RT kernel services for interrupt handling, memory allocation, and timer management. However, the hardware-facing and abstraction layers — comprising approximately 15,500 lines of code — are VMS-proprietary and designed around VMS's unique hardware architecture. Dr. Beecroft characterizes DW-002 as potentially an "extension" of ATLAS-RT within the meaning of Section 7.2 — it adds new functionality built on top of ATLAS-RT's device driver framework — but notes that the module could also be characterized as an independent interoperability layer that bridges VMS hardware with the RTOS, rather than a derivative work of the RTOS itself.
Dr. Beecroft concludes that DW-002 could be adapted for alternative RTOS platforms with moderate re-engineering effort, estimated at approximately 1,200–1,800 engineering hours (roughly $175,000–$260,000 at VMS's fully loaded cost rate). The RTOS-facing layer would need to be rewritten to interface with the alternative platform's device driver framework, but the hardware-facing and abstraction layers would require only minor modifications.
DW-003: Adaptive Vehicle Diagnostic and Telemetry Module. DW-003 is a diagnostic and telemetry module that monitors adaptive vehicle systems, collects operational data, performs diagnostic analysis, and transmits telemetry data to VMS's cloud-based fleet management platform. The module comprises approximately 16,000 lines of code and implements a modular architecture with (i) a data collection layer that gathers operational data from vehicle subsystems, (ii) an analysis engine that performs real-time diagnostic computations, (iii) a telemetry transmission layer that communicates with VMS's cloud infrastructure via VMS's proprietary communication protocols, and (iv) an RTOS interface layer that uses ATLAS-RT API calls for task scheduling, inter-process communication, and memory management.
DW-003 has the loosest coupling to the ATLAS-RT source code of the three modules. The RTOS interface layer comprises approximately 1,800 lines of code and interfaces with ATLAS-RT exclusively through documented, public API calls — standard RTOS services for task creation, message passing, semaphore operations, and timer management. Dr. Beecroft notes that these API calls conform to a subset of the POSIX real-time extensions standard (IEEE Std 1003.1b), meaning that the RTOS interface layer could be redirected to any POSIX-compliant RTOS with minimal modification. The remaining approximately 14,200 lines of code are entirely VMS-proprietary, implement VMS's diagnostic algorithms and telemetry protocols, and have no dependency on ATLAS-RT source code or architecture.
Dr. Beecroft concludes that DW-003 is substantially separable from ATLAS-RT and could be ported to an alternative RTOS platform with relatively minor re-engineering effort, estimated at approximately 400–600 engineering hours (roughly $58,000–$87,000). He characterizes DW-003 as more properly an independent application that uses ATLAS-RT as a runtime platform rather than a work that modifies, adapts, or extends ATLAS-RT source code.
This represents the strongest case for VMS's sole-ownership position.
Aggregate Valuation. Dr. Beecroft estimates the aggregate commercial value of the three derivative work modules at between $1,800,000 and $2,500,000, broken down approximately as follows:
C. Separability Analysis
A central component of Dr. Beecroft's assessment is his analysis of the separability of each module from the ATLAS-RT codebase. Separability is relevant to both the copyright analysis (determining whether the modules constitute derivative works of ATLAS-RT or independent, separable works of authorship) and the contractual analysis (determining whether the modules constitute "modifications, adaptations, or extensions to ATLAS-RT source code" within the meaning of Section 7.2).
Dr. Beecroft's separability conclusions are summarized as follows:
DW-001: Likely inseparable. DW-001 directly modifies ATLAS-RT kernel source files and data structures.

MEMORANDUM

Record

Parties

Dates

Amounts