Releasing your code 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.
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 is 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. Here are some key questions that should be considered when choosing a licence:
This is just a handful of the questions you need to consider, and the answer to each will lead to further questions. However, the final decision really depends on the answer to the first question: Do you want to allow others to create derivative works that are not necessarily open source? This is not to say that the other questions are not important; they are, and often the answers to them will inform your answer to the first question. This means that you will need to consider all these questions, and more besides, together. The precise questions to be answered will depend on your specific circumstances; we therefore recommend that you contact OSS Watch for a licence consultation so that you can fully explore your options.
Whatever your intentions regarding the future use of your software, there is an OSI-approved licence to suit your purposes. OSI-approved licences, broadly speaking, fall into three main categories:
A copyleft licence, such as the GNU GPL, mandates that anyone who modifies the software and wishes to distribute their modified version needs to do so under the copyleft licence in question. This is intended to ensure that the code is not taken away from the community, and that all improvements are available to all. A permissive licence, such as the MIT licence, allows reuse on much broader terms, including modification and release in non-open forms. This is intended to maximise the use of a piece of software, even by businesses who wish to base closed products on the code. Some licences, such as the Mozilla Public License (MPL), attempt to take a little from each of these approaches, mandating the preservation of the MPL on files modified from the original project, but not on new files introduced into the project. These are known as partial or weak copyleft licences. The OSS Watch website has documents describing the major open source licences.
The licence you choose will depend on your plans for the future of your code, as indicated by your answers to the questions above, and also on your ethical stance towards free software. Copyleft proponents, such as the Free Software Foundation, hold it as an ethical principle that a user ought to be free to use, study, re-distribute and modify the software they use. To deny these freedoms to the users of one's software is considered by proponents of copyleft licensing to be anti-social and unethical. Therefore, copyleft licences are written to ensure that copyleft-licensed cannot easily be incorporated into software that is not similarly liberally-licensed.
In the context of a business - for example, one which sells services based on their code, such as doing installation and customisation for users - it may be possible to use either a copyleft or a permissive licence. However, a permissive licence could increase the number of collaborative partners by not excluding those who would wish to release derivative products under a non-open licence. Proponents of permissive-licensing, responding to the ethical objections of copyleft proponents, would argue that, while permissive licensing does allow the incorporation of code into proprietary works, the benefits of submitting one's changes back to the community make this less likely to happen in practice.
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, 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.
It is also important to consider the interaction between your chosen licence and that of other products you might wish to reuse or contribute to as part of your work. Combining two pieces of software code under different licences can be complex. Prompted by controversy over the reuse of BSD-licensed software to augment Linux's wireless networking capabilities, the Software Freedom Law Center produced this useful guide for developers working on GPL-licensed projects, who wish to make use of software available under a so-called permissive licence, such as the BSD or MIT licences. Although written by US lawyers, it is just as relevant for developers working in the UK.
Clearly, choosing the right licence is a complex decision. OSS Watch can help by providing free licence consultations to higher- and further-education institutions in the UK; 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".
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.
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?".
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:
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.
If your code bundles 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, 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 license file will be renamed to clearly indicated which library it applies to. So, for example, if the project bundles the library "jtidy-04aug2000r7-dev.jar" it should include the libraries license 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.
Becoming an open source project 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 is also an area in which OSS Watch can offer assistance.
The most important legal issues to be considered before releasing code as open source can be summarised as follows:
It is licensed under the
Creative Commons Attribution-ShareAlike 2.0 England & Wales licence.
OSS Watch is funded by the Joint Information Systems Committee.