Source: https://de.scribd.com/document/164885236/A-Guide-to-Open-Source-Software
Timestamp: 2019-01-19 17:41:48
Document Index: 430718806

Matched Legal Cases: ['art 3', 'art 2', 'art 1', 'art 4', 'art 2', 'art 1']

A Guide to Open Source Software | License | Free Software
Uploaded by ravikirantelu
ans_cou
Eula 53001
ExcelSDK_eula
OVP BHM PPM Function Reference
With the exception of the Commonwealth Coat of Arms and material sourced from the Open Source Initiative, the material sourced from the book titled The Open Source Alternative: Understanding Risks and Leveraging Opportunities by Heather Meeker, the material sourced from the Free Software Foundation and where otherwise noted, all material presented in this document is provided under a Creative Commons Attribution 3.0 Australia (http://creativecommons.org/licenses/by/3.0/au/) licence. The details of the relevant licence conditions are available on the Creative Commons website (accessible using the links provided) as is the full legal code for the CC BY 3.0 AU licence (http://creativecommons.org/licenses/by/3.0/au/legalcode). The document must be attributed as the Guide to Open Source Software for Australian Government Agencies. Use of the Coat of Arms The terms under which the Coat of Arms can be used are detailed on the following website: http://www.itsanhonour.gov.au/coat-arms/. Contact us Enquiries regarding the licence and any use of this document are welcome at: Assistant Secretary Governance and Policy Branch Australian Government Information Management Office Department of Finance and Deregulation John Gorton Building King Edward Terrace Parkes ACT 2600 Email: aga@finance.gov.au
It also provides information on the types of open source software licences. subject to licensing conditions. copy.Foreword I am delighted to be publishing Version 2 of the Guide to Open Source Software for Australian Government Agencies. agencies must actively and fairly consider open source software in all their information and communications technology (ICT) software procurements. Open source software is an alternative to proprietary software that provides users with the ability to view. licensing risks and risk mitigation techniques. including the key issues to consider when procuring open source software. Under the Australian Government’s Open Source Software Policy (AGIMO Circular 2010/004 released in January 2011). The Department of Finance and Deregulation would like to thank the Australian Taxation Office and the Australian Government Open Source Software Community of Interest for their assistance in developing Appendix 1: Australian Government Open Source Software Licensing Risk Framework. Open source software can offer benefits to both the Australian Government and wider community. modify and distribute the software. The guide provides practical information to assist agencies assess open source software solutions. the Guide has been updated to reflect the policy and the increasing maturity of open source software. This document is a companion document to the 2007 publication A Guide to ICT Sourcing for Australian Government Agencies (second edition). such as improving interoperability and possible cost savings. Foreward Ann Steward Australian Government Chief Information Officer Australian Government Information Management Office Department of Finance and Deregulation A Guide to Open Source Software for Australian Government Agencies iii . As a result.
iv A Guide to Open Source Software for Australian Government Agencies .
Background to the framework 3.Contents Foreword one Introduction  1. Outline of the framework 4.1 4. Australian Government Open Source Software Licensing Risk Framework Appendix2:Linkstootherresources Appendix3: Acronymsanddefinitions   A Guide to Open Source Software for Australian Government Agencies v .1 1.2 Key issues Beyond use: code forking and reciprocity Appendix1: AustralianGovernmentOpenSource SoftwareLicensingRiskFramework 1.3 Definition of open source software Development and support of open source software Benefits of open source software three AustralianGovernmentOpenSourceSoftwarePolicy 3.2 Intent Audience iii 1 2 2 3 4 6 6  9 10 11 13 14 15 17 18 21  23 24 24 25 26 51 57 CONTENTS two.1 2.2 Principles Compliance four Procurementofopensourcesoftware  4.1 3.2 2.Whatisopensourcesoftware? 2. Overview 2.2 Common issues in software procurement Four-phase ICT sourcing lifecycle five Comparingopensourceandproprietarysoftware 5.1 5.
1.1	Intent
The guide is a stand-alone reference document on open source software; however, agencies are encouraged to read it alongside A Guide to ICT Sourcing for Australian Government Agencies (Guide to ICT Sourcing). This guide is not a substitute for legal or procurement advice. Any decisions on the use of software, including open source software, or associated services should be made according to the Commonwealth Procurement Guidelines and the Australian Government’s Open Source Software Policy Agencies should be aware that this guide is focused on open source software. It does not provide a complete picture of the benefits and risks of using proprietary software solutions.
Although this guide can be considered general background reading for anybody who is interested in open source software within government, the primary audiences for this guide are project managers and procurement teams who are sourcing software to meet business requirements. Agency personnel who influence the selection of software may also find this guide useful. The Australian Government Open Source Software Licensing Risk Framework is designed for ICT specialists.
two What is open source software? two .
and it does not necessarily have a higher or lower total cost of ownership. Derived Works The licence must allow modifications and derived works. Deliberately obfuscated source code is not allowed. downloading via the Internet without charge. but it can mean different things to different people. there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably. and must allow them to be distributed under the same terms as the licence of the original software. Integrity of The Author’s Source Code The licence may restrict source-code from being distributed in modified form only if the licence allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. Source Code The program must include source code. The distribution terms of opensource software must comply with the following criteria: 1.org 4 A Guide to Open Source Software for Australian Government Agencies . The source code must be the preferred form in which a programmer would modify the program. and must allow distribution in source code as well as compiled form.1 an organisation established to promote open source software.1	Definition	of	open	source	software The Open Source Initiative (OSI). Intermediate forms such as the output of a preprocessor or translator are not allowed. This section defines open source software and highlights its benefits.two What is open source software? Open source software is a popular term in the information and communications technology (ICT) industry. The licence must explicitly permit distribution of 1 Open Source Initiative: http://opensource. 3. Free Redistribution The licence shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. Where some form of a product is not distributed with source code. The licence shall not require a royalty or other fee for such sale. It is not inherently more or less secure. T WO W HAT IS OPEN SOURCE SOF T WA RE? 2. Agencies should keep in mind that open source software is not intrinsically of higher or lower quality than proprietary software. has developed an Open Source Definition (OSD) as follows: The	Open	Source	Definition	Introduction	Open source doesn’t just mean access to the source code. 2. 4.
html. open source software is often linked with open standards. 10. Licence Must Be Technology-Neutral No provision of the licence may be predicated on any individual technology or style of interface. Licence Must Not Be Specific to a Product The rights attached to the program must not depend on the program’s being part of a particular software distribution.gnu. Licence Must Not Restrict Other Software The licence must not place restrictions on other software that is distributed along with the licensed software. A Guide to Open Source Software for Australian Government Agencies 5 . the licence must not insist that all other programs distributed on the same medium must be open-source software. For example. shareware. Note: freeware is not the same as free software. Software can be offered under both open source and proprietary licences. community source software and freeware. If the program is extracted from that distribution and used or distributed within the terms of the program’s licence.2 In addition. t wo W hat is open source sof t wa re? Misconceptions Although open source software often involves a distinctive development and distribution model. Where software is dual-licenced. For a definition of free software. No Discrimination Against Persons or Groups The licence must not discriminate against any person or group of persons. 7. 9. all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.software built from modified source code. 8.org/philosophy/free-sw. it may not restrict the program from being used in a business. however. community source software and freeware are available at Appendix 3: Definitions. Open source software is sometimes confused with public domain software. not all open source software products use open standards. Distribution of Licence The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional licence by those parties. or from being used for genetic research. The licence may require derived works to carry a different name or version number from the original software. For example. see the Free Software Foundation’s website: http://www. it may also be bundled and sold as part of a package with proprietary software. 2 D  efinitions of public domain software. 5. agencies should choose the arrangement that best matches their requirements and provides value for money. shareware. No Discrimination Against Fields of Endeavour The licence must not restrict anyone from making use of the program in a specific field of endeavour. 6.
human-readable programming instructions written by software developers. When open source software is labelled as ‘free’. open source software is usually available free of upfront costs. In most circumstances. Sun Microsystems (now owned by Oracle) provides the OpenSolaris operating system under this model. Some open source software is developed or supported by a single corporation. In this model. T WO W HAT IS OPEN SOURCE SOF T WA RE? 2. Commercial open source. they can be seen as general characteristics of open source software. In some cases there are risks associated with the benefits.3 The definition of open source software does not preclude people from selling the software.3	Benefits	of	open	source	software Open source software has a number of potential benefits. not the cost of the software. These benefits are not applicable in every instance. The commercial organisation usually provides support to a defined service level agreement. despite this. Oracle’s and IBM’s web servers are both based on the community-developed Apache. 3 All software is written in source code. Source code refers to the underlying. More than one organisation can provide support for a product. The commercial organisation may choose to create its own community to develop the open source software or they may choose to leverage off an existing product created by a volunteer community. Source code is used to specify actions to be performed by the computer. leading to competition based on the quality and price of the service. modify and redistribute the source code of the software. • • 2. as discussed in Section 4. Support is available through the members of the community. Some of these benefits can be realised only when agencies contribute back to the community. Some commercial organisations provide support for open source software. the machine-readable code that actually runs or executes on a computer or is interpreted by another platform. 6 A Guide to Open Source Software for Australian Government Agencies . There is generally no service level agreement available from the community. programming instructions are compiled into binary code. there is no specific corporation managing the development process. who have forums and other feedback mechanisms to receive requests from users. although agencies still need to be aware of the total cost of ownership (TCO). Corporate-backed community. However.Another common misconception about open source software is that it can always be obtained free of financial cost. however. For example.2	Development	and	support	of	open	source	software There are three broad models for open source software development and support: • Volunteer community. Popular packages such as the Apache web server and the Linux operating system have been developed using this model. that word refers to the ability of people to read. A large proportion of open source software is developed by a community of skilled people who usually communicate online.
agencies should ensure that they understand the obligation for reciprocity that is included in many open source licences. As the source code is publicly available. This may be a benefit to agencies that possess the appropriate skill base. Many open source software packages use open standards. May reduce vendor lock-in. customers are able to support the software themselves. However. Commercial organisations may provide support for an open source package. even if the original community discontinues development. Allows users to take advantage of the improved functionality of new releases more rapidly. however. Increases interoperability. which tend to lower the costs of integration and improve interoperability. Encourages a collaborative approach. Open source software packages are generally modular. Many new open source software communities follow the maxim of release early. where any user of the software can contribute ideas to improve it.Open source software: • Usually has no upfront payment. A Guide to Open Source Software for Australian Government Agencies 7 . including all support services that will be required to operate the software over its lifespan. In addition. it is possible for any software organisation to provide support for an open source product. Allows users to view and modify the source code. agencies should consider the total cost of ownership. if there are enough users willing to pay for that service. The ability of users to scrutinise and change the source code of open source software may lead to increased stability and security. Allows the opportunity to try the software before committing to it. Encourages a competitive market for support services. as with all software. This tends to promote a collaborative approach that may foster innovation. release often’. Open source software encourages an open exchange of ideas. most licences will allow any individual or group to further develop the software without the obligation to support other users. Places fewer restrictions on the users of the software. This will enable agencies to test the viability of the software before fully committing to it. 4 Usually is modular. The lack of upfront payment may seem to benefit agencies financially. Provides the opportunity for users to take direct control of the maintenance and support of the software. It also allows agencies to tailor the software to their own needs. meaning that users can quickly gain extra functionality for the software. which means that changes to one part of the source code is less likely to affect the rest of the software package. Most open source software licences place fewer restrictions on the users of the software and emphasise respect for the privacy of the users. Because the source code is available. T WO W HAT IS OPEN SOURCE SOF T WA RE? • • • • • • • • • • 4 Agencies should be aware that not necessarily all open source software solutions will use open standards.
three Australian Government Open Source Software Policy three .
transferability. It is recognised there may be areas where open source software is not yet available for consideration. as required by the Commonwealth Procurement Guidelines. This includes how they considered open source software suppliers when selecting suppliers to respond to the Select Tender or Request for Quotation. security. For a covered procurement (over $80K).three Australian Government Open Source Software Policy This section describes the principles that underpin the Australian Government’s policy in regard to the procurement of open source software and suggests ways that consideration of open source software can be incorporated into procurement processes. Procurement decisions must be made based on value for money. Procurement decisions should take into account whole-of-life costs. In January 2011. Suppliers will need to provide justification outlining their consideration and/or 10 A Guide to Open Source Software for Australian Government Agencies . Agencies are required to insert this requirement into their tender documentation. agencies are required to include in their procurement plan that open source software will be considered equally alongside proprietary software. the Australian Government released a policy requiring agencies to consider open source software for all software procurements. THREE A  USTRALIAN GOVERNMENT OPEN SOURCE SOF T WARE POLICY 3. The Open Source Software Policy. support and manageability requirements.1	Principles The policy directs agencies to comply with three core principles. For a non-covered procurement (below $80K). Tender responses will be evaluated under the normal requirements of the Commonwealth Procurement Guidelines. Australian Government agencies must actively and fairly consider all types of available software (including but not limited to open source software and proprietary software) through their ICT procurement processes. capability. will apply to any ICT procurement activity initiated after 1 March 2011. Principle 2: Suppliers must consider all types of available software when dealing with Australian Government agencies. which is available from the Department of Finance and Deregulation website. scalability. Agencies will be required to insert a statement into any Request for Tender that they will consider open source software equally alongside proprietary software. agencies are required to document all key decisions. Australian Government agencies will require suppliers to consider all types of available software (including but not limited to open source software and proprietary software) when responding to agencies’ procurement requests. Principle 1: Australian Government ICT procurement processes must actively and fairly consider all types of available software.
• for inclusion in request for quote/select tender checklists Have you considered all types of available software (including but not limited to open source software and proprietary software)? • for inclusion in requests for tenders for covered procurements [Agency Name] encourages suppliers to submit and/or develop open source software for this tender. When responding to this tender. Agencies may choose to draft their own clauses. will actively seek to keep up-todate with international best practice in the open source software arena. THREE A  USTRALIAN GOVERNMENT OPEN SOURCE SOF T WARE POLICY 3. Agencies will determine compliance with this requirement when assessing tender responses. Australian Government agencies should also actively participate in open source software communities and contribute back where appropriate. through AGIMO. In evaluating the tender. Principle 3: Australian Government agencies will actively participate in open source software communities and contribute back where appropriate. The policy provides the following sample clauses: • for inclusion in procurement plan/procurement documentation [Agency Name] will actively and fairly consider all types of available software for ICT software procurements. suppliers must demonstrate a willingness to actively consider open source software throughout all stages of procurement. This may include incorporating open source software components together with proprietary software components.exclusion of open source software in their response to the tender. [Agency Name] will consider open source software equally alongside proprietary software. through engaging with other countries and organisations. The Australian Government. A Guide to Open Source Software for Australian Government Agencies 11 .2	Compliance The policy suggests sample draft clauses designed to assist agencies in complying with the policy. Open source software will be considered equally alongside proprietary software. solution design and implementation in order to produce a product that demonstrates value for money and is fit for purpose. • for inclusion in request for tender assessment checklists Has the supplier sufficiently demonstrated that they have considered all types of available software (including but not limited to open source and proprietary software)? Agencies are also encouraged to include a definition of open source software in their procurement documentation.
four Procurement of open source software four .
•	Total cost of ownership. Agencies need to ensure that they comply with the procurement procedures outlined in the Commonwealth Procurement Guidelines. There are variations in the stability. Further details on the four-phase ICT sourcing lifecycle can be found in A Guide to ICT Sourcing for Australian Government Agencies (Guide to ICT Sourcing). •	Aligning with the agency’s strategy and architectures. maintenance and exit costs. support and deployment. system integration. Agencies may also need to pay a developer to modify or integrate the software. 14 FOUR P  ROCUREMENT OF OPEN SOURCE SOF T WARE 4. It is important for agencies to understand the range of different software options available. When considering value for money.1	Common issues in software procurement In many aspects. innovation and maturity of both open source and proprietary software packages. and they may also have costs involved with installation. agencies need to take into account the total cost of ownership (TCO). Even software that can be downloaded and used without cost may have downstream support. The following sub-sections identify the common issues in software procurement and the specific issues that should be considered when procuring open source software. Agencies need to take these differences into account when procuring software. Most agencies will incur some combination of internal staff charges and external support and maintenance charges for either proprietary or open source software. The strategy and architectures of an agency may dictate certain principles. data conversion and testing. for use of the software. Agencies must consider the following when procuring either open source software or proprietary software: •	Applicability of the Commonwealth Procurement Guidelines. any relevant agency Chief Executive Instructions and any relevant whole-of-government ICT policies. also known as the whole-of-life costs.four Procurement of open source software This section uses the Department of Finance and Deregulation’s four-phase ICT sourcing lifecycle to identify issues that agencies should consider when procuring open source software. •	Matching support and maintenance arrangements to the agency’s requirements. •	Matching product innovation. procuring open source software is similar to procuring proprietary software. Consistent application of an agency’s strategy and architectures helps to reduce staff training and ICT support costs. Agencies should ensure that the risk profile of their service level agreement for support and maintenance is appropriate for the business criticality of the software. standards and technologies that need to be taken into account when considering new software. A Guide to Open Source Software for Australian Government Agencies . maturity and roadmap to the agency’s requirements. Agencies must always follow the Commonwealth Procurement Guidelines when selecting a software solution. Refer to the Guide to ICT Sourcing for more information. Agencies may need to purchase services for maintenance.
–– Agencies should be aware that it may be necessary to procure support services separately for open source software. •	Phase II—Decide sourcing strategy –– Agencies should decide whether there is any justification for limiting their software selection to specific technologies. open source software that is not customised – including commercial software licensed under an open source software licence – is considered off-the-shelf software. In this instance.. It should be noted that an approach to an open market will provide the most objective evidence of available options. Agencies can still customise or bespoke develop software provided they comply with the requirements of the strengthened governance arrangements. –– Agencies should also consider any whole-of-government ICT policies that may influence their decision making. and integration with existing software or systems. especially if they choose to procure open source software. Within the purview of the ICT Customisation and Bespoke Development Policy. for example.4. including the TCO. •	Phase III—Undertake procurement –– Agencies’ procurement processes must be compliant with the Open Source Software Policy. –– Agencies should ensure that there is a software licence management framework.5 –– Agencies should be aware that open source software can be sourced ‹in house’ by downloading open source software from various online repositories. Agencies should consider the market conditions and TCO. packages or software models. The benefits and risks of ‘in house’ sourcing should be assessed. maturity. especially support and transition costs. customisation is any deviation from the available versions of the open source software. support. This may include identifying any need for innovation. See Appendix 1: Australian Government Open Source Software Licensing Risk Framework for more information.2	Four-phase ICT sourcing lifecycle The Guide to ICT Sourcing divides the sourcing lifecycle into four phases. •	Phase IV—Transition and manage –– Agencies should continue to manage their software against the licence conditions. FOUR P  ROCUREMENT OF OPEN SOURCE SOF T WARE 5 The ICT Customisation and Bespoke Development Policy is focused on strengthening governance around customisation  and bespoke development. A Guide to Open Source Software for Australian Government Agencies 15 . –– Agencies should also keep up to date on the changing software industry landscape. The key issues to consider for open source software in each phase are: •	Phase I—Case for change –– Agencies should clarify their business need using their strategy and architectures to define their business case for change. the ICT Customisation and Bespoke Development Policy.
five Comparing open source and proprietary software five .
An agency may use the software as supplied. see the Australian Government’s Cloud Computing Strategic Direction paper: http://www. Agencies should consider whether they need to customise the software and whether there are any applicable whole-of-government ICT policies (for example. •	The business alignment of the initiative. however. If agencies customise open source While most open source software can be readily downloaded and used without paying a licence or acquisition fee of any  kind. distribute it or use it as a component of another software implementation. FIVE C  OMPARING OPEN SOURCE AND PROPRIE TA RY SOF T WA RE 5. •	Access to source code. open source software makes the source code available to anyone for viewing. this is not an inherent characteristic of all open source software. if an agency’s software uses a particular standard. For  further information on cloud computing. Although open source software usually has no upfront cost.finance. training and exit costs. there may be a change in the risk profile. there may be an opportunity to leverage an agency’s existing software investments. Implementing open source software does not necessarily expose an agency to greater risk than implementing proprietary software.1	Key issues Agencies need to consider the following when procuring open source or proprietary software solutions. •	Capital expenditure. However. Agencies need to understand the opportunities and risks associated with the different software options. integration. This is based on the relevance of the initiative to the agency’s core business. The Guide to ICT Sourcing provides a framework for assessing initiatives as vital.au/e-government/strategy-and-governance/cloud-computing. By definition. •	Customisation. the cost of integration may be reduced by integrating software that supports the same standard.five Comparing open source and proprietary software This section highlights some of the key issues that agencies should consider when comparing open source software to proprietary software. 7 Agencies should note that alternative sourcing models such as cloud computing also do not have capital expenditure. unless the proprietary software is provided as a service. Some of the factors that will affect the risk profile are: •	How the agency is using the software.7 Agencies should consider the TCO for both proprietary and open source solutions. the TCO is unlikely to be nil. Considerations include acquisition. Proprietary software generally restricts access to and modification of its source code. maintenance and upgrades. Agencies should also consider any licensing obligations.6 Proprietary software generally includes an upfront fee. deployment. for example. they should consider the cost of future support. even if an agency provides in-house support. vetting and modification. support and maintenance.html 6 18 A Guide to Open Source Software for Australian Government Agencies . or discretionary and support. Customisation of open source software can be undertaken either by the agency or by a third party.gov. duty-bound. modify it. the ICT Customisation and Bespoke Development Policy). If agencies choose to customise the software.
Some open source software licences may oblige agencies that modify and distribute the software to contribute all changes back to the open source software community. Agencies should also consider the possibility of being locked in due to a lack of support options. Open source software is generally developed by communities of developers who work together online. This exemption allows the Commonwealth to retain intellectual property in products governed by open source licences. However.8 These communities may also be supported by commercial organisations. A Guide to ICT Sourcing for Australian Government Agencies provides a detailed review of this topic.nsf/Page/CopyrightStatement_of_Intellectual_Property_Principles_for_Australian_ Government_Agencies. Agencies need to be aware of any liability they may face when modifying and distributing software.10 •	Liability. a broad user base. The nature of open source software allows agencies to contribute back to the product.net). Some open source software products will come with an option to configure them to a more familiar interface. The Statement of Intellectual Property Principles for Australian Government Agencies is available for download from  www. •	Licence obligations. it should carefully assess the credentials and resources of the developers. FIVE C  OMPARING OPEN SOURCE AND PROPRIE TA RY SOF T WA RE 8 9 10 Many open source software products are available on SourceForge (sourceforge.ag. as agencies will need to factor in the cost of contributing back (i. a good governance structure and regular updates is more likely to be responsive to user requests. The corporate history and product roadmap of proprietary software vendors may give agencies an indication of the quality of the vendor. Agencies should be aware of the risks of being locked-in to one type of software. Agencies should be aware of their licensing obligations. which can improve interoperability and reduce vendor lock-in.software and do not contribute the modified product back to the open source software community. The agency should consider whether appropriate development of the software will continue during the expected lifespan of its use by the agency. Code forking is discussed in further detail in the next section. An open source software community with an active and diverse membership. The training necessary for end users should be considered whenever a new software purchase is made or an upgrade is obtained. •	End user.gov. including the possibility of the software being dual licensed. this may affect the TCO of the product. proprietary software relies on the vendor to drive innovation. Proprietary software also comes with its own set of licensing obligations. staff costs). Any liability that agencies may face is generally listed in the software licence conditions under disclaimer of liability or disclaimer of warranty.9 •	Innovation. Historically. There is a specific exemption for software governed by open source licences in the Australian Government’s Statement of Intellectual Property Principles for Australian Government Agencies. •	Lock-in. Before an agency commits to using any software package. this is called code forking. •	Development/Governance. A Guide to Open Source Software for Australian Government Agencies 19 . which can aid innovation.e. Open source software may align to open industry standards.au/www/agd/agd. •	Intellectual property.
–– Commercial: Support can be procured from a commercial organisation.php 20 A Guide to Open Source Software for Australian Government Agencies . and the associated risk management and support tasks. The Defence Signals Directorate’s Evaluated Products List provides a list of products that are certified for specific purposes and specific security levels. However. agencies need to ensure that they have the appropriate governance structures in place for any shared solutions.11 •	Support and maintenance. it is generally purchasing services and receiving the related software free of charge. governance and deployment arrangements. Open source software allows agencies the opportunity to examine the source code. All software should be scrutinised for its security. However. •	Reliability. When an agency acquires an open source software solution through an external service provider. Proprietary software will usually have some restrictions on its use. Open source software may encourage re-use through the community creation of solutions specifically for government use.•	Maturity and portability. •	Release management.gov. This includes considering the risks of having to change to a different product in the future. which may assist in assessing security risks. Open source software offers the following options for support and maintenance: –– In-house: Support and maintenance can be provided in-house by the agency.au/infosec/epl/index. which may include the requirement to pay additional licensing or support costs if there is a change in how the software is to be used. release management. agencies should ensure that they understand the licence conditions before modifying the software. •	Restrictions on use. Open source software generally has an increased number of new releases that may have a negative impact in terms of greater requirements for integration testing. Agencies should ensure that they evaluate the maturity of any software product they are procuring.dsd. Support and maintenance for proprietary software is generally provided 11 FIVE C  OMPARING OPEN SOURCE AND PROPRIE TA RY SOF T WA RE http://www. Commonly used open source software products may be more reliable as the community works to select the best improvements and offer them in the next release. particularly if it will be used in a high-security area. agencies need to assure themselves of the capacity and capability of any organisation claiming to offer support services. bug fixes. Open source software that is in widespread use is likely to have more competitive support services. Agencies should evaluate the reliability of any software product they are procuring. The ICT Customisation and Bespoke Development Policy provides governance principles for cross-agency solution sharing. •	Security. However. There is usually a competitive market for commercial support services for open source software. •	Re-Use. Some open source software products may depend on key individuals within a community or a specific vendor to support the product. Agencies should also check the support arrangements. –– Community: Free support can be provided from the open source software community. There are typically few or no restrictions on the use of open source software.
open source software that is procured from a commercial vendor will generally come with similar warranties to proprietary software. This risk may be mitigated by contributing modified source code back to the open source software community. they may also be obligated to publish any changes that have been distributed. Depending on the licence. such as the ICT Customisation and Bespoke Development Policy. Any further changes made by either the agency or the community will increase the fork. If agencies do not follow the terms and conditions of a software licence. they risk being in breach of copyright. • The benefits. The fork is the split between the agency’s version of the software and the version published by the community. generally A Guide to Open Source Software for Australian Government Agencies 21 . alignment is maintained with the published version. A highly reciprocal licence will require agencies to make any modified code publicly available. which may involve prosecution. Reciprocity	International precedent strongly suggests that the copyright attached to open source software is legally enforceable in Australia. Agencies working with open source software have the option to publish changes back to the development community. Agencies should be aware of whole-ofgovernment ICT policies that may govern their ability to customise software.2	Beyond	use:	code	forking	and	reciprocity This section gives further information on two issues that apply when modifying or developing open source software. FIVE C  OMPARING OPEN SOURCE AND PROPRIE TA RY SOF T WA RE 5. Some open source software licences include the concept of reciprocity. Agencies should also ensure that they have the appropriate skill base to manage the development and ongoing maintenance of the forked software. This can make it difficult for the agency to upgrade to a new published version. costs and risks of customising should be included in the business case for any software initiative. Should these changes be accepted by the community and integrated into the base product. as upgrading to the next supported version of the package may be more expensive and time consuming due to the customisation. as the agency would have to reapply all its changes. Customising commercial products can also create a future liability for the agency. Code	forking Code forking occurs when agencies make changes to the code of open source software without publishing the code back to the software’s development community. However.by the vendor or authorised partners. • Warranties. Code forking is similar to customising proprietary software packages. with a certain amount of first level support usually being provided in-house. Open source software that is downloaded free generally does not offer warranties. Agencies need to consider the implications of contributing modified source code back to the community.
under the same licence. Agencies that use the open source software without modifying it are unlikely to trigger a reciprocity provision. The current law is unclear as to the boundaries of distribution. Without strong governance. agencies run the risk of being unaware of licensing risks. It is strongly recommended that agencies seek legal advice whenever they seek to modify open source software. FIVE C  OMPARING OPEN SOURCE AND PROPRIE TA RY SOF T WA RE 22 A Guide to Open Source Software for Australian Government Agencies . If the modified source code is used only within one agency. Agencies will need to consider the implications of publishing the whole of the derived work. Low reciprocity or permissive licences do not oblige agencies to contribute back any changes. Agencies are encouraged to set up strong governance to track all instances of open source software in their systems. Further information on reciprocity is available in Appendix 1: Australian Government Open Source Software Licensing Risk Framework. it is unlikely that reciprocity will be triggered. Reciprocity is triggered when a derived work is distributed.
Appendix 1: Australian Government Open Source Software Licensing Risk Framework .
assessing and managing risk and compliance issues to do with open source software.	Overview Open source software is licensed under conditions that allow users to view. This may involve reviewing and adapting the licensing compliance methods that they have established.Appendix 1: Australian Government Open Source Software Licensing Risk Framework 1. The Australian Government Open Source Software Policy requires agencies to consider both types of software when procuring software to meet their business needs. similarly to proprietary software •	customisation through external contractors or inhouse developers •	integration with other software (including open source. A Guide to Open Source Software for Australian Government Agencies . Agencies that are considering modifying open source software are advised to consult their legal departments to clarify their licence obligations. which usually disallows access to source code and is available only on payment of a fee. open source software may have significant advantages. Attachment A to the framework provides a list of assumptions behind the creation of the framework.	Background to the framework The use of open source software has no more inherent risks than the use of proprietary software. Increasingly. To access those benefits. deployment. 24 APPENDIX 1 2. in fact. proprietary or custom developed software) •	bespoke development. These characteristics differentiate it from proprietary software. use and modify the source code. Agencies need to fully understand and comply with the terms and conditions of the licences that govern the software that they use. Australian Government agencies are choosing to procure open source software for application in one or more of these scenarios: •	use without modification. developed or distributed. to ensure that they are equally effective in managing both proprietary and open source software. development. It is generally available free of any fee for access or use. Open source software has many potential benefits for Australian Government agencies. particularly in situations where open source software might be modified. agencies must understand the issues posed by open source software licences in respect to the use. modification and/or distribution of the software. The purpose of the Open Source Software Licensing Risk Framework (Licensing Risk Framework) is to provide a high-level overview of the key issues that Australian Government agencies need to consider when identifying.
Part 3: Anatomy of licensing risk for project managers. It is not legal advice. Part 2: Anatomy of licensing risk for technical staff. including those cases in which software development is outsourced. The attachments provide more detailed information on the assumptions on which the framework is based. understand and mitigate potential risks and issues involving open source software.	Outline	of	the	framework The Licensing Risk Framework will assist agency staff members to identify. This section recommends how licensing risk should be managed throughout the term of a project.The Licensing Risk Framework is designed to advise agencies about risks and issues they may face when using. integrating or developing open source software. The framework is presented in four parts: • Part 1: Introduction to licensing risk. based on a risk matrix. This section briefly summarises the purpose of the Licensing Risk Framework and outlines why the Australian Government needs a framework to address the risks involved in open source licensing. It provides a model that enables an agency to assess its licensing risk in its specific circumstances. All relevant staff members are encouraged to read this section. APPENDIX 1 3. This section introduces the concept of reciprocity and describes how reciprocity applies to both the licensor and licensee. Part 4: Attachments. • • • A Guide to Open Source Software for Australian Government Agencies 25 . customising. technical information on particular aspects of open source software licensing and an example of an agency’s approach to identifying licensing risk. Staff members who may be interested in this framework include: • • • technical staff who are involved in building software solutions project managers who manage project delivery and project risks agency policy makers.
there is some ambiguity about how open source licences can be legally enforced. In addition.4.13 Breaches of licence provisions are not always intentional. after which only the copyright holder can reinstate the licensee’s rights. this has not been tested in Australian courts. While proprietary software licences attract the standard protections available under copyright law. in Europe and the United States. agencies may not be aware of all the actions that may lead to a breach of an open source licence. Any breach may have far-reaching consequences. To date. A Guide to Open Source Software for Australian Government Agencies . agencies must ensure that they have the appropriate governance in place to track. the Free Software Foundation has successfully taken legal action against distributors that have failed to comply with open source licensing provisions. Therefore. monitor and evaluate all instances of open source software. However. but there are other implications of this and it is the exception rather than the rule. they may be due to a lack of governance in the tracking the use of open source software within an agency. traditional mechanisms for assessing and approving procurement may need to be supplemented with mechanisms for acquisition and deployment. Staff members who use the software should be informed of the licensing obligations.12 A breach of an open source licence will occur if software covered by an open source licence is used contrary to the terms of the licence. Agencies need to comply with the provisions of both open source and proprietary software licences. Given that open source software can generally be acquired without incurring any licence fee. Australian Government Open Source Software Licensing Risk Framework 1: 26 APPENDIX 1 4P A R T Introduction to licensing risk This part: • • outlines the importance of being aware of open source licensing risks offers an approach to identifying and managing the risks related to open source software licensing. 12 13 The Free Software Foundation is a not-for-profit organisation that advocates and educates on the value of free software. a breach of the GNU General Public Licence V2 immediately terminates the licence. the licensee must immediately cease using or distributing the software. as is the case for proprietary software. Without a valid licence. It is possible in some circumstances that use for the purposes of the Commonwealth could continue under special rights contained in the Copyright Act 1968. For example.
Figure 1 provides a general overview of the potential risks applicable in different licensing scenarios. an obligation to publicly release the modified code is triggered only if all three of these conditions apply: •	the licence contains a reciprocity provision •	a derived work has been produced •	that derived work has been distributed. This includes whether the agency intends to modify the open source software product (that is. agencies need to be aware of the: •	Type of licence. However. For example. medium or low) or restrictiveness (restrictive. This will ensure that agency staff members are aware of the risk level acceptable to their agency. Typically. Figure 1: Risk matrix for open source software use Intended use Distribution of derived work No distribution of derived work Licence Type 1 High reciprocity Very high risk potential Medium risk potential Licence Type 2 Medium reciprocity High risk potential Low risk potential Licence Type 3 Low reciprocity Low risk potential Very low risk potential APPENDIX 1 Agencies can integrate a similar risk matrix into their corporate risk management framework. restrictive hybrid or permissive). by using libraries or tools). licences will be both highly restrictive and reciprocal. The type of licence can affect what an agency can do with the software. the agency should consider not using open source code and tools that are subject to a restrictive licence. Generally. If the public release of modified code is not acceptable to an agency. Open source software licences may be described in terms of their reciprocity (high.Identifying licensing risks Generally. •	Intended use. to help determine their individual risk appetite for initiatives that involve open source software. or both permissive and lowly reciprocal. they need to be aware of. A Guide to Open Source Software for Australian Government Agencies 27 . agencies that use open source software without modification are unlikely to trigger any licensing compliance issues. when dealing with open source software. Attachment E provides an example of the procedure for applying such a matrix. Reciprocity and restrictiveness are further defined in Part 2 of this framework. the associated licensing risks and issues. create a derived product) and to distribute any modified versions of the product (derived works). When agencies modify or develop open source software (for example. and manage. an agency that modifies and distributes an open source product with a restrictive licence will trigger an obligation to publicly release the modified code back to the open source community.
nsf/Page/Copyright_CommonwealthCopyrightAdministration_ StatementofIPPrinciplesforAustralianGovernmentAgencies A Guide to Open Source Software for Australian Government Agencies . and especially with open source licences. to mitigate this risk. and that components used in the project carry mutually compatible licences.au/www/agd/agd. There are additional licensing risks when agencies engage external contractors for software development.gov. they must ensure that their policies. agencies have limited control and day-to-day oversight over vendor activities. 14 The Statement of Intellectual Property Principles for Australian Government Agencies specifically excludes ICT products  governed by open source licences from the general advice to allow vendors to retain the intellectual property in software developed under contract for agencies. When external contractors are engaged. procedures and tools are adequate to manage the risks. Project managers should also ensure that they are fully aware of all open source software within their project.After agencies have identified the risks associated with a project. Therefore. agencies should stipulate in the contract that copyright of any code developed under restrictive open source licences lies with the agency. Effective governance of source code management is critical to managing open source software licensing risk. http://www. including the selection. use and management of open source software.ema.14 28 APPENDIX 1 Mitigating risk Table 1 describes the risk mitigation techniques that agencies may choose to follow in order to ensure compliance with software licences in general.
•	Ensure that the agency has considered the implications of deviating from the baseline product. . support and maintenance over the intended lifetime of use of the software in the agency.Table 1: Risk mitigation Mitigation practices for circulation outside of the agency •	Read the licence to ensure compliance with all the terms and conditions. costs and risks of reapplying agency-specific changes to future baseline upgrades. integration. This is generally true for open source software. •	Ensure that there is a clear understanding of the legal boundary of the agency and the software’s intended use. The above action plus: Derive (create a customised or modified version inhouse) •	Ensure that the licence conditions allow for derivation. integration. •	Consider the reputational and liability risks in being seen as a distributor of the software. Mitigation practices for use within the agency Use as is (use without modification) •	Read the licence to ensure compliance with all the terms and conditions. •	Ensure that the licences for all components are compatible. Without that understanding. •	Ensure that the agency has access to the skills necessary for the development. costs and risks of reapplying agency-specific changes to future baseline upgrades. an agency may accidentally distribute its derived code. but generally limited for proprietary software. in proportion to the business criticality of its role. which may trigger an obligation for the agency to publicly release the derived code. or immediately stopping the distribution of the software if it is found to be in breach of licence conditions. •	Ensure that the agency has access to the skills necessary for the development. including the likely additional time. •	Consider the reputational risks to the agency due to the quality of the published software. The above actions plus: •	Ensure that the licence conditions allow for derivation. •	Consider the possibility of the agency having to publish all source code that is being integrated with open source components. •	Ensure that there is a clear understanding of the legal boundary of the agency and the software’s intended use. including the likely additional time. but generally limited for proprietary software. support and maintenance over the intended lifetime of use of the software in the agency. 29 APPENDIX 1 A Guide to Open Source Software for Australian Government Agencies •	Ensure that the agency has considered the implications of deviating from the baseline product. in proportion to the business criticality of its role. This is generally true for open source software. •	Ensure that the licence allows the agency to act as a distributor.
expectations of what ongoing support or assistance might be provided by government to the community. the package will need to be governed by a compatible licence. For proprietary software.1 APPENDIX 1 Mitigation practices for use within the agency All of the above actions plus: A Guide to Open Source Software for Australian Government Agencies Bespoke development (develop a new solution from scratch. this will involve making sure that the contractual and other arrangements accord with all obligations under relevant licences. this may involve a review of provisions relating to the use of runtime environments and libraries. •	Ensure that the arrangements will comply with any licence arrangements for development tools and/or licensed components. •	Ensure that the arrangements will comply with any licence arrangements for development tools and/or licensed components. this will typically mean that either the contract must provide that your organisation owns all intellectual property or that the code is licensed under an open source licence that is compatible with all other relevant tools and components forming part of the bespoke development.gov.au/www/agd/agd. –– Consider potential issues that may arise with a community.1 1 See the Statement of Intellectual Property Principles for Australian Government Agencies. For open source restrictive licence development tools and/or licensed components. www.ag.nsf/Page/Copyright_CommonwealthCopyrightAdministration_StatementofIPPrinciplesforAustralianGovernmentAgencies . and whether or not parts of the community may take the software in different directions (forking). for example. For open source restrictive licence development tools and/or licensed components. you need to consider whether any potential issues would arise if external parties were to exercise their right to include the code in commercial products. Where external contractors are involved. Where external contractors are involved. –– If a permissive licence is being considered.30 Mitigation practices for circulation outside of the agency All of the above actions plus: •	Consider the risks of open sourcing against the benefits. either inhouse or by use of contractors) •	Consider the risks of open sourcing against the benefits. –– The type of licence used may affect the likelihood of an external community forming to further develop/support the open source initiative that you are starting. this will typically mean that either the contract must provide that your organisation owns all intellectual property or that the code is licensed under an open source licence that is compatible with all other relevant tools and components forming part of the bespoke development. •	Consider the best type of open source licence to govern the package. this will involve making sure that the contractual and other arrangements accord with all obligations under relevant licences. –– If components/tools governed by a restrictive licence are used.
including an overview of the concept of dual licensing. the risks are comparable to the risks incurred when an agency is using a proprietary product. A Guide to Open Source Software for Australian Government Agencies 31 . while an analysis of what constitutes distribution is in Attachment C. see Attachment D. Generally. compliance with open source licences may become complicated. Whenever an agency creates a derived work and distributes that work. the definitions and boundaries of these terms are not clear. particularly when a developer intends to create a new application incorporating code from a variety of sources. Industry views on what constitutes a derived work are available in Attachment B. Agencies that are considering modifying open source software should seek legal advice. the agency will need to comply with any reciprocity provisions that exist in the relevant open source licence. However. Each open source software licence imposes a specific set of requirements and limitations on developers wanting to modify and/or redistribute the licensed software.APPENDIX 1 4P A R T 2: Anatomy of licensing risk for technical staff This part: •	describes the concepts of reciprocity and restrictiveness. Due to a lack of legal precedent in this area. regardless of what open source licence is attached to the product. For links to open source licences. and the conditions that trigger reciprocity •	provides an open source licensing risk model for agencies to assess their licensing risks •	emphasises the need for agencies to consult with their legal departments before modifying open source software. when an agency is using an unmodified open source software product.
The obligation is generally triggered when all of the following provisions are met: •	The licence contains a reciprocity provision •	A derived work has been produced •	That derived work has been distributed. They aim to encourage the widespread use of the software by placing few barriers to its use. Open source licences can be divided into three broad categories. based on the level of reciprocity obligations they contain: •	Permissive licences contain no reciprocity provisions. reciprocity is not triggered until derived work is distributed. see Attachment B. for further information on the definition of derived work. A Guide to Open Source Software for Australian Government Agencies . 32 APPENDIX 1 Derived works Even under a restrictive licence. Figure 3 illustrates five scenarios in which a software developer incorporates open source software into an agency’s ICT project. A highly restrictive licence will mean that all derived software must come under the same licence as the original source. Combining open source code and other code is called deriving. •	Restrictive (sometimes called copyleft) licences contain strong reciprocity provisions (to ensure the freedom of the software cannot be compromised). The list of scenarios is not designed to be exhaustive.Restrictiveness and reciprocity Reciprocity refers to the obligation to make available to the development community any changes that are made to the source code of licensed open source software. To clarify the range of circumstances in which modifying source code creates a derived work. •	Hybrid restrictive licences contain reciprocity provisions that have some exceptions or apply only in some circumstances. They aim to encourage the continued growth of the software by ensuring that those who use it share their changes with the development community. A permissive licence allows for a greater freedom in how the original components of a derived work can be licensed. A more restrictive licence will tend to mean that agencies are restricted in the choice of licence they can use for the derived software.
Figure 2: Scenarios for developing software with open source software (OSS) components OSS Licensed code APPENDIX 1 Inputs Result Coding A Program Original code B Module Compiler Original code Compiled Program Compiler Installer Runtime Library Production environment C Runtime Library Original code D Program Compiler Installer Compiled Program Runtime Library Production environment Exec E Program Coding effort Web service Remote client Note:  The scenarios assume that the original open source software is licensed under a restrictive licence. A Guide to Open Source Software for Australian Government Agencies 33 . The five scenarios are: •	Case A—200 lines of source code are added to extend the software’s functionality.
under an open source software licence. where the General Public Licence (GPL) and the Lesser General Public Licence (LGPL) are involved. called an exec command. and the agency must publicly release the source code of the derived product. Open	source	software	licensing	risk	model A licence is a legal agreement between two parties. The derived work has been then distributed or conveyed to others. 17 However.• • • Case B—The custom source code is compiled with open source software licensed code (a static library) into a single executable. the parties to an open source software licence are the copyright holder/licensor (typically. one or more software developers) and the licensee. the foundation may coordinate and fund efforts to enforce compliance. to a third party. regardless of whether the agency intended the trigger events to occur or abandons the project after the event: • • • The open source software component is subject to a non-permissive open source licence. the agency must make the source code of the derived work available and licence the derived work under the applicable open source software licence. In the case of the Licensing Risk Framework. 15 A Guide to Open Source Software for Australian Government Agencies . Failure to release the source code under the relevant open source software licence would be a breach of the agency’s legal obligations governing the open source software component of the derived work. Historically. namely • Case E—This is similar to Case A. Any licensee that does not follow the terms and conditions of the licence risks being subjected to legal action. the licensor has the legal right to enforce their rights as outlined by that licence. the Free Software Foundation has instigated compliance action in the event of a reported breach. Even where developers retain the copyright. The functionality of an open source software based solution is extended. The foundation has a proven track record in mounting successful legal action before United States and European courts to enforce the GPL and LGPL licences. the relevant Australian Government agency does not have any obligation to maintain the software. 17 Agencies should refer to their Chief Executive Instructions as well as the Financial Management and Accountability Act 1997 to determine what delegations are required to enter into such arrangements. The first program invokes the second program via the operating system. reciprocity is triggered.15 Generally. the rationale being that the foundation is best positioned to enforce the licence should a licensing breach occur. open source software developers turn over their copyright ownership to the Free Software Foundation. Case C—A custom-built proprietary program interacts with a runtime library licensed Case D—This is similar to Case C. These improvements are implemented as an online service over a network. 34 APPENDIX 1 a system-level command. The open source software component has been used by the agency to create a derived work. 16 In many cases. Having chosen a type of open source licence that suits their purposes. the licensee is generally the agency. 16 If all of the following conditions are met. Once reciprocity has been triggered.
Attachment E provides an example of a risk treatment matrix and assessment procedure. an agency should be able to determine whether its actions will trigger any reciprocity provisions. such as the example in Figure 3. Agencies are recommended to seek legal advice regarding reciprocity. The agency can then use a model for working through the concepts involved in open source software licensing.Having determined whether it is creating derived works and what constitutes distribution of those derived works (see attachments B and C). based on the fairly comprehensive approach adopted by the Australian Taxation Office. A Guide to Open Source Software for Australian Government Agencies 35 APPENDIX 1 . as part of its strategic approach to identifying and managing risks.
Figure 3: Open source software licensing risk model 36 APPENDIX 1 Agency selects OSS Product governed by OSS Licence with Terms and Conditions High Reciprocity Agency chooses to If agency does not contribute back to the community then Derive and Distribute Have obligation to Contribute back to community Medium Reciprocity Agency chooses to Derive and Distribute May have obligation to Contribute back to community Low Reciprocity Agency chooses to Derive and Distribute No obligation to Contribute back to community BREACH Acts upon Licensor or Free Software Foundation A Guide to Open Source Software for Australian Government Agencies .
In that case. •	The terms and conditions may specify obligations for agencies. •	Agencies that choose an open source software product with a medium-reciprocity licence may have an obligation to contribute back to the community if they derive and distribute. •	Agencies that choose an open source software product with a high-reciprocity licence are obliged to contribute back to the open source software community any work that they derive from that product and distribute.Key points In developing a risk-management strategy. •	Agencies that choose an open source software product with a low-reciprocity licence will have no obligation to contribute back to the community even if they derive and distribute. •	Agencies must accept the licence attached to pre-existing open source software that they use. •	The licence comprises terms and conditions. •	The open source software product is governed by an open source software licence. except where the creation is actually derived from other open source software. A Guide to Open Source Software for Australian Government Agencies 37 APPENDIX 1 . the degree of reciprocity in the terms and conditions of the licence for the pre-existing components may influence the choice of licence for the derived components. Those obligations are triggered by the act of distributing derived work. •	The Free Software Foundation has successfully acted on breaches of licence conditions on behalf of licensees. More highly reciprocal licences will trigger the obligation more readily. Agencies may choose the licence for open source software that they create. which can be classified by the degree of reciprocity. it is important for the agency to note that: •	The agency selects the open source software product.
A Guide to Open Source Software for Australian Government Agencies . and use the Open Source Initiative and Free Software Foundation websites to verify compatibility between licences. It is important for project managers to work in concert with technical staff to identify. Keep this list up to date in the agency’s source repository. Use of the framework It is difficult to generalise about open source software licensing. the version of the code and the contact details (usually a website) for the code’s authors. Therefore. In particular. ask the vendor about their compliance procedures. contractors or consultants. agencies must ask what mechanisms they have in place to aid the agency with compliance. •	Where software development is outsourced. project managers should pay close attention to the following points when managing open source software projects: •	Ensure that the agency has copyright over any code that has been written for the project by staff. •	Search the codebase for code from external projects and note the licence used. scope and manage licensing risk throughout the development lifecycle. Project managers and technical staff should begin by reading the general overview of open source licensing risks of Part 1 of this framework. It is also advisable to ask the vendor if they will formally indemnify the Commonwealth in case the agency is found to be in violation of any licence.38 APPENDIX 1 4P A R T 3: Anatomy of licensing risk for project managers This part: •	informs project managers of specific issues they need to consider when managing open source software projects •	reminds project managers of the necessity to consult with their legal department when considering open source software. Key points In particular. A project manager should use the Licensing Risk Framework to arrive at informed decisions about: •	the appropriateness and merits of using component-based open source software rather than source code written in-house •	the likely risk of being obliged to make any newly created source code publicly available under any of the relevant open source software licences. project managers may find it hard to determine the best approach to identify and mitigate licensing risks.
•	Attachment B provides advice on how to identify a derived work. Most importantly. 4P A R T 4: APPENDIX 1 Attachments The following attachments provide more technical guidance on the issues described in the framework. •	Attachment E provides an example. For example.•	Choose an appropriate licence for the release of the derived code. of an open source software treatment matrix and assessment procedure. •	Attachment D gives links to different types of open source software licences. drawn from Australian Taxation Office documentation. making sure that it is compatible with existing licences and that it meets the agency’s business needs. A Guide to Open Source Software for Australian Government Agencies 39 . the GPL may be appropriate if the agency wants others to contribute back any enhancements they make to the project. •	Attachment A outlines the assumptions on which the framework is based. •	Attachment C provides advice on distributing or conveying a derived work. the agency’s legal department should be consulted before any decisions are made.
For example. currently. due regard should be had to information generally regarded within the open source software community as authoritative or reliable. rather than about what may or may not be legally arguable. an agency should adopt the most conservative position. in the absence of a clear judicial ruling to the contrary. including those involving software development. consequently. Research undertaken by the open source software community suggests that many organisations using open source software fail to manage the end-to-end risk from the point of acquisition to an application’s retirement. it would be unwise to adopt a practice in opposition to advice given from the Free Software Foundation or the Open Source Initiative. Furthermore. there is some uncertainty about whether dynamically linking GPL-licensed code to agency-developed code creates a combined derivative work to which the GPL applies. the Commonwealth has an interest in ensuring that such measures are well informed. Although there are various expert opinions on open source licensing. The risks for agencies will vary mainly in the extent to which a particular agency uses open source software for software development. These risks are exacerbated by a number of factors: •	Open source software awareness within agencies.Attachment A: Assumptions and risk factors The Open Source Software Licensing Risk Framework is based upon the following assumptions: •	Individual Australian Government agencies are responsible for managing their own legal risks. The Free Software Foundation is emphatic that it does. Consistent with the conservative approach above. This guide is about appropriate approaches to managing open source software associated risks. 40 APPENDIX 1 : AT TACHMENT A A Guide to Open Source Software for Australian Government Agencies . they may inadvertently overlook licensing implications when using open source software. software developers are not fully aware of software licensing issues. •	The open source software community provides quality information sources that can provide sound guidance on many complex issues. scope change. while the Open Source Initiative thinks the situation is unclear. •	Where there is any uncertainty about whether an open source software licensing right or obligation applies. The conservative assumption is to treat the package as a combined derivative work to which the GPL applies. they may not realise that the risk relates to the type and specific provisions of the open source software licence governing each open source software component used in a project. Typically. Similarly. There is also a level of uncertainty about licence interaction. change of use and other factors that might trigger unintended licence breaches. this guide draws heavily on reliable information from the open source software community about what is considered best practice and the safe approach to any area of potential controversy. For example. and the potential consequences of a breach. •	Understanding the likelihood of enforcement is more useful to the analysis of open source software licensing risk than the abstract legal questions of the meaning of key terms such as derived works. there has been few court cases. however.
use and management of open source software. in particular. Open source software is very easy to download from the Internet and thus can be difficult for an organisation to track and manage. in whole or in part.•	Licence and source code management issues. including the selection. Open source software is used in a number of contexts. agency staff have limited control and day-to-day oversight over vendor practices. for use by other agencies or even by members of the community. If and when agencies engage external contracting houses to undertake software development. The risk relates the use to which the software developed under a project will be put and. •	Distribution of open source software–based solutions. •	Software development scenarios. A Guide to Open Source Software for Australian Government Agencies 41 APPENDIX 1 : AT TACHMENT A . whether that use might involve the developed software being distributed or conveyed outside the developing agency. Certain licences require explicit actions if and when software constituting a derived work is distributed. whether solely for internal use or passed on.
This position is based on the theory that the GPL can control only what is controllable under copyright law and also on some of the phrases in GPL2 used to define the scope of a work based on the Program.Attachment B: Identifying a derived work Although there is no definitive guide on how to identify a derived work. “The ‘user program’ exception is not an exception at all. The following quote is an excerpt from Heather Meeker’s book The Open Source Alternative: Understanding Risks and Leveraging Opportunities. you will likely not run afoul of the FSF position. However. John Wiley & Sons. Linus Torvalds: User space is outside the boundary of the kernel.18 This analysis may assist agencies in determining whether their activities will lead to the creation of a derived work. But as stated. FSF: User space is outside the boundary of the kernel. Torvalds and the FSF are in agreement on this point: Each recognizes that interaction between user space and kernel space does not create a derived work. This special exception is expressly allowed in Section 3 of GPL2. If you use standard UNIX system calls (with accepted Linux extensions).”19 Heather Meeker. many in the industry use this rule because it represents a safe position: If you assume that all linked code creates a derived work. are respected industry authorities on the subject. by default it’s obviously derived—the very fact that you need to do something as fundamental as linking against the kernel very much argues that your module is not a stand-alone ‘thing’. in which case linked code is outside the boundary. The FSF recognizes an exception for interaction between user space and kernel space. regardless of where the module source code itself has come from. This position is based on the FSF FAQ on GPL2 and FSF comments on the GNU Lesser General Public Licence (LGPL). the Free Software Foundation (FSF) and Linus Torvalds. 42 APPENDIX 1 : AT TACHMENT B 18 19 A Guide to Open Source Software for Australian Government Agencies . Thus. the developer of the Linux kernel. LGPL must be different from GPL or there would not be two different licences. either directly or through a module. for example. the case is just a lot more muddy. Whenever you link into the kernel. Inc. The LGPL explicitly allows linking to LGPL code. Agencies should still seek legal advice if it seems that a derived work may result from the agency’s project. your program obviously doesn’t ‘derive’ from the kernel itself. FSF: Any linking (dynamic or static) to GPL code is a derived work within the boundary. In truth. Quote originally from Linus Torvalds. linking brings code within the GPL boundary. Copyright © 2008 by John Wiley and Sons. FSF: The boundary is identical to what composes a derived work under copyright law. it’s just a more clearly stated limitation on the ‹derived work’ issue. 2008. which implies that the FSF considers this to create a derived work but has allowed an exception for it. The Open Source Alternative: Understanding Risks and Leveraging Opportunities. the FSF position is not quite this clear-cut.
they are definitely combined in one program. If modules are designed to run linked together in a shared address space that almost surely means combining them into one program. function calls within a shared address space. or the exact words of any extrinsic commentary. So when they are used for communication.g. the modules normally are separate programs. it is unclear why the standard C libraries (glibc) are licensed under LGPL. We believe that a proper criterion depends both on the mechanism of communication (exec. In other words. This violates the spirit of the GPL. FSF: Software that interacts via communications protocols such as pipes and sockets is not a derived work. clearly described. The FSF views standard system libraries such as Java standard classes as an exception. But if the semantics of the communication are intimate enough. One useful approach is to focus on the spirit of the GPL rather than its letter.) This approach is attractive both because it bears directly on risk assessment (by irritating the least number of licensees who want to modify the GPL code) and A Guide to Open Source Software for Australian Government Agencies 43 APPENDIX 1 : AT TACHMENT B .FSF: Linking to standard language routines does not create a derived work. the interface is all that matters. The spirit of the GPL is to allow licensees to freely use and modify code. and creates a true ‘black box.’ then the spirit has been served. sockets and command-line arguments are communication mechanisms normally used between two separate programs. etc. RPC. Therefore. The FAQ on the GPL2 (version 2) says: “What constitutes combining two parts into one program? This is a legal question. so it functions as a black box. If the modules are included in the same executable file. pipes. then the spirit of the licence has not been served. if the interface between the proprietary module and GPL code is simple. static link. (A black box means that the programmer modifying the GPL code does not need access to the proprietary code. ‘How does this affect my licensees?’ If the existence of the proprietary module means the licensee cannot effectively modify the GPL code. See FAQ quoted earlier. that too could be a basis to consider the two parts as combined into a larger program. However. or otherwise.) and the semantics of the communication (what kinds of information are interchanged). The whole question of the border dispute arises because segregating code into linked files is a way to hide functionality in proprietary modules. which ultimately judges will decide. the programmer does not need to see the workings of the proprietary module. However. exchanging complex internal data structures. By contrast. The FSF’s overall position on linked code has more to do with the ‘intimacy’ of integration between modules than their method of integration: dynamic link. a company considering distributing a proprietary module should always ask. Any programmer worth his or her salt can move any key functionality into a separate file and obfuscate it in binary form. FSF: Clean integration (e. pipes. data sharing). if this is so.” FSF: Software that interacts via an exec statement is not a derived work.
Black boxes are good design. because the header is often the file that indicates licence terms. This statement is heard often. 44 APPENDIX 1 : AT TACHMENT B A Guide to Open Source Software for Australian Government Agencies . but what it means is not always clear. In a sense it is a truism. Because this line of demarcation seems more an industry adage than a reasoned opinion. because a link requires a header to connect the two linked files.because it is based on sound engineering principles. I leave it aside in favour of the more detailed cases discussed earlier. Anything with a GPL header must be covered by GPL. more often it means that any module linked to GPL code must be under GPL. However. Every engineer understands that. without a complex explanation of circuit splits and copyright law.
20 The GPL is a free. It is not legal advice. Generally. this includes the obligation to: • • • license the modified code on the terms of the GPL ensure that the fact that original work has been modified is clearly notified in each changed file provide. GPL 2. Inc: http://fsf.0 refers to distribution. or offer to provide.0 uses the word ‘convey’. The GNU website provides a list of Frequently Asked Questions that gives guidance on the difference between conveying and distribution. APPENDIX 1 : AT TACHMENT C Definitions There are currently several versions of the GPL. A Guide to Open Source Software for Australian Government Agencies 45 . copyleft licence that is © 2007 Free Software Foundation.org/. which use slightly different definitions. the agency may only convey or distribute GPL code that it has modified (within the meaning of the GPL) to another person if it complies with relevant obligations set out in the GPL. Scenarios	involving	Australian	Government	entities The following is a summary of scenarios in which a copy of a modified work subject to the GPL may be passed between government entities.20 This analysis may be used indicatively to determine what constitutes distributing under other open source licences. but does not contain a definition of ‘distribute’.Attachment C: Distributing and conveying under the General Public Licence This attachment provides an overview of what constitutes distributing or conveying under the General Public Licence (GPL). Any code that is subject to the GPL may be freely modified by an agency for its own use. as well as examples of both conveying and distribution. However. indicating whether the scenario would be considered conveying for the purposes of the licence. GPL 3. the source code of the modified work.
Providing a copy of a modified work for use by a related legal entity will be considered conveying the modified work.au/publications/flipchart/index. gov.finance. statutory corporations subject to some CAC Act provisions. and Commonwealth-controlled Corporations Act 2001 companies. As there does not appear to be any Australian law that would override this position. statutory corporations that are subject only to certain CAC Act provisions and Commonwealth-controlled companies are separate legal entities. the flipchart can be downloaded from http://www. departments of the parliament and non-statutory prescribed agencies are all part of a single legal entity. Commonwealth authorities within the meaning of section 7 of the Commonwealth Authorities and Companies Act 1997 (the CAC Act). To provide a copy of a modified work subject to the GPL for use within the legal entity that made the modification is not considered conveying (or distributing) the modified work within the meaning intended by the GPL.html. it is best to assume that the provision of copies between related legal entities will be considered conveying those copies. Commonwealth departments of state.Table 2: Scenarios for distributing or conveying derived work between government entities Receiving agency type Supplying agency type Departments of state Departments of the parliament Non-statutory prescribed agencies Departments of state Departments of the parliament Non statutory prescribed agencies Statutory prescribed agencies CAC Act bodies1 State or territory governments Foreign governments 1 46 APPENDIX 1 : AT TACHMENT C Statutory prescribed agencies CAC Act bodies1 Not conveyed Seek specific legal advice Assume conveyed Seek specific legal advice Conveyed Conveyed Seek specific legal advice Assume conveyed Conveyed Assume conveyed Assume conveyed Conveyed  odies established under the Commonwealth Authorities and Companies Act 1997: includes government business B enterprises. unless the laws of the relevant jurisdiction prevent that. The Department of Finance and Deregulation publishes a flipchart that lists Australian Government entities by type. A Guide to Open Source Software for Australian Government Agencies . Statutory prescribed agencies consist of a range of agencies that can have unique characteristics. so agencies should seek legal advice to determine how the law applies in each case (the safe position is to assume that conveying or distributing might be involved until such time as it is established that it is not).
softwarefreedom. •	A list of licences that qualify as free software licences as per the Free Software Foundation definition is available at http://www. The most common occurrence of this is dual licensing.gnu. this allows users to pick their preferred licence. A Guide to Open Source Software for Australian Government Agencies 47 APPENDIX 1 : AT TACHMENT D . •	The Software Freedom Law Center has an overview document that provides a primer to open source software.linuxfoundation. It can also allow a product to be licensed under two open source licences in order to ensure licence compatibility when code from different projects is combined. This overview document includes a summary of open source software licence types: http://www.org/programs/legal/compliance. •	Various products that agencies may use to monitor their compliance with open source software licences are available.org/licenses/license-list.org/licenses.html. which can allow a product to be simultaneously licensed under an open source licence and a proprietary licence. •	A list of open source licences managed by the Open Source Initiative is available at http://www.org/resources/2008/foss-primer.Attachment D: Open source software licences Software may be offered under multiple licences. The Linux Foundation offers such a program at http://www.opensource. In addition.html.
Prohibit the creation of derived works involving the software covered by this licence. The GPL is incompatible with certain other licences.Attachment E: Example of the application of a risk management matrix for open source software The following open source software treatment matrix and accompanying sample assessment procedure were taken from Australian Taxation Office documentation to provide an example of a possible way to mitigate the risks presented by open source licences. A Guide to Open Source Software for Australian Government Agencies . Treatment for internal use only Creating a solution based on either dynamic or static linking to open source software components is permitted but only if the preconditions listed in the Exceptions section are mostly/fully met. Permissive Applies to whole applications or to component software. so code mixing should be avoided in such cases. Permit use of this software but ensure that client leaves any labelling crediting the original author (an ‘advertising clause’) intact. Carries obligations related to labelling and attribution of creator’s work on source code. Restrictive-Hybrid Applies to whole applications or to component software. Earliest licence type. Accommodates the linking of source code libraries with proprietary code without derived works being created. Reciprocal obligations arise if a derived work is created and then distributed. The use of unmodified applications is permissible. They may be adopted and altered by other agencies. Allow exceptions only if the preconditions listed in the Exceptions section are mostly/ fully met. 48 APPENDIX 1 : AT TACHMENT E Matrix of licence types Restrictive Description Applies to whole applications or to component software.
Creating a solution based on dynamic file linking to open source software components is permitted. That said.	 Consult the cell in the risk treatment matrix that corresponds to the results of the preceding steps.	 In the case of the restrictive or restrictive hybrid licence types. Permissive Permit use of this software but ensure that client leaves intact any warranty and labelling crediting the original author (an ‘advertising clause’). 3. Sample assessment procedure 1.	Classify the open source software licence as restrictive. 2. Prohibit the creation of any derived works. The treatments listed should be strictly observed and considered as default positions that constitute an acceptable level of risk to the agency. The requirements in the Exemptions section below should be addressed before exemptions are considered. Check the licensing terms to see whether static linking constitutes derived work. No exceptions allowed. and that an exception to these treatments is necessary and warranted.	 Determine whether the proposed solution involves distribution of a solution. A Guide to Open Source Software for Australian Government Agencies 49 . establish whether an intended use and proposed solution constitute a derived work. Contact the licensor to confirm the agency’s intended use and that the design of the solution is consistent with their intent in using the licence. Contact the licensor to confirm the agency’s intended use and that the design of the solution is consistent with their understanding of the licence. Note: This is dependent on the response to Step 1. restrictive hybrid permissive. Restrictive-Hybrid Derived works not permitted. The final determination will depend on the terms of the licence.APPENDIX 1 : AT TACHMENT E Restrictive Treatment if intending to distribute Unmodified applications permissible. 4. a staff member or sponsor may assert that their circumstances are special.
An exemption to the nominated risk treatments should only be considered if all of the following conditions are met. This treatment will protect the agency’s intellectual property by avoiding the obligation to make publicly available the source code for the entire solution. To be adequately managed. The client or business owner accepts these conditions of use in writing and is prepared to be audited if and when that is deemed necessary. 50 APPENDIX 1 : AT TACHMENT E • • A Guide to Open Source Software for Australian Government Agencies . The client demonstrates that they have a clear understanding of the need for and commitment to complying with conditions of use for the software to address licensing risk.Exemptions No exemptions should be granted for any solution based on the restrictive licence classification type if the solution constitutes a derived work and involves distribution. A simple checklist of expectations will be issued to the client at an appropriate time. all of the open source software licences associated with a given ICT project should be traceable and auditable at any time. • The appropriate decision maker accepts the risk for managing software and licensing obligations while the software operates in the agency’s computing environment. including any proprietary code developed by the agency.
Appendix 2: Links to other resources .
Source: http://www.au/publications/guide-to-ict-sourcing/index.ag.au/procurement/ict-procurement/index.gov. manufacturer.au/procurement/index.finance.finance. and their officials. accountability and audit obligations of agencies (including departments) that are financially part of the Commonwealth (and form part of the General Government Sector).au/e-government/strategy-andgovernance/docs/ICT_Customisation_and_Bespoke_Development_ Policy. trademark.gov. which aims to increase ICT governance and reduce customisation and bespoke development within FMA Act agencies. Source: http://www. Source: http://www.pdf A Guide to ICT Sourcing for Australian Government Agencies is a guide for Australian Government agencies that are dealing with ICT sourcing issues.Appendix 2: Links to other resources Any reference to any specific commercial product.au/www/agd/agd. which includes guidance on software development.finance.gov.au/procurement/ procurement-policy-and-guidance/procurement-policy-faqs.finance.au/publications/fmg-series/ procurement-guidelines/index.html The Financial Management and Accountability Act 1997 (FMA Act) sets out the financial management. http://www. Source: http://finance.au/e-government/strategy-andgovernance/australian-government-architecture. or otherwise does not constitute or imply its endorsement.html 52 APPENDIX 2 Commonwealth Procurement Guidelines FMA legislation ICT customisation and bespoke development ICT procurement Intellectual property principles The Attorney-General’s Department has published a Statement of intellectual property principles for Australian Government agencies. when performing duties in relation to procurement.html.finance.html.au/financial-framework/fma-legislation/ index.nsf/Page/ Copyright_CommonwealthCopyrightAdministration_ StatementofIPPrinciplesforAustralianGovernmentAgencies A Guide to Open Source Software for Australian Government Agencies . http://www. process or service by trade name.gov.gov. Australian Government Architecture Description The Australian Government Architecture (AGA) aims to assist in the delivery of more consistent and cohesive service to citizens and support the more cost-effective delivery of ICT services by government.html The Commonwealth Procurement Guidelines establish the core procurement policy framework and articulate the Australian Government’s expectations of all departments and agencies subject to the FMA Act. recommendation or favouring by the Department of Finance and Deregulation.finance.gov. Source: http://www.html The ICT Customisation and Bespoke Development Policy is a whole-of-government policy.finance. Some Commonwealth Authorities and Companies Act 1997 (CAC Act) agencies are also subject to the guidelines. Details are available at http://www.html.gov.gov.gov. Source: http://www.
Source: http://www. Source: http://www.gov. licence and support of commercial-off-theshelf software. The SourceIT templates are designed to cater for simple procurement of hardware acquisition and support.gov.nsf/Page/Protective_ Security_Policy_Framework http://www. which outlines mandatory security requirements and links to protocols and guidelines.gov.finance. Source: http://www. Open Standards and Re-Use: Government Action Plan Description This document contains guidelines for the procuring of Open Source Software in the European Union and template texts for tenders.ag.gov. The Defence Signals Directorate has published many security resources.osor.au/procurement/ict-procurement/ contract-framework/sourceit-model-contracts/index.APPENDIX 2 Australian Government Description Security requirements The Attorney-General’s Department has published the Protective Security Policy Framework.uk/resource-library/opensource-open-standards-and-re-use-government-action-plan A Guide to Open Source Software for Australian Government Agencies 53 . Source: http://www.cabinetoffice.au/www/agd/agd. including the Evaluated Product List and the Information Security Manual.dsd.au/ The SourceIT contracting framework is a legal framework established by the Australian Government to provide standard terms and conditions for the purchase of ICT goods and services.html SourceIT Other Government EU: Guideline for Public administrations on Procurement and Open Source Software Open Source. licence of commercial-off-the-shelf software (without support) and ICT consultancy services.eu/studies/expert-guidance/guidelinefor-public-administrations-on-procurement-and-open-sourcesoftware-2010 This document contains the UK strategy for open source software.
Source: http://sourceforge. Source: http://drupal. Source: http://www.gnu. Debian. They are commonly used with a Linux kernel to give an open source Unix-like operating system.54 APPENDIX 2 Open source software products/ repositories Apache Description A not-for-profit corporation that manages a number of open source software development projects.org/ An open source content management system. applications and developer tools. Source: http://www.org/ A family of Unix-like operating systems. Examples include the Apache HTTP Server and Tomcat Java Servlet and JSP engine.opensourcewindows.org/ An open source content management system. Source: http://moodle.elgg.org/ http://www.org/ A large repository of open source software and development tools.org/ An open source social networking engine that allows organisations to create their own social networking sites. mostly distributed with open source licences. which provides the basis for interfaces.org/ An open source software office suite based upon OpenOffice.linux.openoffice.org/ A list of open source software that can be used with the Windows operating system.com An open source course management system that allows educators to create virtual learning environments.net/ Drupal ELGG Freshmeat GNU Joomla LibreOffice Linux Moodle OpenOffice Open Source Windows SourceForge A Guide to Open Source Software for Australian Government Agencies .apache. Source: http://www.joomla.libreoffice. libraries and utilities to build complete operating systems.org/ A catalogue of applications and other software. It includes a range of Unix and cross-platform applications.org/ An open source software office suite that is available in many languages and works on a range of operating systems. Source: http://freshmeat. Source: http://www. Distributions of Linux include Ubuntu.net/ A collection of open source libraries. Source: http://documentfoundation. Fedora and Kubuntu. Source: http://www. Source: http://www. Source: http://www.
net. It also provides licences for free software developers to share their code.opensource. It also provides licences for open source software. Source: http://www. including the GNU General Public Licence. Source: http://fsf.APPENDIX 2 Open source software groups Free Software Foundation Description Group that manages directories of information for the free software community.moodleusergroups. Source: http://www.org The Sydney Moodle User Group (SMUG) provides ongoing support to individuals and organisations using Moodle as an e-learning platform.org/ Open Source Industry Australia (OSIA) Open Source Initiative (OSI) Sydney Moodle User Group A Guide to Open Source Software for Australian Government Agencies 55 .osia. Source: http://www.org The national industry body for open source within Australia.au A not-for-profit corporation formed to educate about and advocate for the benefits of open source software and to build bridges among different constituencies in the open source community.
Appendix 3: Acronyms and definitions .
Appendix 3: Acronyms and definitions Definition Community source software Community source software is a subset of open source software. propagate and make available to the public. In this framework. Community source software is not made publicly available in the same way as open source software. The benefit of this approach is the re-use of a library’s functionality. condensation or any other form in which a work may be recast. Freeware is free to use and distribute. Derived work refers to a work including or based upon one or more pre-existing original works. adapted or extended version or a translation. It will only remain available to the specific community of developers who created the software. It usually involves an upfront free for use and may or may not include access to the source code. Proprietary software usually does not provide any right for the user to modify the software or redistribute it to any other party. Users may use the software. Open standards are a detailed. such as a modified. descriptive overview of a process. the word distribute is used to refer to the act of making relevant software available to anyone else in a manner that triggers an obligation to release the source code. modify and distribute. transformed or adapted. The library is not included within the program. but not necessarily free to modify. 58 APPENDIX 3 Derived work Distribute (or convey) Dynamic linking Freeware GPL ICT Licensing Risk Framework Open source software Open standards Proprietary software A Guide to Open Source Software for Australian Government Agencies . but may not access the source code to modify it or for any other reason. They must be openly published and there should also be no legal or intellectual property restrictions. Distribute refers to the act of making a copy of software licensed under the GPL available to a third party (or the public in general). Open standards are generally defined by focus groups within standards organisations. They are formulated through stakeholder consensus. Proprietary software is licensed for use under specific terms set by the copyright owner of the software. Open source software is subject to specific licensing conditions that may obligate organisations to openly distribute any modifications. Dynamic linking is a mechanism available to one or more software programs during the operation of a computer system that allows them to request the services of (invoke) a separate executable (a library) to undertake more specialised tasks on their behalf. protocol or format. Other terms for the same concept include convey. General Public Licence is a model licence for open source software Information and communications technology Open Source Software Licensing Risk Framework Open source software (OSS) is software that is freely available to use.
Generally. There is usually an option to use the software under a proprietary licence that removes the restrictions. Its use is generally restricted in some way: for example. Shareware software is free to distribute. having limited functionality. There are no restrictions on the use. Total cost of ownership TCO A Guide to Open Source Software for Australian Government Agencies 59 . working only for a limited time or including advertising in its interface. modification and distribution of public domain software.APPENDIX 3 Definition Public domain software Shareware Public domain software is not subject to copyright. the source code is not available.
Documents Similar To A Guide to Open Source Software
crazyman772