Information Security News: Some thoughts on the mod_security acquisition

[InfoSec News <alerts () infosecnews org>]

http://www.regdeveloper.co.uk/2006/12/12/open_source_mod_security_acquisition/

By Nick Kew
12th December 2006

Column - First, a public service announcement. The next European 
ApacheCon event will be held in Amsterdam, in the first week of May. The 
Call for Papers is now open at http://apachecon.com/. There will be a US 
ApacheCon in November. Now to the column.

Many products are moving from commercial closed-source to open or 
part-open source. This article looks at a product that has moved from 
classic open source to more overtly commercial, while remaining open 
source. In doing so, we look at the licensing nuances that affect its 
use both as an open source and a commercial product.

On September 25, Breach Security Inc. acquired Thinking Stone Ltd. In 
practical terms, this means it acquired mod_security, the application 
firewall/protection module for Apache. Ivan Ristic, the man behind 
mod_security, takes up a senior position with his new masters.

This is almost certainly good news for the people concerned. Breach gets 
the asset. Ristic gets far more robust resources backing him, and (we 
presume) due reward for his work. Breach's greater resources should also 
be good news for those users who want a commercially-supported product. 
But is it also good news for the open source world?

mod_security has always been open source, licensed under the GNU General 
Public License (GPL). The announcement tells us that mod_security will 
continue as open source, and will be joined by related products, both 
open source and commercial. This includes the core ruleset, without 
which (in the absence of an alternative, such as an expensive support 
contract), an application firewall like mod_security does nothing.

Among the related products that may materialise is a commercial 
ModSecurity Pro. That open the possibility, in principle at least, that 
developer effort could shift away from the open source module, leaving 
it orphaned. I don't believe that's likely to happen: even if good 
intentions get overtaken by events, it's hardly going to be in Breach's 
interest to abandon the market where mod_security is strongest.

A professional product can easily distinguish itself by building 
non-core features (like for example a classy GUI, and higher-level 
reporting options for management) onto the open source product. Besides, 
Ristic has assured us of the future of mod_security in a couple of 
interviews published since the takeover (here, for example).

But suppose, in a parallel universe somewhere, Breach was to abandon the 
open source module and concentrate exclusively on the commercial. What 
might happen to it? It could share the fate of an abandoned 
closed-source product, and languish unmaintained until it dies of 
obsolescence. Or someone entirely different could take over, and 
continue to maintain and support it. Since it's a popular product, that 
would be almost certain to happen. Some of its users would be happy to 
pay to make it happen, and thank their foresight in using an open source 
product that made it possible to guarantee continued maintenance!

But back in this world, where we assume it will continue to be 
maintained by Breach, nearly the same thing could happen. That is to 
say, someone entirely different can take mod_security, fork a new and 
improved product, support it commercially, and derive other products 
from it, all in direct competition with Breach. That of course is one of 
the most commonly-cited reasons for companies to keep source code 
secret.

Should Breach worry about competition with mod_security? Its current 
competition is from vendors of closed-source commercial products, and 
mod_security has a bigger market share than any of them. A mod_security 
competitor in the marketplace would need both technical competence and 
commercial credibility, which puts up a significant barrier to entry. 
And there's a further barrier to hostile competition: the GPL.

When the competitor ships mod_security with the killer improvements to 
overshadow Breach, they are bound by its terms to release their source 
code. So Breach, too, benefits from this competition. Breach has 
acquired not only Ristic's expertise and credibility, but also a 
monopoly right to distribute a closed-source derivative product such as 
a Pro version, should they choose to do so. If mod_security was under 
the Apache license instead, that monopoly wouldn't exist.

Now to what may become a real dilemma. I am contemplating a new module 
to help web applications. Its main function is to sanitise inputs in the 
manner of Perl's taint checking, to help protect them from attack. If I 
write that, I'll be moving onto territory very close to mod_security, 
and could probably benefit by re-using some of its code. Or even build 
what I have in mind into mod_security itself: much of it is already 
there. That's the great advantage of open source.

But there's also a downside: if I reuse mod_security, then my module 
itself comes under the GPL, and that decision is out of my hands. OK, 
that's fine: I like the GPL, and apply it to many of my own Apache 
modules, too. But in this case, I'd like to keep open the option of 
incorporating the new module into the core Apache distribution.

Since the GPL is not compatible with Apache licensing, I'm faced with an 
either/or choice: write it from scratch, or give up the option of 
incorporating it into Apache. Such is the fragmentation among open 
source licenses! [Readers might like to check out the list of almost 60 
open source licences here- Ed]

This echoes Apache's experience when we introduced the DBD framework for 
SQL support. The existing libdbi has been used in third-party Apache 
modules in the past, and though not an ideal fit, could have been a 
candidate for implementing what is now the apr_dbd layer. But its 
licensing terms (LGPL) prevented that happening within Apache, so that 
was not an option. For the same reason, the MySQL driver for Apache DBD 
remains outside Apache; the problem here is that MySQL is GPL-licensed, 
which imposes restrictions that are not compatible with ASF policies.

In summary, I think the answer to my question is yes, the takeover of 
mod_security is good news for open source. Our expectation is that we 
lose nothing, and may even gain something. But it's not necessarily an 
unqualified yes, as there are now limits to how we can reuse 
mod_security code.


_____________________________
Subscribe to InfoSec News
http://www.infosecnews.org/mailman/listinfo/isn