1. Introduction

Dependency Management for Third-Party Libraries Compliance refers to the legal, technical, and organisational framework through which an organisation identifies, evaluates, acquires, uses, monitors, updates, and removes software libraries developed by external individuals, companies, or open-source communities.

Modern software applications rarely operate entirely on internally developed code. They depend on third-party libraries, frameworks, packages, APIs, and software components to perform functions such as authentication, encryption, data processing, artificial intelligence, cybersecurity, and database management.

For example, a biotechnology company developing a genomic-analysis platform may rely on external Python libraries, machine-learning frameworks, encryption packages, and cloud-based software components. Although these components improve efficiency, they also introduce legal and regulatory risks.

These risks include:

Open-source licence violations.

Copyright infringement.

Software supply-chain attacks.

Security vulnerabilities in external packages.

Personal-data breaches.

Patent infringement.

Failure to maintain software updates.

Contractual and regulatory non-compliance.

Unauthorised redistribution of third-party code.

Liability arising from defective software components.

Dependency management compliance therefore ensures that organisations remain legally accountable for software components even when those components are developed and maintained by external parties.

2. Meaning and Nature of Third-Party Software Dependencies

A third-party software dependency is an externally developed software component incorporated into an organisation's own application, system, or digital infrastructure.

Common examples include:

Open-source libraries.

Commercial software development kits (SDKs).

JavaScript packages.

Python modules.

Artificial-intelligence frameworks.

Cryptographic libraries.

Database connectors.

Cloud software dependencies.

External authentication tools.

Machine-learning models and supporting packages.

Dependencies may be direct or indirect.

Direct dependencies: Software components deliberately selected and installed by developers.

Transitive dependencies: Additional components automatically introduced because a selected library itself depends on other software packages.

Transitive dependencies create particular compliance problems because organisations may use software components without knowing their existence.

For this reason, modern dependency management requires a complete Software Bill of Materials (SBOM), vulnerability monitoring, licence verification, and continuous security assessment.

3. Legal Framework Governing Dependency Management

A. Copyright law

Third-party software libraries are generally protected by copyright.

The owner of copyright may control reproduction, modification, distribution, and other legally restricted uses of the software.

In India, the principal legislation is the Copyright Act, 1957.

Relevant provisions include:

Section 14: Meaning of copyright and exclusive rights.

Section 17: First ownership of copyright.

Section 51: Copyright infringement.

Section 52: Certain acts not constituting infringement.

Section 55: Civil remedies for infringement.

Section 63: Criminal consequences of knowing infringement.

An organisation incorporating a third-party library must ensure that its use is authorised by the relevant licence or other legal permission.

B. Open-source software licensing

Open-source software is not necessarily free from legal restrictions.

Different licences impose different obligations.

Failure to comply with licence conditions may result in infringement claims, injunctions, damages, or termination of licence rights.

C. Information technology law in India

The Information Technology Act, 2000, is relevant where third-party software dependencies create cybersecurity or unauthorised-access risks.

Important provisions include:

Section 43: Compensation for specified unauthorised computer-related acts.

Section 43A: Compensation for failure to protect sensitive personal data or information, subject to its applicable legal framework.

Section 66: Computer-related offences involving dishonest or fraudulent conduct.

Section 70B: CERT-In and cybersecurity incident-response functions.

The Digital Personal Data Protection Act, 2023, is also relevant when third-party libraries process personal data.

Organisations must assess whether dependency-related data processing complies with applicable data-protection obligations, including lawful processing, security safeguards, and accountability requirements.

D. European Union regulatory framework

Important European legal instruments include:

General Data Protection Regulation (GDPR).

Cyber Resilience Act.

NIS2 Directive.

EU AI Act, where relevant.

Software liability and product-safety frameworks.

The EU Cyber Resilience Act introduces cybersecurity obligations for products with digital elements, including relevant software products and their manufacturers.

Its requirements make vulnerability handling, security updates, and software-component management especially important.

4. Important Judicial Decisions and Case Laws

Courts have recognised that software licensing, copyright permissions, contractual obligations, and technology-related responsibilities are legally enforceable. The following decisions are particularly relevant.

Case 1: Jacobsen v. Katzer (2008)

Citation: 535 F.3d 1373 (Fed. Cir. 2008).

Facts:

Robert Jacobsen developed software and distributed it under the Artistic License, an open-source licence. The defendants allegedly incorporated his software into commercial products without complying with the licence conditions.

Legal issue:

Whether conditions imposed by an open-source software licence could be legally enforced through copyright law.

Judgment:

The Federal Circuit held that certain licence conditions were limitations on the permission to use copyrighted software. Their violation could constitute copyright infringement rather than merely a contractual breach.

Legal principles:

Open-source software remains protected by copyright.

Licence conditions must be respected.

Commercial use does not automatically eliminate attribution obligations.

Software developers must examine licence requirements before incorporating external libraries.

Importance: This is one of the leading authorities establishing that open-source dependency management is a matter of legal compliance, not merely software administration.

Justia Law+1

Case 2: Artifex Software, Inc. v. Hancom, Inc. (2017)

Court: United States District Court, Northern District of California.

Facts:

Artifex alleged that Hancom used Ghostscript software, distributed under the GNU General Public License (GPL), without complying with the licence requirements.

Legal issue:

Whether an open-source GPL licence could create enforceable contractual obligations.

Legal significance:

The court declined to dismiss Artifex's contract claim at the pleading stage. The litigation demonstrated that GPL obligations could be pursued through contract law.

Principles:

Open-source licences can create enforceable legal obligations.

Commercial organisations cannot assume that publicly available software is unrestricted.

Licence compliance must be assessed before distribution.

Organisations should preserve evidence of licence permissions and compliance.

Importance: The case illustrates the potential contractual liability associated with improper use of third-party libraries.

Note: The decision at this stage was not a final determination that Hancom had infringed the licence.

Case 3: SAS Institute Inc. v. World Programming Ltd. (2012)

Citation: Case C-406/10, EU:C:2012:259.

Facts:

SAS Institute developed a software system for data processing. World Programming created a competing program designed to reproduce certain functionalities of the SAS system.

Legal issue:

Whether software functionality, programming languages, and data-file formats receive copyright protection in the same way as source code.

Judgment:

The Court of Justice of the European Union held that the functionality of a computer program and programming languages are not, as such, protected by copyright under the Software Directive.

However, protected source code and other original expression remain subject to copyright protection.

Importance for dependency management:

Organisations must distinguish software functionality from protected code.

Reimplementation of functionality is not automatically copyright infringement.

Copying protected code from external libraries requires appropriate legal permission.

Software audits should distinguish independent development from unauthorised copying.

Case 4: Oracle America, Inc. v. Google LLC (2021)

Citation: 593 U.S. 1 (2021).

Facts:

Google incorporated portions of the Java API declaring code into its Android operating system.

Legal issue:

Whether Google's copying of the API declaring code constituted fair use under United States copyright law.

Judgment:

The United States Supreme Court assumed, without deciding, that the copied material was copyrightable and held that Google's particular use was fair use.

Importance:

This judgment is significant for organisations integrating software interfaces and third-party programming components.

It demonstrates that:

Copyright issues may arise from software interface reuse.

Fair use is fact-specific.

Commercial software development does not automatically establish infringement.

Organisations should assess copyright risks before reusing externally developed code.

The decision should not be treated as blanket permission to copy third-party libraries.

Case 5: Software Freedom Conservancy, Inc. v. Vizio, Inc. (2021–2024)

Facts:

Software Freedom Conservancy alleged that Vizio failed to satisfy GPL-related source-code obligations concerning software used in its smart televisions.

Legal issue:

Whether a third-party organisation could enforce certain open-source licence obligations and whether the GPL's source-code requirements were applicable.

Legal importance:

The litigation highlighted the importance of:

Identifying open-source components embedded in commercial products.

Maintaining corresponding source code.

Providing required licence information.

Establishing compliance procedures for software supplied by external vendors.

Importance: Organisations distributing connected devices and embedded software should not overlook third-party licence obligations merely because the components were incorporated by a supplier.

Case 6: Bowers v. Baystate Technologies, Inc. (2003)

Citation: 320 F.3d 1317 (Fed. Cir. 2003).

Facts:

The dispute concerned software licensing restrictions and the use of reverse engineering.

Legal issue:

Whether contractual restrictions on software reverse engineering could be enforceable.

Judgment:

The Federal Circuit upheld the relevant contractual restriction in the circumstances of the case.

Importance for dependency compliance:

Software licences may impose restrictions beyond what users initially expect.

Contractual permissions must be examined separately from general copyright exceptions.

Organisations should review restrictions on modification, reverse engineering, redistribution, and sublicensing.

Case 7: Vernor v. Autodesk, Inc. (2010)

Citation: 621 F.3d 1102 (9th Cir. 2010).

Facts:

The dispute concerned the resale of software copies distributed under restrictive licensing arrangements.

Legal issue:

Whether the software recipient was an owner of a copy or merely a licensee.

Judgment:

The Ninth Circuit treated the relevant software recipients as licensees under the circumstances, rather than owners entitled to rely on the first-sale doctrine.

Importance:

Third-party dependency agreements must clearly identify whether an organisation receives ownership, a licence, or limited usage rights.

This distinction affects redistribution, sublicensing, transfer, and commercial exploitation.

5. Major Compliance Challenges

A. Licence incompatibility

Different software libraries may operate under different licensing arrangements.

For example, an application may incorporate:

MIT-licensed code.

Apache-licensed libraries.

GPL-licensed components.

Commercial proprietary software.

These licences may impose different obligations concerning attribution, source-code disclosure, patent rights, and redistribution.

An organisation must assess licence compatibility before combining components.

B. Transitive dependency risks

A developer may install one library without realising that it automatically introduces several additional libraries.

This creates hidden risks involving:

Unknown copyright owners.

Incompatible licence conditions.

Outdated software versions.

Security vulnerabilities.

Unauthorised data collection.

An effective compliance programme must identify both direct and indirect dependencies.

C. Software supply-chain security

Third-party libraries may contain malicious code or vulnerabilities.

A compromised dependency can expose an organisation's entire digital infrastructure.

Examples include:

Malicious package updates.

Dependency confusion attacks.

Typosquatting.

Compromised package repositories.

Unauthorised code injection.

Abandoned software packages.

Organisations should use authenticated package sources, version controls, integrity verification, vulnerability scanning, and incident-response procedures.

D. Data protection violations

Third-party libraries may collect or transmit personal information without adequate organisational oversight.

For example, an analytics library incorporated into a healthcare application may transmit patient identifiers or device information to an external service.

This may create data-protection obligations under applicable privacy legislation.

The organisation must assess the purposes of processing, data flows, security safeguards, contractual arrangements, and relevant international transfers.

E. Patent infringement

Some software components may be subject to patent rights.

A library may be distributed under an open-source licence that contains patent-related provisions, but the precise scope and conditions must be examined.

Organisations should undertake patent-risk assessments where commercially significant software is being developed or distributed.

6. Software Bill of Materials (SBOM) and Legal Accountability

A Software Bill of Materials is a structured inventory of software components incorporated into a product.

Software Transparency and SBOMs

velentiummedical.com

An SBOM generally identifies:

Component name.

Component version.

Software supplier.

Licence information.

Dependency relationships.

Component origin.

Known vulnerability information, where available.

The SBOM helps establish what software was included in a product at a particular time.

The National Telecommunications and Information Administration and Cybersecurity and Infrastructure Security Agency have published guidance supporting SBOM development and consumption. The World Intellectual Property Organization also explains the importance of maintaining component inventories and licence-compliance materials.

ntia.doc.gov+2

Legal significance: An SBOM can help demonstrate reasonable software governance, assist vulnerability investigations, and provide evidence of licence compliance. However, merely possessing an SBOM does not establish complete legal compliance.

7. Regulatory Compliance Under the EU Cyber Resilience Act

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is particularly important for third-party software dependency management.

It establishes cybersecurity requirements for products with digital elements, including relevant software components.

Important obligations include:

Conducting cybersecurity risk assessments.

Maintaining vulnerability-management procedures.

Monitoring third-party software components.

Providing security updates.

Documenting identified vulnerabilities.

Cooperating with component developers and maintainers.

Maintaining security throughout the relevant product lifecycle.

Important implementation dates:

Under Article 14, applicable manufacturers must report actively exploited vulnerabilities and severe incidents. The reporting framework includes an early warning within 24 hours and further notifications within 72 hours.

Shaping Europe’s digital future+2

8. Organisational Compliance Framework

Organisations should establish a systematic dependency-management programme.

Dependency compliance lifecycle

Identification

Identify all direct and transitive software dependencies.

Licence verification

Examine copyright, open-source licences, patent provisions, and redistribution conditions.

Security assessment

Examine vulnerabilities, malicious packages, and software integrity.

Approval

Obtain appropriate technical, legal, and compliance approval.

Documentation

Maintain an updated SBOM and software dependency register.

Continuous monitoring

Monitor security advisories, licence changes, and newly discovered vulnerabilities.

Remediation

Patch, replace, isolate, or remove non-compliant dependencies.

Audit and accountability

Maintain evidence of compliance and investigate incidents.

9. Liability and Legal Consequences of Non-Compliance

Failure to manage third-party libraries properly may create several forms of legal liability.

An important legal distinction is that the mere presence of a vulnerable third-party library does not automatically establish negligence or liability. The relevant facts include foreseeability, applicable duties, knowledge of vulnerabilities, reasonable security practices, causation, and resulting harm.

10. Special Issues in Biotechnology and Healthcare Software

Third-party dependency compliance becomes particularly important in biotechnology, genomics, pharmaceutical research, and healthcare applications.

For example, consider a genomic sequencing platform using external machine-learning libraries.

Suppose an external library contains a vulnerability that allows an attacker to access genetic information.

This may create several legal issues:

Whether the organisation performed reasonable security assessments.

Whether the external software provider complied with contractual obligations.

Whether personal genetic information was adequately protected.

Whether the organisation maintained appropriate security updates.

Whether the incident must be reported to relevant authorities.

Whether affected individuals are entitled to legal remedies.

Under these circumstances, dependency management becomes an important part of biotechnology governance and data-protection accountability.

11. Important Legal Principles Emerging From the Case Laws

The cases discussed above establish several important principles.

First: Open-source does not mean unrestricted.

Jacobsen v. Katzer demonstrates that open-source licensing conditions can be legally enforceable.

Second: Software licensing creates contractual obligations.

Artifex v. Hancom illustrates the potential enforceability of open-source licensing arrangements through contract law.

Third: Software functionality and copyrighted expression must be distinguished.

SAS Institute v. World Programming clarifies the legal distinction between software functionality and protected expression.

Fourth: Software interfaces raise copyright questions.

Google v. Oracle demonstrates that software interface reuse requires fact-specific copyright analysis.

Fifth: Software ownership and licensing are different concepts.

Vernor v. Autodesk illustrates how licensing arrangements may restrict the rights associated with software copies.

These principles collectively support a compliance model based on legal permission, transparency, security, documentation, and accountability.

12. Conclusion

Dependency Management for Third-Party Libraries Compliance is an essential component of modern software governance.

Organisations cannot avoid legal responsibility simply because their applications rely on externally developed software. They must establish effective mechanisms to identify dependencies, examine licence conditions, assess cybersecurity risks, maintain SBOM records, and monitor software throughout its lifecycle.

The decisions in Jacobsen v. Katzer, Artifex v. Hancom, SAS Institute v. World Programming, and Google v. Oracle provide important judicial foundations for understanding software copyright and licensing obligations.

In India, the Copyright Act, 1957, the Information Technology Act, 2000, applicable data-protection legislation, and contractual principles provide important elements of the compliance framework. However, the precise legal obligations depend on the nature of the software, its distribution, the parties' contractual relationships, and the applicable jurisdiction.

Ultimately, dependency management is not merely a technical exercise. It is a legal governance responsibility involving intellectual property, cybersecurity, privacy, contractual accountability, and organisational risk management.

13. Key References for Further Legal Research

Copyright Act, 1957 (India).

Information Technology Act, 2000 (India).

Digital Personal Data Protection Act, 2023 (India).

Regulation (EU) 2024/2847 – Cyber Resilience Act.

GNU General Public License (GPL).

Apache License 2.0.

MIT License.

GDPR, Regulation (EU) 2016/679.

WIPO guidance on open-source software compliance.

CISA guidance on Software Bill of Materials.

Useful authoritative resources:

Official EU Cyber Resilience Act – full legislation

WIPO – Open-source software compliance guidance

CISA – Software Bill of Materials guidance

Jacobsen v. Katzer – full judgment

Academic research note: The leading judicial authorities above are predominantly from the United States and European Union. They are persuasive comparative materials, not binding precedents in Indian courts. The Indian legal analysis should therefore distinguish statutory provisions from foreign judicial interpretations.