Buy vs. Licence: Who Should Have Ownership of Software Source Code?

Louise Clayton

In 2022, startups outsourced 21% of their software development; in 2023, this number is expected to reach 36%.¹ As more companies seek the support of external developers, the question of who should own software source code is becoming increasingly important.

But for many businesses, code ownership is not top of mind when seeking out a software development company and service — after all, it feels intuitive to assume that if you are buying an application or piece of software, you will then own it. However, in the world of software engineering and application development, this is often not the case.

There is no easy answer to the question of who ‘should’ or ‘shouldn’t’ own source code: both buying and licensing have a range of different benefits and challenges.

In this article, we’ll explain what source code ownership really entails, and consider what impact it can have on a business.

Suggested reading: Read our eBook, ‘Legacy Systems are Costing Your Business Growth’, to learn more about why cloud innovation is so important.

What is the default for software source code ownership?

Questions regarding software source code ownership affect a range of sectors, from application development to SaaS and IT. As a whole, the ‘default’ for source code ownership is a licence; certainly in SaaS and low-code development, the source code will always be owned by the provider.

Unless specified otherwise, most custom-built applications default to licensing rather than ownership. However, this is something that is typically established on a 1:1 basis between the software developer and their client during the development discovery phase.

Both parties are responsible for transparently discussing what level of ownership they are looking for, and where they see the application going in the future. This applies in the same way to agreements between independent contractors or freelancer developers and their clients.

The main reason for provider-owned code being the default is because software source code often integrates third-party licences and open-source software (OSS), which is not owned by the developer; they are not, therefore, allowed to sell it as a whole.

Section 3: Client-owned software source code

It’s estimated that by 2025, 70% of new applications will use low-code or no-code technologies — a sign of the steady decline of client-owned software source code.² However, there are a number of valuable reasons that a client might choose to request ownership of the source code:

Budget: they have the budget and capability to manage upgrades and code changes in-house.
Long-term goals: they want to be able to copy, sell, or modify the code in the future.
Protection: they want to ensure the source code is not used in other applications, for example, by their competitors.

Let’s explore some of the key benefits and potential drawbacks of code ownership in more depth:

High and long-term costs

It’s well-known that the cost of buying an application through custom development and implementing cloud innovation can be expensive. Adding software source code to this price will undoubtedly make the costs higher.

Like most other commercial products, source code is expensive for a reason: an application development company will likely have spent many years creating and refining its application development process, so the code that they write is highly valuable. As well as the upfront cost, those who own their source code will also face long-term costs associated with:

Ongoing maintenance of the application
Ensuring code bugs are fixed quickly
Potentially extending their in-house application management team

However, if the buyer has a strong financial base and is willing to accept these costs in exchange for full ownership of their application, then they can arrange this directly with their tech partner.

Intellectual property

One of the greatest benefits of owning your own source code is the independence it grants you. Companies that have code ownership can do whatever they want with the application as it becomes their intellectual property, and they are not bound by copyright law.

It is worth noting that it is reasonably easy to reach this same independence with the correct licence and contractual agreement — so this benefit should not necessarily be the biggest incentive for owning or not owning your code.

Purchasing the source code could be most beneficial for companies that:

Have in-house capabilities and are confident managing their code in the long term.
Want to change their code in the future.
Foresee extensive business changes in upcoming years that may make working with a developer or management team difficult.

Pro tip: Companies that are not confident in application management, and particularly cloud-native applications, are generally advised not to purchase their code for these very reasons: without the right expertise, they could risk their application architecture becoming unstable.

Although most custom applications can be managed by external developers, there is a risk with ownership that quirks in the code or non-standard code practices will put managed support providers off.

Unique application

Clients who purchase the source code for their application are guaranteed a unique piece of software — no other company will use the same code as them. This makes it a good choice for companies looking for a highly individual piece of software, and who don’t want to rely on any pre-existing open-source or third-party code.

Again, this should not necessarily be the main incentive for owning or not owning a piece of code. After all, a custom-built application will be completely unique to the company at hand, whether or not it is used via licence or via full ownership.

One final and less commonly mentioned benefit of owning the source code is that it can then be sub-licensed to other users, or if a business wants to stand out from competitors, it can limit its use to ensure exclusivity. The owning company will be bound by tight national licensing regulations, but this can provide a long-term source of income that helps to negate the upfront cost of the application.

Section 4: Licensed software source code

As we mentioned at the start of this article, licensed software source code can include any applications built through SaaS, generic application building programs, or custom development. The practice of code licensing is often preferred by developers — but this doesn’t make it bad for the client by any means.

Developer-owned source codes will often be bound by what is known as an ‘irrevocable perpetual licence’ (IP licence), which provides the client with full control over their application. Clients might opt for source code licensing due to:

Maintenance responsibilities: they do not want to be responsible for maintaining their code, and would rather employ bespoke application support.
Neutral stance: they are happy for the developer to use parts of their code in other applications.
Faster development: they do not want to slow down the development process by prohibiting the use of ‘code in the cupboard’ — code that has been used in other builds.
Budget: they do not have the budget to purchase the code and do not want to shoulder the long-term costs.

Although there are a number of websites promoting source code ownership, it is quite simply not a viable option for many companies or developers.³ This is due largely to the cost, time, and resources that it demands.

For example, if part of an application is reliant on a third-party product such as software development kits, then there is no benefit in owning the IP of the custom code that sits around it, as the client would never own all the IP for a fully functioning system.

Pro tip: See our pricing page to learn more about the typical cost of custom cloud application innovation.

Types of licence

The type of licence you choose will ultimately dictate what your experience of code licensing is like. As a general rule, licences can be divided into two key categories:

Copyleft: the code is made open-source, allowing it to be used and modified by anyone. The purchaser can run, modify, and distribute the software as they would like, but it has to remain open-source. As you might be thinking, this kind of licence is not the best choice for those working within highly competitive industries.
Permissive: this type of licence typically gives clients a lot of freedom, and includes the well-known ‘irrevocable perpetual royalty-free licence’. This allows clients to maintain and modify the source code without owning the IP, and add restrictions to the licence to prevent the software developer from building a competitor’s app for a certain number of years.

Now that we’ve established the two primary types of licence — each of which has dramatically different results and benefits — let’s explore the more general pros and cons of source code licensing:

Lower costs

The most straightforward benefit of developer-owned software source code is that it significantly lowers costs in what can already be an expensive purchase. Although the client may have to purchase additional code upgrades later down the line, these are likely to be few and far between.

Clients are able to have a clearer understanding of all the costs associated with their new application, and can then develop budgets accordingly. However, if the client then goes on to sell their project or application, they may run into difficulties regarding intellectual property and software development regulations.

Pro tip: SaaS, custom application licensing, and low-code applications are all lower-cost than custom source code ownership — however, they have varying degrees of flexibility. Read our blog on power apps vs custom builds vs SaaS to learn which solution might be the best fit for your business.

Developer-dependent

One of the most discussed drawbacks of licensed source code is that it supposedly leaves the client developer-dependent. This, in turn, can lead to ‘vendor lock-in’, a scenario in which clients are stuck using a single software developer and may be exposed to increasing costs, poor business relations, and reduced ROI.

However, there are straightforward ways to mitigate this risk. If you have the right licence type, you should be able to take your code to any other developer or supplier and be completely developer-independent.

Vendor lock-in can also be avoided through the use of a source code escrow agreement or clause, which indicates that, in the case of a specified event, the source code will be released to the licensee. For example, if the developer becomes insolvent, this clause will allow the licensee to gain total control of their code.

While some view ‘developer-dependency’ (and we use this term with a pinch of salt) as a drawback, others view it as a benefit: if upgrades or alterations to the source code are needed, the original developer can ensure these are done in good time so as to reduce downtime and maintain system stability. A company that owns its code may not have the time to collect resources, train staff, or locate a provider to fix its system in adequate time.

Unique application

Licensed software source codes often use a range of open-source and third-party software, which allows the application to be developed:

Quickly — though this may depend on the type of application being developed.
At a lower cost than using custom code.
According to established, industry-standard best practices.

Typically, developers will only recycle small sections of their code and will develop custom code for everything else. This means that the end product of an application where the code is licensed is unlikely to actually bear any resemblance to other applications created by the same developer.

Licensed-code applications are also typically more stable and secure, as the open-source software (OSS) used within them is employed worldwide. This means that if patches or upgrades are needed, they can be done more quickly — as Wilson Center Science and Technology Innovation Program experts recognise:

‘OSS has another benefit for cybersecurity writ-large; unlike proprietary code and packages, there is an active community to alert, fix, and mitigate exploits in OSS’.⁴

This should not be relied on alone as a security defence — but can be a key consideration for those considering whether they are happy with OSS being used in their application.

Suggested reading: Read our blog, ‘What is the Future of Cloud Security?’, to learn more about developments in the cloud application security landscape.

Buy vs licence: does it really matter?

As we’ve established, there are a range of benefits and downsides to both sides of this debate. Does it really matter which option you choose?

In short, yes. However, this is not a black-and-white choice: it depends hugely on the short, medium and long-term needs of the company at hand, as well as its resources and limitations. The key points you should consider before deciding whether to purchase the software source code of your application are:

The size and skill of internal IT teams: would your team be able to quickly fix source code bugs or do upgrades at short notice?
Initial budget: buying the source code makes application development significantly more expensive. Do you have the upfront (and ongoing) budget for this to be sustainable?
Long-term goals: if you are hoping to sell your application in the future, it may be worth buying the code. If not, this may be an unnecessary cost.
Speed of development: do you require a custom application to be developed at a reasonable speed, such as in two to three months? In this case, licensing may be a better choice as it can use ‘in the cupboard’ code. A larger project or full roadmap may take between one and five years, and will have more flexibility with regard to which ownership option you choose.

Cloud-native applications that make an impact

Talk Think Do is an industry-leading cloud application development company, offering application innovation services that support clients from project discovery to post go-live support.

During the discovery phase, we work alongside clients to fully define and clarify the goals of the project, to ensure that they receive an application that meets all of their unique business requirements. We can advise on whether you might benefit from owning the source code of your application, helping to minimise risks in delivery and ensure that every decision is made with your best interests at heart.
Book a consultation today to discuss how our application innovation service could help you.