OSS Governance Policy

Open Source Software governance in the corporate context is the first step to both realizing the many benefits of OSS as well as mitigating any potential risks.  Any good governance process should begin with a corporate policy spelling out the parameters of its applicability and purpose.

• Policy Applicability:  The policy should explicitly indicate who is covered.  For OSS purposes, the most common actors are employees, vendors, outside agents or contractors who use open source software in the performance of their responsibilities on the company's behalf.

• Policy Statement:  The policy should include an affirmative statement of what is permitted subject to any review and approval processes.  At the policy level it is best to avoid laying out specific operational processes as these are often subject to change.  But it is helpful if the policy delineates the parameters and purpose of what expected governance processes will cover.  Examples might include:
• ensuring license compliance
• understanding provenance
• evaluation and mitigation of risk to company intellectual property
• indication of the various stakeholders to participate in review; legal, architecture, security, quality etc.
• establishing an executive owner and providing for waiver discretion

• Business Purpose: Since all corporate policies should exist for the purpose of achieving organizational goals, a good open source policy will describe the nature of the OSS ecosystem and why it is desirable to participate.  This background information will be useful as the policy is interpreted over time as necessary to evolve specific governance processes to meet new challenges and opportunities.

Finally, as a practical matter, I have found it better to address open source consumption policy separately from active participation and contribution to OSS community projects.  Many times an organization will find it beneficial to acclimate itself to the consumption side of the equation first while building confidence through experience.  Active community participation and contribution are a natural progression and often best served by separate policy considerations once the consumption processes are mature and functioning smoothly.

Next up, I will begin addressing ideas for specific OSS governance processes.

Open Source Contribution Policy Considerations

I have addressed Open Source Policy as a need for any organization which intends to consume from or contribute to the Open Source Community.  Such policies are critical to form the foundation upon which good governance processes can be constructed and put effectively into daily operation.

I thought it might be helpful to further discuss the policy needs as it relates specifically to the contribution side of the equation.

There are many reasons why an organization may consider becoming an active contributor to one or more open source projects:

1. Cost efficiencies - contributing simple bug fixes and feature enhancements needed by the organization back to the community edition can save enormous time and resources in the long run
2. Quality - a vibrant community supporting a project will most always result in a better project since every consumer is also a tester
3. Security - contributors have a vested interest in secure code.  They take great pains to ensure their contributions follow best practices and reduce attack surfaces and vulnerabilities wherever possible in order to keep a project viable and a good long term investment.
4. Reducing technical debt - every software platform or architecture decision comes with a certain level of commitment and open source is no different.  Active contributors ensure they have a voice in a project's direction and longevity ensuring the maximum return for their efforts.

This is by no means an exhaustive list but it is enough to justify the creation of a solid contribution policy for an organization to build upon in order to realize these and other benefits of open source.

So, here are my suggestions for how a good open source contribution policy should be crafted:

• State objectives explicitly in the policy.  This will help guide process development for policy implementation.  The four reasons listed above are a good starting point and there are always others which may be specific to your client.
• Don't lay out specific governance processes or procedures in the policy.  This will not allow for the normal evolution required in such a dynamic area.  Instead, list the subject matter which the policy expects to be covered by governance and implementation.  Here are few examples:
• Evaluation of OSS license compatibility to business goals
• Evaluation of patent/trademark questions
• Quality controls including security issues
• Criteria for evaluating a community compatible with business goals and culture
• Clearly articulate who or what team is accountable to implement the policy, make final decisions on governance, and grant exceptions when necessary.
• Set up clear expectations for artifact record keeping, including where process definitions, instructions and training materials will reside.
• Include a definitive statement for policy applicability.  For example, does it apply to contractors as well as employees?
• Indicate a time schedule for policy review to ensure updates are considered as needed.

Policy drafting is often viewed as less than useful, but if done with thoughtful input from those impacted it can enable clients to reach their open source goals.

Open Source Provenance

It seems like common sense.  In order to analyze potential risks for consuming a particular open source component or application, it is necessary to understand who owns the copyright and under what terms the owner has licensed it to the community.

However, as anyone who has delved into the OSS world knows these questions more often result in muddled answers than crystal clear ones.  Several reasons for the confusion become obvious once you step back and understand the nature of open source software:

• OSS often begins with an individual who was simply trying to solve a particular problem or need and thought others might like to try their solution and perhaps improve upon it.  Such informal circumstances mean not much attention is paid to the OSS license chosen, and of course as is a copyright holder's prerogative, subsequent iterations of the same component are often released under different licenses over time.
• OSS components are often bundled together into derivative works which taken as a whole address some larger problem, business or academic need.  These derivative works are sometimes assigned licenses without regard for terms applicable to the base components or downstream compatibility.
• Communities which manage an OSS project will often have contributors acknowledge a contribution agreement before submitting a new feature or bug fix.  Most agreements I have reviewed contain all the basics one would expect but does the community carefully research the provenance of all the code submitted to ensure license compatibility?
• Automated tools which scan code for license hints or even snippets of previously licensed code through sophisticated text comparison algorithms can often reveal a plethora of resulting "hits" and false positives to weed through.
• It is becoming a common business model for companies to purchase the underlying copyrights for a popular open source project.  This often results in a roadmap where certain versions or features are retained in an open source community edition while the newest capabilities are only provided via traditional proprietary licensing.  And the line between the two is often shifting by design to maximize adoption and exploitation of the intellectual property.

Given all these potential concerns, how best to advise our clients?

How does your organization address such issues?

My approach is outlined next time.

 

Licensing Obligations - Copyleft or Viral Requirements

Copyleft or Viral Requirements:  These requirements are either some of the most onerous in the open source world, or they are the reason open source has flourished.  It is really just a matter of perspective.

At its most basic, copyleft (a play on the word copyright) terms require that a consumer who uses an OSS component to create any manner of derivative work, or perhaps causes such a component to be redistributed to others, or both, to license the entire resulting work product under the terms of the copyleft license at issue.  This attachment of terms and conditions is sometimes why these licenses are referred to as viral in nature.

There are many nuances to these licenses depending on specific use cases and one's interpretation of their obligations.  However, there is agreement among professionals attempting to navigate these waters that it can be tricky at times.

Examples include:

1. GNU GPL - version three found here
2. GNU LGPL - version three found here
3. GNU Affero GPL - version three found here
4. OSL - version three found here

Corporate OSS consumers tend to be wary of these licenses with reciprocal terms because they limit an entity's ability to exploit the code for commercial purposes.  Conversely, those who choose these licenses to protect their intellectual property tend to do so exactly for the same reason, so that the code remains freely available for anyone to use, consistently available under the same licensing scheme without fear that later iterations will be walled off into some unacceptable proprietary licensing framework.

I am firmly convinced these  licenses have their place within the OSS ecosystem.  However, it is imperative that individuals or organizations which contemplate using code subject to their terms fully understand both the freedom of use and reciprocal obligations which accompany the intellectual property in question.


 

Licensing Obligations - Source Code Availability Requirements

Source Code Availability Requirements:  It is not unusual for an open source license to require downstream consumers make the component source code easily available as a condition of use.  This requirement nurtures the open source culture by ensuring any end user can have access to review and obtain copies of open source licensed code from applications in which they have an interest.

A few examples of common open source licenses where this requirement is expressed to one degree or another include:

• Apache License 2.0
• Mozilla Public License 2.0
• Common Development and Distribution License 1.0
• GNU GPL 2.0

Depending on the specific license involved, the source code requirement may be triggered by distribution or the creation of a derivative work or both.
 

In order to consistently comply with the spirit of these requirements across multiple licenses in a given organization, I have found an obligation statement similar to the following satisfies or exceeds the majority of license terms in this category and is easily understood by business and technology resources:
 

"Component source code and supporting files must be made available in a timely manner to any end user through a reasonable request process."

 

Such an approach allows software architects to plan on common compliance schemes such as providing web links to a publically available library of open source code or a soft transfer to an online knowledgebase or helpdesk request process.

 

Next up, Copyleft or Viral requirements.