Open Source Policy Builder

Effective and comprehensive open source policies are based on a

thorough and unbiased organizational assessment. You can start
building your organizations 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

www.openlogic.com

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 companys OSS policy?
m Company-wide
m Divisional/line of business
m Department
m Product
m Other: ______________________________
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
m Other: ______________________________
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 companys products?
m All open source licenses
m OSI-approved licenses only
m All except reciprocal licenses
m Company-specified list

www.openlogic.com

6. What business justification is required before approval is given for the use of OSS in your companys 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 companys 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 companys 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 companys product being commercially shipped
m Other : ______________________________

www.openlogic.com

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
m Other: ______________________________
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
m Other: ______________________________
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
m Other: ______________________________

www.openlogic.com

3) Acquisition and Provisioning of OSS

OSS rarely goes through the well-established software procurement processes created by your organization. In many
cases this doesnt 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 companys products?
m Any employee
m Only authorized employee(s)
m Only Open Source Review Board (OSRB)
m Other: ______________________________
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

www.openlogic.com

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, its 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 companys 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 partners 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

www.openlogic.com

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

www.openlogic.com

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 companys 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
m Other: ______________________________
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
m Other: ______________________________

www.openlogic.com

7) OSS Community Interaction

Inevitably, as your developers use OSS, they will have interaction with OSS communities and groups. Whether its to
ask questions about packages they use or becoming committers and contributors on OSS projects, its 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 employees 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 organizations use of OSS in products?
m No
m Yes, with prior management approval
m Yes, with specified approved topics
m Yes, under any circumstance

www.openlogic.com

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

www.openlogic.com

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 Waves 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