Intellectual property (IP) in projects is a topic that project managers encounter in almost every delivery context but rarely receive formal training on. Who owns the software code written by a contractor? What happens to the data model developed during a joint venture project when the partnership ends? Does the client own the project methodology and templates the PM team brought to the engagement? These questions have significant legal and commercial consequences that project managers must understand well enough to protect their organisation’s IP interests, avoid inadvertent infringement, and ensure that contracts are structured correctly before work begins. This guide provides the IP foundations every project manager needs.
The Four Main Types of Intellectual Property
Intellectual property law recognises several distinct categories of IP, each with different creation requirements, duration, and protection mechanisms. Project managers encounter all four regularly:
Patents
A patent grants the holder exclusive rights to an invention — a novel, non-obvious process, device, or composition — for a defined period (typically 20 years from filing). Patents require a formal application and examination process. In a project context, patents are most relevant when the project involves developing genuinely novel technology, manufacturing processes, or pharmaceutical compounds. Project managers should ensure that potentially patentable inventions are identified early, disclosed to the appropriate legal function, and protected before any public disclosure that would invalidate a future patent application.
Copyright
Copyright protects original creative works — software code, written documents, designs, data models, training materials, and multimedia content — from the moment of creation without requiring registration. In a project context, copyright is the most frequently relevant IP category because almost everything projects produce (deliverable documents, code, reports, designs) is automatically protected by copyright. The critical question is: who owns that copyright? The answer depends on whether the creator is an employee, a contractor, or a joint venture partner — and what the contracts say.
Trademarks
Trademarks protect distinctive identifiers — brand names, logos, slogans, and trade dress — that distinguish goods and services in the marketplace. In project contexts, trademarks become relevant when projects involve creating new products, brands, or market identities. Project managers must ensure that proposed brand names and logos are cleared for trademark use before they are embedded in deliverables, marketing materials, or product registrations — rebranding after launch is extraordinarily expensive.
Trade Secrets
Trade secrets are confidential business information that provide a competitive advantage — algorithms, customer lists, pricing models, manufacturing processes, and strategic plans. Unlike patents, trade secrets are protected indefinitely as long as they remain confidential. In project contexts, trade secrets become relevant when the project involves access to a client’s or partner’s confidential information. Non-disclosure agreements (NDAs) and confidentiality provisions in project contracts are the primary mechanisms for protecting trade secrets.
The Work-for-Hire Doctrine: Who Owns Project Deliverables?
The work-for-hire doctrine is the most practically important IP concept for project managers because it determines the default ownership of IP created during a project. In most common law jurisdictions, IP created by an employee within the scope of their employment belongs to the employer. IP created by an independent contractor, however, belongs to the contractor by default — unless the contract explicitly assigns ownership to the commissioning party.
This default rule creates a significant IP risk in projects that use contractors, agencies, and consultants: if the project contract does not include an explicit IP assignment clause, the deliverables produced by external parties (code, designs, reports) belong to those external parties, not to the organisation that paid for them. Project managers must ensure that all project contracts with external parties include clear IP ownership provisions before work begins. Attempting to acquire IP rights after the fact is expensive, often impossible, and potentially litigious.
“The most common IP mistake in projects is not malicious infringement — it is the assumption that paying for something means you own it. You must explicitly acquire IP rights in every contract with every external party.” — World Intellectual Property Organisation (WIPO)
Open Source Software: A Special IP Case
Open source software (OSS) is ubiquitous in modern software projects — virtually every project uses open source libraries, frameworks, and components. This creates IP obligations that project managers often underestimate. OSS is not “free of IP obligations” — it is licensed under specific terms that impose specific conditions on how it can be used, modified, and distributed.
The two main categories of OSS licences have very different implications for commercial projects: permissive licences (MIT, Apache 2.0, BSD) allow OSS components to be used in commercial products with minimal obligations — typically attribution in documentation. Copyleft licences (GPL, LGPL, AGPL) impose a “share-alike” obligation: if you use GPL-licensed code in a commercial product, you may be required to release your own product’s source code under the same licence. This “GPL contamination” risk is a serious commercial concern for organisations building proprietary software products. Software Composition Analysis (SCA) tools should be integrated into the CI pipeline to identify all OSS components and their licences, flagging any copyleft components that require legal review.
IP in Joint Ventures and Consortium Projects
Consortium projects — where multiple organisations collaborate to deliver a complex outcome — create complex IP ownership questions that must be resolved contractually before the project begins. Key questions that the project IP agreement must address: Who owns IP created by the consortium collectively? Who owns IP brought to the consortium by each party (background IP) versus IP created during the project (foreground IP)? What rights does each consortium member have to use foreground IP after the project ends? What happens to foreground IP if a consortium member withdraws? These questions are not hypothetical — IP disputes between consortium members are one of the most common and most expensive causes of post-project litigation.
IP Risk Assessment by Project Type
| Project Type | Primary IP Risk | Key Control |
|---|---|---|
| Software development with contractors | Contractor retains code copyright | IP assignment clause in all contracts |
| OSS-heavy software project | Copyleft licence contamination | SCA tool in CI pipeline from day one |
| R&D / innovation project | Failure to patent before public disclosure | IP disclosure process before any publication |
| Consortium / joint venture | Disputed ownership of foreground IP | IP ownership agreement signed before project starts |
| Brand / product launch | Trademark infringement in new brand | Trademark clearance search before brand commitment |
Key Takeaways
- IP in projects spans four main types — patents, copyright, trademarks, and trade secrets — each with different creation requirements, duration, and protection mechanisms.
- The work-for-hire doctrine means contractor-created IP belongs to the contractor by default — IP assignment clauses must be included in every contract with every external party before work begins.
- Open source licences are not IP-free — copyleft licences (GPL, AGPL) can require commercial code to be released as open source; SCA tools identify this risk automatically in the CI pipeline.
- Consortium projects require an IP ownership agreement signed before the project starts — foreground IP, background IP, and post-project use rights must all be explicitly addressed.
- Paying for work does not mean you own it — always explicitly acquire IP rights in writing before the project produces deliverables that the organisation intends to own or commercialise.
- IP disputes are among the most expensive post-project legal risks — investing in correct IP contractual structuring at the start is dramatically cheaper than litigation after the fact.
