Guide to Open Source Software for Australian Government Agencies
Understanding the legal context
The growing popularity of open source software has encouraged greater interest in software licensing. This interest is intensified by the fact that open source licences are very different to traditional proprietary software licences.
Most proprietary licences contain similar terms and users of such software have accumulated a broad understanding of these licence terms. Proprietary software licences focus on what the user may or may not do with the software in question (particularly relating to the number of systems on which the software can be installed or the number of concurrent users).
In contrast, open source licences are generally not concerned with how users use the software at all. The focus is on redistribution of the software and continued access to source code.
As a result, proprietary software has a different risk profile to open source software. Agencies need to understand and manage these risks.
Assessing licence risks
Most open source software is released under one of a number of different licensing schemes. There are several dozen such licensing schemes in common usage. This high number reflects the fact that most open source software is developed by consortia of developers or by vendors and each has different expectations about how their software should be reused by downstream developers. In some cases, developers who find that an existing licence does not fulfil their requirements may simply formulate a new one.
Commentators often complain that there are too many open source licences and that this adds to the confusion and therefore risk for users. While many in the open source industry would prefer to restrict further fragmentation in licensing, there is no mechanism to prevent new licences being added to the list maintained by the Open Source Initiative[5].
Not all software categorised as open source has an explicit licence governing its use and redistribution. For example, public domain software (software with no copyright attached) has no restrictions or requirements pertaining to subsequent use and redistribution.
Licence auditing should be considered best practice for both OSS and proprietary products. To mitigate risk, agencies should understand every product licence used within their environments, both proprietary and open source.
OSS licence types
All licences certified by the Open Source Initiative (OSI) as compliant with the Open Source Definition[6] share important characteristics. The most important of these are specific freedoms for users who run the software. However, even OSI-compliant licences have important differences, particularly in the redistribution of source and binary code.
OSI licences generally fall into two distinct categories:
- Attribution-style licences, exemplified by the Berkeley Software Distribution (BSD) licence; and
- Share and share alike licences, exemplified by the GNU General Public Licence (GPL).
Most OSI licences have minimal variation in terms of usage risk (as opposed to redistribution risk).
Attribution licences allow other developers to take some or all of the source code from a codebase and reuse it within another software codebase. The copyright and licence references must be kept intact and attribution statements must be added to the derived software. The derivative software can be re-released under any other licence, including closed source proprietary licences. This facility results in situations where attribution-licensed software can be (and has been) embedded within many proprietary products already used by agencies.
Software licensed under a share-and-share-alike scheme requires that any modifications, derivations or redistributions of the original software that are made available to a third party must then be made openly available. It is therefore not possible to take such software and make it proprietary. Developers of software based on share-and-share-alike schemes demand that their software remain open and free in perpetuity.
Implications of open source copyright
The most common open source licence is the GNU General Public Licence (GPL). This licence ensures that downstream programmers adhere to the original programmer’s licensing requirement for free redistribution of the source code. Like most open source software, GPL-licensed software is protected by copyright.
The GPL uses copyright protection in a manner that ensures the continued availability of the underlying product source code. Agencies that intend to modify GPL-licensed products and redistribute those modifications should understand the legal implications of such a move. The legal intricacies of redistributing open source software are discussed in ‘Sharing OSS solutions’. Agencies that merely use an OSS package and do not intend to redistribute the software have no additional risk management issues in this area.
The GPL legally enforces its mandate by allowing free redistribution of the software only when the licence is accepted as a whole. Failure to comply with the full licence removes the right of the downstream developer to copy the GPL-licensed code.
Downstream programmers who want to modify a GPL-licensed codebase and redistribute the resulting software as a product must comply with the GPL conditions in full. The licence specifies that modifications to source code, if released to a third party, must be made available to downstream users. A modifier must also allow users of their product to modify the source code under GPL terms or their right to redistribute the software is revoked.
Contrasting open source and proprietary licences
There are almost as many proprietary licences as there are proprietary software packages. Proprietary software licences generally focus on the use of the software. This may be defined in terms of the size, scale or types of use that are permitted. Most proprietary licences:
- Restrict the user in the number of systems (PCs, servers) on which the software can be installed;
- Limit the number of processors those systems can have;
- Limit the number of simultaneous users: the more users running the software, the more licences an agency needs to purchase;
- Prohibit users from copying the software (beyond backup copies);
- Prohibit decompilation or interoperability engineering (reverse engineering), including activities that are necessary to create software that can transfer data to and from an application; and
- Include additional esoteric requirements such as stipulations that the user must not use the software to create and publish material disparaging the vendor. Other licences limit the user’s ability to publish information or the results of benchmarking tests that compare the product to competing products.
In contrast, open source software licences are not concerned with the mode or scale of usage. Most of these limitations have no comparable requirements in OSS licensing schemes. All open source licences involve similar risks for users. Where there is variation between licences, this usually relates to the way source code can be extended, enhanced, embedded or redistributed.
Contrasting different open source licences
It is important for agencies to understand software licences before agreeing to use a product, be it proprietary or open source. When using an OSS product, an agency should also consider the impact of the software licence if it is contemplating modifying the OSS package and redistributing the resulting software to other agencies or the wider ICT community. If an agency is planning source code modifications, then a deeper understanding of the nuances of the software’s licence is mandatory. See the chapter on ‘Sharing OSS solutions’, for detailed discussion of this issue.
Modification scenarios
There are several scenarios to consider that may involve modification of an OSS package:
- Scenario 1: An agency takes an existing open source product and extends it to fit the agency’s specific purposes and requirements. The agency plans only to use the resulting software in-house.
Applicable OSS licences: All open source software licences allow for this scenario. The agency can proceed regardless of what open source licence the product was originally released under.
- Scenario 2: In a slight modification of the previous example, an agency takes an existing open source product and extends it to fit specific agency purposes and requirements. The agency then wishes to redistribute the resulting technology to other Australian Government agencies.
Applicable OSS licences: As the Commonwealth is a single legal entity (despite the fact that it is represented by many Australian Government agencies), making modified versions of open source software available to others within those agencies does not amount to redistribution that may trigger obligations under the terms of the relevant open source licence. However distribution to Australian Government entities that are independent legal entities would trigger such obligations.
- Scenario 3: An agency takes an existing open source product and extends it to fit the agency’s specific purposes and requirements. The agency wants to allow distribution of the modified software beyond the Australian Government.
Applicable OSS licences: All open source software licences allow for this scenario. However, some OSS licences require the agency to provide the modified source code to the recipients of the modified programs.
- Scenario 4: An agency takes an existing open source product and extends it to fit the agency’s specific purposes and requirements. The agency then wishes to distribute a ‘closed source’ version of the software.
Applicable OSS licences: Some OSS licences, such as the General Public Licence (GPL), impose restrictions that prevent this activity. To enable redistribution of a modified OSS product in closed source format, agencies may wish to consider open source products with licences that permit the process of ‘closing off’ the open source software codebase. The Berkeley Software Distribution (BSD) licence is one example of a licence that permits closing off.
- Scenario 5: An agency wishes to redistribute a closed source (proprietary) product that it has developed. It also plans to package the software alongside open source modules, components, libraries or applications.
Applicable OSS licences: If the proprietary product does not directly link into these other technologies, the agency is free to redistribute this bundling. Nevertheless it is prudent to read and understand the licence terms of each bundled technology to reduce legal risks.
- Scenario 6: An agency plans to redistribute a software product (either open source or closed source) it has developed. The software has direct links into open source modules, components or libraries.
Applicable OSS licences: The agency must understand and comply with the licence of each product its software links into. If any of these products are licensed under the GPL scheme, then source code must be provided to users of the resulting product. If the linked products are licensed under the Lesser General Public Licence (LGPL) scheme (which allows users to create closed source modifications without having to provide open source code) or an attribution licence such as BSD, then source code need not be provided.
SOFTWARE LICENSING, WHETHER OPEN SOURCE OR PROPRIETARY, IS A COMPLEX LEGAL AREA. APPROPRIATE LEGAL ADVICE SHOULD BE OBTAINED BEFORE ENTERING INTO A LICENCE AGREEMENT.
Figure 7 provides a matrix showing which open source licences are available for each time of in-house development and redistribution situation.
Figure 7. DECISION MATRIX FOR OPEN SOURCE LICENCES[7]
| Action to be taken with open source software |
Licences available | Specific licences you can use |
|---|---|---|
| Do not plan to modify source code |
All open source licences | GPL, BSD, Mozilla Public Licence, MIT Licence, LGPL |
| Plan to modify source code | All open source licences | GPL, BSD, Mozilla Public Licence, MIT Licence, LGPL |
| Plan to modify source code and distribute only within the Australian Government |
All open source licences | GPL, BSD, Mozilla Public Licence, MIT Licence, LGPL |
| Plan to modify source code and distribute beyond the Australian Government as an open source product |
All open source licences | GPL, BSD, Mozilla Public Licence, MIT Licence, LGPL |
| Plan to modify source code and distribute beyond the Australian Government as a proprietary product |
Cannot use open source licences that contain a “share and share alike” clause mandating open release of modified code in perpetuity |
BSD, MIT Licence |
| Plan to link open source product with internally developed code and distribute beyond the Australian Government as a proprietary product |
Cannot use open source licences that contain a “share and share alike” clause mandating open release of modified code in perpetuity |
BSD, MIT Licence, LGPL |
Examining open source licences in detail
As a matter of best practice, agencies are advised to ensure they understand the licences that apply to all software they wish to use, including both proprietary and open source solutions. This reduces the risk that an agency may inadvertently contravene a particular licence condition. This requirement goes beyond merely ensuring that each user is licensed to run a copy of that software.
As discussed above, open source software licences are not generally concerned with what users do with the software. They usually focus on how other downstream software developers and software publishers may modify or redistribute the software.
Figure 7 (above) provides a quick reference matrix to help agencies understand the main variations among open source licences. This table is not a substitute for a close examination of the actual software licence provided with a product.
Applicability of open source licences in Australia[8]
As explained above, Australian Government agencies procure and use software under many different types of licences. For effective risk analysis, it is important to understand these licences and their application in the context of the Australian legal framework.
Few software licences (proprietary or open source) have been fully tested through the legal system. Indeed, there have been no known instances of an open source licence being defended or tested in an Australian court. Internationally, only a small number of cases have arisen where the most popular open source licence, the General Public Licence, was tested in court.
Procurement of OSS solutions involves a number of business issues that are not completely addressed by open source licences. For example, there is no definition of the “ancillary services” that a vendor is to provide as part of the solution, including:
- Assessment of customer needs;
- Installation and integration services;
- Training; and
- Ongoing support services.
Many of these issues would normally be covered by procurement contracts such as the vendor services agreement or a support contract, rather than the software licence. This approach can be applied to either proprietary or OSS solutions.
In addition, other matters of interest are ill-defined, including stipulation of the governing jurisdiction, alternative dispute resolution procedures, confidentiality issues, taxation issues and so on. Agencies should ensure such ancillary considerations are addressed in the contractual framework through it undertakes procurement.
Trade Practices Act considerations
In some circumstances, OSS licences appear to exclude all warranties about product quality. However, agencies and vendors need to consider the impact of Trade Practices Act 1974 (TPA). The TPA imposes certain implied warranties in all sales contracts and many of these warranties cannot be excluded by contract. The TPA is complemented by various state and territory laws covering fair trading and the sale of goods.
Agencies need to take particular care in situations when they may redistribute or sell an OSSbased solution to other organisations outside the sphere of the Australian Government. In such cases, it is prudent to obtain legal advice about the impact of TPA and sales of goods laws.
Broader intellectual property implications
Intellectual property (IP) issues are often confusing for people without a legal background. Nevertheless, it is important for agencies to understand how different strands of intellectual property law relate to software. Many of these issues are particularly important in the open source industry. This section provides an overview of the topic, specifically highlighting intellectual property issues with implications for assessing risks related to OSS procurement. The Department of Communications, Information Technology and the Arts (DCITA) has produced material covering these issues in greater detail[9].
Agencies face a different and possibly less defined intellectual property environment in the OSS space owing to the open nature of the source code and the different types of licensing used for OSS products. Some users who are new to open source assume that there are no intellectual property boundaries and that everyone is free to reuse any intellectual property contained in OSS products. This is not the case.
If anything, open access to the underlying intellectual property means IP subtleties are perhaps even more important for open source software. Agency staff should be well briefed in these subtleties to ensure they have the analytical and decision-making skills required to judge and manage the different risks involved.
Who owns and controls open source software
Although the authors of some software may have waived intellectual property rights to open software they have created (i.e. it has been donated to the ‘public domain’), the copyright in most open source software is owned by the respective developers of the code in exactly the same way as proprietary software.
Just as the owners of proprietary software prevent unauthorised use of their code by licensing their software, open source software owners do the same thing. It is only the terms of the licence that are different. Rather than restricting use, an open source licence seeks to prevent licensees from restricting the further development and redistribution of the code.
Copyright and legal enforceability of licence agreements are thus just as fundamental to open source software as they are to proprietary software.
It is usually the case that an open source software product has many contributing authors and thus potentially many different copyright owners. To date this has not proved to be an impediment to effective enforcement of open source licences, but some open source projects have taken steps to simplify the ownership arrangements by arranging for all contributors to assign their copyright to an appropriate legal entity that becomes the owner/guardian of the code. This single entity can then take enforcement action if it becomes necessary in much the same way as a proprietary software company would take action to protect its software.
If the author of open source software retains ownership of the code, they can continue to exercise the benefits of ownership concurrently with the rights they have irrevocably granted to open source users. For example, an author can release both open source and proprietary licensed versions. What the open source concept is designed to ensure is that the author cannot use legal means to control the future of the code within the open source licence scope once it is released.
So, different types of software are subject to different risks. Although open source software’s development effort is subject to the skills and enthusiasm of its supporting community, it is not subject to other risks that are part and parcel of the proprietary software model, most notably that a product can whither and die when the copyright owner is taken over by another company.
Similarly, although some aspects of open source software development may make them seemingly more vulnerable to intellectual property infringement claims than proprietary software, well managed projects are subject to close peer scrutiny which tends to mitigate against such risks. The reality is that both proprietary and open source could be subject to infringement claims and that agencies should always think through what options they have if their ability to use a product is disrupted or they find themselves embroiled in infringement litigation as a user of a software product.
The value of indemnities from a vendor should not be overlooked, though their scope needs to be legally scrutinised and the financial ability of the vendor to stand behind them assessed, should a major problem occur. Insurance policies to indemnify users of major open source products are also beginning to emerge and might also be considered as a risk management tool.
[5] OSI list of open source licences: www.opensource.org/licenses/index.php [
]
[6] OSI definition of open source: www.opensource.org/docs/definition.php []
[7] Note that this matrix does not cover all OSS licences, only the most commonly used licences. For a full list of OSS licences, see the Open Source Initiative website: www.opensource.org [].
[8]Some of the ideas for this section are based on arguments presented by Peter C J James, a partner at the law firm Allens Arthur Robinson, during the ‘Legal Issues Relating to Free and Open Source Software’ conference at Queensland University of Technology School of Law in 2003. The paper has been published in the conference proceedings: www.law.qut.edu.au/files/open_source_book.pdf [].
[9] Commonwealth IT IP Guidelines: http://archive.dcita.gov.au/2004/09/commonwealth_it_ip_guidelines [].
Contact for information on this page: SourceIT@finance.gov.au