Every company that develops software whether for internal use or to sell to customers is now working in a new "mixed-IP" environment created by the spread of Open Source. This new environment's impact on software development has been dramatic.
A mixed-IP environment means that virtually all software developed today is a mix of proprietary software and Open Source programming libraries. And while this environment has dramatically accelerated software development, it has also muddied the waters with respect to understanding the intellectual property (IP) ownership issues behind one's software assets. If you or your company develops software, you need to understand what's going on.
There's no arguing that the impact of Open Source on IT has been huge. The impact of Linux alone has been incredible, with IDC recently forecasting that the market for "desktops, servers, and packaged software running on Linux will exceed $35 billion by 2008." By anyone's standards, $35 billion is a lot of money.
But the impact that Open Source is having on software development is in many ways more dramatic that its impact on IT, yet it isn't talked about nearly as much. It's difficult to find out, for example, the dollar impact that Open Source programming libraries have had on software development. But while I don't know the exact number, I can tell you it too has been huge.
The Two Categories of Open Source
At a high level, Open Source code can be separated into two categories: full applications and programming libraries. This is illustrated in Figure 1.
From this figure, you can see how these two groups break down. Open Source applications are applications that you can use immediately to solve business problems. The Apache Web Server and Linux are great examples, but there are thousands of others that are less well known. These applications are reshaping the IT landscape by providing organizations of all kinds with free high-quality applications they can put to work immediately.
Open Source programming libraries, however, are less visible and less well known than the major Open Source applications. But in some ways, they are having an even greater impact. For example, while not every IT shop uses Linux yet, virtually every programmer today is using Open Source programming libraries.
Virtually every Java programmer, for example, uses Sun's JDK to write and run Java programs. Not all of them realize, however, that Sun's JDK includes copies of Open Source programming libraries for XML, XSLT, and XPATH processing. These programming libraries come from the Apache Software Foundation and are included at no cost in the JDK.
Sun includes these Open Source programming libraries in Java for the same reason that other companies use Open Source programming libraries - they are high-quality libraries with rich feature sets that can be used and distributed by them at no cost.
What would it cost Sun if it had to develop all this functionality internally? It would certainly be significant. Not only that, Sun would also lose the advantage of being able to use code that's already widely used and debugged. The Apache XML libraries are used by thousands of applications around the world and they're solid. It wouldn't make business sense for Sun to write XML processing libraries when these other libraries are available and free.
For the same reasons, it doesn't make sense for any other company to write XML processing libraries either. Why waste time writing XML processing libraries when your developers can be focusing on important things like implementing new features to solve important customer (or internal) problems?
And Java XML processing libraries are just the tip of the iceberg. Open Source programming libraries are available for virtually any programming problem today regardless of the language you program in. There are libraries available for building graphical interfaces, for processing complex math algorithms, for security, for e-mail processing, for generating reports and graphs, and for virtually any other common programming task.
The result of all this is that there has been a massive shift from programmers working on low-level development tasks to writing code that leverages Open Source libraries and focuses efforts on higher-value activities involving the actual business logic in their applications. The net result is that there have been huge gains in programmer productivity; programmers can now build applications dramatically faster. As a result, they can spend more time focusing on what their users need.
But these benefits haven't come without challenges. These challenges are related to understanding the IP ownership issues behind software assets.
Open Source's Impact on Software Assets
Before Open Source programming libraries were widely used, understanding the IP ownership of a software program was relatively simple. Basically, companies either developed all their own software or licensed source code from some third party. Figure 2 demonstrates this.
In any case, it was clear who owned what. Besides, they had contracts that spelled out exactly what their rights were with regard to the proprietary/licensed code they got from third parties.
Contrast this with the following Figure 3, which shows how software assets are structured now that companies are leveraging Open Source programming libraries.
As you can see, the Open Source libraries are now a core part of the software asset. The software asset requires these libraries to run; without them the software program doesn't work.
On the one hand, this dependency brings with it a significant increase in the productivity of the company's development staff. It can get much more done using Open Source libraries, but some dependencies are built into the application that weren't there before.
Besides increasing the productivity of a company's developers, using Open Source libraries can sometimes make it affordable to build applications that would otherwise cost so much to develop that they'd never get built. In these cases, accepting the dependencies on Open Source libraries is the only choice available.
On the other hand, these new dependencies raise some new questions. One important one is, "Who owns the software asset now?" The company owns the code it wrote itself, of course. And the proprietary/licensed IP is owned by whoever developed and licensed it to them. But now things are more complicated; who owns the Open Source programming libraries and how does that impact ownership and licensing of the software asset as a whole?
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.