--- title: "Source Code Ownership: Where the Code Sits, or Whom It Belongs To?" description: "Source code ownership is established not by the code sitting in company repositories but by tying every contribution source — employee, contractor, agency, acquired team, open-source component — to a written and signed transfer of rights. Where that chain is incomplete, the effect reaches price indirectly: through special indemnities, a higher escrow percentage, pre-closing conditions and a longer transaction timetable." url: https://www.beirek.com/en/blog/source-code-ownership-due-diligence canonical: https://www.beirek.com/en/blog/source-code-ownership-due-diligence published: 2026-07-04 modified: 2026-07-04 category: "Intellectual Property" category_url: https://www.beirek.com/en/blog/category/intellectual-property language: en-US reading_time_minutes: 9 publisher: BEIREK LLC publisher_url: https://www.beirek.com license: "© BEIREK LLC — citation with attribution and link permitted" keywords: ["source code ownership","chain of title","intellectual property due diligence","assignment of economic rights","open-source license compliance","founder dependency","escrow and special indemnity"] topics: ["Intellectual property diligence in software transactions","Contractual transfer of copyright in code","Open-source component inventory and license scanning","Transaction structuring: indemnities, escrow and pre-closing conditions","Founder dependency and continuity of technical operations"] alternate_language_url: https://www.beirek.com/tr/blog/source-code-ownership-due-diligence --- # Source Code Ownership: Where the Code Sits, or Whom It Belongs To? > **In short:** Source code ownership is established not by the code sitting in company repositories but by tying every contribution source — employee, contractor, agency, acquired team, open-source component — to a written and signed transfer of rights. Where that chain is incomplete, the effect reaches price indirectly: through special indemnities, a higher escrow percentage, pre-closing conditions and a longer transaction timetable. *In software assets, ownership is established not by where the code is held but by whether every contribution source is tied to a written transfer of rights. Where the chain is incomplete, the effect surfaces not in the headline multiple but in special indemnity language, escrow percentages and the closing conditions list — items that quietly redistribute negotiating leverage.* --- In an investment review, the first working session on a software asset usually opens with a technical walkthrough: the product team narrates the architecture, the repository history is projected onto the screen, and the party conducting the review listens while quietly reading the contributor list. That list will typically contain email addresses that never appeared on the company payroll, the domain of an agency that has since ceased trading, and the founder's personal account from the period before the entity was formed. None of this is, in itself, the problem; software commonly grows in exactly this layered fashion, and at an early stage the practice is an efficient way of converting scarce capital into shipped product. The problem is that the same names have no counterpart in the contracts folder, and in most companies that mismatch has never once been examined before the diligence table is set. The second observation concerns the shape of the answer once the question is finally put. Asked who owns the source code, management characteristically describes where the code resides — in our own repositories, under our own cloud tenancy, in an environment from which nothing can be copied out. The slippage between custody and ownership is not innocent, since digital control over an asset and the identity of the party holding transferable rights in that asset are separable questions, and only the latter yields something a buyer can underwrite. This is precisely where the existence dimension is tested: whether source code ownership sits inside the company as an internally shared assumption, or as a defined structure that traces the chain of rights source by source, in a form that survives being read by someone who did not build the product. Mechanically, the position begins with the rule, common across jurisdictions, that authorship vests in the natural person who created the work, and that the passage of economic rights to the company occurs not automatically but through a contractual act of assignment. Under United States practice, works produced by independent contractors fall within work made for hire only across an enumerated and narrow set of categories, so assuming that rights have vested in the company absent a written and signed assignment is an assumption that diligence rarely accepts. Under Turkish law, the requirement that transfers of economic rights be in writing and that each transferred right be separately identified can, in turn, deprive a single generically drafted employment clause of standalone sufficiency. The origin of the gap is not legal ignorance; for as long as the marginal return on an engineering hour exceeds the marginal return on a legal hour, deferring assignment paperwork is a defensible allocation. The difficulty lies not in the choice but in its persistence after the condition changes — after the company becomes an asset capable of being sold or financed. The documentation dimension separates the existence of an instrument from its currency. An assignment signed in the year of incorporation does not reach code produced in later years by agencies, interns, offshore subcontractors and small acquired teams; and corporate events such as a change of name, the migration of operations into a new legal entity, or an intra-group transfer of the codebase can sever the chain without anyone noticing at the time. Accessibility constitutes a separate threshold altogether, because a document known to exist somewhere but not locatable within the diligence window produces, in practical terms, the same outcome as a document that was never signed. What a mature structure therefore presents is not a stack of executed PDFs but a chain-of-title record that maps each contribution source to its corresponding instrument and that is maintained on the same cadence as the codebase itself. The channel through which this gap reaches valuation is rarely the headline multiple; it is the peripheral architecture of the transaction. What an acquirer purchases in a software asset is not the product but the right to reproduce it, modify it and defend it against third parties, and where the chain supporting that right is incomplete, the response is structural rather than arithmetic: a special indemnity is drafted against the seller, the escrow percentage is raised, and a portion of consideration is deferred past closing and conditioned on completion of the chain. In transactions supported by representations and warranties insurance, the exclusion of an intellectual property matter identified during diligence from policy coverage is an ordinary underwriting outcome, and in that configuration the risk is not distributed to the insurer but returned directly to the seller's balance sheet. The second channel is the calendar. Where a portion of past contributors must be located and asked to execute retroactive assignments, the pre-closing conditions list can extend by weeks, and the effect of that delay on negotiating position is frequently more decisive than the indemnity language itself, since alternative transaction options, financing commitment periods and market conditions all move while the list is being cleared. The third channel is open-source compliance: a copyleft component that obliges derivative works to carry the same license, embedded in the distributed portion of the product, can require either a rewrite of the affected module or a re-examination of the intellectual property indemnities already extended to customers. Operating together, these three channels can render a technically sound product structurally fragile at the transaction table, without a single line of code having been defective. That source code ownership is a measurable domain is not obvious at first reading, yet the indicators the reviewing side consults are unusually concrete: what proportion of the individuals who have committed to the repository is covered by a signed assignment, when the third-party component inventory was last refreshed, whether the license scan runs as a gate on the release pipeline or is executed manually once a year, and what share of code in business-critical modules depends on a single contributor. None of these figures reaches the financial statements, yet each of them answers the same underlying question — whether the company knows more about its own codebase than an external review would independently produce. Where the answer is negative, review duration, adviser cost and finding count all increase in predictable proportion, and every additional finding converts into explanatory burden carried by the seller for the remainder of the process. The ownership dimension explains why this area is left unattended so frequently. Source code ownership sits on the boundary between engineering and legal: the legal function does not look at the repository, the engineering function does not open the contracts folder, and each side reasonably assumes the other is attending to the matter. In an institutionally defined configuration, three distinct authorities are addressed separately — the authority to place an assignment instrument into the signature cycle whenever an external contributor is onboarded, the authority to determine license compatibility whenever a new third-party component is introduced, and the responsibility for periodically verifying the chain-of-title record against the codebase as it stands. These three need not converge in one person; leaving them undefined, however, largely accounts for why the implementation dimension tests weak even in companies that can produce a written policy on request. What the continuity dimension seeks is a codebase that can be administered independently of its founders, and the fragility that surfaces here is more often operational than legal. Repositories held under a founder's personal account, domain and certificate renewals tied to a single personal mailbox, deployment credentials for the production environment residing with one individual, or a build that depends on an undocumented local environment setting — none of these defeats title, but each of them removes the practical exercisability of title. For the reviewing side the implication is unambiguous: an acquirer that receives the rights yet cannot build and ship the product without the founders has not acquired the whole of what it paid for. This is among the most concrete surfaces on which founder dependency converts into a valuation discount, and it is typically priced through an extended earn-out or a transition services arrangement rather than a headline reduction. Establishing this area institutionally requires less a one-off legal clean-up than the joint operation of four components: (a) a chain-of-title record that maps every contribution source — employee, contractor, agency, acquired team, open-source component — to its corresponding instrument and is maintained alongside the codebase; (b) an onboarding gate that conditions repository access on an executed assignment, embedding the process in access administration rather than in anyone's memory; (c) a component inventory and license scan that run as a condition of the release cycle rather than as a periodic manual exercise; and (d) an access matrix demonstrating that repositories, domains, signing certificates and deployment keys are held under corporate identities. What these four share is that they reside in the workflow rather than in individual diligence; any control that depends on personal discipline erodes predictably as the team grows. When BEIREK enters this area, the first artifact constructed is not a policy document but the record itself: a chain-of-title table in which the codebase is decomposed by contribution source, each source is set against the instrument covering it and the date that instrument bears, and every empty cell is flagged as a candidate pre-closing condition. The second step is to prevent that table from remaining a photograph taken once, by attaching control points to the processes that actually move — access provisioning, release cutting and vendor onboarding — so that the record ages in step with the codebase rather than behind it. In the third step, ownership is written down as three distinct authorities allocated across engineering and legal and bound to a periodic verification rhythm, with the result that the question the reviewing side will eventually ask becomes a question the company already asks itself, and the answer is retrieved rather than manufactured inside the data room. Source code ownership presents as a technical matter, yet it is among the clearest available indicators of whether the value a company produces is separable from the people who founded it, because knowledge of who wrote the code persists in institutional memory of its own accord, whereas knowledge of who owns it exists only to the extent it has been documented. What is priced at the diligence table is neither the capability of the team nor the maturity of the product, but the demonstrable convergence of those two bodies of knowledge. When the value of a software asset is under discussion, the operative question is not what the code does; it is how many signatures, and how many weeks, the company would presently need in order to prove its right to it. ## Key Points - Holding code under the company's technical control and holding the transferable rights in that code are two independent questions, and only the second one produces an answer that can be priced at the transaction table. - Economic rights do not migrate to the company by operation of fact; contribution sources without a signed instrument of assignment are typically treated in diligence as unverified rather than as merely undocumented. - A gap in the chain of title generally converts into a special indemnity, an elevated escrow percentage and an extended closing timetable rather than into a visible reduction of the valuation multiple. - Where the third-party component inventory and the license scan are not tied to the release cycle, a copyleft component embedded in the distributed portion of the product can force a rewrite or a re-examination of customer-facing IP indemnities. - Repositories, domains and deployment keys held under personal accounts do not defeat legal ownership, but they render that ownership unusable, and the market prices this as founder dependency. ## Questions ### Does ownership of software written for a company pass to the company automatically? It cannot be assumed to. In most jurisdictions authorship vests in the individual who wrote the code, and the passage of economic rights to the company depends on a written act of assignment. Where contributions came from independent contractors, agencies or freelancers and no such instrument exists, the chain of title is treated as incomplete. Turkish law additionally requires each transferred right to be separately identified, so a single generically drafted contractual clause may not suffice on its own. ### How is source code ownership actually proven during due diligence? Proof lies in tying contribution sources to instruments, not in demonstrating where the code is stored. The reviewing side typically reads the repository contributor list, the assignment provisions in employment and contractor agreements, the transaction documents covering acquired teams, and the third-party component inventory as a single body of evidence. A current chain-of-title record mapping each contribution source to its corresponding instrument materially shortens the process and reduces the number of findings generated. ### Does using open-source libraries reduce a company's valuation? Use itself does not; uncontrolled use does. What matters is whether the component inventory is kept current and whether the license scan runs as a gate on the release cycle. Where a component requiring derivative works to carry the same license is embedded in the distributed portion of the product, either a rewrite of the affected module or a re-examination of the intellectual property indemnities already given to customers may follow, and both consequences surface in indemnity language and in the closing timetable. ### Why is a repository held under a founder's personal account treated as a risk? Because it removes the exercisability of ownership even where it does not defeat ownership itself. Where repositories, domains, signing certificates and deployment keys are attached to personal identities, the party receiving title cannot build and ship the product independently of the founders. Under the continuity dimension this reads as founder dependency, and it is generally priced through an extended earn-out, a transition services agreement, or a pre-closing condition requiring migration to corporate identities. --- Source: https://www.beirek.com/en/blog/source-code-ownership-due-diligence Publisher: BEIREK LLC — https://www.beirek.com