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

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. 

Introduction to Software Source Code

In the world of software development, source code is the foundation upon which all applications are built. It is the set of instructions written by programmers that tells a computer how to perform specific tasks. Understanding the intricacies of source code is crucial for businesses and developers alike, as it directly impacts the functionality, security, and maintainability of software applications.

What is Source Code

Source code is the written set of instructions that a programmer writes to create a computer program. It is written in a human-readable format using a computer programming language, such as Python, JavaScript, or Java. The source code provides the instructions for how the computer program will function and respond to user interactions. Programmers write source code using a text editor or an integrated development environment (IDE), which provides features such as syntax highlighting, auto-completion, and debugging tools. The source code is then translated into machine code, also known as object code, which the computer can execute. This process is called compilation, and it is an essential step in software development.

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.

Management systems play a crucial role in overseeing and organizing source code development. They are essential for version control, collaboration among developers, and tracking various stages of project development, ensuring that modifications are documented and that team members can effectively manage multiple coding projects.

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

Automated tools are vital in maintaining and enhancing the quality of source code. These tools not only improve productivity but also play a crucial role in identifying bugs and security vulnerabilities, thus contributing to the creation of more reliable and secure software.

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, especially for complex projects.

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

Modifying source code is crucial for long-term maintenance, especially in open source projects where collaboration and innovation are encouraged.

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.

Additionally, the original source code is transformed by a compiler into non-human-readable executable code, which is essential for the application to run on machines.

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.

Furthermore, it is important to understand the distinction between closed source and open source software. Closed source, or proprietary code, is private and restricted, owned by individuals or companies with strict limitations on modifying or sharing the code, contrasting with the collaborative nature of open source.

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. For instance, there are numerous examples of unique applications that demonstrate how different programming languages handle similar tasks, such as the classic ‘Hello, World!’ program.

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. Additionally, sharing code within the open-source community fosters innovation and collaboration, allowing developers to customize applications and contribute to various projects.

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. Integrated development environments (IDEs) play a crucial role in licensed software development by allowing developers to create code more efficiently and in an organized manner compared to simple text editors.

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.

Visual programming tools, such as LabVIEW and Bubble, offer an alternative to traditional coding by allowing users to create software visually, often employing block diagrams. These tools are categorized into ‘no-code’ and ‘low-code’ systems, making them accessible to users with varying levels of coding expertise.

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. Access to the source code allows skilled users to customize the software and enables programmers to contribute to the community by sharing and modifying code.
• 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. Other developers can utilize the licensed source code to create similar programs for different operating platforms, facilitating software customization and community collaboration among programmers.

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. Additionally, licensed source code is valuable for learning purposes, as it allows developers to share and study code, enhancing their programming skills through practical examples.

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. Moreover, understanding the output generated by the source code is crucial for cost-effective software development, as it helps in evaluating the efficiency and functionality of the application.

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. Understanding source code is essential not only for computer programmers but for anyone interested in software development. Computer programmers play a crucial role in managing licensed source code, employing various tools and programming languages to create and maintain programs.

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. Executing tasks such as performing calculations and outputting results is fundamental in maintaining system stability, regardless of the specific programming language used.

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.

Web development plays a crucial role in creating unique applications by utilizing various programming languages to manage website elements and instruct how a computer program operates.

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.

Structure is essential in developing stable and secure applications, as it defines the organization and arrangement of code and content within programming languages and web development.

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’.4

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.

Software Development Process and Ownership

The software development process involves several stages, including planning, design, implementation, testing, and maintenance. During the implementation stage, programmers write source code using a programming language, such as C++ or Python. The source code is then compiled into object code, which is executed by the computer. The ownership of source code is an important aspect of software development, as it determines who has the rights to modify, distribute, and use the software. There are two main types of software ownership: open source and proprietary. Open source software allows users to modify and distribute the source code freely, while proprietary software restricts the use and distribution of the software. Companies and developers use licensing agreements to protect their intellectual property and control the use of their source code.

Code Management and Ownership

Code management is the process of organizing, maintaining, and tracking changes to source code files. It is an essential aspect of software development, as it ensures that the source code is accurate, complete, and up-to-date. Programmers use version control systems, such as Git, to manage and track changes to the source code. These systems allow multiple developers to collaborate on a project, and they provide a history of changes made to the source code. Code ownership refers to the rights and responsibilities associated with the source code. It determines who has the authority to modify, distribute, and use the software. Developers and companies use code analysis tools, such as code review and unit testing, to ensure that the source code is of high quality and meets the required standards. By managing and owning the source code effectively, developers can create high-quality software that meets the needs of users and is easy to maintain and modify.

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. Certain languages provide specific conveniences and are better suited for particular domains, influencing the decision to buy or license source code. 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. Programming languages play a crucial role in source code ownership, as different programming languages, such as Python, JavaScript, and C++, provide specific functionalities and influence the development process.

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. Our expertise extends to developing software for various operating systems, ensuring seamless integration and performance across different platforms.

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. This source code is crucial for creating and managing computer programs that drive cloud-native applications. Book a consultation today to discuss how our application innovation service could help you.

Software Development Outsourcing To Grow 70% by 2023: Report – Spiceworks

Low-code tools can fill a void caused by the Great Resignation | Computerworld

What is source code? How it works and why you should own yours. | Codebots

Open Source Software and Cybersecurity: How unique is this problem? | Wilson Center