Alto News
A few thoughts about Open Source software
October 15, 2010
“Open Source” software has revolutionized software development over the last several years. Today, thousands of commercial products—hardware, software, websites, and the like—all use some amount of open source software. Indeed, not using open source in software development is a disadvantage, as competitors are able to develop products faster and cheaper.
Should you decide to use open source in your software, here are a few things to think about:
1. Make Sure To Look At The Actual License. “Open Source” means different things. There are organizations that are trying to standardize this definition, but they are all voluntary corroborations among different people and entities, with no real authority. Thus, there is no one form of “open source” license. Various licenses may have similarities (for example, many disclaim all warranties), but they generally have many more critical differences (waivers of intellectual property rights, distribution requirements or limits, etc.). Sometimes, a developer will release software under a “dual license,” giving out source code under the terms of a free, open source-style license, and requiring a different, fee-based license for commercial use. Thus, it’s important to have a lawyer take a look at the license that accompanies any source code that your developers use to develop your software.
2. Keep Track of It. The last thing that you want is to have one of your developers use open source code without you knowing about it. Doing so risks inadvertently violating the license, and causing you a lot of headaches down the road. Open source developers are getting more aggressive in enforcing their rights, and even if no litigation results, your company could be “flamed” as an abuser. And, if you want to obtain financing or be acquired, you must know what is in your code base. Most financing and M&A agreements have a rep and warranty regarding the use of open source software, and VCs and acquirers can use one of many sophisticated tools in due diligence to verify what is in your code. These tools can compare your code, line-by-line, to a huge database of open source code, identifying when open source was used even if the license and copyright info is not in the code base. Tell your developers to report and track any use of open source (and any other code that they themselves did not write), and keep an updated list of what is in a given version of your software, as well as notes on any special requirements you have to meet.
3. Be Wary of The GPL. The General Public License or “GPL” put out by the Free Software Foundation is one of the most common open source licenses used, and thus is almost impossible to completely avoid. That said, any use should be done with care. The GPL contains a specific term, called “Copyleft,” that requires disclosure of any source code that can be considered a “derivative work” of the GPL-licensed software. Lots of folks have opined about the scope of Copyleft, but none of those opinions are legally binding on anyone. To date, no court has issued a definitive opinion about Copyleft. “Derivative work” is a complex term of art in copyright law, and US courts use different tests to determine when one software program is “derivative” of another. The risk to you is that connecting a GPL-licensed module with a proprietary one could result in your having to disclose the source code for the entire work, including the proprietary code. So, while you should always be careful when using any open source code, using GPL code requires more diligence. It is possible to use GPL code along with non-GPL code such that the combination does not trigger Copyleft, but doing so requires careful consideration of your software architecture. If you use open source, you will likely have to deal with the GPL; do so with care.
Remember: open source code is no different than using source code that you license from another company, whether you paid for it or not. The fact that the source code is “open” does not change best practices for using other people’s software. The license, and not the label, determines what you can and cannot do.
Should you decide to use open source in your software, here are a few things to think about:
1. Make Sure To Look At The Actual License. “Open Source” means different things. There are organizations that are trying to standardize this definition, but they are all voluntary corroborations among different people and entities, with no real authority. Thus, there is no one form of “open source” license. Various licenses may have similarities (for example, many disclaim all warranties), but they generally have many more critical differences (waivers of intellectual property rights, distribution requirements or limits, etc.). Sometimes, a developer will release software under a “dual license,” giving out source code under the terms of a free, open source-style license, and requiring a different, fee-based license for commercial use. Thus, it’s important to have a lawyer take a look at the license that accompanies any source code that your developers use to develop your software.
2. Keep Track of It. The last thing that you want is to have one of your developers use open source code without you knowing about it. Doing so risks inadvertently violating the license, and causing you a lot of headaches down the road. Open source developers are getting more aggressive in enforcing their rights, and even if no litigation results, your company could be “flamed” as an abuser. And, if you want to obtain financing or be acquired, you must know what is in your code base. Most financing and M&A agreements have a rep and warranty regarding the use of open source software, and VCs and acquirers can use one of many sophisticated tools in due diligence to verify what is in your code. These tools can compare your code, line-by-line, to a huge database of open source code, identifying when open source was used even if the license and copyright info is not in the code base. Tell your developers to report and track any use of open source (and any other code that they themselves did not write), and keep an updated list of what is in a given version of your software, as well as notes on any special requirements you have to meet.
3. Be Wary of The GPL. The General Public License or “GPL” put out by the Free Software Foundation is one of the most common open source licenses used, and thus is almost impossible to completely avoid. That said, any use should be done with care. The GPL contains a specific term, called “Copyleft,” that requires disclosure of any source code that can be considered a “derivative work” of the GPL-licensed software. Lots of folks have opined about the scope of Copyleft, but none of those opinions are legally binding on anyone. To date, no court has issued a definitive opinion about Copyleft. “Derivative work” is a complex term of art in copyright law, and US courts use different tests to determine when one software program is “derivative” of another. The risk to you is that connecting a GPL-licensed module with a proprietary one could result in your having to disclose the source code for the entire work, including the proprietary code. So, while you should always be careful when using any open source code, using GPL code requires more diligence. It is possible to use GPL code along with non-GPL code such that the combination does not trigger Copyleft, but doing so requires careful consideration of your software architecture. If you use open source, you will likely have to deal with the GPL; do so with care.
Remember: open source code is no different than using source code that you license from another company, whether you paid for it or not. The fact that the source code is “open” does not change best practices for using other people’s software. The license, and not the label, determines what you can and cannot do.
By Greg Zafiris
