Open Source
Policy Builder
In This Guide:
• Key issues to consider when formulating an
open source policy
• Characteristics of best-in-class open
source policies
The following questions represent key characteristics of best-in-class components of a comprehensive open source policy. Each question has several policy choices listed below. Your organization can build its open source policy by answering the questions and formulating language expressing its choices in a policy statement.
1. Which open source software (OSS) licenses are approved for use in company products? • All open source licenses
• OSI-approved licenses only • All except reciprocal licenses • Company-specified list
2. External acquisition – where can a customer obtain source code for products purchased from the company? • From the company site – e.g., www.opensource<company>.com
• From the Internet, any source (e.g., SourceForge, FreshMeat, GitHub, Google, OSDir, other repositories) • From a third party supplier, i.e., Red Hat, IBM
3. Internal acquisition – who is authorized to bring in open source software that will be used in the company’s products? • Any employee
• Only authorized employee(s)
• Only Open Source Review Board (“OSRB”) • Other
4. Internal acquisition – how do company employees acquire open source software for use in company products? • From the internet regardless of repository
• From the public repository at OpenLogic Exchange (http://olex.openlogic.com) • Internal, centralized location governed by the OSRB
5. Partner software acquisition – how do partners acquire open source software for use in company products? • From the internet regardless of repository
• From the public repository at OpenLogic Exchange (http://olex.openlogic.com) • Internal, centralized location governed by the partner’s OSRB
6. Who in the organization is responsible for understanding and ensuring compliance with the terms and conditions of OSS licenses? • Legal
• Audit • Engineering
• Individual developers • IT management
• Open Source Review Board (OSRB) • Other
• All of the above
7. What level in the organization is responsible for understanding and ensuring compliance with the terms and conditions of OSS licenses? • Corporate officer
• Board of directors • Company counsel • Other
8. What business justification is required before approval is given for the use of open source software in company products? • None needed
• Must meet engineering requirements that specify the use of open source software
• Must demonstrate business value – TCO versus functionally-equivalent commercial software, ROI, etc.
Open Source Policy Builder
9. Who is the owner of open source software that is brought into the company for the express purpose of using in company products? Who is responsible for initial acquisition and lifecycle management of an OSS component?
• Individual developer
• Each OSS component has a ‘named’ owner • One person or central body/team, e.g. OSRB 10. How is the acquisition of open source software initiated?
• Acquisition is the responsibility of the individual developer
• Acquisition is the responsibility of procurement/supply chain management • Acquisition requests are directed to the OSRB
11. Security and Integrity: what kind of security/integrity review is required before open source software is procured? • None
• Download from OSRB-approved repository is sufficient • MD5 checksum or other prevailing security verification method • Virus scan with an up-to-date fingerprint library
• Complete source code scanning for security and integrity • Manual review
12. Security and integrity: what kind of security/integrity review is required before open source software is incorporated into a company product?
• None
• Verified download from OSRB-approved repository is sufficient
• Verified MD5 checksum (against OSRB-registered MD5) or other prevailing security verification method • Virus scan with an up-to-date fingerprint library
• Complete source code scanning for security and integrity • Manual review
13. Security and integrity: what kind of security/integrity review is required before a company product that includes open source soft-ware is shipped?
• None
• Company-conducted complete source code and binary code scanning for security and integrity
• Certified scan results provided by supply chain vendors that include open source software in the components they supply to the company
• Manual review • Other
14. Procurement: does the company distinguish between companies that supply open source software and companies that provide proprietary software?
• No • Yes
15. Warranty: what warranties must be obtained from vendors that supply software? (e.g., free replacement of IP infringing code) • None (no warranties)
• Bare bones – all software provided “as is”
• Vendor-supplied software includes/does not include open source software (simple yes/no) 16. Damages: what are the minimum damages required when dealing with a vendor that supplies software?
• None (no damages; sufficient to cure the breach in an agreed-to timeframe) • Partial (damages only in actual costs incurred by company to address the breach) • Full (damages cover the all costs including indirect costs – e.g., loss of reputation)
Open Source Policy Builder
17. Indemnification: what kind of indemnification must be provided by vendors who supply software to the company? • None – software is “as is”
• Minimal - terms of license is sufficient • Full indemnification
18. Policy scope: what is the scope of the company OSS policy? • Company-wide
• Divisional/line of business • Department
• Product • Other
19. What provisions (if any) are in place for dealing with software license conflicts? • None
• Light – we only are concerned with product-level licenses and potential conflicts
• Robust – we have the requisite tooling and procedures to identify all licensed software within the product • Other
20. What level of software categorization does the company have for software contained in distributed products? • None
• Light • Ideal • Other
21. Remediation: once this policy is established, what are the remediation requirements with respect to existing products that incorpo-rate open source software?
• None, grandfathered in
• Existing products with OSS must be inventoried (e.g., scanned, audited) within X days
22. OSS architecture: for open source software to be brought into the company for use in distributed products, is there a minimum technical standard that must be met?
• None – developers take all the responsibility, use at own risk
• Project must be considered stable in SourceForge/Freshmeat and/or community must be considered stable (subject to approval by OSRB)
• Must have significant widespread adoption as measured by downloads • Must have significant commercial base, i.e. MySQL dual-license • Other
23. Forking/community abandonment: How will the company deal with project forking or abandonment of open source software used in company products? Are there alternate vendors/suppliers available?
• Will deal with it when it happens
• Must have alternate vendor/suppliers listed or identified prior to committing to incorporate the software within company products
Open Source Policy Builder
24. Certification: do OSS components have to be certified before they can be implemented or deployed? If so, who must certify and what kinds of certification must be done? When can OSS be deployed to production?
• None, no certification needed
• Locally certified by ‘owner’ or end-user • Formal certification by central IT staff • External certification
• Commercial certification
25. Will OSS be distributed in company products? • No, all use is internal
• No, but will be used in customer-facing environments • Yes, will distribute unmodified OSS externally • Yes, will distribute modified OSS externally
• Yes, will integrate and distribute OSS with proprietary IP 26. Can OSS that is to be used in company products be modified?
• No, must be used in native form • Can be modified with approval • Can be modified in specified ways
• Can be modified in any way if not distributed • Can be modified without restriction
27. Who is responsible for maintaining inventory, usage and other metadata related to OSS component, including licenses? • Individual developer
• Company legal department
• Each OSS component has a ‘named’ owner (can be used in 20 divisions) • One central person or central body/team, e.g., Open Source Review Board
28. Security: who will be responsible for overseeing security of OSS components? Who will check if the code contains vulnerabilities? Who is responsible for applying security patches?
• Individual end-user
• One central person or central body/team, e.g. Open Source Review Board • Team to be named
• IT security staff
29. Are contributions to open source projects allowed? • No
• Yes, but only indirectly via use of a proxy (e.g., supplier)
• Yes, with valid business need and/or approval from management / Open Source Review Board • Yes, but only on employees’ own time
• Yes, but employees must use non-corporate email addresses for interacting with the community • Yes, totally unregulated
30. Under what circumstance can an employee make a contribution to an OSS project if it is not related to company business? • Under no circumstance – possible violation of employment contracts
• Yes, without attribution to company name and on employee’s personal time and no requirement to inform the company of such activity
Open Source Policy Builder
About OpenLogic
OpenLogic is a leading provider of enterprise open source solutions for the cloud and the data center. OpenLogic helps hundreds of leading enterprise across a wide range of industries to safely acquire, support, and control open source software. OpenLogic offers certification, commercial-grade technical support and indemnification for 600 open source packages backed by the OpenLogic Expert Community. OpenLogic also offers CloudSwing, a complete open PaaS solution for enterprises seeking to deploy applications and 31. Email communication: Under what circumstances can employees communicate with OSS communities (with company attribution)?
• Never
• When business need dictates but subject to approval/oversight of Open Source Review Board along with Company Com-munications Department
• Freely for any reason subject to employment guidelines
32. Are company employees allowed to speak publicly about the company’s use of open source software in products? • No
• Yes, with prior management approval • Yes, with specified approved topics • Yes, under any circumstance
33. Support: What level of technical support must be in place prior to implementing open source software in company products? • Individual developer responsibility
• Provided by formal internal team, development or central IT • Combination internal with external provider
• Must have SLA signed with business partner
34. Where should OSS used in distributed company products be housed? • Developer responsibility
• Centrally-managed repository
• Vendor-managed repository (e.g., OpenLogic)
35. Are source code and binary code scanning of all software in a distributed product required to avoid IP infringement? • No
• Yes, source code and binary code must be fingerprinted upon initial acquisition only • Yes, source code and binary code must be scanned periodically
• Yes, source code and binary code must be scanned prior to company’s product being commercially shipped • Other
36. Repository tracking: how are open source software components/projects tracked within the company? • No special project tracking of the repository
• Custom-built project tracking tool
• Yes, with vendor-provided tool (e.g., OpenLogic.)
37. What are the requirements for software delivered to the company from a supplier?
• None, responsibility of contractor to make sure they are adhering to any and all OSS or proprietary licenses
• Supplier must detail all software in their components, including the specific licenses under which the software is being made available
• Supplier must provide a contractual bill of lading that includes detailed list of software, license(s) along with test results from a code scan (e.g., OpenLogic)
