BSD: Best License for IT? An Interview with Mark Brewer, CEO of Covalent Technologies

by Dan Woods


DAN WOODS: Why do you favor the BSD license over other open source options for the IT context?

MARK BREWER: I should clarify that when I say I believe that BSD-based license technology is better for IT departments, I mean IT departments that are taking in code and potentially changing it, enhancing it for their own business use or incorporating it into other products or other software development projects. IT departments who are just taking in GPL code as is, and don’t intend to make any modifications, or go back to the community that owns that code and tell them or give those changes back, then they’re fine. I think there’s definitely a place for GPL-based software and I think there’s definitely a place for BSD-based software.
I am very pro-BSD for a number of reasons. One reason is that when you look at the successful projects that Covalent happens to be involved in, they have not forked, and they have not died like so many of the early advocates of the GPL predicted. Apache or BSD-based technologies have done extremely well, and the communities around them have done very well at enhancing and maintaining them, and not not forking them. Moreover, we’ve seen projects like Apache Tomcat flourish and grow, it’s in version 5.5 now and it is the most widely used application server out there. Another reason I’m an advocate of BSD is that I think software vendors as a whole should be able to take advantage of open source technologies without having to deal with all the issues that the GPL presents. In fact, the GPL is frequently, not compatible with other licenses software vendors may have, or other licenses they wish to use within their product. BSD-based software lets you do whatever you want.

DW: What are the advantages of using BSD for building applications and toolkits?
MB: If I’m a software vendor and I want to take some open source code and make it work for my customers -- if I’m selling to a financial institution, for example -- then I’m writing some specific functionality that’s going to address their business needs. Clearly, the BSD is going to be a lot more acceptable to that customer because they don’t even have to think about any enhancements to that open source code being given back to the community and getting into their competitors’ hands. If you’re writing applications, you need to pay very special attention to what license it is that you’re using. And, in cases like this, I believe that a BSD type of license is going to be much more appropriate to you than something that is GPL-based.

DW: But in the cases where you are using an open source project but not modifying it, aren’t all licenses basically equivalent?
MB: No. If it’s GPL-based code, you have to be more aware of how it’s being used, and how it might be included or compiled into another product. So you definitely have to pay more attention to exactly what you are doing with GPL code versus BSD code. The BSD license is pretty open, you can do whatever you want, however you want. The only requirement, generally, is that you need to acknowledge who the author is and who has copyrights.

DW: Do you think that the provisions of the GPL license are having a negative effect on adoption of open source because they’ve been used by opponents of open source to spread fear, uncertainty and doubt?
MB: Yes. Microsoft’s done a good job of that. I think even Sun’s done a good job of that. A lot of the big vendors who didn’t want projects that were out there under a GPL code to be successful used that FUD.
We are fortunate enough to have a large number of Fortune 1000 customers and I can name a dozen who specifically said to us, “We don’t allow our developers to download any GPL source code,” because they’re afraid of the consequences. There are very few lawsuits that have been filed against the GPL. But those that have been filed were because somebody simply forgot, or didn’t know that they had included a GPL-based piece of software in a product, and didn’t realize they were in any sort of violation.

DW: And this has been extended by the distorters to make it seem that if you even use GPL code all of a sudden your intellectual property is at risk.
MB: Exactly. The GPL is a much more confusing license agreement. So it’s easy to have FUD when somebody can’t interpret or understand the terms.

DW: But if someone wants to develop an open source platform that is immune to legal risk it requires ignoring a huge amount of open source that is under GPL. How would you advise people to make the tradeoff between re-creating the functionality of GPL and coping with the legal difficulties of GPL?
MB: If the functionality that you’re building your framework around is largely already done under a GPL license then by all means you should go with the GPL. Because, otherwise, you are re-creating all of that work and not taking advantage of what the whole open source community is about. The negative side is that you really don’t have a choice unless you want to start from scratch.

DW: If you were designing the next version of GPL, how would you recommend that it be evolved in order to make itself friendlier to IT adoption?
MB: One recommendation, and I believe this is going to be part of the 3.0 revision of the GPL, is to clearly address patents and copyrights. Be explicit about allowing people to still have patents on software that might be included in GPL code. Right now that is prohibitive. It’s not clear enough in the current version that you cannot have any patented software.
The second thing is that the viral nature of the GPL needs to be made explicit. The GPL license, which everybody interprets differently, says that if you take GPL-based source code and modify it or enhance it, then the derivative work or new product that you deploy must be licensed under the GPL. And some interpretations are even broader than that. This needs to be clarified. What is a derivative work? What does it mean to include GPL software inside of another application? And does that in due course mean that it has to be licensed under the GPL also? One of the big fears of software vendors—including even a company like Covalent who does everything on open source—is that I might take in some GPL code, modify it or include it into some other product or software package and not license it appropriately. There’s a lot of confusion out there, and even I have been confused at times when I read a software license as to whether this is supposed to be licensed under the GPL or not.

DW: Let’s say someone in an IT department recognizes an opportunity for open source use -- they have the skills in-house, they are able to institutionalize them, they understand the software and how to use it, support it operationally and to support it based on the community -- and then they run into a roadblock from a legal department or a risk management department that is ignorant of the real nature of open source licensing. What would your recommendation be in order to overcome those barriers and educate people about the risks associated with using open source?
MB: This comes up all the time. Somebody within an IT department decides to use Apache Tomcat or some other product that we happen to support and their legal department finds out about it and says, “Wait a minute, we can’t be allowing this open source software in-house.” They argue that there must be a way to either find a proprietary solution that does the same thing. The other option, and this is what’s happened with Covalent and other companies, is they find a vendor who takes that open source technology and provides enterprise software type of support, indemnification insurance and all the protections that go with it. Clearly, that’s one of the reasons we’re in business. A few years back a very large and well-known software house was considering using Apache in a product and their legal department said flat out no. They contracted us to come help them evaluate the risks of bringing Apache into their product and offering it to their customers. So it was mostly a legal discussion between our lawyers and theirs about the Apache license and what you have to do if you’re going to include it in your products. The BSD or Apache license is so straight forward that it wasn’t difficult to explain, and was, therefore, pretty acceptable to them. There isn’t a lot of risk around an Apache-based technology.
Now, if somebody asked me the same question about using a GPL or LGPL code, I would encourage him or her to take a close look at how that product is being used. Are they modifying the source code? And are they involved with the community? Ideally, they should have somebody who is doing development with that code involved in that community so they can keep up to date on fixes and so forth. And further to assure that any changes they might make get attributed back so that they’re not violating the GPL or LGPL.

DW: Why is the LGPL insufficient to solve this problem?
Brewer: Well, it’s better at solving the viral nature that we were talking about earlier. But it doesn’t change the fact that you have to license it under the same license if you’ve made changes to the code. It just makes it easier to include that software in another product and not be a derivative work. Additionally,it’s supposed to be used only for libraries, but we’ve seen the LGPL used for much more than just libraries.

DW: How do you think the alternative indemnification mechanisms, like open source risk management, have been accepted by IT departments?
MB: Not very well yet. The reason is that it’s still not the same as calling on a vendor. A vendor is a true throat-to-choke, right? If you feel like there is a problem, whether it’s an infringement claim or anything else, going to a vendor is a lot easier and they have incentive to address your problem.

DW: What are the five biggest myths in IT departments about the legal and IP risks of using open source that you and your sales staff run across when trying to sell Covalent products and services?
MB: The biggest legal risk that people are afraid of is that they have no indemnification coverage. And that isn’t a myth, it’s absolute reality -- I don’t know of an open source license that explicitly indemnifies you or protects you in any way. So that’s why a vendor’s important. If there is some infringement claim made and they’ve taken in this open source software and used it in an application or used it somewhere in their company, then they are protected.
I think the second myth is similar to what we’ve been talking about. What are the license requirements? Not necessarily restrictions on use but requirements like including acknowledgement of who owns the copyrights or who authored the software. These are the two things that if you’re going to use open source you really must understand: your comfort level with the indemnification issues and a clear understanding of the license.
Another myth is that that if you just use GPL software that somehow you lose your right to intellectual property. And that one also needs to be clarified in the next version of the GPL.
And there are other myths, like that if you’ve made a code change of any type and didn’t distribute that code within an LGPL or GPL licensed product you still need to commit it back to the community. People think that they have to commit back changes under all circumstances and that isn’t true. In some cases you don’t have to. For instance, if you’ve made modifications just for yourself and you’re not distributing the software.
A few years ago we certainly heard a lot more of, “How do we get fixes?” If something was broken they didn’t feel that it could be addressed. Many of these IT departments don’t have the access to the community. They don’t have any way to get a hold of them and say, “Hey, help me fix this problem.” That’s less of an issue today.
Another thing that we used to have to protect a lot more against was the potential introduction of viruses. You know, big companies would look at open source technology and say, “It seems a lot more risky.” Because the source code is available to anybody so some hacker could write a virus and stick it inside the source code… We don’t hear that one as much, but it’s still out there.
And then of course there is the myth that open source has no quality control. I think that the last few years have shown that’s not true. Apache clearly is more secure, more reliable than Microsoft’s own web server, or Netscape’s web server. Why else are 78% of the web servers out there running Apache? As far as quality control and quality assurance or QA testing, it’s something that a vendor like Covalent provides on top of the community. But the community does a pretty good job, honestly. They do a good job with basic testing because the people who develop that code are very proud of what they’ve written. They really care about what it is that’s being used by the world and their community, and their cohorts in the community pay attention. When they see something wrong with a piece of code, they’re not going to be shy about saying you just developed or delivered a bad piece of code.



Is licensing really chooseable? Most of the time IT doesn't have an alternative and so much is in GPL the it must be accepted.


2 Comments

alexfarran
2005-07-13 07:53:22
The other side of the coin.
It's not surprising that businesses like other people's software to be BSD licensed. I'm sure they're less enthusiastic about releasing their own software under the BSD license. The competition could improve it and beat them with their own product. Under the GPL that can't happen. I think that's fairer.



markbrewer
2005-07-14 10:33:38
The other side of the coin.
While I share your assessment that the GPL prevents software companies from improving code and keeping it for themselves. However, history certainly hasn't proven that software companies don't contribute their code and enhancements under the BSD license. Not only has Covalent made numerous contributions and enhancements to Apache projects, but look at IBM's donation of Cloudscape (Derby) and BEA's contribution and commitment to Beehive.