Towards Free/Libre Open Source Software (“FLOSS”) Governance in the Organisation
Richard Kempa
(a) Partner, Kemp Little LLP, London, http://www.kemplittle.com
Abstract
According to a Gartner survey, 85% of companies use FLOSS and the remaining 15% are expecting to use it in the next 12 months. However, there is still a disconnect between uptake and effective governance. This article articulates a practical approach towards implementing sensible, proportionate FLOSS governance focusing on the governance documentation concerned, and proposes a three level approach where the output of internal governance discussions are statements of Strategy, Policy and Process.
Keywords
Law; information technology; Free and Open Source Software; governance;
Info
This item is part of the Articles section of IFOSS L. Rev. For more information, please consult the relevant section policies statement. This article has been independently peer-reviewed.
1. Introduction
(a) Recent surveys
When IT consultancy Gartner released its survey in November 2008 of FLOSS use by 274 end user organisations around the world, it came up with two key findings. First, 85% of the companies surveyed then used FLOSS, with the remaining 15% then expecting to in the next 12 months – around the time of writing (November 2009). Secondly, 69% of the companies surveyed had no formal policy for evaluating or cataloguing FLOSS use in their organisation.
As in the aftermath of the dotcom bust, continuing tougher economic times are hastening the uptake of FLOSS in the organisation, which on Gartner’s figures, now approaches ubiquity. However, by all accounts there is still a disconnect between uptake and effective governance: on Gartner’s figures, FLOSS governance remains more widely honoured in the breach than the observance. In the press release that accompanied its November 2008 survey, Laurie Worster, Gartner’s research director said:
“Just because something is free doesn’t mean it has no cost. Companies must have a policy for procuring FLOSS, deciding which applications will be supported by FLOSS and identifying the intellectual property risk or supportability risk associated with using FLOSS. Once a policy is in place, then there must be a governance process to enforce it”1.
Gartner’s findings are corroborated by a survey in March 2009 by Black Duck Software2, which (although of a smaller survey sample) found that only 40% of larger companies (500 developers or more) had written governance policies and, of the sample as a whole, only one in five had written governance in place.
(b) Purpose
FLOSS governance is now, somewhat belatedly, rising up the corporate agenda3 and the purpose of this article is to articulate from a practical approach towards implementing sensible, proportionate FLOSS governance focusing on the governance documentation concerned4. This approach has as its start point that most organisations wish for reputational and competitive reasons to be seen in their use of FLOSS as in other matters to be good corporate citizens. It then proposes a three level approach where the output of internal governance discussions are statements of Strategy, Policy and Process that the relevant stakeholders buy into are then fully integrated around the organisation. There is no magic about such an approach, but it seeks to focus clearly on the high level issues, the policy that the organisation will define for its stakeholders and the day to day processes around implementation – the FLOSS governance toolkit.
(c) Scope
Organisations’ circumstances will differ widely so it is not practical to offer template ‘one size fits all’ documents. However this article offers in the tables below and the commentary pointers towards what stakeholders should consider in developing FLOSS governance for their organisation and the areas that strategy, policy and process statements should cover.
Although the purpose of effective FLOSS governance is to establish a practical, event-driven mechanism so as to enable an organisation to come to the right decisions on the range of particular questions that arise, this article does not itself address any of the granular technical FLOSS issues that continue to absorb significant amounts of management, technical and legal time. These issues include the multiplicity of FLOSS licenses; the ‘do’s and don’ts’ for licences and licence families themselves; and GPL-related issues as to what constitutes ‘distribution’ or the closeness of information communication triggering requirements on licensing of works of the organisation when combined with other works containing so called reciprocity or copyleft requirements.
2. Fundamentals of FLOSS Governance
(a) Objectives.
Embarking on the journey towards effective FLOSS governance can be a challenging process for any organisation. Starting out, it is critical to know the direction of travel: what are the organisation’s objectives for FLOSS and governance? As with other intellectual property based policies and governance, these can generally be succinctly stated around the high level aims of reducing/managing risk and maximising reward by:
- (i) avoiding disputes and managing regulatory risks;
- (ii) achieving good management/housekeeping for a financial event – for example, an investment round, IPO, trade sale, etc;
- (iii) customer satisfaction; and
- (iv) being a good FLOSS/corporate citizen.
(b) Key principles.
Supporting these objectives, the key principles of FLOSS governance may similarly be concisely articulated as:
- (i) source reliability: know where the FLOSS your organisation is using is coming from;
- (ii) acquisition: know what FLOSS your organisation is using;
- (iii) tracking: know what the FLOSS your organisation is using does and where it is being used and reused;
- (iv) roles and responsibilities: know who is responsible for what; and
- (v) licence compliance: know that your organisation is complying with its FLOSS licence obligations.
(c) FLOSS governance is particular to each organisation.
Whilst the basic key FLOSS governance objectives and principles may easily be stated, applying them to any organisation moves quickly from the general to the particular. Effective FLOSS governance does not exist in a vacuum and needs to be anchored in the high level and the day to day – the strategic and the tactical – of the organisation and its operations.
(d) The range of organisations for which FLOSS governance is relevant.
On the one hand, if your organisation is engaged for example in internal use only of FLOSS – i.e. no re-distribution outside the organisation – the issues and so governance will differ from an organisation using FLOSS in the products or services that it markets. Equally, in the ‘internal use only’ case, the position of a public sector organisation – say a Government Department or Local Authority - will be different from the private sector as public sector organisations, in their drive to use public money wisely, may be encouraged or mandated to use FLOSS over proprietary solutions and may have more formal, even statutorily prescribed, procurement procedures which FLOSS governance will need to be consistent with.
On the other hand, if your organisation develops software using FLOSS and then distributes software with FLOSS components (whether as a service or as a licence), different and likely more complex issues will arise compared to the ‘internal use only’ case. In this ‘distribution’ case, emphasis is also likely to differ as a practical matter between a business to consumer (‘B2C’) organisation supplying FLOSS components within the software it commercialises for use by the consumer end user and a business to business (‘B2B’) organisation supplying FLOSS components within the software it commercialises for use by other businesses (and not the consumer end user).
Other factors relevant to the emphasis that FLOSS governance will take in any particular case include the geographical spread of the business(es) – a company with a number of development centres around the world will look at things differently from a company with all its developers under one roof; and product spread – to take an example from the communications industry, a manufacturer of devices with embedded software applications like mobile phones will be in a different position from a fixed or mobile operator principally supplying telecoms services rather than products (even if, as in the case of BT, the service may be delivered using a router containing embedded FLOSS applications as part of the service).
3. Contexts of FLOSS Governance – Building Blocks, Threads and Integration
It is helpful to think of the components of successful FLOSS governance as building blocks, linked or threaded together by context. These threads include ‘achievements to date’ and acquired FLOSS experience when embarking on FLOSS governance implementation; the people context; the strategic context; the policy context; and the process context. Each of these threads, and the individual building blocks within them, need then to be integrated across the organisation to take account of the context as a whole.
(a) Thread 1: FLOSS achievements to date
Each organisation at the stage where it is considering formalising FLOSS governance will almost certainly have arrived at a start point which likely has some notable FLOSS achievements to date – it might have shaped the core FLOSS issues it faces in its business and may already have done ad hoc work identifying the top FLOSS licences it uses in its business.
(b) Thread 2: the People context
FLOSS use in the organisation on anything other than a purely ad hoc basis will involve a number of stakeholder groups inside and outside organisation and effective FLOSS governance will depend on integration and cooperation between them in a way that is supportive and positive. There may well be many interested stakeholders whose interests will need intermediation in order to arrive at an agreed approach to governance. Table 1 below illustrates potential stakeholders in an organisation and summarises for each possible objectives in relation to FLOSS and how they may be achieved.
|
TABLE 1 – STAKEHOLDERS, THEIR FLOSS OBJECTIVES AND HOW THEY ARE ACHIEVED |
|||
|
|
|
|
|
STAKEHOLDER/GROUP |
PRIME FLOSS OBJECTIVE |
HOW PRIME FLOSS OBJECTIVE IS ACHIEVED |
||
1 |
CEO/Leadership Team |
Managing and ensuring effective use of FLOSS aligned with corporate strategy |
Shaping and delivering best practice to achieve FLOSS governance |
|
2 |
CFO/Finance Team |
Organisation’s FLOSS benefits and risks identified, quantified and managed |
FLOSS components and licences and other commitments (like other software assets) identified and recorded |
|
3 |
CIO/Technical Team |
Delivery of FLOSS components/developments on time and on budget; technical management of FLOSS governance programme |
Implementing technical side of FLOSS governance (e.g. code indicator tool) |
|
4 |
Contractors |
See Customers, Developers Suppliers |
See Customers, Developers Suppliers |
|
5 |
Customers |
Business advantage through use of Organisation’s technology/services with FLOSS risk managed |
Performance of contractual commitments in Organisation/customer contracts |
|
6 |
Developers |
Knowledge that FLOSS use is encouraged & understand how he/she is able to use FLOSS in daily work |
Follow FLOSS governance & feed back on possibilities for improvement |
|
7 |
Directors/Supervisory Board |
Organisation adopts appropriate FLOSS governance aligned to organisation’s strategy |
Effective FLOSS governance properly implemented |
|
8 |
FLOSS Compliance Officer (‘FLOSSCO’) |
Developing, implementing and ensuring ongoing compliance with FLOSS governance |
FLOSS strategy, policy and process statements articulated, agreed and implemented |
|
9 |
FLOSS Working Party (‘FLOSSWP’) |
Focal point for interests of organisation’s stakeholders; crucible for FLOSS governance |
Manages FLOSSCO; communication back to other stakeholders |
|
10 |
HR Team |
To understand the HR and legal status to be given to FLOSS governance and Policy statements |
FLOSS Policy statement to form part of the organisation’s employee/contractor handbook |
|
11 |
Legal Team |
Minimising legal risks maximising benefits to Organisation in its contractual commitments and FLOSS governance |
Support other stakeholders in managing FLOSS governance, with particular emphasis on documents (statements, contracts, etc) |
|
12 |
Sales & Marketing Team |
Revenue generation/cost reduction, customer satisfaction |
Risk of unauthorised FLOSS use managed |
|
13 |
Shareholders |
Shareholder value |
Using FLOSS in an efficient, compliant way enables cost reduction, increase in profit, increased competitiveness, increased efficiencies and reduced IP leakage |
|
14 |
Suppliers |
Performance of contractual commitments in Organisation/supplier contracts |
Compliance with Organisation’s inbound transactions/procurement policies for FLOSS |
(c) Thread 3: the Strategy context
FLOSS governance does not live in a vacuum. At the highest level, it should align with other statements of organisational strategy – including corporate, risk management and IP strategy generally. The FLOSS Strategy statement is also the mechanism by which the internal consensus between the stakeholders is established and articulated. It is then a key point of reference for communication and education and for the development of the FLOSS Policy statement. The organisation’s leadership must be able to intermediate between the different groups and arrive at an agreed, short, clear, high level statement about where and why it will and will not use FLOSS. Table 2 illustrates pointers towards an organisational FLOSS Strategy.
TABLE 2 - Pointers towards a FLOSS Strategy statement for [Organisation]
within [Organisation]:
with [Organisation]’s partners:
|
(d) Thread 4: the Policy context.
The heart of FLOSS governance is the FLOSS Policy statement. A well crafted Policy should:
- be clear and brief, otherwise people will not read and understand it;
- be event driven, setting out roles and responsibilities as to who to go to and who does what in particular scenarios;
- set out criteria and decision points for FLOSS use: apply Occam’s razor – the simpler answer is usually right– and try to calibrate the Policy so it will settle 80% of decisions, while providing for effective exception management; and
- set out the information to be collected and tracked.
Table 3 below sets out pointers towards a FLOSS Policy around three main headings – scope and rationale; roles, responsibilities, training and awareness; and by transaction type - inbound, in house and outbound. Commentary on a number of the more difficult issues in practice is provided by way of footnote.
TABLE 3 - Pointers towards a FLOSS Policy statement for [Organisation] Scope and rationale
Roles, Responsibilities, Training and Awareness
FLOSS Policy in inbound transactions, in house development and outbound transactions11
by: |
(e) Thread 5: the Process context
The FLOSS processes should take the strain of FLOSS governance. The process context is where the interrelationships with and dependencies on policies outside the FLOSS area and other building blocks and threads within it need to integrate. These are illustrated at Part A of Table 4 below.
Pre-implementation (see Part B of Table 4), the project needs to be treated like any other development project in the organisation, with proper resource allocation, planning, mapping and timetabling. Consider using a pilot in one part of the business to gain experience that can than be rolled out across the organisation as a whole. Consider an amnesty to get the development community onside – this is the ‘hearts and minds’ time. As a practical matter, the importance of technology platforms to take out time and cost, add efficiency enhance collaboration, improve record keeping and ensure validation can scarcely be over emphasised.
Part C of Table 4 sets out consideration that the organisation will need to address on implementation. The FLOSS governance processes will need to be supple enough to cater for the range of activities post-implementation, and these are summarised at Part D of Table 4.
TABLE 4 - CHECKLIST FOR FLOSS PROCESS statement for [Organisation]
|
4. Conclusion
As FLOSS use in the organisation approaches ubiquity, FLOSS governance is rapidly becoming a ‘must have’ not just a ‘nice to have’ in order to manage risk and benefit effectively. Each organisation’s needs will be different, and senior management will need to consider all aspects of this complex question carefully before embarking on FLOSS governance implementation, as they would in any sophisticated software development project. At the end of the journey, management is looking to have in place integrated processes across all relevant business functions to manage effective use of FLOSS throughout the organisation. To get there, it should consider disassembling the various pieces into their building block components and threading them together by start point (achievements to date), people (stakeholders) and the strategic, policy and process aspects.
About the author
Richard Kemp is one of the UK's top technology and communications lawyers. He has a particular reputation for developing commercial and innovative legal solutions to the business challenges of technology development, application, implementation and regulation.
Richard is ranked in the global top 10 in both the IT and telecoms fields in the Expert Guide to the World's Leading Lawyers - Best of the Best 2008. He has been listed in the Best of the Best series since 2000 and in the top band of UK technology lawyers in the UK legal directories since setting up Kemp & Co in 1997. Richard has participated in teams that have won numerous legal industry awards and sits on the boards and editorial panels of a number of technology law specialist groups.
Richard qualified as a solicitor with Clifford-Turner in 1980 after graduating from Cambridge (1977) and from the ULB in Brussels (1979). He established Kemp & Co in 1997, which became Kemp Little LLP, the first UK law firm LLP, in 2001.
Licence and Attribution This paper was published in the International Free and Open Source Software Law Review, Volume 1, Issue 2 (December 2009). It originally appeared online at http://www.ifosslr.org. This article should be cited as follows: Kemp, Richard (2009) 'Towards Free/Libre Open Source Software Governance in the Organisation', IFOSS L. Rev., 1(2), pp 61 – 72 Copyright © 2009 Richard Kemp. This article is licensed under a Creative Commons UK (England and Wales) 2.0 licence, no derivative works, attribution, CC-BY-ND. As a special exception, the author expressly permits faithful translations of the entire document into any language, provided that the resulting translation (which may include an attribution to the translator) is shared alike. This paragraph is part of the paper, and must be included when copying or translating the paper.
|
1 Gartner press release of 17 November 2008: “Gartner Says as Number of Business Processes Using Open-Source Software Increases, Companies Must Adopt and Enforce an OSS Policy”. Available at: http://www.gartner.com/it/page.jsp?id=801412
2 Black Duck press release of 11 March 2009: “Black Duck Survey Reveals Open Source Development Trends”. Avalable at: http://www.blackducksoftware.com/news/releases/2009-03-11
3See for example the abstract from IT research company Forrester’s paper “Best Practices: Improve Development Effectiveness Through Strategic Adoption Of Open Source” of 2 February 2009: “[FLOSS] is getting renewed attention from application development professionals who are looking for cost-saving alternatives amid the economic recession. But many aren't asking the right question: Instead of "should we adopt [FLOSS]?" they should be asking, "how will we adopt [FLOSS]?" [FLOSS] is already seeping into development shops through a variety of channels, whether managers know it or not. Unchecked tactical adoption of [FLOSS] creates unmanaged risk and unrealized returns, and application development professionals should not tolerate it. Regardless of whether you view adoption of [FLOSS] as desirable or inevitable, the first step in moving from a tactical mess to a strategic plan is to specify the conditions under which [FLOSS] is permissible in your development shop. By creating a concise [FLOSS] policy, re-engineering the software acquisition process, and adding control points to [lifecycle management] processes and tools, application development professionals can shift from tactical responses to conscious integration based on realistic expectations and articulated economic benefits” , available at: http://www.forrester.com/Research/Document/Excerpt/0,7211,46361,00.html.
4With the historically low take up of more formal FLOSS governance there has until recently been relatively little publicly available online material about FLOSS governance. FLOSS software/support developers Black Duck, Palamida and HP’s FOSS Bazaar provide resources at:
http://www.blackducksoftware.com/resources/whitepapers#managingos (Black Duck);
http://www.palamida.com/themes/resources/Palamida_WhitePaper_PCIComplianceAtRisk.pdf (Palamida);
https://fossbazaar.org/openSourceGovernanceFundamentals (White paper on FOSS Governance Fundamentals) and
https://fossbazaar.org/content/best-practices-open-source-governance (Best Practices in Open Source Governance).
See also the OLEX (OpenLogic Exchange) Wazi at http://olex.openlogic.com/wazi/2009/create-open-source-policy/ (Best Practices for Creating an Open Source Policy) and http://olex.openlogic.com/wazi/2009/create-an-open-source-governance-process/ (From Policy to Process: Best Practices for Creating an Open Source Governance Process); and http://www.softwarefreedom.org/resources/2008/foss-primer.pdf (a Legal Issues Primer for Open Source and Free Software Projects). In the published books, see in particular Meeker, The Open Source Alternative, Wiley, 2008, Chapters 10 (Developing a Corporate Open Source Policy) and 10A (Open Source Corporate Policy) and Woods/Guliani, Open Source for the Enterprise, O’Reilly, 2005, Chapter 7 (Designing an Open Source Strategy).
5The HR aspects of the Policy are particularly important in considering how the organisation will ensure that FLOSS governance is effective. If it already has IT (email use for example) or intellectual property policies that are incorporated expressly or by reference into the HR handbook or even the contract of employment, it will be relatively straightforward to treat FLOSS governance similarly. If there is nothing comparable already in place, a number of questions need to be addressed, including particularly consequences of non-compliance where a developer uses FLOSS otherwise than in accordance with the FLOSS Policy or contributes to a FLOSS project otherwise than as permitted.
6HR difficulties can be compounded by the tension that generally arises between copyright law (where copyright in software developed by an employee in the course of his or her employment generally vests in the employer by operation of law) and code contributions to FLOSS projects (which generally provide that copyright in code contributed to the project is owned by the project). Again, corporate policy needs to be thought through and articulated in advance here. To complete the picture, it is worth remembering that under English law for example software developed by a contractor – whether an individual or a corporation – needs to be expressly assigned in order to belong to the organisation engaging the contractor. This requirement arises as a result of Section 11 of the UK Copyright Designs and Patents Act 1988, which provides that the individual who writes the software is the first copyright owner (S.11(1)) except where that individual is an employee writing software in the course of his or her employment, the employer is the first copyright owner in the absence of agreement to the contrary (S.11.(2)).
7The products of specialist FLOSS service providers like Black Duck, Palamida and Fossology and the code indicator tools and other technology platforms they supply can automate and take significant cost out of manual processes. See also Table 4, Part B below (Processes).
8 The FLOSSCO and the FLOSSWP are the lynchpins of the FLOSS governance process. The FLOSSCO is generally drawn from the development or technical rather than Legal team in practice, with Legal team representation on the working party.
9 See previous footnote.
10 An effective, continuing communication, training and awareness programme is of the essence of good FLOSS governance.
11The FLOSS policy should be event driven – i.e. it needs to think through and define in advance the sorts of issues that will arise. It should then aim to prescribe decision making which will deal with 80% of the issues that arise, with effective escalation to deal promptly with the other 20%. The events in this illustration are defined by reference to inbound, in-house and outbound transactions.
12 See footnote 8.