Open Source Licenses and Code Ownership in Business Software Projects: What to Check Before It Is Too Late

Almost every modern business application is built on open source components. Web frameworks, interface libraries, databases, build tools, and even small parts such as a PDF generator often come from projects with open licenses. That is a good thing: costs fall and development is faster. But behind it sit two legal questions that often surface too late: what are our obligations under the licenses of the components we use, and who actually owns the code a vendor builds for us?

These questions become very real when a company wants to sell or bring in investors, go through due diligence, switch vendors, or simply sell a software product to customers. This article covers the basics of open source licensing in business language, the difference between ownership and licensing, the contract clauses to check, and simple habits for keeping your code legally clean. It is not legal advice; for important decisions, involve counsel who understands intellectual property.

Summary

• Open source does not mean no rules: every component has a license with different obligations, from merely giving attribution to opening your own code
• Permissive licenses such as MIT, BSD, and Apache 2.0 are generally safe for commercial products; strong copyleft licenses such as GPL and AGPL need special attention
• Ownership of custom code does not automatically pass to the payer unless the contract says so; check the intellectual property clause before the project starts
• Ask the vendor for a component list (software bill of materials) and a license report, and keep them as part of project documentation
• Small habits such as an approved license policy, automated scanning, and recording attributions prevent costly problems during due diligence

Open source does not mean no rules

The term open source is often misunderstood as free and usable for anything. In truth, open source code is released under a license, an agreement that grants certain rights on certain conditions. You may use it, often for commercial purposes, but you must meet its conditions. Breaching them can mean losing the right to use, legal claims, or an obligation to open your own code.

Because modern applications contain hundreds or even thousands of components, including components brought in by other components (transitive dependencies), nobody can remember them all. That is why license management must be a process, not someone's memory. The security side of third party components is covered in the article on dependency and software supply chain security; licensing is the legal side of the same problem.

Three license families to know

There are hundreds of licenses, but for business decisions it is enough to understand three broad groups and their implications. The descriptions below are general; the actual license text always governs.

1. Permissive licenses

Examples are MIT, BSD, and Apache 2.0. These give wide freedom: you may use, modify, and distribute the code, including in closed source commercial products. The main obligation is usually to include the copyright notice and license text. Apache 2.0 also includes a patent license grant that protects users from patent claims by contributors. This group is generally the easiest and safest for business.

2. Weak copyleft licenses

Examples are LGPL and MPL. If you modify the component itself, those changes must be shared under the same license, but your own code that merely uses it as a library can remain closed, subject to conditions about how it is linked. Care is needed in how the component is connected to the application.

3. Strong copyleft licenses

Examples are GPL and AGPL. In principle, if you include such a component in a product you distribute, the product as a whole must be under the same license and the source code must be made available. AGPL extends this to software run as a network service: users of your service may be entitled to request the source code. For companies that sell products or run a SaaS platform, a GPL or AGPL component that slips in unnoticed can become a big problem. It is not forbidden, but it must be a deliberate, reviewed decision.

Beyond these three groups there are also source available licenses and licenses with commercial use restrictions, which sometimes look like open source while limiting how the software may be used. Read the license; do not rely on the label alone.

The difference between ownership and a license

These two concepts are often mixed up and are a source of disputes in custom software projects.

• Copyright ownership: who holds the rights to the code as a work. In general, copyright in code initially belongs to its author, or to the company where an employee wrote it within an employment relationship, unless another agreement says otherwise
• License: permission to use the code, which can be granted without transferring ownership, and can be exclusive or nonexclusive, limited in time, territory, or purpose

As a result, when you pay a vendor to build an application, the code does not automatically become yours. If the contract is silent, the vendor may still hold the copyright and you may only have a permission to use whose scope is unclear. That is enough to become a problem when you want to modify the application yourself, move to another vendor, or sell the company. This topic touches on key points in a software development contract and how to choose a software house.

Contract clauses to check

When reading or negotiating a development contract, look at the following. Consult counsel for the exact wording.

• Assignment of rights: whether copyright in the work product is transferred to you after full payment, and from when
• Scope of deliverables: whether it includes full source code, build scripts, documentation, designs, and configuration, not just the finished application
• Vendor background components: whether the vendor uses internal libraries or its own framework that are not transferred, and how those components are licensed
• Third party components: the vendor's duty to declare the open source and commercial components used and their licenses
• Warranties: the vendor's statement that the code does not infringe others' rights and does not contain code that violates licenses
• Indemnification: who bears the cost if an intellectual property infringement claim arises
• Code custody: the duty to deliver code to a repository you control, not only in the vendor's account
• Continuity: access to code and documentation if the vendor ceases operating or the relationship ends

If the vendor wants to reuse parts of the code for other clients, this can be agreed explicitly, for example with a license to the vendor over generic components and a clear separation from your specific business logic. What matters is that it is written down, not assumed.

A component list: the basis of all license management

A software bill of materials (SBOM) is a list of all components that make up an application, with their versions and licenses. This document is increasingly requested by corporate customers, auditors, and regulators, because it serves two purposes at once: assessing license compliance and knowing whether the application is affected when a new vulnerability is announced.

What you can ask of the vendor or internal team:

• A list of direct and transitive dependencies with versions
• The license of each component, with special flags for copyleft and unrecognized licenses
• License texts and attribution notices that must be fulfilled
• Notes on components that were modified or forked
• An update of this list at every major release

Automated scanning tools can generate this list from the code and flag conflicts. Running them as part of an automated testing and CI/CD flow means violations are detected when a component is added, not years later.

A simple but firm license policy

Companies that have a software product, or often commission custom software, should have a one page policy on component licenses.

• Green list: licenses that may be used without approval, usually MIT, BSD, Apache 2.0, and similar
• Yellow list: licenses that need review before use, for example LGPL, MPL, or licenses with special restrictions
• Red list: licenses that must not be used in certain products without legal approval, for example GPL and AGPL in products that are distributed or run as a service
• Approval process: who decides for the yellow list and how decisions are recorded
• Attribution duties: where copyright notices are displayed, for example an about page or a license document inside the application

The policy need not be complicated. The goal is for developers and vendors to know the limits before writing code, not after the product is on the market.

Special risks in the AI era

The rise of AI coding assistants adds a new layer. Code suggested by a model may resemble snippets from a particular open source project, and the copyright and licensing status of AI output is still evolving legally in many countries. A sensible practice is to set rules for using such tools, enable the filter for matches with public code where available, and still review and scan AI assisted code like any other code. A broader discussion is in the article on AI assisted software development, opportunities, risks, and quality control.

Likewise, AI models themselves are often released under special licenses, including commercial use restrictions or user count thresholds. When choosing a model, read its license as carefully as you would when choosing a library.

During due diligence: what is usually asked

Investors, prospective buyers, or large customers often ask for proof of code cleanliness. Common questions:

• Who wrote the code, and is everyone bound by a rights assignment agreement, including freelancers and vendors
• What open source components are used and what are their licenses
• Whether there are strong copyleft components inside a product that is sold or run as a service
• Whether any code was copied from sources with unclear licenses
• Whether the source code is stored in a repository controlled by the company, with a clear change history
• Whether any intellectual property claims or disputes have occurred

Companies that already have a component list, a license policy, and tidy rights assignment contracts answer all of this in days. Those that do not often spend weeks tracing and fixing, sometimes at a cost and with a lower valuation.

Practical steps for a business

1. Review running vendor contracts: check that clauses on rights assignment and source code delivery are present.

2. Make sure project code is stored in a repository in your company's name, with access you control.

3. Ask the vendor for a component and license list, and make it part of the handover.

4. Draft a one page license policy with green, yellow, and red lists.

5. Turn on automated license scanning in the development flow.

6. Make sure all contributors, including freelancers, sign a clear rights assignment or license agreement.

7. Display required attributions inside the application or documentation.

8. Review every year, or before fundraising and selling the company.

For businesses planning to move a project to another vendor, these steps also ease the handover as discussed in the article on rescuing a stalled software project and switching vendors.

Frequently asked questions

Does using open source force our application to be open? Not automatically. Permissive licenses do not require it. The duty to open code arises mainly with strong copyleft licenses and only under certain conditions, for example when the product is distributed or, for AGPL, when run as a network service.

Do we automatically own code built by a vendor we pay? Not always. Ownership depends on the contract and applicable law. So write the assignment of rights or license explicitly before the project starts.

What if we only discover a problematic component after release? Assess how big the problem is, then choose a path: replace the component, buy a commercial license if one exists, or adjust the architecture. Involve counsel. The earlier it is found, the cheaper it is to fix.

Is this article enough as legal guidance? No. It is a general guide to understanding the issues. Decisions and contract wording should be reviewed by counsel who understands intellectual property law in your jurisdiction.

Conclusion

Open source gives access to world class technology at low cost, but every component comes with conditions. Ownership of custom code cannot be assumed either. With a clear contract on rights assignment and source code delivery, a component list with licenses, a simple license policy, and automated scanning, a company can enjoy the benefits of open source without legal surprises. The cost of doing this early is small. The cost of fixing it during due diligence or a dispute is far greater.