Open source software is shifting the software industry into a new paradigm, moving from developing proprietary code behind closed doors to developing code that can be shared, modified and redistributed openly. Key benefits associated with this shift is reducing development cost and software components complexity, developing re-usable common-off-the-shelf software assets, while increasing flexibility and using common enablers. Organizations that embrace the open source model and follow it when it influences positively their ways of building software, will increase their chances to retain their competitive advantage. In this article, we review some of the best practices to follow when taking a proprietary technology and making it open source.

1.  Open Source for the Right Reasons
To be successful in open sourcing a project, you must have the right reasons or motivations. In a previous article published in Enterprise Open Source Magazine, we discussed the top good reasons to open source proprietary software, which included:

• Providing a reference implementation to a standard
• Ensuring that critical software remains viable
• Ensuring that new features are implemented
• Taking control of your own destiny
• Undercutting the competition
• Commoditizing a Market
• Partnering with others and promote goodwill for your company in the developer community
• Driving market demand by building an ecosystem
• Offering your customers the ability to support themselves and add their custom features

2.  Legal Review and Understanding Intellectual Property Implications
The second step in the process is to audit the code base which you plan to open source thoroughly to verify that all of the code is owned by you or, in the case of open source packages that might be included in your code, that you have the appropriate distribution rights. This audit may be partially automated with the use of scanning tools that are commercially available today.

Furthermore, you must also evaluate if any of your intellectual property (IP) will be released as part of open sourcing the code. Note that, in the case of a large company, one division may not be aware of the IP from another division. In that situation, it is important to have your open source project reviewed by a group that is familiar with all of your company's IP.

3.  Select an Open Source License
The adoption of a simple, well known and popular open source license will go a long way to encourage community participation in your project. Therefore, instead of creating your own open source license, it is most preferred that you use an existing license already approved by the Open Source Initiative (OSI). A list of OSI approved licenses can be found at www.opensource.org.

It is highly recommended to involve your company's legal department in the license selection process. In all cases, there are some general guidelines that we present below:

• Contribution to an existing open source project must follow the project's license.
• Contribution to the Linux kernel must be released under the GNU General Public License (GPL) Version 2.
• Creation of a new open source project requires choosing a license that matches your business goals, and preferably use an existing and OSI approved open source license.
• If you want all future derivative work of your contribution to be distributed in source code format, then the GPL is a logical choice.
• If you care contributing to a library, then you might consider the GNU Library or "Lesser" General Public License (LGPL).
• If you want your contribution to be usable within both open source and proprietary (commercial) products, then you might consider the BSD license or the Apache 2.0 license.

• General open source concepts
• Open source licenses
• Risks associated with open source software
• Your company's open source policies and compliance rules
• Open source development model
• Integrating open source software within your software development model
• Working with the open source community