When and Why Do I Update Open Source Policy Rules?

  

 Email Article  

Tweet  

  

In today’s article I will discuss some internal and external events that may cause you to update your open source policy rules.  For this discussion it is important to differentiate between the open source software (OSS) policy and the rules that flow from the policy.

The OSS policy is an extensive document or framework that covers such topics as: free and open source software product and license definitions, company terminology, usage models, support strategy, information security risk thresholds, contribution guidelines, best practices, and so forth.  The OSS policy rules are the day-to-day guidance established by your open source review board (OSRB) for the entire company.  Policy rules generally trigger by license type, OSS package, or how the software is being used.  Even considering these categories, it's nearly impossible to write rules that are going to take into account every scenario you will come across.  A flexible and actionable open source management process will allow your OSRB to update and add rules as new scenarios arise or business needs require.  There are a variety of internal and external events that may require such updates.  Lets start with some internal events.

Internal events that may require OSS policy rule update:

• A developer, architect, or system admin wants to use a new OSS package that has not previously been requested of the OSRB.  Depending on the OSS package, its licensing, and other information, a new rule may need to be created.   The new rule could allow use of the OSS under any circumstance, deny use of the product, or conditionally approve use one time, but require review for future use.

• An OSS inventory scan or scan for policy and license compliance has been completed and OSS was found that was not previously approved.  Such a scenario indicates a hole in either the existing rules or the tracking progress.  Increased communication and education about the importance of the policy rules and perhaps a new policy rule will need to be implemented.

• A new internally developed project that runs on open source is going through QA and is nearing a production environment implementation.  Has technical support been obtained, if not via internal expertise, then by a third-party provider?  Using open source in a mission critical production environment without technical support is a ticking time bomb and policy rules should address this issue.

• Business units intend to share technology resources that are known to include OSS.  The usage model of one division may not align with other divisions of the same company requiring different rules for different business units.

An actionable open source policy that allows the creation of new policy rules to align with these internal events is completely within your control; your OSRB should be meeting at regular intervals to discuss and consider these examples.  Now lets consider some external events. 

External events that may require OSS policy rule updates:

• An open source community develops new versions of software and assigns a new license style or moves to a dual licensing scenario.   If a policy rule is triggered by a particular OSS package and the license model changes from this may impact the type of review the OSS packages needs before being used.

• Your company is entering a new market or selling to a new customer that has clear guidelines as to what open source can and cannot be used.  Can your company afford to not enter new markets or gain new customers that have this requirement?  You might not think of an actionable OSS policy as a sales tool, but your ability to easily adapt and respond to your customer's requirements in this regard is just as important as in any other way.

• The copyright holder of an OSS project contact’s your company with a notice of non-compliance and a request for remediation actions to achieve compliance.  After responding to notice, you will want to launch an immediate investigation into where the gap was in your license compliance rules.  Does something need to be updated or have your rules not been enforced effectively?   Fixing this gap will need to be part of your remediation.

• A breach of corporate information security controls occurs due to an outdated OSS environment or outdated OSS policy rules.  New versions of open source include increased functionality and critical patches to security vulnerabilities; part of your policy should require open source environments to be updated regularly.

The future software is being built today with open source.  Updating the policy document itself might only be a once a year project, but OSS moves in and out of organizations far to quickly to not allow the flexibility to update policy rules as needed.  Don't wait for external events to initiate revising the policy rules!  Review your rules more often than your policy.

View Jesse Hood's profile