Can a technology company use open-source software in a commercial product?

A Pakistani technology company can generally use open-source software in commercial products if the licence authorises the proposed use and the company meets the licence conditions. Open-source does not mean copyright-free. Permissive, weak copyleft and strong copyleft licences impose different obligations on code distribution, modification, attribution and in some cases network use. The relevant contract and copyright questions are distinct from security quality and software suitability.

Map the software components

Prepare a software bill of materials listing dependencies, versions, sources and licences. A commercial mobile application may use many libraries transitively. One developer's assurance that the project uses only free code is not enough. Dependency updates can change code and legal obligations, so the record should be maintained through development and releases.

Publicly visible code is not always open-source

A GitHub repository is not automatically licensed for commercial redistribution merely because anyone can view it. The author may have retained ordinary copyright without a licence. Obtain the licence associated with the specific version. Copying unlicensed protected code into a commercial app may infringe regardless of whether a download button appeared on a public webpage.

Copyright principles in Pakistan

The Copyright Ordinance, 1962 protects qualifying software as a form of literary work under relevant provisions and principles. A valid open-source licence grants permission subject to its terms. The company should distinguish rights given by the licence from ownership of the original work. Rebranding copied code does not make the licensee its sole copyright owner.

MIT and BSD-type permissions

Permissive licences often allow use, modification and distribution in proprietary or commercial products, subject to preservation of specified copyright notices or other terms. The exact licence matters: different BSD variants have different wording. A company should keep the relevant notices and include attribution in a practical third-party information file rather than assume none is required.

Apache-style licences

An Apache licence can grant broad copyright and specified patent permissions while imposing notice and modification marking requirements. A company should preserve licence and NOTICE material as required. Patent clauses can affect parties contemplating patent claims against contributors. It is unwise to describe all permissive licences as legally identical.

GNU GPL obligations

The GNU GPL is a copyleft licence that can impose source availability and licensing conditions when covered software or qualifying derivative works are distributed. The result depends on actual integration and licence wording. A company cannot assume proprietary distribution of a modified GPL program is permitted without meeting conditions. Conversely, not every separate software process interacting with GPL code automatically inherits the licence.

AGPL and network services

The Affero GPL addresses certain network interactions and can create source-access duties in specified circumstances. A SaaS provider should not assume that keeping its modified program on its own server avoids all relevant obligations. The technical architecture and exact component must be examined. This is particularly important for cloud applications wishing to keep substantial modifications private.

LGPL and linked libraries

The LGPL can allow defined use of covered libraries with conditions concerning modifications, replacement or relinking. Static or dynamic linkage can be relevant but is not a universal answer in isolation. Developers should explain how code is distributed and whether users can exercise the rights the licence preserves. A legal assessment should inspect the version actually used.

Internal use and distribution

A business running an open-source component internally may encounter obligations different from those triggered by distributing executable copies. Mobile apps and downloadable desktop software distribute code to users, while a browser-accessible service may not do so in the same way. AGPL can change network-use analysis. The company should map each component rather than treat the entire product as one undifferentiated program.

Attribution and notices

Required notices should be collected from all dependencies and preserved in distributed products as applicable. An automated third-party notices file can assist but should be reviewed for accuracy. Deleting original copyright headers from modified code can create a breach. A proprietary end-user agreement must not purport to remove rights required under the applicable open-source licence.

Modifying components

Track source modifications and their authors. Some licences require changes to be marked or covered source to remain available. The company's new features may be separately authored but combined distribution can create licensing questions. Preserve git history and development records, especially where disputes concern whether copied code was incorporated before an acquisition or client delivery.

Employees and contractors

Employment contracts should require lawful third-party code use and accurate disclosure of licences. A freelancer's statement that all work is original may be inaccurate where deliverables contain substantial open-source dependencies. The business should conduct code provenance review before treating the finished product as exclusively proprietary intellectual property.

Patent and trademark considerations

Open-source copyright permission does not necessarily permit use of a project's trademark or guarantee freedom from all patents. A company should assess brand guidelines when reusing project logos. Some licences provide explicit patent licences and conditions. A product using a recognised project's code should not imply official endorsement unless authorised.

Cybersecurity and quality

Licences often disclaim warranties. The company remains responsible for testing components, monitoring vulnerabilities and updating systems according to customer commitments and regulatory duties. A legally compliant open-source library can still contain a critical flaw. Software composition analysis should therefore include both licensing and security checks, with separate remediation plans.

Customer contract warranties

Enterprise purchasers may require assurances regarding software ownership, non-infringement and ongoing maintenance. A vendor cannot truthfully promise every line is solely its property when open-source components remain owned by others. Instead, disclose licence usage accurately and warrant compliance within agreed limits. Customers may require an inventory of restrictive copyleft components.

An Android app example

A startup packages an app using MIT-licensed interface components and a GPL-covered module. The startup should preserve MIT notices and separately analyse whether distribution triggers GPL source and licensing requirements for the relevant combined work. Merely paying for an app-store developer account does not override either licence.

A commercial SaaS example

A company modifies a network-accessible AGPL application for its subscription service. The fact that customers do not download the executable may not settle source-access obligations. The firm should review the licence and architecture and, where necessary, comply or use an alternative commercially licensed component.

Infringement complaint and remediation

If a rights holder alleges violation, identify the exact code, version, licence and alleged omission. Preserve software releases and development records. Depending on the licence, restoration of notices, source disclosure, replacement or negotiated commercial permission may resolve issues. Do not assume buying a licence today automatically erases all past breaches.

Opinion and recommendation

Open-source code can support commercial software, but permission is conditional. Maintain a reliable dependency inventory, comply with attribution and copyleft requirements, review distribution and network obligations, and assess security independently. The safest business practice is to understand the actual licence before incorporating a dependency into customer deliverables.

Principal authorities: Copyright Ordinance, 1962; Contract Act, 1872; applicable MIT, BSD, Apache, GPL, LGPL and AGPL licence terms; relevant international intellectual property obligations where distribution occurs abroad.