Looking for something else?
There are many pitfalls awaiting enterprise software development shops that use open source code without first setting down a clear strategy, according to Protecode CEO Mashad Koohgoli. Koohgoli is a serial entrepreneur with more than 25 years of experience in the telecommunications industry. He co-founded Protecode, his fourth company, in 2007. Protecode provides software governance and IP management tools that let companies keep track of what licenses govern the code they use. In this Q&A, Koohgoli discusses dual licensing and how companies use some of the more common open source licenses available.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Rob Barry, SearchSOA.com: There is a very wide variety of open source licenses out there. What are some of the characteristics that differentiate them?
Mashad Koohgoli, CEO, Protecode: There are something like 80 licenses approved by the open source institute. These are the standard licenses that open source vendors are encouraged to fit into and, in fact, there is still an effort going on trying to reduce the number of these licenses. But if you do create a product and you want to make it available to the public under an open source license, you are not bound to pick any of these. You can take any of these and make a variation. What it means is that although you have 80 standard licenses you may have literally more than 1,000 different variations on a license.
SearchSOA: What are some questions a developer might ask about a specific license?
Mashad Koohgoli, CEO, Protecode: A developer will have to ask several things. Am I using the licensed software internally—within my own organization, maybe within a server only—or am I distributing it? If I'm distributing it, can I distribute my software with the external open source content in it unmodified, or is there going to be any modification of this external open source content? Can I release the source code of my modifications to the public, or can I just keep it proprietary? Can I use the licensed software as part of a specific technological measured delivery? For example, there are certain pieces of software that I can't use for encryption purposes. Or can I use the binary form of this software unmodified and distribute it unlinked to my software and leave it to the user to link them together?
SearchSOA: What are a few of the most common open source licenses we see today?
Koohgoli: We have a database of something like 450,000 projects in different licenses. I think GPL and GPL version 2 has been the most commonly used public license in our libraries for the open source content that's out there. Some other common licenses are LGPL and the BSD license. Apache is very common, as is the Mozilla public license. The MIT license is very popular because of its attributes. There are some Microsoft public license projects out there but, relatively speaking, they are not that popular.
SearchSOA: What are some hidden challenges to working with public licenses?
Koohgoli: The trickiest licenses are the licenses with the copy left attribute. You touch it and you have to make your own resulting product open source and available under the same terms and conditions. Of the copy left licenses, the most used and the best known one is GPL and its variety. That's tricky because in a lot of cases your business model does not allow your software to be released to the public.
But in a lot of cases it is perfectly fine. You open up your Apple iPhone and there is a license and a legal tab. And if you read the legal tab on your iPhone it basically lists all the GPL content that they're using. Because for Apple, for that application, it is okay for them to release the source code.
Other licenses may well be aligned with your business objectives but they still have requirements. For example, the BSD license, the MIT license, Apache - they all expect you to repeat a specific header at the top of all your source code. Certain licenses require you to actually have the text of the license packaged with your distribution. None of these are necessarily showstoppers for you business, but failing to comply with those requirements means you're breaking the license. And you could be liable for that.
SearchSOA: So what is the most typical scenario you see where a large enterprise will run into trouble with an open source license?
Koohgoli: We've been trying to document some of the cases that have been popular. A lot of these cases are legally pursued in different parts of the world but definitely Europe, Germany, is very active. More and more the U.S. is becoming more active.
You probably heard about the recent Microsoft Windows 7 USB download tool that they released under a Microsoft license. It turns out that the content that Microsoft believed was theirs wasn't theirs actually. Some developer had taken a piece of functionality from some open source content. That open source had a GPL licensing attribute, and therefore Microsoft had to make available the source code for that function.
That was at the end of last year. What happened was, Microsoft put the Windows 7 software out, somebody in the market detected that this is actually using a piece of GPL open source and Microsoft had to halt distribution until they decided what to do. Their options were either to open source the project, replace that functionality with another piece of software that had the right licensing attribute, or rewrite it from scratch. The last two cases meant significant delays to the product launch, so they decided to open source that specific application.
Good developers these days don't write code from scratch. Good developers know where to get code and combine it with their own value-add to get the functionality.
SearchSOA: Tell me about dual licensing, where a company can offer versions of a product with both commercial and open source licenses. Is this a common practice now?
Koohgoli: It's common in that there are a lot of companies – very reputable companies – that have been using this model. MySQL, before they were acquired by Sun, had a very successful dual licensing strategy where the original code was released under an open source license. For enterprise use, there was a proprietary license that you paid for. There was added functionality and as part of the payment you got some service. With the open source license you were on your own. The success of that model is debatable. It can lead to confusion in the marketplace unless it's managed and communicated very clearly.
SearchSOA: What is the benefit to dual licensing?
Koohgoli: To the vendor, the benefit is that you're hoping to create a revenue stream out of providing a restrictive license, getting paid for it and, in return, you're promising certain functionalities, certain content and a certain level of support. You stand behind it. With the open source license, what you see is what you get. The source code is available and you are responsible for taking the core open source software and massaging it into your application or product.
The whole idea is that the open source will create awareness of the product. And a lot of companies don't want to go through the trouble of integrating the open source model into their product line. They will go and purchase the commercial version with its supported, indemnified content. Red Hat has been using this dual licensing method for a long time.
SearchSOA: Are there any major risks to dual licensing?
Koohgoli: It needs careful packaging in terms of the business model, functionality and licensing terms. It requires careful separation of the openly licensed version and commercially licensed version. There has to be enough value in the commercially licensed version so that it's very clear to communicate it to your customer.
In a lot of cases this differentiation is not communicated very well. Or the differentiation is so small that a client can forego paying additional money and not have the additional features in place. Or the licensing terms of the public version are not, in a majority of cases, onerous enough to encourage a company to get the commercial version.
SearchSOA: And for companies who do use dual licensing, what is the most common open source license to offer?
Koohgoli: The most common would be GPL for open source. Commercial would be proprietary. The reasoning, I think, is because the GPL license and their copy left requirements would not fit in with a lot of companies business models. It would create an incentive for those companies to go and learn about the commercial license.
SearchSOA: Finally, what are a few things companies can do to keep out of trouble with open source licensing?
Koohgoli: The first thing would be to have a conscious open source adoption strategy in place. Have a policy. The policy says for a particular project, product or for the whole company, what are the rules around what open source licenses you can and can't have in your product. Once that's established, you can go ahead and take advantage of all this "free" software out there. Open source is wonderful if its adoption is managed properly. Have an open source adoption strategy in place, have a strategy in place and know what's going into your software.