Open Source Policy Builder Effective and comprehensive open source policies are based on a thorough and unbiased organizational assessment. You can start building your organization s open source policy by answering these questions, taken from industry best practices, to develop guidelines, shared understanding, and policies. Embrace the power of open source confidently and consistently.
Table of Contents 1) Usage Policy and Governance of Open Source Software (OSS)...3 2) OSS License Compliance...5 3) Acquisition and Provisioning of OSS...6 4) OSS in the Supply Chain...7 5) OSS Tracking and Management...8 6) Security and Maintenance...8 7) OSS Community Interaction... 10 8) Training and Education... 11 2
1) Usage Policy and Governance of Open Source Software (OSS) This section answers the question, How will we apply our OSS policy? Will it be on a global or divisional basis; will it govern based on usage, product, or license; or will you require product reviews and business justification before using all important aspects to building your policy. 1. What is the scope of your company s OSS policy? m Company-wide m Divisional/line of business m Department m Product 2. Who owns the creation and maintenance of your OSS policy? m Shared across groups m A standards committee (e.g. Open Source Review Board (OSRB)) m Open Source compliance officer 3. Do OSS components have to be certified before they can be implemented or deployed? If so, who certifies and what kinds of certification must be done? m None, no certification needed m Locally certified by owner or end-user m Formal certification by central IT staff m External certification m Commercial certification 4. If OSS components have to be certified before they can be implemented or deployed, when can OSS be deployed to production? m Before certification is complete m During the certification process m After certification is complete and successful 5. Which open source software (OSS) licenses are approved for use in your company s products? m All open source licenses m OSI-approved licenses only m All except reciprocal licenses m Company-specified list 3
6. What business justification is required before approval is given for the use of OSS in your company s products? m None needed m Must meet engineering requirements that specify the use of OSS m Must demonstrate business value total cost of ownership versus functionally-equivalent commercial software, return on investment, etc. m Must demonstrate why OSS was chosen over a commercial solution 7. Once the open source policy is established, what are the remediation requirements for existing products that incorporate OSS? m None, grandfathered in m Existing products with OSS must be inventoried (e.g., scanned, audited) within X days 8. Will OSS be distributed in your company s products? m No, all use is internal m No, but will be used in customer-facing environments m Yes, will distribute unmodified OSS externally m Yes, will distribute modified OSS externally m Yes, will integrate and distribute OSS with proprietary IP 9. Can OSS distributed in your company s products be modified? m No, must be used in native form m Can be modified with approval m Can be modified in specified ways m Can be modified in any way if not distributed m Can be modified without restriction 10. Are source code and binary code scanning required of all software in a distributed product to avoid IP infringement? m No m Yes, source code and binary code must be fingerprinted upon initial acquisition only m Yes, source code and binary code must be scanned periodically m Yes, source code and binary code must be scanned prior to company s product being commercially shipped m Other : 4
2) OSS License Compliance Perhaps one of the biggest concerns in the use of OSS today is license compliance. This section helps you answer the question of how your organization will handle the Who, what, when, and how of OSS license compliance. 1. Who in your organization is responsible for understanding and ensuring compliance with the terms and conditions of OSS licenses? m Legal m Audit m Engineering m Individual developers m IT management m Open Source Review Board (OSRB) m All of the above 2. What level in your organization is responsible for understanding and ensuring compliance with the terms and conditions of OSS licenses? m Corporate officer m Board of directors m Company counsel 3. Where can your customers obtain source code for products purchased from your company for license compliance purposes? m From the company via physical media through a fulfillment process m From the company site e.g., www.opensource<company>.com m From the Internet, any source (e.g., SourceForge, GitHub, Google Code, CodeProject, or other repositories) m From a third party supplier, e.g., Red Hat, IBM 4. What provisions (if any) are in place for dealing with software license conflicts? m None m Light we are only concerned with product-level licenses and potential conflicts m Robust we have the requisite tooling and procedures to identify all licensed software within the product 5
3) Acquisition and Provisioning of OSS OSS rarely goes through the well-established software procurement processes created by your organization. In many cases this doesn t pose an issue but, if no process exists, problems can occur down the road that could significantly increase risks. This section answers the question of how you manage the procurement of OSS. 1. Who owns OSS that is brought into the company for the express purpose of using in company products? Who is responsible for the initial acquisition and lifecycle management of an OSS component? m Individual developer m Each OSS component has a named owner m One person or central body/team, e.g. OSRB 2. Who is authorized to bring in OSS that will be used in the company s products? m Any employee m Only authorized employee(s) m Only Open Source Review Board (OSRB) 3. How do company employees acquire OSS for use in company products? m From the internet regardless of repository m From the public repository at OpenLogic Exchange (http://olex.openlogic.com) m Internal, centralized location governed by the OSRB 4. Who is responsible for initiating OSS acquisition? m Individual developer m Procurement/supply chain management m Designated person or central body/team, e.g. OSRB m Requests are directed to the OSRB 6
4) OSS in the Supply Chain If you use and distribute OSS in your commercial products, you are ultimately responsible for license compliance even if that OSS was contained in a component obtained from a supplier. For an example of why this is important please see: http://opensource.com/law/13/7/fantec-german-foss-compliance. An often-overlooked component of OSS policies is how you will handle OSS that comes into your organization from the supply chain. This section helps you build that component of your policy. 1. What are the requirements for software delivered to your company from a supplier? m None, it s the responsibility of the supplier to make sure they are adhering to any and all OSS or proprietary licenses m The supplier must detail all software in their components, including the specific licenses under which the software is being made available m The supplier must provide a contractual bill of lading that includes a detailed list of software, license(s), and test results from a code scan (e.g., OpenLogic) 2. How do your partners acquire OSS for use in your company s products? m From the internet regardless of repository m From the public repository at OpenLogic Exchange (http://olex.openlogic.com) m An internal, centralized location governed by the partner s OSRB 3. What kind of indemnification must be provided by vendors who supply software to your company? m None software is provided as is m Minimal terms of license is sufficient m Full indemnification 4. What are the minimum damages required when dealing with a vendor that supplies software to your organization? m None (no damages; sufficient to cure the breach in an agreed-to timeframe) m Partial (damages only in actual costs incurred by company to address the breach) m Full (damages cover all costs including indirect costs e.g., loss of reputation) 5. What warranties must be obtained from vendors that supply software to your company? (e.g., free replacement of code that infringes on IP) m None (no warranties) m Bare bones all software provided as is m Vendor-supplied software includes/does not include OSS (simple yes/no) 6. Are vendors that supply software to your company required to run an OSS scan? m No m Only when vendors supply software that will be used in a product shipped to customers m Only when using outsourcers (commercial off the shelf (COTS) excluded) m Always 7
7. Does your company distinguish between companies that supply OSS and companies that provide proprietary software? m No m Yes 5) OSS Tracking and Management The heart of an OSS policy is how you plan to track the OSS used in your organization. This section helps you answer the question of how OSS is managed and tracked. 1. Who is responsible for maintaining inventory, usage, and other metadata related to OSS components, including licenses? m Individual developer m Company legal department m Each OSS component has a named owner m One central person or central body/team, e.g., Open Source Review Board (OSRB) 2. How are OSS components/projects tracked within your company? m No special project tracking of the repository m Custom-built project tracking tool m A vendor-provided tool (e.g., OpenLogic) 3. Where is OSS used in distributed company products housed? m Developer responsibility m Centrally-managed repository m Vendor-managed repository (e.g., OpenLogic) 6) Security and Maintenance Tracking is just part of the solution in terms of managing OSS. Maintaining your OSS and insuring you minimize associated security vulnerabilities and exposures is key to a successful OSS policy. This section answers the question of how you manage the security and maintenance of the OSS. 1. What level of technical support must be in place prior to implementing OSS in company products? m Individual developer responsibility m Provided by a formal internal team, development, or central IT m Combination of internal and external providers m Must have SLA signed with business partner 8
2. Who is responsible for overseeing the security of OSS components? Who will check if the code contains vulnerabilities? Who is responsible for applying security patches? m Individual end-user m One central person or central body/team, e.g. Open Source Review Board (OSRB) m Team to be named m IT security staff 3. What kind of security/integrity review is required before OSS is procured? m None m Download from an OSRB-approved repository is sufficient m MD5 checksum or other prevailing security verification method m Virus scan with an up-to-date fingerprint library m Complete source code scanning for security and integrity m Manual review 4. What kind of security/integrity review is required before OSS is incorporated into your company s products? m None m Verified download from an OSRB-approved repository is sufficient m Verified MD5 checksum (against OSRB-registered MD5) or other prevailing security verification method m Virus scan with an up-to-date fingerprint library m Complete source code scanning for security and integrity m Manual review 5. What kind of security/integrity review is required before shipping products that include OSS? m None m Company-conducted complete source code and binary code scanning for security and integrity m Certified scan results provided by supply chain vendors that include OSS in the components they supply to the company m Manual review 6. How will your company address project forking or abandonment of OSS used in company products? Are there alternate vendors/suppliers available? m Manage when it happens m Alternate vendor/suppliers are listed or identified prior to incorporating the software within company products m Active written response plan 7. Is there a minimum technical standard that must be met for OSS to be brought into the company for use in distributed products? m None developers take all the responsibility and use at their own risk m Project must be considered stable in SourceForge/Github and/or community must be considered stable (subject to approval by OSRB) m Must have significant widespread adoption as measured by downloads m Must have significant commercial base, i.e. MySQL dual-license 9
7) OSS Community Interaction Inevitably, as your developers use OSS, they will have interaction with OSS communities and groups. Whether it s to ask questions about packages they use or becoming committers and contributors on OSS projects, it s important that you have a policy in place to retain proprietary in using OSS and to protect the intellectual property created by your organization. This section answers the question of how to manage the interaction of your developers with the open source community. 1. Are contributions to open source projects allowed? m No m Yes, but only indirectly via use of a proxy (e.g., supplier) m Yes, with valid business need and/or approval from management/open Source Review Board (OSRB) m Yes, but only on employees own time m Yes, but employees must use non-corporate email addresses for interacting with the community m Yes, no restrictions 2. When can an employee make a contribution to an OSS project if it is not related to company business? m Never this is a possible violation of employment contracts m Always, without attribution to company name and on employee s personal time and no requirement to inform the company of such activity 3. When can employees communicate with OSS communities (with company attribution)? m Never m When business need dictates but subject to approval/oversight of OSRB along with company communications department m Freely for any reason subject to employment guidelines 4. Are employees allowed to speak publicly about your organization s use of OSS in products? m No m Yes, with prior management approval m Yes, with specified approved topics m Yes, under any circumstance 10
8) Training and Education OSS training is becoming more important as companies utilize more OSS. Not only do you need to communicate and train employees on your internal policies, it is a very good idea to educate your people on the risks associated with OSS. This section answers the question of how and what training is required around OSS. 1. What type of OSS training will you deploy in your organization? m None m Basic OSS 101 create general awareness and education of OSS issues and risks m OSS education and policies general awareness and education on internal polices for compliance purposes m Specialized by group Different training for different groups: developers, project managers, compliance managers, legal, partners, etc. 2. Who will be required to take OSS training? m No one m Only designated groups that use or interact with OSS m Partners m All employees 3. Who will develop the training? m In-house m Out source 11
Rogue Wave provides software development tools for mission-critical applications. Our trusted solutions address the growing complexity of building great software and accelerates the value gained from code across the enterprise. Rogue Wave s portfolio of complementary, cross-platform tools helps developers quickly build applications for strategic software initiatives. With Rogue Wave, customers improve software quality and ensure code integrity, while shortening development cycle times. Copyright 2014 Rogue Wave Software. All Rights Reserved