Source code ownership and licensing: questions for your vendor

01Separate ownership, permission and access

Ownership identifies who holds relevant intellectual property rights. A license grants permission to do specified things under specified conditions. Access concerns whether your team can obtain the code and supporting assets. These are related decisions, but one does not automatically settle the others.

For example, a supplier might grant a durable license to a reusable reporting framework while assigning rights in your custom business rules. That arrangement can support long-term independence if another maintainer can use the framework as required. Calling the whole application yours without documenting the exception leaves a costly ambiguity.

Copyright rules vary by jurisdiction and by how the work was created. As a United States example, the Copyright Office publishes the ownership and transfer rules, including the distinction between owning a copy and owning copyright. Do not assume that paying an invoice transfers every right internationally.

Have counsel assess the intended arrangement under the contract’s applicable law, including subcontractor contributions and any formalities for assignments. The commercial brief should explain the activities you need; legal drafting then has a concrete target. A copied clause with no delivery context can miss both.

Ask when the agreed rights take effect and what happens during a payment dispute or termination. Your business may need continuity while an unresolved invoice is being discussed. The answer should specify the relevant deliverables and trigger, rather than relying on a verbal promise that everything will be handed over later.

02Map custom work and third-party components

Request an inventory that reflects the actual delivered version. Include packages, plugins, paid services, fonts, design files and deployment tooling where they affect ongoing use. A list of major frameworks alone can miss the proprietary component that prevents a new team from building the product.

SPDX provides standardized license identifiers that make component records more precise. An identifier helps people agree which license they mean; it does not establish that all obligations have been met or that a scanner has identified every embedded component.

Ask how the supplier checks new dependencies and records changes during maintenance. Review responsibility should continue after the first handover. An application with a clear original inventory can become difficult to transfer if later fixes add undocumented paid modules or code with different conditions.

For an illustrative customer portal, separate the custom authorization rules from the UI library and the email delivery service. Determine who controls each service account, whether another supplier may modify the custom rules and which third-party terms remain relevant. This turns a broad ownership debate into answerable questions.

03Make the license match your future plans

Describe expected use beyond today’s deployment. You may add a subsidiary, open a new market, offer a customer-facing service or sell the business. A license that permits one internal installation may not support those plans. Ask about users, entities, territory, hosting and duration explicitly.

Confirm that authorized maintainers can inspect, modify, test, build and deploy the necessary code. If they need access to a supplier framework, define the permission and confidentiality requirements that make that possible. Permission to run a compiled application does not necessarily cover developing a replacement component.

Address exclusivity with a business reason. You may need protection for a distinctive process without requiring exclusive ownership of a common login utility. Identify what must remain confidential and what the supplier may reuse. Overbroad language can make the agreement difficult to perform without improving continuity.

Treat recurring license fees and external subscriptions separately from development fees. Ask which charges stop the system working if unpaid, which can be replaced and how renewal decisions are communicated. Do not estimate future cost from a single hosting quote that excludes required services.

Record whether rights survive ordinary contract termination and how they can be transferred to a buyer or reorganized entity. These are negotiation questions, not universal default entitlements. A supplier’s standard terms may work for a small pilot but need adjustment for a business-critical platform.

04Use open source with its actual conditions

The Open Source Initiative’s definition covers rights to use, modify and redistribute under qualifying licenses. Seeing source code is insufficient to establish that software is open source. A source-available proprietary component may offer inspection while restricting commercial use or redistribution.

Ask for the exact license and version, rather than accepting labels such as free library or industry standard. Assess how the component is used and delivered. Different licenses attach different conditions, and those conditions require an assessment of the actual application rather than a blanket statement about all open source.

Keep notices and other required material with the deliverable. Where an obligation depends on distribution or another triggering activity, document how the product reaches users. An internal server application, a downloaded desktop client and a distributed SDK should not be treated as interchangeable use cases.

Have an appropriate reviewer assess difficult license combinations and changes before release. The aim is to understand the obligations while there is time to choose a different dependency. A last-minute license report can leave the team negotiating or replacing a central component under pressure.

Open source can reduce dependence on a proprietary supplier, but it does not remove maintenance responsibility. Ask who follows security updates, decides when to upgrade and tests compatibility. A legally usable library still needs an operational owner when the original implementation team leaves.

05Demand a handover that another team can use

Agree the repository location, access roles and delivery cadence at the start. Customer-controlled accounts can simplify continuity, provided permissions and operating responsibilities are clear. Whatever arrangement you choose, avoid making the only working copy depend on a former employee’s personal account.

• Source code with relevant history and a clearly identified release.
• Dependency lock files, configuration examples and reproducible build instructions.
• Database schema, migration procedure and documented integration contracts.
• Deployment steps, operating runbooks and a tested backup restoration procedure.
• Editable design assets, license records and a list of customer-owned service accounts.

Keep secrets out of ordinary source archives and transfer access through a controlled process. Rotate credentials when responsibilities change. The receiving team needs permission and configuration guidance, not a spreadsheet of permanent passwords copied across unrelated suppliers.

Set an acceptance exercise in which a person who did not implement the system follows the documentation in a clean environment. Have them build it, run meaningful checks and explain deployment. Record missing steps and resolve them before treating the handover as complete.

Include operational data as a separate deliverable. A code repository does not contain the customer records, attachments or service configuration needed to resume operations. Agree export formats, identifiers and a reconciliation process so the business can verify that the transferred information is usable.

For a supplier that has already stopped responding, the website, domain and code takeover guide addresses the immediate access problem. Use the findings from that recovery to improve the next contract’s delivery and transition requirements.

06Make exit arrangements part of acceptance

Define the assistance available when you change maintainers: its scope, access window, fees and responsible contacts. Identify how unfinished work, outstanding defects and supplier-managed accounts are handled. A transition promise is useful only when both sides understand what the departing team must actually do.

Escrow can be appropriate when ordinary source access is unavailable, but evaluate its release conditions and deposit quality. An old archive released after a triggering event may still lack dependencies or permission to operate external services. Ask how the deposited release is kept current and verified.

Prepare a short decision record for each unresolved issue: affected component, business consequence, proposed contractual treatment and delivery proof. This helps procurement, legal and engineering review the same problem. A clause can then be assessed against a practical scenario instead of a vague demand for total ownership.

Do not sign off solely because the application works in the supplier’s environment. Acceptance should cover the promised operating capability, the agreed rights and the delivery materials. A smooth demo establishes useful behavior, but it does not establish that another team can maintain it next year.

Review these arrangements whenever the product changes materially. A new mobile client, a resale model or an acquired subsidiary may introduce a different use case. Keep the component inventory and legal scope aligned with the software you are actually operating.

07Questions about software rights and handover