Towards Free/Libre Open Source Software (“FLOSS”) Governance in the Organisation
| Author | Richard Kemp |
| Position | Partner, Kemp Little LLP, London |
| Pages | 62-72 |
Page 62
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.
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 reputationalPage 63and 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.
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.
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.
Page 64
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 re-used;
(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.
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.
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).
Page 65
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.
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.
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.
Page 66
[SEE CHART IN ATTACHED PDF]
Page 67
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]
-
[Organisation]’s FLOSS objectives. [Organisation] will continue to use FLOSS in order to increase [Organisation]’s:
• ability to attract the best talent by building a development community at the forefront of FLOSS skills;
• competitiveness by increasing development and operational efficiency and effectiveness, enabling faster time to market and reducing costs; and
• value to stakeholders.
-
FLOSS compliance. [Organisation] fully recognises and respects the rights of, and its agreements with, others just as it expects others to respect [Organisation]’s rights and perform their agreements with us. Accordingly, [Organisation] respects the need to ensure compliance with the terms of its legal obligations in licence agreements for FLOSS that it uses.
-
FLOSS governance within [Organisation]: achieving the right balance. [Organisation] is committed to implementing best practice FLOSS governance. The purpose of [Organisation]’s best practice FLOSS governance is effectively, appropriately, proportionately and transparently to balance the objectives set out at paragraph 1 and the compliance expectation set out paragraph 2. This balance will be achieved:
within [Organisation]:
• by supporting [Organisation]’s development community in their work - as governance for developers by developers;
• by effective communication, including educating, training and raising/maintaining awareness of FLOSS issues among all stakeholders;
• by taking into account the interests of all stakeholders; and
• through the active and timely support of all stakeholders;
• with [Organisation]’s partners:
• by ensuring that [Organisation]’s supplier and customer partners are aware of and comply with their FLOSS obligations, through [Organisation]’s contracts and appropriate relationship management.
-
The mixed software environment. [Organisation]’s use of FLOSS will continue to be in a ‘mixed’ software environment:
• using FLOSS and proprietary [Organisation]- and third party- owned software;
• constantly evaluating where FLOSS is best used within [Organisation]; and
• through re-use of FLOSS components where appropriate thereby leveraging [Organisation]’s knowledge and technical resources.
-
Further details, etc. This Strategy statement forms part of [Organisation]’s FLOSS governance along with our Policy statement and Process statement. It is subject to review and change. For further details please contact [Organisation]’s FLOSS Compliance Officer at [email] and our FLOSS online resource kit at [intranet URL].
The heart of FLOSS governance is the FLOSS Policy statement. A well crafted Policy should:
(i) be clear and brief, otherwise people will not read and understand it;
(ii) be event driven, setting out roles and responsibilities as to who to go to and who does what in particular scenarios;
(iii) 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
(iv) set out the information to be collected and tracked.
Page 68
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
-
Scope
• Purpose: This Policy statement is designed to supplement our existing policy and processes relating to [Organisation]’s products and services. It deals specifically with development and licensing considerations that must be fully understood and complied with when using and otherwise dealing with FLOSS within products and services that [Organisation] [markets][uses];
• Who does this Policy statement apply to?5 This Policy statement is mandatory and applies to everybody in [Organisation] who is responsible for [product design, launch and support across all [Organisation]’s solutions, whether as an employee or contractor. The intention is to ensure that [Organisation] understands, complies with, and is seen to understand and comply fully with the obligations and duties as contained in the relevant FLOSS licence terms;
• What is the legal status of this Policy statement?6 This Policy statement [forms part of [Organisation]’s HR handbook (for employees) and part of the Contractor handbook (for corporate and individual contractors)] [has the same legal status as equivalent policy statements];
• Design process: All products and services that [Organisation] markets and that contain FLOSS must be [design approved by the [Organisation] review body] [(or other authorised body or process)], taking into account architectural, security, legal, commercial and all other relevant considerations. In particular, as part of that design approval FLOSS licence terms must be understood and processes put in place to ensure [Organisation] compliance once the product/service is launched;
• Code indicator tool7: All source code in products and services that [Organisation] markets are to be scanned before launch using a FLOSS indicator tool. This will enable FLOSS code to be identified and all associated FLOSS licences to be checked for compliance with the relevant licence’s terms. Information from the scan must be acted upon so as to ensure [Organisation]’s compliance with the obligations in the relevant FLOSS licences;
• Further details, etc: This Policy statement forms part of [Organisation]’s FLOSS governance along with our strategy statement and Process statement. It is subject to review and change. For further details please contact [Organisation]’s FLOSS Compliance Officer at [email] and our FLOSS online resource kit at [intranet URL].
-
Rationale
• The rationale behind this part of the Policy statement is to provide an introduction to FLOSS models and ensure FLOSS licences are given the attention and respect they require as a legal document;
• The licensing of FLOSS code follows a different style of business model to the type [Organisation] has historically been used to. Most proprietary software is licensed under what can be called a Proprietary Model, where the copyright owner reserves all the rights the law grants, except for certain specific rightsPage 69which are granted for a licence fee (e.g. for £ I license you (i.e. grant you permission) to use, but not to copy, modify or publish etc the software);
• FLOSS code on the other hand is in the main licensed either under: ◦ an Academic Model - such as the BSD, MIT, AFL, Apache licenses. Academic FLOSS Licences are typically light-touch agreements that basically seek “Freedom” for the software code. The main positive obligation on the Licensee is the duty to identify the origins of the FLOSS code – “attribution” ; or
◦ a Reciprocal Model - such as the GPL, MPL, CPL and EPL. Reciprocal FLOSS Licences are generally more assertive in putting positive obligations on the Licensee with the objective of ensuring that all the copyright owner’s rights (use, copy, modify, publish etc) are passed down to other users;
• [Organisation] will continue to operate in a ‘mixed’ software environment, using proprietary software under the Proprietary Model and (for FLOSS) the Academic Model and the Reciprocal Model;
• Regardless of the underlying model, every software licence that attaches to software code (whether proprietary or FLOSS) constitutes a legal agreement between the licensor and the licensee. [Organisation] will comply fully with its legal obligations as set out in any licence agreement attaching to software code that is used within [Organisation], including used within [Organisation] products or services.
Roles, Responsibilities, Training and Awareness
-
Roles and responsibilities
• FLOSS Compliance Officer8: In order to help [Organisation] achieve its FLOSS objectives, [Organisation] has created the position of FLOSS Compliance Officer (‘FLOSSCO’). FLOSSCO will be the first line of support for the development community within [Organisation] on questions you may have around FLOSS;
• FLOSS Working Party:9 FLOSSCO will report to the FLOSS Working Party (‘FLOSSWP’). The FLOSSWP has members drawn from [Organisation]’s stakeholders. The role of the FLOSSWP is to give guidance to the FLOSSCO and, reporting to [], to ensure that [Organisation]’s use of FLOSS is aligned to [Organisation]’s strategy and the FLOSS Strategy Statement.
-
Training and awareness10. FLOSSCO and the FLOSSWP will organise and carry out regular and frequent FLOSS training and awareness to ensure that the principles of [Organisation]’s FLOSS strategy and policy are understood and met throughout [Organisation].
FLOSS Policy in inbound transactions, in house development and outbound transactions11
-
FLOSS Policy on inbound transactions
• FLOSS in [Organisation]’s procurement policies
• Pre-contractual documents (RFIs, RFPs, etc) and contracts are to provide that software deliverables to [Organisation] are not to contain FLOSS unless FLOSS components individually identified before contract signature and expressly agreed by [Organisation];
• [Organisation]’s procurement contracts to reserve the right for [Organisation] to apply code indicator tool to carry out assessment in any case;
• [Organisation]’s procurement contracts to include warranty/indemnity protection for nonidentified/agreed FLOSS and (in addition to normal remedies) to provide for rewriting as remediation on case by case basis;
• FLOSS in inbound development agreements: as per procurement policies outlined above;
• FLOSS in M&A:
• Technical and legal due diligence to be configured to enable all FLOSS in target company’s code base to be identified early on;
• Consider using code indicator tool provider on escrow basis to carry out independent assessment;
• Allow sufficient time for remediation by rewriting between signature of contracts and closing/completion;
• FLOSSCO and [legal representative of [Organisation]] will be available to discuss particular issues arising on inbound transactions.
Page 70
-
FLOSS Policy on in house development
• outline of authorisation mechanism:
• FLOSS governance will operate across the organisation on the basis of pre-approved FLOSS components/software and the FLOSS licences that attach to them;
• Assessments through indicator tool: [Organisation] will:
• assess what FLOSS it [and its contractors] [is/are] using in [its/their] operations; and
• associate the relevant FLOSS licences with the FLOSS so assessed to be used;
• assessing ‘incoming’ code using the code indicator tool;
• pre-launch/release code assessments; and
• carrying out periodical assessments of internally developed code to verify that the FLOSS being used within [Organisation] is what is expected to be used;
• Remediation where necessary: [Organisation] will develop a process to review, assess and remediate instances of non-compliance with [Organisation]’s Policy statement or otherwise in relation to a particular FLOSS licence;
• FLOSS licence approval:
• approval will be on the basis of the FLOSS licences determined to be most commonly used within [Organisation];
• Approval ‘do’s and don’ts’: approval will be to enable use of the software concerned on the basis of clear, short, simple ‘do’s and don’ts’ addressing the needs of [Organisation] developers;
• Scope of approval: Unapproved open source software, software licensed on an unapproved licence, or use outside the ‘do’s and don’ts’ will be prohibited;
• Post-implementation approval: The post-implementation approval process will involve the FLOSSCO and will be designed to support the development community in giving timely positive assistance whilst respecting open source licence obligations.
-
[Organisation]’s Policy on contributions to FLOSS projects. [set out here whether and if so to what FLOSS projects and on what terms [Organisation] developers may contribute code and other work]12.
-
FLOSS Policy on outbound transactions
- [Organisation]’s template [licence/services agreements] set out [Organisation]’s approach to FLOSS in its customer contracts;
- FLOSSCO and [legal representative] of [Organisation] will be available to discuss particular issues arising on outbound transactions.
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]
-
Dependencies
-
Dependencies on/links with:
Page 71
• FLOSS governance Strategy and Policy statements;
• [Organisation] patents and other IPR policies;
• Relevant stakeholder groups – e.g. architecture group, etc;
• Source code management (CVS, subversion, etc);
• HR policies;
• Inbound/outbound contract groups;
• Exit strategy (if applicable).
-
-
Pre-Implementation
-
Project planning, road mapping, timetabling. Treat implementation of FLOSS governance at the process level like any other development project – with sufficient/appropriate resources, and detailed project planning, road mapping, dependency management and timetabling.
-
Indicator tool implementation. Consider procurement of and budget implications for indicator tool well in advance of FLOSS governance implementation.
-
Initial assessment. Consider initial code assessment (NB: make sure you can continue to use the assessment results even after the contract with the indicator tool provider has terminated).
-
Consider amnesty for developers pre-implementation to encourage/bolster need for compliance use post- implementation. For example, where a developer had perhaps mistakenly used FLOSS otherwise than in strict compliance with the relevant licence terms but, on realising the mistake, had not informed the his or her manager, the ‘amnesty’ would seek to encourage full reporting of the mistake within the Organisation before a certain date without fear of adverse consequences – on a sort of ‘confess and be forgiven’ basis. This would enable the Organisation to have a full picture and a firm foundation from which to assess and if necessary remediate.
-
Consider pilot project implementation of the processes initially before roll out across [Organisation] in order to gain experience about what works best.
-
-
Implementation
-
Approval for FLOSS licences most commonly used. o Identify [Organisation]’s ‘top [X]’ FLOSS licences most commonly used within [Organisation], e.g.: [list]; o Refer [intranet hyperlink] for methodology of how these FLOSS licences have been identified and analysis;
-
Approval ‘do’s and don’ts’ o Consider approval on the basis of short form, easily accessible/readable ‘Do’s and Don’ts’; o Consider maintaining intranet URL to show FLOSS [components] whose licences have been approved; o Consider maintaining separate intranet URL to show FLOSS licences that are approved for use;
o Consider maintaining separate intranet URL of FLOSS components/licences (if any) whose use always requires prior specific approval from FOSSCO/legal;
-
Pre-launch/release compliance check using code indicator tool or otherwise.
-
Set out service levels for FOSSCO/FOSSWG responses to individual questions outside scope of policy/process guidance.
-
-
Post Implementation
-
Arrangements for code and other information repository.
-
Periodical code assessment.
-
Remediation where necessary.
-
Training and awareness.
-
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.
Page 72
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.
---------------------
[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
[3] See 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.
[4] With 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_P CIComplianceAtRisk.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-governanceprocess/ (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).
[5] The 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.
[6] HR 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)).
[7] The 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.
[11] The 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.
