Open source development - an introduction to ownership and licensing issues

by Rowan Wilson on 1 February 2005 , last updated


When you write software, you are creating a kind of property. By default, this property will be owned by somebody. If you are an employee, it is likely that your employer will own the software you create in the course of your employment. If you are working for yourself, or working in your free time on matters unrelated to your work, then it is likely that you will own it. If you are self-employed and developing software as a service under a contract agreement, then the contract ought to define who owns the intellectual property that results. If the contract does not define who will own the property, it is more likely than not that the contractor who wrote it will own it. If you are working as part of a group, where there are multiple employers, contractors and/or individuals, or some parties are based outside the UK, then the ownership of the resulting property can be complex. It may be that all contributors jointly own all of the property, or that the property is divided into sections that are owned by different people or organisations. Ideally, an agreement detailing who will own what should be made before the work is begun.

In order to be safe, one should always make sure that agreements or contracts specify who will own the intellectual property that results from any collaboration, consortium or contract work.

Computer software is protected by copyright law. Copyright law gives the owner of a work certain rights over it, and makes it illegal for others to use the work as though they were its owner. Copyright originally came into being to ensure that literary authors were properly remunerated for their work. Its concepts originate in the protection of written works, and it can be helpful to remember that computer software and its associated materials are treated by the law as species of literary work.

Owning the copyright in a piece of work, whether literary or programmatic, means that you decide who can copy it, adapt it and distribute it. By default, only the owner can do these things. Anyone who copies, changes or distributes someone else’s work without permission can have legal action taken against them.

Copyright comes into being as soon as a work is fixed — meaning as soon as it is recorded in some way. There is no need to register your work in order to gain copyright; it happens automatically. There is also no requirement to mark your work as copyrighted with a © symbol, although you should, as this emphasises the legal presumption of your ownership of it.

Writing software may well result in more than one piece of property. For example, program’s source code is property, as can be the preparatory design material for it, its general organisation and its user interface. The consequences of this fact are worth bearing in mind.


If a copyright owner wants to make money from their work, they can sell the rights to it outright (known as “assignment of copyright”). As with physical property, assigning the copyright involves handing over complete ownership of the work to a buyer or assignee.

Another approach to exploiting a copyright work is to license it. A licence is a permission given by the copyright owner to another person (known as the licensee). The copyright owner agrees to permit the licensee to take actions that would otherwise be prohibited by law, such as copying, adapting and/or distributing the work. The licensee will agree to take these actions within the boundaries set by the licence — perhaps only creating and distributing a certain number of copies, or paying a royalty on each copy distributed. Although a licence can be created without the forming of a contract, most licences are granted in a legal form where both parties undertake certain obligations in respect of each other and the licensed copyright work; this is known as a “licence agreement”.

Licence agreements are technical legal documents that have many legal rules describing and confining their content and manner of expression. It is therefore worth noting that should there ever be a disagreement over whether or not there has been a breach of the agreement, in the final analysis the law will determine the outcome. A poorly drafted licence may, when construed by a court, be found to mean something quite different from what both the copyright owner and the licensee intended.

What is open source licensing?

Open source describes a group of licences that all meet a certain set of conditions. The conditions are maintained by a group called the Open Source Initiative, and together they are referred to as the Open Source Definition (OSD). We will briefly review them here.

An open source licence must:

  • grant the licensee the right to distribute the program themselves, including the right to charge money for it
  • grant access to the program’s source code
  • grant the right to modify the program
  • grant the right to distribute modified versions of the program
  • allow use of the program by all persons or groups in all fields of endeavour
  • apply to everyone who receives the program, without the need for any additional agreements
  • apply to the program it licenses, whether the program is obtained as part of a group of programs, or on its own
  • allow distribution with any other software
  • allow distribution in any form

The desired effect of these conditions is to promote wide distribution of software, and to encourage people who receive the software to contribute to its functionality by modifying the source code. Although it may seem that granting these rights might lead to a large number of slightly variant versions of a piece of software, in practice successful open source software projects tend to absorb disparate modifications made by many contributors back into a single modified and improved version.

It is worth noting the second part of the first bulleted point above. It is a common misconception that one cannot charge money for distributing open source software. This is not the case. In practice, it is rarely done, mainly because each one of your customers could give away the software in direct competition to your own sales.

Complex ownership

As a piece of open source software is developed, often by many different people and groups, its ownership becomes more and more complex. The issues relating to collaboration and ownership identified above apply equally to unplanned collaborations over a period of time. It is conceivable for every contributor to own the copyright to their contribution. While in practice most contributors will willingly agree to license their material under the same licence as the original work, meaning that the process of uptake and improvement can continue, still it can be complex to ascertain who should make a legal complaint if someone decides to use the program in a way that violates its licence. To avoid this issue, some open source projects ask that contributors explicitly assign the copyright in their contributions to a body that administers the project, thus keeping ownership centralised and making enforcement of the licence easier. An alternative approach is to have contributors license their contributions to the project’s administrative body under a licence agreement that permits the body to relicense the contribution.

It is often observed that licences such as those within the OSD are problematic because there is no overt act of acceptance by licensees who take them up. End-user licence agreements that are distributed with proprietary software often require a user to click a button to accept the conditions, and this fact leads many to believe that open source licences should require something similar to be binding. This is incorrect.

Proprietary end-user licence agreements are contracts to govern many aspects of the relationship between company and user. If the user breaks the agreement, they have breached their contract, and the software company may choose to use the law of contract to punish them. But this can be difficult, particularly as the law of contract varies from country to country. Obtaining overt consent from users by making them click the ‘I accept’ button helps make the process of prosecuting breaches of the agreement under contract law easier. Some would argue that the button is unnecessary, as a user has a responsibility to acquaint themselves with any licence and contract terms associated with software they use — however, proprietary software firms tend to err on the side of caution and mandate the ‘I accept’ button.

Although they are not considered to be contracts, properly drafted open source licences are legally binding and enforcement action can be taken against those who breach them. This may be under contract or copyright law, depending on how the licence is framed. No-one is forced to explicitly accept the licence, but implicit acceptance of the licence conditions is the only route to legitimate use under copyright law.

Beyond the Open Source Definition

The Open Source Initiative website currently lists over 50 licences that meet the conditions described in section 3. It is not within the scope of this document to examine them all. It is notable, however, that the most widely used open source licence in terms of the number of projects that use it — the GNU General Public License (GPL) version 2 — imposes a major further condition upon those who copy, adapt or distribute software under it. All software created by modifying the original software must also be licensed under the GPL (if it is distributed). The aim of this condition is to produce a body of open source software that grows as users contribute, and that cannot be shrunk by users adding their own effort to a piece of software and then relicensing the result under terms that are more restrictive than those of the GPL. Because this condition can be seen as an attempt to subvert the proprietary use of copyright, it is sometimes known as copyleft.

It is worth noting that there is no compulsion to release changes that you make, either under the GPL or any other open source licence; you may keep internal versions of GPL software that you have modified without necessarily licensing them to anyone else. This applies equally to individuals and legal entities like companies and institutions.

Licence compatibility

It is tempting to believe that all the source code that is available under an open source licence can be adapted and combined without restriction in order to produce new open source software. Unfortunately this is not the case. Two licences that each meet the requirements of the Open Source Definition individually may nevertheless contain terms that make them incompatible with each other. The GNU GPL (all versions) provides an example of this: it mandates that code that incorporates GPL-licensed code must itself be licensed under the GPL as a whole if it is distributed. It also mandates that no additional restrictions on the rights it grants can be imposed on GPL-licensed code. These two conditions combine to mean that GPL-licensed code can only be merged easily with other GPL-licensed code, or with code whose licence imposes only conditions present in the GPL. Clearly it is not an easy task to establish whether a condition in one licence is the exact equivalent of a differently worded condition in another licence. The Free Software Foundation, which administers the GPL, makes available a list of licences that they consider to be compatible with it.

The issue of licence compatibility is a complex one, and determining whether two licences are compatible will require the help of a lawyer in all but the most simple of cases. Programmers working on a piece of software that is to be distributed under a licence (whether open source or otherwise) need to be aware of the potential difficulties in this area before attempting to merge in open source code. Often the simplest way of resolving licence conflicts is to ask the code’s owner(s) if they would be willing to relicense their code for inclusion. However, this approach is only really practical where the number of owners is small.

Tracking intellectual property

The issues of licence compatibility and of complex multiple ownership of intellectual property mean that it is desirable, if not essential, for programmers and their managers to keep detailed records. Version control systems provide some of this record-keeping automatically, recording who made changes to the code and what they did. To complement this information, managers should keep records of the contractual and licensing status of contributors in order to establish who owns their work. They should also require and store explicit agreements from copyright owners that their contributions may be licensed and distributed under the licence selected for the project as a whole. Where code is brought in from existing open source software, the details of the relevant licence must be recorded (having first established that this licence is compatible with the project’s overall licensing policy).


To briefly summarise the points made in this document:

  • Software is intellectual property.
  • Software is protected under copyright law.
  • The ownership of software can be determined by a technical legal examination of any contracts under which it was produced, and any other legally relevant circumstances.
  • Copyright law says that by default only the owner of software may copy, adapt or distribute it.
  • The owner of software can agree to let another person copy, adapt or distribute the code - this agreement is called a licence.
  • Open source licences grant these rights to anyone who chooses to take them up, with certain conditions.
  • Open source licences aim to create a community of contributors who will fix and develop the software.
  • Combining two pieces of software code under different licences can be complex.
  • All projects that produce software need to keep complete, detailed records of the licensing and ownership of contributions to that software.

Further reading


Related information from OSS Watch:


This document is intended to highlight areas that may cause difficulty to programmers and their managers. It was not produced by lawyers, and is not legal advice. Please consult a lawyer to resolve your licensing and intellectual property issues.