Open-Source vs Proprietary Code in Business Applications

The distinction between open-source and proprietary code matters to your business because it affects what you can do with the software, what obligations sit around it, and who controls its future. But the practical reality is that nearly every business web application uses a mixture of both. The question is not whether to use open-source code at all, but where the boundaries sit and what that means for your rights and risks.

Decision summary: Assess component licences, support, update routes, replacement options and exit risk rather than treating either label as inherently safer.

Proprietary code is software whose source code is owned by a specific party and distributed under a licence that restricts what others can do with it. You typically receive a right to use it, sometimes to modify it, but not to redistribute it freely. When you commission a custom CRM, portal or internal tool, the code written specifically for your business should be proprietary to you — assuming your contract is structured that way. The supplier builds it, you pay for it, and you own the result.

Open-source code is software whose source code is made publicly available under a licence that grants certain rights to use, study, modify and distribute it. Those rights come with conditions. Some licences, such as MIT and Apache 2.0, are permissive: they allow you to use the code in proprietary applications with minimal obligations, usually just preserving the original copyright notice. Others, such as the GNU General Public Licence (GPL), are copyleft: if you incorporate GPL-licensed code into your application and distribute it, you may be required to make your entire application's source code available under the same licence. That distinction has direct commercial consequences.

The confusion arises because most business applications are not built from scratch. They sit on frameworks, libraries and packages — many of which are open-source. Your custom business logic, your database schema, your integration code and your user interface might all be proprietary, but the application likely depends on open-source components for fundamental functions: handling HTTP requests, encrypting data, rendering pages or managing background tasks. Understanding which components are which, and what licences they carry, is a basic part of responsible software ownership.

Licence obligations matter more than the label

Open-source and proprietary components can both be appropriate. The practical review should identify each dependency, licence, notice, source-disclosure or redistribution obligation, update route, support position and replacement option. “Open source” does not automatically mean free of cost or risk, and “proprietary” does not automatically mean unsupported or locked in.

Internal tools and admin panels

For internal systems that never leave your organisation — admin panels, reporting dashboards, workflow tools — the copyleft question is less pressing because you are not distributing the software externally. GPL-licensed components can generally be used without triggering an obligation to publish your source code. However, internal use does not eliminate other concerns: you still need to track what is installed, keep it updated and understand the security profile of each dependency.

Customer-facing portals and SaaS products

When your application is delivered to customers as a service, the legal position around copyleft licences becomes more nuanced. Some copyleft licences were written with software distribution in mind, and whether providing access over the web counts as distribution has been debated for years. Newer licences such as the AGPL were specifically designed to close that gap. If you are building a SaaS product, your development team or legal adviser needs to review the licence of every significant open-source component before it is adopted, not after.

Permissively licensed open-source components — MIT, Apache 2.0, BSD — are widely used in commercial SaaS products precisely because they allow the business to retain full control over its own code while still benefiting from community-maintained infrastructure.

Replacing or extending legacy systems

When modernising an older application, you may discover that it depends on open-source libraries that are no longer maintained, or that its proprietary components were built by a supplier who retained ownership. In both cases, the open-source versus proprietary question shapes your options. An unmaintained open-source dependency can be forked and patched if you have the capability, or replaced if you do not. A proprietary component that you do not own may need to be rebuilt or re-licensed before you can make changes safely.

Support and long-term maintenance

Proprietary software from a commercial vendor typically comes with a support contract, defined service levels and a party legally responsible for fixes. Open-source software offers no such guarantee. Support comes from the community, from paid consultants, or from your own team. For business-critical components, the relevant question is not whether the code is open-source or proprietary, but whether there is a clear, funded path to keep it secure and functional over the period you need it.

Assuming open-source means no obligations

Every open-source licence imposes conditions. Failing to comply — for example, by stripping copyright notices or distributing copyleft-licensed code without meeting the terms — creates legal risk for your business. Before any open-source component is added to your application, someone should read and record the licence terms. This is a routine part of professional software development, but it is frequently skipped in smaller teams or rushed projects.

Not maintaining an inventory of dependencies

A typical business web application may depend on dozens or hundreds of open-source packages, often pulled in indirectly by other packages. Without a clear inventory — a software bill of materials — you cannot know what licences apply, which components have known vulnerabilities, or what needs updating when a security advisory is published. Ask your supplier how they track dependencies and whether they can produce a current list on request.

Confusing ownership of your code with ownership of the components

Your contract with a development supplier should specify what code you own. That normally covers the custom code written for your project. It does not cover the underlying frameworks, libraries and packages that the application depends on. Those remain subject to their original licences. A clear contract separates your proprietary code from the third-party components, so there is no ambiguity about what you can control and what you are simply licensed to use.

Accepting a supplier's word on licence compliance

If a supplier tells you that all open-source components are permissively licensed and pose no risk, ask for evidence. A dependency audit, a licence report or a software composition analysis output is a reasonable request before you accept delivery. This is particularly important if you are acquiring an existing system or taking over from another supplier, where the original development choices may not be well documented.

Overlooking update responsibility in support agreements

Open-source components receive security patches regularly. If your support agreement covers only your custom code and not the underlying dependencies, you may be paying for maintenance while the most urgent vulnerabilities sit in components nobody is watching. Clarify in writing whether ongoing support includes monitoring and updating open-source dependencies, and at what frequency.

Key questions to put to a supplier

• Can you provide a current list of all open-source components and their licence types?
• Are any components under copyleft licences, and if so, what is your assessment of the impact on our application?
• How do you monitor these components for security vulnerabilities after delivery?
• Does our support arrangement cover dependency updates, or is that a separate scope?
• Which parts of the delivered code do we own outright, and which parts are subject to third-party licences?

Understanding the open-source and proprietary makeup of your business application is not a technical nicety. It affects what you can legally do with the software, how you can maintain it, and what happens if you need to move it to another supplier. Treat it as a standard part of due diligence, not an afterthought.

Contract points to settle before signature

• Identify which signed document controls if schedules, proposals or emails conflict.
• Obtain current legal advice for the actual parties and transaction before relying on contractual wording.
• Make the contract, schedules, statement of work and change-control process consistent with one another.
• Distinguish ownership, licence rights, practical access and third-party restrictions.

Primary guidance checked for this edition

Sources for “Open-Source vs Proprietary Code in Business Applications” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.

• UK IPO: Ownership of copyright works
• GOV.UK: Model Services Contract
• ICO: Contracts between controllers and processors