Making your code available under an open source licence

by Ross Gardler, Elizabeth Tatham, Amir Nettler on 21 September 2009 , last updated

Introduction

Making your code available as open source involves much more than just indicating on the project web page that the code is licensed under a particular open source licence. Not only do you need to provide a way for people to download and/or contribute to the project, but you also need to choose the most appropriate licence and address other legal requirements. One of the most important of these is that you must be able to prove that the code can legally be released under that licence; another is that people who download it must be told what their responsibilities are to the project owner.

This document highlights the main legal issues faced by projects wishing to release open source code. For an open source project to be successful, however, it is also important to consider a realistic model for long-term sustainability, a major part of which is attracting a community of users and developers. These issues are beyond the scope of this document.

Choosing a licence

The licence defines the responsibilities placed on third parties wishing to modify and/or reuse open source software within their own products, so choosing the right licence is key to ensuring that the project owner is able to sustain the project in whichever way they choose. The first thing we recommend is to use only licences that have been approved by the Open Source Initiative (OSI). There are many good reasons for this, but perhaps the most convincing is that sticking with an OSI licence makes it much more likely that potential users and contributors will understand your licence terms already. Using an obscure licence or writing your own will negate this advantage.

There are a wide range of OSI-approved licences to choose from. Which one is right for a given project depends on the future plans for the software. For more information, see our briefing note What Kind Of Licence Should I Choose?.

An alternative approach to monetising your code is dual-licensing. This involves releasing your software under a strong copyleft licence such as the GNU GPL, and also making available a version under an alternative licence, thus allowing users who do not wish to be bound by the GNU GPL to pay for the non-copyleft version. Generally, they would do this because they wish to produce a product based on the code but not confined by a copyleft licence. Whether the additional administration involved in this model is worth it for you will depend on how likely you think it is that customers will want to pay for the right to produce non-copyleft derivative products. You should remember that in order to offer an additional non-copyleft licence, you must have the agreement of all contributors or own all the copyright in the code yourself

Choosing the right licence(s) is a complex decision. OSS Watch can help by providing licence consultations; please contact us for more information.

For a more detailed discussion of why you need to license your software, see our briefing note Open Source Development - An Introduction to Ownership and Licensing Issues.

Licensing non-software items

It is important to remember that free and open source licences are designed to be used on software code. If your project includes non-software copyright items, such as images, sounds, documentation or databases, there are more appropriate licences available that are tailored to these tasks. For images, sounds and documentation, consider using Creative Commons licences. For databases, which can be protected both by copyright and the separate database right, try an open database licence.

Intellectual property

Once you have chosen the most appropriate OSI-approved licence under which to release your code, you need to make sure that you are legally entitled to do so. This involves ensuring that you can prove that all your code is exclusively your intellectual property (IP) and that you have all the necessary rights to license it as you please, and auditing it on an ongoing basis so that it remains that way.

In small projects, where all contributors and their employment histories are known, this is usually very simple. As long as all contributors are in the employment of the copyright holder and their contracts do not allow them to retain copyright on their own work, and as long as all contributors are willing to confirm that their work is their own and not copied from another project, it is safe to say that all the intellectual property rights belong to the copyright holder.

However, things get more complicated in larger projects that may have received contributions from people not in the employment of the copyright holder. For example, if you used a contractor for some development work, you may not own the copyrights on their work. Similarly, someone who donated code, or whose code has been copied, may not have explicitly granted copyright clearance. Releasing code as open source when you cannot prove that you own all copyrights on that code is not only immoral, but could also result in court action against you.

For more information on this issue, see Can you contribute code to an open source project?, which discusses contribution of code to a third-party project, but is equally relevant to existing projects wishing to release code under an open source licence.

Continued auditing

Auditing your intellectual property is an ongoing task. Tools to enable code review and revision control can be put in place, which will allow you to efficiently audit code as it is contributed and thus remove the overhead of doing periodic audits. Ongoing audits at the point of contribution ensure that you minimise the chances of inadvertently contaminating your code releases, and it is easier to set up such a process at the start of a project, before third parties become interested in your code. This is discussed further in our document on Contributor Licence Agreements.

Setting up the auditing process, and the tools to support it, early on also ensures that there is an audit trail for all contributions, including those from the project team. In the event of any kind of ownership dispute, such an audit trail is vital. The use of version control as an intellectual property rights (IPR) tracking tool is discussed in our briefing note What is version control? Why is it important for due diligence?.

Applying the licence

Once you have chosen the licence you wish to use and confirmed that you are legally entitled to license all the code in your project, you must apply the licence so that people can see it. It is not sufficient to simply state that your code is available under a specified licence; you also need to ensure that it is prominently displayed in all appropriate locations. At a minimum you must:

  • state on your website which licence is applied (preferably on your home page and your downloads page)
  • provide the full text of the licence on your website
  • provide the full text of the licence in the root directory of your source project (usually in a file called LICENSE.TXT)
  • provide a boilerplate notice in the head of each file in the source distribution (The boilerplate text used varies from licence to licence. You will usually find further discussion on how to apply a licence documented alongside the licence in its original home.)
  • provide the full text of the licence in the root directory of your non-source project distributions (usually in a file called LICENSE.TXT).

There are tools available that can help with the application of a licence to your source files. For assistance with this and other code audit exercises, please contact OSS Watch.

Satisfying the requirements of dependencies

If your code includes libraries from another project it is important that you conform to the requirements of that licence. The first thing to consider is whether the bundled code is under a compatible licence or not. This is a complex issue and out of scope for this document. If you need assistance please contact us. However, attribution and notification of bundled licences is easier to address and so is within scope of this document.

Different licences require different attributions, and some don’t require any at all. The best approach is to treat them all the same since giving more attribution than is required is rarely a problem. The most common practice is to include a NOTICE.txt file in the root of the directory which states important information about the licence used and bundled libraries. For example, here is a part of the NOTICE.txt file of the Apache Forrest project:

Apache Forrest Copyright 2002-2009 The Apache Software Foundation. This product includes software developed at The Apache Software Foundation (http://www.apache.org/). See also the file LICENSE.txt The purpose of this NOTICE.txt file is to contain notices that are required by the copyright owner and their license. Some of the accompanying products have an attribution requirement, so see below. Other accompanying products do not require attribution, so are not listed. This product includes software developed by the OpenSymphony Group http://www.opensymphony.com/ This product includes software developed for project Krysalis http://www.krysalis.org/ [and so on…]

It is important to note that one licence, the Common Public Attribution License has very specific requirements with respect to attribution. This is described in our document Common Public Attribution License - An Overview.

In addition to crediting bundled code it is also necessary to include the full licence of any code that is distributed by the project. Again, there is no fixed way of doing this, but a common practice is to include the licence in the same directory as the included library. In this approach the licence file will be renamed to clearly indicate which library it applies to. So, for example, if the project bundles the library ‘jtidy-04aug2000r7-dev.jar’ it should include the library’s licence in a file called ‘jtidy-04aug2000r7-dev.jar.license.txt’ which is stored alongside the library. It is important to use exactly the same filename so that it can be found easily, and you remind developers to check the correct licence is used when a library is updated.

Making the code available

Making your code available as open source does not end with applying a licence to the source code. You must also make the code available for people to download from a suitable distribution point, such as your website or a project-hosting site such as Google Code or SourceForge, remembering to include source to any other open source components you have used in your project. While this is sufficient from a legal point of view, you will need to go beyond this and build a community of contributors and users around your project; this approach is known as the open development method and this is also an area in which OSS Watch can offer assistance.

Summary

The most important legal issues to be considered before making code available as open source can be summarised as follows:

  • Your choice of licence will be dictated by how you wish your code to be used in future; OSI-approved licences are recommended.
  • OSI-approved licences fall into three main categories: copyleft, permissive and partial copyleft.
  • Ongoing auditing of code as it is contributed is essential, as you need to be able to prove that it is exclusively your intellectual property.
  • The licence must be prominently displayed in all appropriate locations.
  • The code must be made available for download from a suitable distribution point such as Github, Google Code or Sourceforge.

Further reading

Links:

Related information from OSS Watch: