The H: With the Apache licence, it's good to have transparent enlightened self-interest...
IR: The GPL, for example; GPL2, wouldn't work. I like GPL2 if you remove the problem of central code ownership. If you remove that, it works, we can see it working for Linux. But it's a chicken and egg situation – someone needs to invest before a community can form, and you have to have enough of a project so that others are interested in it and start to work with it. GPL2 wouldn't do anything about a cloud provider taking a GPL2'd IronBee and putting it into their cloud infrastructure, because without distribution, GPL2 wouldn't be triggered. So we could go to the Affero licence, but the more restrictions you put in place the tougher it gets to maintain the open spirit. So we decided we'd rather risk other companies taking our code and not contributing than restrict our atmosphere and then hindering contributions.
The H: And with the GPL3 and AGPL3, there can also always be the exceptions buried deep in the licence. You can't assume they are automatically identical.
IR: Most people don't actually understand these licences because they are difficult to understand, and you have all these edge cases which are terrible. I wish companies would stay away from controversial moves; if you can keep everything clean and avoid vague situations then the community can actually be confident that they are investing their effort in something that is robust and is not going to fall apart the first time some company decides to sue someone.
The H: Where are you currently with the IronBee code?
IR: I would say about 40% of the code; the goal is to have a fully working production-ready version in Q3, definitely by the end of the year. We went public at the earliest possible time where we felt we had a reasonably good architecture and a decent code base. I wanted to go out and talk to people, I didn't want to finish everything, release it and then say to others "come and join us". I wanted to have the opportunity to spend months discussing this because it is going to take months to get people into this and interested. Also, at this point there's an opportunity for others to influence the architecture, and I think that is very important, because one thing with IronBee is that it is architecture agnostic. We want to embed it in any web server, in any proxy. We want to run it as a reverse proxy itself. It can work as a passive tool or as a command line mode. So the engine itself doesn't care about data acquisition. It just works with modules that will interact with the host, which can be anything, and by having these well defined APIs we are hoping that community members will pick it up. We've had someone come and say "I'm interested in porting IronBee to nginx", and we say "Great", because we don't have the resources ourselves and our hope is many others will come.
The H: Are there any technologies you want to incorporate in IronBee?
IR: We're incorporating the Lua scripting language and the just in time compiler (JIT) as well. So, at one end of the scale we are looking at a simple signature language which will let someone write a rule in half a day, and at the other end of the scale, I want to give those who have the time and the expertise to write any sort of programming logic they need. Many of the problems can't be solved with simple signatures. In a way you have to mimic entire applications to understand their state and to be able to write arbitrary pieces of logic to deal with what's coming to the application, to monitor it all the time, to perform correlation, and you can't really do that with a simple signature range.
We are also looking at byte code, so that as we see IronBee being deployed in many different architectures it is only going to be one per cent of the cases where performance is very important, people running high profile web sites, say. Those people can write in C, which we support, but because of the different infrastructures we want to support compiling to byte code so that you can ship your code to different IronBee installations no matter what infrastructure, and then let the byte code be converted to native code using the just in time compiler, and then it will perform well.
The H: Are you looking at LLVM?
IR: That's what we want to use. We use all the open source projects that fit, so Lua's a good choice for us, and LLVM is a good choice too, which we've had a lot of experience with.
The H: LLVM lets you also compile C to byte code; will you be using that?
IR: Yes, exactly. I think it's very early but the Lua JIT is very robust and very fast, one of the fastest we've come across. Personally, I'm very fond of Java but Java has a problem with memory management; you can't really manage your memory well, and that breaks it for a lot of these systems, which is such a shame. The drawback of having to work in C is you are open to buffer overflows. I see C programming as walking through a minefield. You can do the best job you can possibly do with C, but it doesn't mean you won't make a mis-step.
The H: A common experience; especially with Java, where people would solve problems by throwing more memory at the virtual machines.
IR: Yes, it's tough. I know many people resort to actually restarting their deamons daily to keep it running. If they could fix that one problem, it would make Java really, really good.
The H: That, and some people don't use garbage collection as a safety belt but as something that will catch them leaping off a tall building.
IR: Yes, there are many cases where you can still leak memory as a result of a programming error which cannot be avoided no matter how smart your garbage collector is. I think that also in Java there are some complex class loading issues that create interdependencies which eventually cause these out of memory conditions. It's too much architecture, that's what it is. A lot of people have the tendency to have very layered architectural approaches and because you don't control the entire stack, there's a case of leaky abstractions. That said, Java is still my platform of choice for web applications; it's so much faster to develop in Java and so much more pleasant.
The H: Are you looking forward to Java 7?
IR: What I'm really looking forward to in Java 7 is the SSL update actually, because they will then support TLS 1.2. There's a couple of bugs in the SSL implementation right now that have caused me quite a lot of trouble, and they are fixed in JDK 7. So I'm going to be taking the development version and trying it out.