Software Source Code License Grant

Software Source Code License Grant: a practical guide

A Software Source Code License Grant records permission for one party to use specified software source code under agreed conditions. It helps the Licensor and Licensee clarify what the Licensee may do with the code and which rights the Licensor keeps.

What it's for

People use this document when a developer or other rights holder wants to let a client use source code without transferring ownership of it. The grant can describe permitted uses, such as running, copying, changing, or sharing the code, and any limits on those uses.

The parties should identify the code clearly and discuss how it fits with the project, any deliverables, and the fee. If the intent is to transfer ownership rather than grant permission to use the code, a Copyright Assignment Agreement may be a better fit.

A license for custom code does not automatically cover every tool or component used to make it. The parties should identify third-party or open-source components and check which permissions apply to them before relying on the grant.

Who uses it

• A software developer licensing custom code to a client.
• A small business receiving permission to use software built for its operations.
• A contractor and client clarifying rights to code delivered as part of a project.
• A company licensing code it owns to another business for a defined use.
• Parties who want to separate permission to use code from ownership of that code.

Terms to decide on

Code covered by the grant

Name the software, version, repository, files, or project deliverables as clearly as possible. State whether the grant covers updates, documentation, libraries, or other materials as well.

Permitted uses

List what the Licensee may do, such as run, copy, modify, or distribute the code. Describe any limits on users, projects, devices, or business activities in direct terms.

Ownership and prior materials

Say who keeps ownership of the code and whether the Licensor can reuse general tools, routines, or earlier code. Identify any parts created by someone else and do not promise rights the Licensor does not have.

Exclusivity and sublicensing

State whether the grant is exclusive or nonexclusive. Say whether the Client may let affiliates, customers, or other service providers use the code, and what conditions apply.

Duration and end of use

Specify when permission starts, how long it lasts, and what happens if the project ends or a party ends the arrangement. Explain whether the Client must stop using or delete copies of the code.

Fee and delivery

Clarify whether the fee covers the license as well as development, and when payment is due. Describe how and when the source code and any agreed materials will be delivered.

Third-party components and support

Identify components with separate terms and explain who is responsible for obtaining any needed permissions. State whether updates, maintenance, help, or fixes are included or handled separately.

Common mistakes

• Describing the licensed code only as “the software” can leave both sides unsure what is included. List the project, version, files, or deliverables that the permission covers.
• Using broad words like “use” without saying what they include can cause disagreement over modification, copying, or distribution. Write each important permission and restriction plainly.
• Assuming a license transfers ownership can create a mismatch in expectations. State whether ownership stays with the Licensor or is meant to change.
• Granting rights to code that includes third-party components can overstate what the Licensor controls. Check each component’s terms and describe any separate permissions the Licensee needs.
• Leaving sublicensing unaddressed can cause problems if the Client needs customers, affiliates, or contractors to access the code. Say who may receive access and for what purpose.
• Failing to say what happens when the arrangement ends can leave copies and continued use unclear. Describe the steps each side must take at that point.

Before you sign

• Confirm that the parties and each person signing for a company are named accurately.
• Check that the code, versions, files, and related materials covered by the grant are identifiable.
• Read each permission and restriction from both sides’ perspective, including modification and sharing.
• Confirm who owns the code and which prior or third-party components are included.
• Review the fee, delivery, license duration, and what happens when the arrangement ends.
• Add any project-specific support, update, confidentiality, or security terms in Additional Terms & Provisions.
• Check local rules for signing, witnesses, notarization, registration, notice periods, or required wording where the document will be used, or ask a qualified lawyer when much is at stake.