Intellectual Property and Software Licensing

Introduction

Information technology products are built from intangible assets: source code, algorithms, user interfaces, datasets, documentation, brands, inventions, and confidential business knowledge. These assets may be protected by different legal regimes, each with a distinct subject matter, ownership rule, duration, registration process, and enforcement mechanism. A software organisation that treats all intellectual property (IP) as “copyright” risks losing valuable rights, breaching third-party licences, or making commercially defective agreements.

For IT managers, architects, developers, compliance officers, and legal advisers, IP compliance is therefore both a legal and a governance discipline. It begins before development, continues through procurement and deployment, and remains relevant during maintenance, outsourcing, acquisition, and product retirement. The central question is not merely “Who wrote the code?” but “What rights exist, who owns them, what permissions were granted, and can the organisation prove compliance?”

This chapter uses general principles common to many jurisdictions. Exact rules vary by country, particularly for employee inventions, database rights, software patents, moral rights, and open-source enforcement. Organisations must therefore obtain jurisdiction-specific advice for material transactions or disputes.

Learning Objectives

After completing this chapter, you should be able to:

• distinguish copyright, patents, trademarks, trade secrets, and database rights;
• analyse ownership of software created by employees, contractors, and collaborators;
• interpret permissive, weak-copyleft, and strong-copyleft software licences;
• evaluate digital rights management and its legal and ethical limitations;
• identify IP risks in technology development and procurement;
• design practical controls for software composition, licensing, attribution, and evidence;
• apply an IP-risk framework to a realistic technology project.

1. Intellectual Property as a Portfolio of Rights

Intellectual property is not a single right. It is a collection of legal rights protecting different kinds of intangible subject matter. A software product may simultaneously involve:

Two principles are especially important. First, protection is often cumulative: the same product can contain several separately protected elements. Second, ownership and permission are different. An organisation may own its source code but still infringe a third party’s patent; alternatively, it may not own a component but may possess a valid licence to use it.

1.1 Copyright

Copyright protects original expression fixed in a tangible or legally recognised form. In software, this commonly includes source code, object code, manuals, screen displays, graphics, audiovisual material, and certain database structures. Copyright generally does not protect an abstract idea, programming language, algorithm as such, method of operation, or functional requirement. The boundary between protectable expression and unprotectable ideas is fact-sensitive and jurisdiction-dependent.

Copyright normally arises automatically when qualifying work is created; registration, where available, may improve evidence or enforcement but is not always a condition of protection. Rights commonly include reproduction, distribution, adaptation, communication or public performance, subject to statutory exceptions. Moral rights—such as attribution and integrity—may belong to individual authors even where economic rights are transferred, although waiver rules differ by jurisdiction.

A critical compliance distinction is between ownership and licence. Purchasing software does not usually transfer copyright. It commonly grants a restricted licence subject to limits on users, devices, territories, copying, reverse engineering, resale, or modification.

1.2 Patents

A patent protects a qualifying invention for a limited period in exchange for public disclosure. Patentability usually requires novelty, an inventive or non-obvious step, industrial applicability or usefulness, and patent-eligible subject matter. Software-related inventions are treated differently across jurisdictions. Some legal systems exclude software “as such,” while allowing claims involving a technical contribution or technical effect.

Copyright protects the expression of a program; a patent, where available, may protect a technical solution implemented partly or wholly through software. A competitor can independently write different code and still infringe a patent if the product falls within valid patent claims. Consequently, copyright clearance is not a substitute for patent freedom-to-operate analysis.

Patent risk is often assessed through claim mapping: each element of a relevant patent claim is compared with the proposed product or process. Organisations should also consider patent ownership, filing deadlines, inventorship, prior disclosure, employee-assignment obligations, and patents held by suppliers.

1.3 Trademarks

A trademark identifies the commercial source of goods or services. It may consist of a word, logo, symbol, colour combination, sound, or other sign, depending on local law. Trademark protection is concerned primarily with confusion, association, dilution, and misuse of brand reputation.

Software teams should clear product names before launch, search relevant trademark registers and markets, secure suitable domain names, and establish rules for use by distributors and users. A technically excellent product can still face rebranding costs if its name conflicts with an existing mark. Open-source project names and package names can also create trademark issues independent of the licence governing the code.

1.4 Trade Secrets and Confidential Information

A trade secret is commercially valuable information that is not generally known and is subject to reasonable measures to keep it secret. Examples include source code, security architecture, pricing logic, unreleased product plans, model weights, customer data, and deployment procedures. Protection normally depends on secrecy; once information becomes public through inadequate controls, trade-secret protection may be lost.

Reasonable measures include confidentiality agreements, access control, data classification, logging, least-privilege permissions, secure repositories, staff training, exit procedures, and restrictions on unauthorised copying. A trade secret does not prevent independent development or lawful reverse engineering where permitted. It is therefore complementary to, not a replacement for, patents and copyright.

1.5 Database Rights

Databases may receive copyright protection where their selection or arrangement is original. Some jurisdictions additionally recognise a sui generis database right protecting substantial investment in obtaining, verifying, or presenting contents. This right may restrict extraction or reutilisation of all or a substantial part of a database and, in some systems, repeated or systematic extraction of insubstantial parts.

The legal analysis must separate the database structure from its contents. Facts may not be copyrightable merely because they are collected, but the compilation, investment, contractual terms, privacy obligations, and database-specific rights may still restrict use. Data-protection law is separate from IP law: a lawful copyright licence does not automatically authorise processing personal data.

2. Software Ownership and Allocation of Rights

2.1 Employees

Many legal systems allocate economic rights in work created by an employee in the course of employment to the employer, but the rule is not universal and may depend on job duties, statutory language, and contractual terms. Patent rights frequently require separate analysis concerning the employer’s business, employee duties, notification, compensation, and invention-assignment procedures.

A robust employment agreement should address:

• present assignment of relevant economic rights;
• disclosure of inventions and works created in the employment context;
• confidentiality and protection of trade secrets;
• permitted use of pre-existing employee materials;
• moral-rights consents or waivers where lawful;
• assistance with registrations and enforcement;
• post-employment confidentiality and return of assets.

An assignment should identify the subject matter, rights, territory, duration, consideration, and formalities required by applicable law. “All IP forever” language may be ineffective or may create uncertainty if it fails to distinguish future works, personal rights, or statutory limitations.

2.2 Contractors and Consultants

Contractors usually retain rights unless a valid agreement transfers them or grants an appropriate licence. Payment for development is not, by itself, reliable evidence of ownership. A client should obtain warranties that the contractor has authority to licence or assign the work, has disclosed third-party and open-source material, and will not knowingly introduce infringing content.

The agreement should also address subcontracting, repository access, delivery of source code, documentation, escrow, security obligations, pre-existing tools, reuse rights, and indemnities. A contractor’s reusable framework may be excluded from assignment but licensed to the client. This distinction should be recorded in a schedule rather than left to informal assumptions.

2.3 Joint Development and Academic Collaboration

Joint development creates risks concerning background IP, foreground IP, publication, patent filing, commercialisation, maintenance costs, and decision-making. Parties should define ownership of independently created work, jointly created work, improvements, and data. Universities may impose publication and researcher-attribution requirements that conflict with secrecy or patent filing. The agreement should establish a review period before publication and a procedure for protecting patentable results.

2.4 Ownership Evidence

An organisation should maintain an IP chain-of-title file containing employment agreements, contractor assignments, contribution records, licences, invention disclosures, repository history, approval records, and third-party notices. A chain-of-title audit is especially important before investment, acquisition, public release, or licensing to customers.

3. Software Licensing

A software licence is permission to perform acts otherwise restricted by IP law. It may be proprietary, open source, source-available, freeware, or public-domain-like, but these labels are not interchangeable.

3.1 Proprietary Licences

A proprietary licence commonly restricts copying, modification, redistribution, sublicensing, benchmarking, or use beyond a specified number of users or installations. It may be perpetual or subscription-based. Compliance includes controlling licence keys, authorised users, renewal dates, audit rights, cloud-service restrictions, and termination consequences.

3.2 Open-Source Licensing

Open-source software is made available under licence terms that grant rights such as access to source code, use, modification, and redistribution, subject to conditions. “Free” generally refers to freedom or price; it does not mean absence of legal obligations.

The precise legal outcome depends on the licence text, version, architecture, method of linking, distribution model, and jurisdiction. A compliance programme must not rely solely on labels such as “permissive” or “copyleft.”

Common obligations include retaining copyright notices, reproducing licence texts, providing source code or written offers, documenting modifications, providing attribution, respecting patent clauses, and avoiding additional restrictions. Failure can lead to injunctions, damages, reputational harm, forced release of code, or loss of distribution rights.

3.3 Software Composition Analysis

Software composition analysis (SCA) identifies third-party and open-source components in a product. An effective process includes approved-source policies, component inventories, version identification, licence classification, vulnerability scanning, legal review of exceptions, notice generation, and monitoring for changes.

A software bill of materials (SBOM) records component identity and relationships. Useful fields include component name, version, supplier, package identifier, licence, checksum, dependency relationship, and build provenance. An SBOM supports both IP compliance and cybersecurity response, although it is not itself proof of ownership or compliance.

3.4 Licence Compatibility

Licence compatibility concerns whether two licences can legally operate together in a distributed product. Incompatibility may arise when one licence requires conditions that conflict with another licence’s prohibition on additional restrictions. Compatibility analysis must consider the actual combination, not merely whether each licence is individually valid.

A practical decision process is:

1. identify each component and exact version;
2. locate the authoritative licence text;
3. classify how the component is used—copied, linked, modified, dynamically loaded, or accessed as a service;
4. determine whether the product is distributed and in what form;
5. map all notice, source, attribution, patent, and modification obligations;
6. obtain legal approval for uncertain cases;
7. record the decision and implement release controls.

4. Digital Rights Management and Technological Protection

Digital rights management (DRM) uses technical measures to control access to or use of digital content. Encryption, licence servers, secure containers, device binding, watermarking, and controlled playback are common techniques. DRM can support contractual business models, reduce casual copying, and provide evidence of authorised access.

DRM is not equivalent to legal ownership. A technical restriction may be circumvented, may interfere with lawful exceptions, or may create accessibility and interoperability problems. Many jurisdictions prohibit circumvention of effective technological measures, but exceptions differ for education, research, security testing, repair, accessibility, libraries, and government activities.

A responsible DRM design should consider proportionality, privacy, resilience, availability during service outages, accessibility, preservation, and legitimate secondary uses. DRM should not be used to conceal unfair terms, evade consumer-protection obligations, or collect excessive personal data. Security researchers should have a documented safe-harbour and disclosure process where possible.

5. Employee Inventions and Innovation Governance

An invention disclosure process allows employees to report potentially patentable technical developments before public release. The organisation should record the inventors, dates, problem solved, technical contribution, known prior art, funding sources, and proposed publication. A patent decision should be made before conference presentations, public repositories, product demonstrations, or customer disclosures, because public disclosure can destroy novelty in many jurisdictions.

Not every invention should be patented. The decision may compare patent cost, expected market life, enforceability, disclosure consequences, competitive value, and the availability of trade-secret protection. A portfolio approach categorises inventions as patent, secrecy, defensive publication, open-source release, or abandonment.

Employee invention law may impose mandatory compensation, notice, or assignment rules. HR, engineering, legal, and research leadership should therefore use a coordinated process rather than treating inventions as ordinary code contributions.

6. IP Risk in Technology Development

IP risk can be assessed across the product life cycle.

A useful qualitative risk model considers likelihood, impact, detectability, and control maturity. It is not a legal formula, but a prioritisation tool. High-impact risks include missing chain of title, incompatible copyleft obligations, unlicensed code, undisclosed patent exposure, leakage of trade secrets, and use of a supplier’s data outside contractual permission.

7. Illustrative Case: The Atlas Analytics Platform

Background

Atlas Analytics, a fictional enterprise, developed a predictive-maintenance platform using employee code, a contractor’s data-processing library, an open-source machine-learning framework, customer equipment data, and a newly developed optimisation technique. It planned to offer the platform as both installed software and a hosted service.

Problem

Before launch, an audit found that the contractor agreement assigned “deliverables” but did not clearly transfer copyright in reusable libraries. The engineering team had copied code from a public repository without recording its licence. The product name had not been searched in the target market. A researcher had presented the optimisation technique at a conference before the patent review. Customer contracts permitted analysis of equipment data but did not clearly permit reuse for model training.

Analysis

The project had several independent risks. The contractor’s rights required a confirmatory assignment or suitable licence. The public repository code required identification and licence analysis. The product name presented trademark risk. The conference presentation might have affected patent novelty in some jurisdictions. Finally, contractual data permission and privacy law had to be assessed separately from database and copyright issues.

Approach and Solution

Atlas paused general release and created an asset register. It obtained a written contractor assignment and listed retained background tools. SCA identified the repository component, after which the team either complied with its licence or replaced it. Trademark counsel cleared a revised product name. Patent counsel assessed available filings in jurisdictions where novelty remained possible and documented a defensive-publication strategy elsewhere. Data governance staff reviewed customer contracts, anonymised training data where appropriate, and established a separate consent and retention policy.

The release process was redesigned to require an SBOM, licence notices, source-code offers where applicable, contributor attestations, and legal approval for exceptions. Atlas also introduced an invention-disclosure form and quarterly chain-of-title audits.

Outcome

The launch was delayed, but the organisation reduced legal uncertainty, improved customer confidence, and gained a reusable compliance process. The case illustrates that IP compliance is most effective when built into engineering workflow rather than performed as a final document review.

Learning Points

• Payment does not automatically establish ownership.
• Open-source use requires evidence and obligation management.
• Patent, trademark, copyright, confidentiality, and data rights must be analysed separately.
• Public disclosure can affect patent strategy.
• An SBOM supports compliance but does not replace legal judgement.
• Release governance should be risk-based and auditable.

8. Contemporary and Emerging Issues

Generative AI creates difficult questions about training data, output ownership, third-party styles, confidential prompts, and provenance. Organisations should define whether employees may submit confidential code or customer data to AI tools, require human review, record material tool use where appropriate, and verify outputs for licence and security risks. AI-generated output may not receive copyright protection in the same way as human-authored expression, and jurisdictional rules continue to develop.

Cloud computing also changes the meaning of distribution. A component used only on a server may be treated differently from one distributed to customers, but network-oriented licences may impose additional obligations. Container images, package registries, infrastructure-as-code, and model dependencies should therefore be included in inventory controls.

Regulators and customers increasingly expect software supply-chain transparency. Secure provenance, signed builds, reproducible processes, SBOMs, vulnerability response, and supplier due diligence serve both cybersecurity and IP governance.

9. Best-Practice Governance Framework

A mature IP programme should include:

1. Policy: define approved repositories, AI tools, open-source use, disclosure, and escalation.
2. Contracting: use tailored employee, contractor, supplier, and collaboration agreements.
3. Inventory: maintain an asset register, SBOM, licence register, trademark portfolio, and invention records.
4. Controls: enforce repository access, contribution checks, code scanning, notice generation, and release gates.
5. Training: teach developers and managers how to recognise protected material and licensing obligations.
6. Assurance: conduct periodic audits, sample repository histories, and test notice and source-delivery processes.
7. Incident response: define procedures for suspected infringement, licence breach, secret disclosure, or unauthorised use.
8. Evidence: retain approvals, searches, assignments, notices, scan results, and remediation decisions.

The objective is not to eliminate all risk. Innovation necessarily involves uncertainty. The objective is to make risk visible, allocate it deliberately, and ensure that the organisation can demonstrate reasonable governance.

Chapter Summary

Intellectual property in IT consists of distinct rights with different purposes. Copyright commonly protects software expression; patents may protect eligible technical inventions; trademarks protect source-identifying signs; trade secrets protect valuable confidential information; and database rights may protect substantial investment in qualifying databases. These rights can overlap, and ownership must be distinguished from permission to use.

Software ownership depends on employment status, contract language, contribution history, statutory rules, and background IP. Open-source software is governed by licences, not by the absence of obligations. Compliance requires component identification, licence interpretation, notices, source obligations, attribution, patent analysis, and auditable release controls. DRM can enforce access rules but must respect law, privacy, accessibility, interoperability, and legitimate exceptions.

Effective IP governance integrates legal review with engineering practice through contracts, invention disclosure, SBOMs, SCA, chain-of-title records, trademark clearance, confidentiality controls, and lifecycle audits. Emerging AI, cloud, and software-supply-chain practices make provenance and evidence increasingly important.

Key Terms

Copyright: Legal protection for original expression, including qualifying software code and documentation.

Patent: Time-limited exclusive right protecting a qualifying invention in exchange for disclosure.

Trademark: Sign identifying the commercial source of goods or services.

Trade secret: Valuable non-public information protected through reasonable secrecy measures.

Database right: A jurisdiction-specific right protecting qualifying database investment or extraction interests.

Moral rights: Personal author rights such as attribution and integrity, subject to local law.

Assignment: Transfer of ownership or specified rights from one party to another.

Licence: Permission to perform acts otherwise restricted by intellectual property law.

Open-source software: Software distributed under terms granting specified freedoms to use, study, modify, or redistribute.

Copyleft: Licensing approach requiring specified reciprocal conditions for certain modified or combined distributions.

Permissive licence: Licence generally allowing broad reuse while imposing limited conditions such as notices.

Chain of title: Documentary record showing how rights were created, transferred, or licensed.

Software bill of materials: Inventory of software components and their relationships, versions, and metadata.

Software composition analysis: Process of identifying and evaluating third-party and open-source components.

Digital rights management: Technical methods controlling access to or use of digital content.

Freedom to operate: Assessment of whether a product can be made or used without infringing relevant third-party rights.

Background IP: Rights owned or developed before a particular collaboration or project.

Foreground IP: Rights created through a particular project or collaboration.

Invention disclosure: Formal report describing a potentially protectable invention before publication or filing.

Licence compatibility: Ability of multiple licence terms to operate together lawfully in a product or distribution.

Review Questions

Short Answer Questions

1. How does copyright protection of software differ from patent protection of a software-implemented invention?
2. Why does payment to a contractor not necessarily transfer software ownership?
3. State three common obligations imposed by open-source licences.
4. What conditions are generally necessary for trade-secret protection?
5. Why should an organisation maintain an SBOM?

Long Answer Questions

1. Compare copyright, patents, trademarks, trade secrets, and database rights in terms of subject matter, acquisition, duration, and principal IT risks.
2. Explain how an organisation should structure ownership and licensing arrangements for software developed by employees, contractors, and research partners.
3. Discuss the compliance implications of permissive, weak-copyleft, strong-copyleft, and network-copyleft licences.
4. Evaluate the legal, technical, ethical, and operational limitations of digital rights management.
5. Design an IP governance framework for a technology company developing and distributing both hosted and installed software.

Analytical / Application Questions

1. A company discovers that its product contains an unattributed open-source library, contractor code without a clear assignment, and a patented technical process used by a competitor. Identify the issues, prioritise the risks, and propose a remediation plan.
2. A university-industry team wants to publish a machine-learning invention while retaining commercial value. Analyse the patent, trade-secret, publication, ownership, data, and licensing decisions that should be addressed before publication.
3. An AI-enabled SaaS provider uses third-party models, customer data, open-source packages, and generated code. Construct a lifecycle control matrix covering ownership, licence compliance, confidentiality, data rights, provenance, and release approval.

Multiple Choice Questions with Answers

Question 1

Which right primarily protects the original expressive form of source code?

A. Copyright

B. Patent

C. Trademark

D. Database right

Correct Answer: A. Copyright

Question 2

What is the principal condition for maintaining trade-secret protection?

A. The information must be registered publicly

B. The information must remain valuable and subject to reasonable secrecy measures

C. The information must be patented first

D. The information must be released under an open-source licence

Correct Answer: B. The information must remain valuable and subject to reasonable secrecy measures

Question 3

Which statement about paying a software contractor is most accurate?

A. Payment always transfers all IP automatically

B. Payment normally destroys the contractor’s copyright

C. Payment alone may not transfer ownership without appropriate contractual terms

D. Payment converts the software into public-domain material

Correct Answer: C. Payment alone may not transfer ownership without appropriate contractual terms

Question 4

What is the primary purpose of an SBOM?

A. To replace all software testing

B. To inventory software components and their relationships

C. To register a trademark

D. To encrypt source code

Correct Answer: B. To inventory software components and their relationships

Question 5

Which licence family commonly allows proprietary derivatives while requiring conditions such as preservation of notices?

A. Permissive

B. Strong copyleft

C. Network copyleft only

D. Patent-only

Correct Answer: A. Permissive

Question 6

Why should a patent review occur before a public conference presentation?

A. Publicity automatically grants a patent

B. Public disclosure can destroy novelty in some jurisdictions

C. Presentations transfer copyright to the audience

D. Trademark registration requires a presentation

Correct Answer: B. Public disclosure can destroy novelty in some jurisdictions

Question 7

What does a trademark primarily identify?

A. The technical novelty of an invention

B. The secrecy of a database

C. The commercial source of goods or services

D. The number of lines of source code

Correct Answer: C. The commercial source of goods or services

Question 8

Which activity is most directly associated with software composition analysis?

A. Identifying third-party components and their licences

B. Designing a company logo

C. Negotiating employee salaries

D. Measuring network latency only

Correct Answer: A. Identifying third-party components and their licences

Question 9

What is a central limitation of DRM?

A. It can never control access to digital content

B. It may interfere with lawful exceptions, accessibility, privacy, or interoperability

C. It automatically establishes copyright ownership

D. It eliminates the need for contracts

Correct Answer: B. It may interfere with lawful exceptions, accessibility, privacy, or interoperability

Question 10

Which document most directly demonstrates how software rights moved from authors or contractors to a company?

A. A marketing brochure

B. A chain-of-title record

C. A system uptime report

D. A user-interface style guide

Correct Answer: B. A chain-of-title record