Some thoughts on the mod_security acquisition

And its consequences for Apache


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.

Nick's book "The Apache Modules Book, Application Development with Apache" is due out in Feb 2007 and can be pre-ordered at the Register Bookshop here. ®


Other stories you might like

  • Prisons transcribe private phone calls with inmates using speech-to-text AI

    Plus: A drug designed by machine learning algorithms to treat liver disease reaches human clinical trials and more

    In brief Prisons around the US are installing AI speech-to-text models to automatically transcribe conversations with inmates during their phone calls.

    A series of contracts and emails from eight different states revealed how Verus, an AI application developed by LEO Technologies and based on a speech-to-text system offered by Amazon, was used to eavesdrop on prisoners’ phone calls.

    In a sales pitch, LEO’s CEO James Sexton told officials working for a jail in Cook County, Illinois, that one of its customers in Calhoun County, Alabama, uses the software to protect prisons from getting sued, according to an investigation by the Thomson Reuters Foundation.

    Continue reading
  • Battlefield 2042: Please don't be the death knell of the franchise, please don't be the death knell of the franchise

    Another terrible launch, but DICE is already working on improvements

    The RPG Greetings, traveller, and welcome back to The Register Plays Games, our monthly gaming column. Since the last edition on New World, we hit level cap and the "endgame". Around this time, item duping exploits became rife and every attempt Amazon Games made to fix it just broke something else. The post-level 60 "watermark" system for gear drops is also infuriating and tedious, but not something we were able to address in the column. So bear these things in mind if you were ever tempted. On that note, it's time to look at another newly released shit show – Battlefield 2042.

    I wanted to love Battlefield 2042, I really did. After the bum note of the first-person shooter (FPS) franchise's return to Second World War theatres with Battlefield V (2018), I stupidly assumed the next entry from EA-owned Swedish developer DICE would be a return to form. I was wrong.

    The multiplayer military FPS market is dominated by two forces: Activision's Call of Duty (COD) series and EA's Battlefield. Fans of each franchise are loyal to the point of zealotry with little crossover between player bases. Here's where I stand: COD jumped the shark with Modern Warfare 2 in 2009. It's flip-flopped from WW2 to present-day combat and back again, tried sci-fi, and even the Battle Royale trend with the free-to-play Call of Duty: Warzone (2020), which has been thoroughly ruined by hackers and developer inaction.

    Continue reading
  • American diplomats' iPhones reportedly compromised by NSO Group intrusion software

    Reuters claims nine State Department employees outside the US had their devices hacked

    The Apple iPhones of at least nine US State Department officials were compromised by an unidentified entity using NSO Group's Pegasus spyware, according to a report published Friday by Reuters.

    NSO Group in an email to The Register said it has blocked an unnamed customers' access to its system upon receiving an inquiry about the incident but has yet to confirm whether its software was involved.

    "Once the inquiry was received, and before any investigation under our compliance policy, we have decided to immediately terminate relevant customers’ access to the system, due to the severity of the allegations," an NSO spokesperson told The Register in an email. "To this point, we haven’t received any information nor the phone numbers, nor any indication that NSO’s tools were used in this case."

    Continue reading

Biting the hand that feeds IT © 1998–2021