Being on the ODBMS train of thought, I checked out a few products that are out there, and something struck me – all of them would be really difficult to bring in to a project. The reason is not technical, but rather one of hassle. All of the products are either proprietary closed-source or GPL dual-licensed. These licensing models actively discourage people from bringing them into the enterprise.
Commercial software is notoriously hard to get approved, and there is generally a long-winded process that has to be followed so that the bean-counters can say “can’t you use an open-source alternative”. GPL dual-licensed stuff is almost as bad! Most of the places I have worked have a blanket ban on GPL software (excluding GNU-type tools which generally sneak under the radar in a server installation). Financial companies in particular are almost paranoid about this. Anything that’s not Apache, or LGPL has to go to the legal department, who will take ages only to eventually say “we’re not comfortable with this”.
Licensing is one of the main reasons I conciously jumped ship from the Microsoft world to Java. I found it really painful to get the most basic library approved for use. Who cares that tool X it would save me a week of development – it cost $50! Then I jumped into Java and it was like a blessing. You need a rules engine? Workflow? Plugins for XML for your IDE? No approval process – no worries! My life became much, much easier. I could just dowload what I required and get on with doing what I needed to do.
There are always exceptions. MySQL springs to mind. The fact that it is standalone made people a bit more comfortable using it without the specter of viral licensing rearing its ugly head. ODBMSes are not like a normal database. They integrate directly into your code and distribution to your server means that they are a core part of your application. I suspect that GPL may be triggered at this point because of the “distribution clause”. I have read the exact opposite on the DB4O forums, which say that server stuff is OK to use under GPL, but distibuting client (desktop) software that uses the ODBMS forces GPL on your application.
Hmm. This is a pretty murky line, and one that I’m not comfortable with. What about if you “distribute” your server software around a cluster? I’ll be happy to put my hands up and just throw this in the “too hard” basket. If I can’t advocate that a piece of software has no legal repercussions on the ultra-proprietary system that I’m writing, I will lose no sleep whatsoever looking somewhere else. I suspect that I’m not the only one. It seems that there is a fine line between external dependency and a core library that is part of the application.
I appreciate why dual-licensing is there, and acknowedge that it’s a valid business model – for certain types of applications. However, you just can’t see it working everywhere. How far would Spring have gone if it was GPL dual-licensed? You only have to look at ExtJS to see how well-received frameworks or libraries are when it becomes too hard to justify their use.
Most large organizations in my experience are more than happy to buy support for LGPL stuff. Once it’s in there, someone wants the reassurance that there will be someone there to bug in case of difficult issues or simply to point the finger at (depending on the company culture). Dual-licensed stuff won’t even get it’s foot in the door – not even a sniff at success. I would really like to use an OO DB in a real-world setting, but it just seems like it would be far easier to get around the hassle of getting it approved if I just used something that’s not quite a 100% fit for the use case. That’s a real shame, and the software engineer in me just sighs deflatedly as the realist wins again in the face of pending deadlines.
Maybe that’s why so many people put up with the object-relational mismatch instead of trying a different approach. In the world I live in, an administrator’s “no” outweighs a technical “yes” every time.
This post is not intended to create FUD, just to outline why uncertainty may be enough to stop someone working with what may otherwise be brilliant stuff.