Getting Approval from Your Company

Before you can announce your open-source project to the world, you have one last hurdle to clear: getting official approval from your company. Working with open source is similar to introducing a new product or making use of another company's proprietary code. In both cases, your company is making a legal agreement that can limit future choices and create future obligations. This is all part of normal business and so your company should have an established procedure for approving the use of open source in company activities. Just as most companies require approval before a new product is introduced or an old product is retired, there should be an official approval process to create a new open-source project or end participation in an existing one.

A small company might do this casually, whereas a larger company will probably have a formal approval process. If you've done all of the steps mentioned so far in this chapter, then you should have answers to the questions that will be asked during the approval process, and you should have no trouble getting your project approved.

Most companies will have different approval procedures depending on whether a project is intended to create a new open-source project to release source code developed internally (outbound open source) or whether code from an existing open-source project will be used in-house or incorporated into one of the company's products (inbound open source). There may be still a third process to approve joining an existing open-source project, where you plan to both contribute company-developed source code and make use of externally developed code.

Your company should also have an approval process for employees who are working on an open-source project as individuals on their own time. Although this is primarily to protect that individual and the open-source project they are participating in, it can also benefit your company by signalling its support for open source.

Finally, there needs to be an approval process for stopping work on an open-source project or decreasing the company resources allocated to it. Just as every company needs to control how it ends the life of a product, similar end-of-life (EOL) considerations apply to stopping work on an open-source project.

Different issues and concerns are important for each of these situations; we discuss each in turn. Note that each company will have its own process, so you need to contact your company's legal department for details of your company's policy.

Who Should Be Approving Open-Source Activities?

Because of the possibly serious implications and requirements associated with both inbound and outbound open source, it is important that any approval body consist of executives at the same level as those who approve new products. The approval board should include senior executives from development, marketing, product planning, and legal. The reviewing team may include the head of your business unit.

It is vital that the approval of a company-sponsored open-source project come from a level higher than that of the manager who will be running the project, and it should come from a level above all of the groups that will be affected by the project.

If you are creating a new approval process for your company, be sure to announce it to everyone who might be involved. Especially when it comes to downloading source code from the Internet, many engineers may not realize that they are potentially exposing the company to harm.

Creating a new open-source project is almost like releasing a new product--it consumes company resources, its quality reflects on your company, and it implies a certain commitment. If you start a new project and it fails, this will probably generate bad publicity for and bad will toward your company. The approval process needs to weed out the badly conceived projects and make sure that proposed projects have not neglected anything important.

There are two parts to a basic approval process for creating a new open-source project: a business analysis to explain your business strategy and make the case for doing open source and due diligence to guarantee that the source code does not include any embarrassing comments or third-party encumbrances. Only after both steps have been successfully completed can the project be started. In fact, no announcement of your company's intent to release the code should be made until both steps have been completed.

Requirements for the Business Analysis

The business analysis should require you to examine two main areas: the suitability of the source code for public distribution and the strategic significance for your company of releasing the code.

Steps for determining suitability include the following:

Identifying the source code.
Determining what stage of development the code is in--is it mature code?
Confirming that the source code is free of viruses.
Confirming that there is adequate documentation.
Confirming that the source code is sufficiently modular and buildable that outside developers will be able to use it.
Identifying the engineers who will participate on the due-diligence team.
Identifying the employees who will interact with the community created by the new open-source project and confirming that they all understand how to interact.

Steps for determining strategic significance include the following:

Listing the business goals for making the source code public.
Identifying the audience/community that will use the code.
Identifying the factors critical to the success of the effort, including the resources needed.
Specifying which licensing model your project will use.
Identifying what the financial impact on your company will be.
Specifying a schedule for the project, including the target date to announce the release of the source code.

This information should be reviewed by your approval board, and if they decide that there are suitable business reasons for using open source, then you need to start the due diligence process.

Requirements for Due Diligence

Due diligence includes a review of the source code and documentation by your company's legal and technical staff to determine whether any third-party technology or proprietary information has been incorporated into the source code you are planning to release. This is done by examining the source code thoroughly to determine the origin of each part. Any code not developed by your company must be checked to determine whether it is under a license that allows you to include it in a public release, and, if not, the code must be replaced or relicensed.

The due diligence effort also includes the following:

Confirming that appropriate copyright, trademark, and patent filings have been made.
Determining whether there are any export restrictions.
Removing any inappropriate, derogatory, or offensive statements or references in the source code.

Upon successful completion of the due diligence process, the approval board that reviewed the business analysis should either approve the project itself or pass a recommendation to an appropriate senior executive for final approval. Once the project has been approved, you may announce the project and release the source code.

Getting Approval To Use Source Code Developed Outside Your Company

If you are planning on downloading source code that has been released under an open-source license, then before you can incorporate that code into a company product or use it internally you will first need to get company approval. This is to ensure that your business unit, any affected functional groups (for example, support), and your upper management are making informed decisions when they acknowledge and accept the risks and obligations dictated by the license that the downloaded code uses.

These risks include the following:

No warranties, which means that if the source code infringes the intellectual property rights of a third party, your company could be required to stop shipping products containing the downloaded code and could be forced to pay monetary damages.
No support, so, if needed, your company must resolve performance, customer support and maintenance, internationalization, and localization issues. (Of course, providing support for an open-source product can be an excellent business opportunity.)
Limits on what your company can do with a product based on the open-source code, which means that your company may not be able to release a larger work under a desired license.
Additional requirements on your company, such as that all source code in any derived work must be made publicly available.
Indiscriminate dissemination of the downloaded source code within your company, which could permit it to be unknowingly used in some other, inappropriate company product.

The approval process needs to review the business case for using the downloaded code, including how these risks will be minimized or handled. Issues that must be addressed fall into three main categories: business analysis, strategic analysis, and legal review.

Business Analysis

First you must do the following:

Identify and describe the technology you wish to use.
Explain the strategic significance of the technology: What gap does it fill? What is its benefit to your company? What alternatives are there?
Identify which of your company's products will use the technology and how they will use it: Will it be embedded in the product or just bundled with it? If embedded, will the downloaded code be used as is or will it be modified?
Describe how your company will distribute the technology (for example, in source or binary): Will the technology's functionality be segregated from your company's proprietary code?
State whether there will be any license fees or royalties for the company products that will include the technology.
Explain how the technology will be maintained and supported.
Describe the proposed licensing model for any of your company products developed using the downloaded source code.
Estimate the difficulty and the time required to remove or replace the downloaded technology if that should become necessary.

Strategic Analysis

Next, someone from your company's corporate strategy and planning department must do the following:

Ensure that your company's strategic rationale and business purposes for downloading the technology are consistent with your company's long-term technical and business objectives.

Check with your company's support division that the appropriate support and engineering resources are available to support the downloaded source code once it has been embedded in one of your company's products.

Legal Review

And, finally, your legal department needs to do the following:

Identify licensing requirements, such as needing to publish the modified source code.
Identify any legal risks associated with using the downloaded technology.
Identify any steps or measures to minimize the risks or to comply with the licensing requirements.

Once you have the information required by these steps, the approval board can review matters. Only after approval is granted can the downloaded source code be incorporated into a company product. Once it has, your group will be responsible for making sure that your company complies with any requirements imposed by the download license.

Several groups in a company might want to use a specific downloaded technology--especially one used only internally and not in any company products, such as Emacs, Apache, or Tomcat. For these cases, it might make sense to create a fast-track approval process that can be used to quickly approve requests to use downloaded software that has already been fully reviewed. The only thing that needs to be checked is that the software will be used the same way.

It may also be possible to automatically approve software downloaded for an employee's individual use, such as a calendar manager, address book, news reader, or web browser. The key point here is that the employee is not modifying or redistributing the software. But even in these cases it is important to check that the license used by the software does not preclude its commercial use, the use of the software as part of an individual's job.

Getting Approval To Participate In An Existing Open-source Project

If you are planning on having your company's employees participate in an existing open-source project, then before they can do any work with it you need to get the proper approval. This approval process will probably be similar to that for participating in a joint effort with another company or an industry consortium. In some cases, all that may be required is that the direct managers give their approval to the participating engineers. For example, a small, focused effort by one of your engineers to help an open-source project adapt its code to run well with one of your company's products should not require a heavyweight approval process.

If code previously developed by your company will be contributed to the project or if the code developed by the project will be incorporated into one of your company's products, then one, or both, of the previous policies may apply and require an additional approval process.

The steps that should be followed before any of your company engineers may participate involve the details of the open-source project such as the following:

Describe the overall open-source project.
Determine the primary reasons that your company should participate.
Determine the precise goals and objectives for your company personnel working on the project.
Determine which open-source license the project uses.
Determine how IP is handled. Does the project allow contributors to retain copyright on contributed code?
Identify other companies participating in the project.

There are also steps involving risks to your company's intellectual property rights, as follows:

Identify the procedures you will put in place to prevent any of the open-source code developed by your company personnel from subsequently getting mixed with your company's proprietary code.
Determine the likelihood that your company personnel developing open-source code will later be asked to develop similar functionality in your company's proprietary code.
Determine whether any existing company patents fall within the scope of the project.
Outline the steps you will take while working on the project to identify possible future patents.
Determine whether participation in the project will increase the risk that company personnel could disclose trade secrets.

Once this information has been obtained and your management grants approval, then you can start to participate in the open-source effort.

Getting Approval as an Individual

Many software engineers choose to spend part of their personal time contributing to open-source projects. By doing so, they learn new technologies, get feedback on their coding abilities, and otherwise grow and develop. This is a benefit to the company they work for because it makes them more valuable as employees. However, it can create a problem if their open-source work conflicts in some way with the company's business.

A company may have legitimate concerns about work employees do in their spare time. If the open-source work is similar to an employee's job then there is the danger that the employee will disclose proprietary information concerning technical ideas or business plans. This could make it impossible to file patents on work the company has done. Likewise, the employee might inappropriately take ideas or code from the open-source project and use it in a company product, thereby tainting it.

Even when an employee's open-source work and normal work assignment are in different areas, the company might have a product that competes with that of the open-source project. That can create a conflict of interest for the employee.

Many companies require their employees to sign an agreement when they are hired that specifies that the company owns anything that the employees invent. Students who are receiving support from their university may be in a similar situation. If the employees or students contribute to an open-source project, then their employer may claim ownership of their work. There have been several stories reported at places such as Slashdot in which this has indeed happened and people had to stop their participation in the open-source project and have their code removed from it. This is bad for the project, is very bad for the individual, and gives the company a bad name. No one benefits from a situation like this.

All these potential problems can be avoided by having a simple process for employees to get approval to participate in an open-source project. The process should ensure that the employees understand company policy regarding intellectual property and conflicts of interest. General guidelines should be established and communicated to the employees. These typically include that any open-source work should be done on the employees' own time, should not be done while at work or using company equipment, and should not be similar to what their normal job duties are. A form amending the original employee agreement should be signed by an appropriate-level company executive and the employees should receive a copy. The form should state that the company gives up any claim to the work done by the employees as part of the open-source project and that the employees have the right to assign their copyrights to the open-source project.

The need for approval arises largely because of the agreement many companies have new employees sign. One suggestion from Slashdot is that when starting a new job the new employee should rewrite any offending clauses to restrict the scope of that agreement. The following is an excerpt from that posting:

A lot of people think they have no negotiating ability. You do. When you're thinking of signing on with some company, and they send you a boiler-plate contract to sign, don't just sign it and send it back. Read it carefully. Alter it as you see fit, striking out sections, adding sections, and initialing each change. Then sign it, make a copy for yourself, and send it back.

Where it says:

company owns the rights to all work produced during the term of employment

Just strike it out, and change it to:

company owns the rights to code written during working hours and in direct furtherance of any tasks assigned by the company

See how much nicer that reads? Now, when you do this, there are two possibilities: either the company will ignore it and hire you, or they will object to your alteration of the contract.1

Many Slashdot posters have described how they did this when they started a new job and that their employers had no problem with making any reasonable changes.

Getting Approval To Stop Or Lessen Participation In A Sponsored Open-source Project

There will come a time when you need to reduce the number of people and resources devoted to an open-source project that your company has been sponsoring. Because it is an open-source project, this is a much more public announcement than reducing the number of employees working on some internal proprietary product. If handled badly, it can hurt your company's reputation in other open-source projects you sponsor or participate in--developers will question your company's commitment to open source. You can also expect news stories reporting your company's change in focus.

Naturally, how damaging such a reduction in support can be depends on the size and prominence of the project. If it is something as large as IBM's support for Eclipse, then reducing commitment will probably be written about in the mainstream press, whereas if it's a small company with a small project, there might be hardly any notice taken outside that project's community. The community surrounding even a trivial project, however, can be vocal and influential beyond the apparent importance of the project itself, and it is sometimes hard to know for sure who is watching the project. So be wary of how you try to reduce your company's commitment.

Because of the potential for damage to your company's reputation, it is important to have an approval process in place to review any decreases in your participation in publicly visible open-source projects. The last thing your CEO wants is for the press to announce that your company is making major changes in strategy all because some low-level manager has laid off or transferred the employees most visible to one of your open-source projects. We've seen this happen--a company laid off the employee providing the technological leadership for one of their open-source projects--along with the subsequent damage control the company needed to recover from it.

If you want to minimize the negative impact of reducing your commitment to an open-source project that your company sponsors, the questions that must be answered include the following:

Is this a decrease in effort, or are you ending your participation in the project?
How will it be announced?
What will the public perception of the reduction be?
How will the community of the open-source project react?
How will this affect other open-source projects your company is participating in?

If you are ending your sponsorship of the project, there must be a plan and schedule for disengaging. You will need to answer the following additional questions:

Who from the community will take over the project?
Where will the project's website be hosted? How will any transition take place?
What obligations do you need to fulfill (for example, continuing to post the source code)?
Is it okay for your developers to continue to participate on their own time if they wish to?

Making sure all of these questions have satisfactory answers before taking any public actions should minimize any possible harm to your company and keep the respect of the open-source world.

What about Small Projects or End-of-Life Products?

For a small project, all of this may seem like overkill. However, the same steps must be followed whether you are releasing 500 lines of code or 500,000. Of course, it is much easier to do due diligence on 500 lines of source code so it can be released.

To be successful, open source requires fostering a community around the code, and that takes work. At a minimum, someone who understands the code must filter suggested changes and help developers work with it. It also requires an archived mailing list or newsgroup and at least a handful of web pages, including one that lets people download the source code and executable versions.

Most open-source projects are fairly small, consisting of fewer than 20 developers and several hundred users. So, the effort required is only the discussion and coding needed to move the project along. As long as the user community is happy with the rate of progress, the project is alive and healthy. For a mature project there may not be many, if any, changes being made to the code--the community will stay healthy from active discussions on how to best use the software.

Because a small project will have a limited budget (and an EOL project may have no budget), it will probably not be able to afford to have a dedicated website. If your company already has a website for small company-sponsored open-source projects, then you can host your project there. For example, a number of smaller Sun open-source projects are hosted at SunSource.net.2 If your company does not have such a website then you will need to use a free website provider, such as SourceForge.3

For EOLed code that is no longer being supported, but that you don't want to die, the amount of effort needed to make it open source may seem to be orders of magnitude more than the work you expect your group will put into the code in the future. Remember that open source is not magic: It takes a lot of work to create a community and make an open-source project successful. You will still need to determine an appropriate license for the software. To give a community a chance to grow, you should expect that you will need to commit one or two engineers for at least a year to engage with the community and to continue working on the code.

For a product that you are about to stop supporting, you may just want to provide the source code to current customers so they can continue to use it. That is, you want to keep your customers happy even though you are discontinuing the product, but you are not interested in creating a community. In such a case, it may be sufficient to make the source code and supporting material, such as build scripts and internal documentation, available for download on your regular corporate website. You should also make sure that there is an email list or forum set up so that your customers can help each other--plan for some of your engineers to participate on that list.

1. http://slashdot.org/article.pl?sid=02/03/21/0139244

2. http://sunsource.net

3. http://sourceforge.net

Innovation Happens Elsewhere
Ron Goldman & Richard P. Gabriel
Send your comments to us at IHE at dreamsongs.com.

Previous Table of Contents Up Next