Most companies using open source software know they need an open source policy. However, when it comes to creating a policy companies often don't know where to start and spend months debating policy details and researching options. This guide is intended to help you write an open source software policy. But perhaps more important, it will also help you figure out who to include in the policy creation process so that your company is likely to agree upon and use the open source software policy once it's been written.
At first many companies question the need for an open source software policy—primarily because they think it will be too difficult to create. Policy creation does require a lot of work and cooperation, but by following this guide you should be able to create and roll out an open source software policy in less than a month.
Some of the main benefits to having an open source software policy include:
The key to writing an open source software policy is just to get started! Companies typically either write, approve, and adopt an open source software policy within a month, or else they spend months working on a policy and yet fail to gain company-wide approval on the finished product. By following these steps you can ensure your company has an approved and adopted policy within a few weeks:
Your first step—the one important to making sure that your policy is adopted—is to identify the stakeholders in your policy. There are several types, ranging from those who care desperately because you might change their ability to do their job (like developers) to those who care desperately because they think a bad policy might get them fired (like CIOs and those who report to them.) Be sure to include people who you think will disagree with your policy—better to address their disagreements upfront than to have them fight the policy because they don't like one part of it.
While you'll have to use whatever strategies work best in your organization, getting all of the stakeholders involved as soon as possible will help your policy get widely adopted more quickly. The more your stakeholders feel like it's their policy, the better. The best case scenario is if they can say they reviewed it and feel comfortable with you (or whoever is writing the policy) taking care of the details.As you put together your list of stakeholders you should consider:
You'll probably have two groups of stakeholders: the key stakeholders who will need to approve the policy, and the people who will be affected by the policy.
An open source software policy is meant to help your company's strategy—both its general strategy and its open source strategy.
For example, you might see open source software as a way to reduce your IT costs. In this case your strategy should not be to "use as much open source software as possible," but rather to "reduce IT costs by using open source software." This will enable all of your employees to make the right decision when it comes to choosing between open source and proprietary solutions. The policy will then help your company reduce IT costs—not just by encouraging the use of open source software that has no licensing fees associated with it, but by also leveraging the preexisting open source knowledge of your IT staff.On the other hand, you might want to build an online community around your company's product. In this case your strategy might be to use open source software in order to encourage outside developers to help build out features that enable your community to grow. Your interest is in the community, not in making money through software sales, so you might even want to open source your own software and grow a community around it.Identifying your open source strategy upfront will not only help you figure out your policy, but it will also help you explain to others why it's the right policy for your company.Here's an example of what an open source strategy statement might look like:
Many open source software policies start by talking about the problem they're trying to solve. Whether or not you need this section probably depends on your company. You may need this section if:
If you decide you need a background statement, make it brief. Some key things to include in the background statement (if you know them) are:
A background statement in an open source policy might look like this:
Your company may have many policies, and it may be obvious who they cover. However, with open source software policies it is often necessary to define not only who is covered but what is covered.
Most companies with an open source software policy adopt the policy company-wide. However, for many organizations it makes more sense to have a very brief company policy that simply states the strategy and provides some general guidelines for how to use open source software. Then, each division is allowed to elaborate and expand on the policy to meet its needs. In other cases, a particular division creates a policy and later tries to get the company as a whole to adopt it.
Don't forget to specify subsidiaries and agents in this definition. You might want to consult with an attorney about whether giving open source software to the company's agents or subsidiaries is considered distribution, as distribution triggers clauses in some open source software licenses.Also, you might want to specify whether or not the open source software policy applies to everyone or just to employees in certain jobs or roles. For example, you may not care how your IT staff uses open source software in the internal IT environment, but you want to ensure that all software developers working on applications that are distributed to others are aware of the open source software policy.Whatever you decide, make sure it's clearly stated and that you have the right people review and approve the policy. The example below illustrates one approach to defining who's covered by a policy:
There's a lot of misunderstanding and disagreement about what exactly qualifies as "open source software." One common misconception is that freeware, free to use, and free for personal use only licenses are open source software licenses.
Companies typically decide that any software released under a license approved by the Open Source Initiative (OSI) is considered open source software.You need to define what is covered and what is not covered by your company's open source software policy. Many companies have different standards for open source software used in IT, development, and production environments.You'll also need to think about what qualifies as open source software and what usage cases need to be covered.
An open source policy might address the issue of what qualifies as open source with language like this:
Your open source software policy will be a living document. As business conditions change, your company becomes more comfortable using open source software, and new open source software packages and licenses become available, you'll want to adapt the policy to the new situations. In addition, an individual or team needs to be available to answer questions, provide training, and approve any exceptions.
Although an individual usually writes the open source software policy, a committee or open source review board should own the policy. A review board is most effective when it represents the main divisions in the company. If every group feels like they're adequately represented, you'll get better buy-in and compliance later on.
Only a couple of people should be allowed to make exceptions to the open source software policy: the owners of the policy, and the business group or manager who's allowed to decide that the business benefit outweighs the risk of breaking from the policy.
While it's easier create an open source software policy before establishing an approval process, in reality the opposite usually occurs. Someone is responsible for making open source decisions, and he or she ends up pulling together a group of people to create an informal approval process. Once established, even informal approval processes can become quite elaborate and efficient.
If you don't have an approval process, you'll want to sent one up. If you have one, you'll need to review it with your open source policy in mind.
You may want to establish a cross-divisional open source review board. This is usually the same team that owns the open source software policy. It should definitely include an attorney or work closely with one.
You'll also want the review board to include any teams that will use approved open source software, as it's important that they agree with the policy as well as the process. They can give you feedback to make sure the process integrates smoothly with their work flow so that reviews happen quickly and issues are resolved smoothly.
Decide what information should be included in the review process. At a minimum you'll want each open source usage request to include:
Next, decide on the process for reviewing requests. You'll probably save a lot of unnecessary reviews by asking local management and attorneys to review requests before they're escalated to the corporate open source review board.
Best practices for open source approval processes include:
Although your policy can require all open source software be reviewed and approved through a defined process, it's impossible to enforce by brute force—open source software can easily and freely be downloaded from the Internet. In order to make sure your approval process is effective and that employees are following it, you'll need to define an audit process.
The flowchart below illustrates a typical open source audit process:
Your policy should explicitly state the websites and methods through which employees are allowed to obtain open source software (sourcing) and how to decide whether a particular open source package is the right piece of software for the job (selection). Who can download software? Where can they go to download it? Do they need permission before downloading? Before using? Before distributing?
Many companies allow developers to download software and try it before going through the approval process. Attorneys are often uncomfortable with this because employees can use the software before the license is reviewed. However, businesses typically balance this concern with the fact that the risk is relatively small while the developer is just evaluating the software.Most companies end up adopting a free-for-all open source download and maintenance program—every team that needs an open source software package is permitted to download it and figure out their own support options. This is highly inefficient and often leads to the situation where a company is using many different versions of the same software package as well as duplicating evaluation and upgrade processes every time a new version is released.Other companies have adopted the idea of an open source repository in which approved open source packages are stored. Employees who need to use open source software are required to download it from the repository instead of the Internet. While an excellent idea, this approach often leads to failure because it's difficult for a single company that's not in the open source software business to create and maintain a comprehensive open source repository. The repository often ends up outdated and missing many useful open source software packages. If you go with this approach, you'll need a very good process for handling requests to add new open source packages or versions to the repository. Alternatively, you can use an open source repository provided by a third-party, like OpenLogic Exchange (OLEX) from OpenLogic.A policy that defines how and where employees can obtain open source software might look like this:Alternatively, your policy can allow employees to make a judgment call when it comes to sourcing:Note that while many attorneys recommend that no software be downloaded until the license is reviewed and approved, this is rarely followed. Your policy needs to take into account the legal risk of downloading software for testing or trial purposes before attorneys have a chance to review it. Adding a clause like this can help mitigate the risk:
Selection is the process of deciding whether or not a particular software package meets your needs and quality standards. In addition to any testing and standards processes already have in place, you might want to consider additional aspects for reviewing open source software such as:
For a list of other factors to consider around open source package selection, see the OpenLogic Certification Process white paper.
A policy might approach the issue of open source selection with language like this:Your policy may also outline what to do in case an open source project "ends" or forks. For example, the policy might define a timeframe in which the team has to find a different open source package to replace the original package:
Don't forget to include a section in your policy about mergers and acquisitions. Enterprises often fail to investigate open source usage or policy until after a target company has been acquired. It makes much more sense to check beforehand. You'll need to make sure your company's mergers and acquisitions team is aware of the internal open source policy as well as the need to investigate open source policy and usage at target companies prior to completing any acquisitions. Open source tools such as FOSSology, OSS Discovery, and OSS Deep Discovery can be run to identify the open source software deployed within a target organization.
A policy might approach the issue of mergers and acquisitions with language like this:
Technical support in the open source world has a bad reputation. While many people think there's no support available for open source software, the real problem is that there are too many choices for open source software support—and few of them resemble what people are used to in the proprietary world.
Options vary from do-it-yourself (by following mailing lists and even fixing critical bugs yourself) to paying a third party for a complete support and maintenance contract. The table below shows some of the common options:
An open source policy might address the issue of technical support with language like this:
Once the decision to use open source has been made, the process of downloading it and getting it to work is often challenging and satisfying. However, it can be frustrating to track the project for security updates, solve problems, and figure out when to upgrade to a new version.
Your open source policy should provide guidance on maintenance concerns by addressing the following issues:
The maintenance section of your open source policy should specify whether or not company employees can modify open source software. While you'll probably want to encourage people to not modify open source software (unless they are planning on fixing a bug or adding a new feature to contribute upstream), it's likely that some packages will require modifications to work in your environment or process. Your policy should specify when that's allowed and how changes are documented for maintenance.
An open source policy might address the issue of ongoing maintenance with language like this:
Your open source policy should include a clear statement about whether or not employees can contribute code changes to open source software projects. There are several situations in which you'll probably will want employees to contribute. For example, if an employee fixes a bug, you'll want him or her to contribute the patch to the project so that you don't have to maintain a unique patch through every version upgrade. In addition, by contributing code your company might gain credibility within the open source community. If your company actively contributes to a project, the community will be be more likely to recognize employees and quickly respond to their emails when issues arise.
Situations to consider when thinking about whether employees can contribute code changes to open source software projects include:
An open source policy might address the issue of open source contributions with language like this:
Some open source policies state that employees can only interact with open source communities using personal email addresses, not company email addresses. Note that if you include this rule in your open source policy, your company will never develop any credibility with the community.
Although many companies try to hide that fact that they use open source software, it rarely remains a secret—especially for organizations that decide to provide their own support using internal resources. It's best to establish a policy for how employees should communicate with open source communities and other interested parties, even if you intend to limit communication about open source usage as much as possible.
Your open source policy should provide guidance on communication by addressing the following issues:
Be sure to remain positive in the summary of your open source policy—after all, you want your employees to want to follow the policy—while also clearly stating when and how open source software usage triggers review. For example, the summary section of a corporate open source policy might look like this:
Allowed tags: <a> link, <b> bold, <i> italics