Who Owns Your Software Asset Now?
Figure 4 tries to demonstrate the ownership of the software asset.

As you can see, the Open Source libraries make understanding the ownership of the overall software asset a lot more confusing. Considering that many software programs contain literally dozens of Open Source libraries, it's easy to see that determining ownership of a company's software asset can be virtually impossible when significant amounts of Open Source are used.

This stems from the fact that copyright law governs software ownership. Copyright laws stipulate that source code is owned by its original developer except in a few cases such as when the developer was an employee of a company when he did the work or if the original developer specifically assigned the copyright to his code to someone else.

To clarify the conditions under which people can use Open Source, these libraries are licensed using Open Source licenses such as the GNU General Public License (GPL), the Mozilla Public License (MPL), or the BSD License. (For more information on these licenses, or on Open Source licensing in general, see www.opensource.org.)

How Does Open Source Licensing Impact Your Software Asset?
Figure 5 demonstrates the various licenses that might apply to a company's software asset.

In this figure, the portion of the software asset owned by the company has been omitted since it doesn't need a license to use software it owns outright.

The proprietary/licensed IP (or third-party code) is generally used under terms that are negotiated between a company and whoever owns the code. A company's lawyers usually review these terms before any agreement is reached on using the software.

Open Source libraries normally all come with licenses as well. Some of these licenses are long and complex and were written by lawyers who have a deep understanding of software licensing. At the other end of the spectrum, some were written by software developers with a very limited knowledge of licensing.

For example, here's the full text of a license written by one Open Source developer:

/*
* --------------------------------
* "THE BEER-WARE LICENSE" (Revision 42):
* <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you
* can do whatever you want with this stuff. If we meet some day, and you think
* this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
* -------------------------------
*/

So, clearly, if you use code licensed under "THE BEER-WARE LICENSE" then you need remember that you'll have to buy Poul-Henning Kamp a beer someday if you ever meet him.

Not all Open Source licenses come with such generous terms. For example, one common requirement for using Open Source libraries is that you agree not to sue any of the people or companies that contributed to the Open Source library for patent violations (even if they sue you first). If you sue them, then your license to use the Open Source library is revoked. This would be a big problem if one of your core software assets needed that library to work.

Some licenses (called "copyleft" or "reciprocal" licenses) insist that if you ever distribute your software to another company you must also provide that company with a copy of your source code - and that you license your source code to them under the terms of an Open Source license. For companies that provide software to their customers or business partners, these licenses can cause big problems.

In the end, by understanding which licenses are appropriate for the needs of a company, it's possible to manage which Open Source libraries get used so that the programmers (and the company) can stay out of trouble.

Software Compliance Management
So we've seen that using Open Source programming libraries can be a huge benefit for companies looking to increase the productivity of their software development teams. We've also seen that companies need to make sure they understand the licenses they need to be in compliance with. They also need to choose Open Source libraries whose licenses meet their overall needs.

The process of understanding licensing requirements for the Open Source (and licensed/proprietary) source code and libraries that you use is called software compliance management and it's a fast-growing discipline.

The goal of software compliance management is to make sure that companies plan and manage their software licenses to stay in compliance with all their obligations.

There are a variety of important pieces to the overall software compliance management puzzle. Here are a few of them:

1.  Understanding the Company's Needs
Effective software compliance management begins by knowing what a company's needs are. For example, is the company going to provide the software to customers or business partners? If so, then it'll need to be careful about using Open Source libraries that require you to distribute source code when you distribute applications.

2.  Planning and Licensing Management
It's critical that any software compliance management program have a planning component. This helps companies avoid situations where they find out at the last minute they have Open Source code or libraries in their products or projects that they didn't know about. Nothing could be worse than finding out just before shipping a product that there are Open Source libraries or code in it that could cause the company problems.

Licensing Management is the part of the planning process where companies evaluate the overall licensing requirements that result from combining Open Source libraries under different licenses and make sure that they understand the overall licensing picture for a software product or project. There are new software programs appearing that let companies "model" their software assets and calculate the overall licensing requirements of the assets.

3.  Analyzing Source Code and Resolving Issues
Before shipping a product (or launching an internal project), the software asset should be reviewed for overall licensing compliance. Issues should be identified and tracked to resolution.

In situations where portions of a project were developed by outsourced and/or offshore developers, a similar analysis should be done on the software they deliver as part of the overall acceptance process.

4.  Ongoing Compliance Management
After an initial analysis and resolution of issues, compliance management should be part of the overall software lifecycle. As new features are implemented and new releases planned, licensing issues should be tracked and managed as part of the process.

Summary and Conclusion
Open Source and the mixed-IP environment describe the new reality of software development for most companies. This new environment provides some huge opportunities, but brings with it new challenges. These challenges center on understanding how Open Source impacts the ownership and licensing of software assets. Software compliance management defines the process by which companies understand and manage the Open Source licensing issues related to their software assets.

So what should you do? How should you begin to incorporate these ideas into your company? How can you take advantage of Open Source in a managed way to gain the tremendous productivity benefits I've described? Well, the first steps are just to be aware of the opportunities and risks. Simply understanding the opportunities in front of you is definitely a start. Understanding how Open Source licensing works and which licenses work for your company follows right behind.

Understanding the importance of software compliance management in keeping the licensing aspects of your software assets under control should be your goal. Understanding and managing the licensing of your software assets is going to be critical as Open Source becomes an ever-greater part of the software development landscape.