Drink OSS Responsibly

Here in DSI, we use a lot of great Open Source Software libraries and tools. Choosing the right ones, and aligning them with our development approaches, helps to boost our productivity and quality. The same realisation has spurred just about every other software development company on the planet, and as a result OSS has really brewed up a storm. But now that the initial euphoria has passed, it’s time to stop and take stock of the situation. There’s another storm brewing, and it’s going to do a lot of damage to those who don’t see it coming.

As has happened so many times in the recent past, innovations that have promised to create ‘a new paradigm’, in the end have had to settle for finding their own place within the pre-existing order. It’s been true for the economy , for Agile Development and for Web 2.0. It’s especially true in business. The fundamentals of the market economy aren’t being re-architected – at most, localized sectors undergo some gentle refactoring from time to time (The economist John Kenneth Galbraith is quoted as saying “When you see a reference to a new paradigm, you should always, under all circumstances, take cover”). The widespread adoption of OSS shook things up for a while, and led to the inevitable declaration of a new era in the software development business. Glasses were clinked, party-streamers were popped, and of course the poor photocopier diligently reproduced the contours of many’s the backside.

I can’t drink two beers without feeling terrible the next day (I know! What kind of an Irishman am I!?) – I have known this for a long time now. But it sometimes happens that when I party with guys who can hold their beer, I forget how poorly I hold mine. Naturally, I live to regret it the next day. The same kind of accidental overshoot is happening with regard to OSS licensing now. A lot of companies are waking up on the office floor, picking up last nights empty bottles and reading the small print on the back. It contains WHAT!!!???

What’s your poison?

Try this out at home: Take a look at the OSS bottles on your shelf right now. If you are really unlucky, it’ll have the following label written on the back:

This product contains GPL. Not to be taken internally. May lead to serious litigation.

Even if you are not using GPL libraries, you will still find a clause similar to the following in your OSS license:

This product is provided without any guarantees that it will ever work.

It might be dressed up nicer than that, but that’s what it boils down to.

Try the following thought experiment. You’re in your office, with your feet up on the desk. In your left hand, you have a copy of the warranty that you supply to your customers. In your right, you have a bottle of the OSS sauce that you’ve been using as an ingredient in your software – the one that comes with no guarantees. Now imagine that your customer walks in and asks asks “What have you got there?”

You want to be able to say to your customer that you know what you are doing. That you can handle this stuff and still develop great software. If you can’t back up the claim with proof, it’s going to sound awfully hollow.

First things first. You need to know what you’re using. Then you need to decide whether you’re prepared to keep using it, by developing an OSS policy. Then you need to police that policy by making license-checking an integral part of your build system.

Let me just stop here for a moment and make a Public Service Announcement:

You need to manage your use of OSS. You need to do it soon. It’s going to get worse the longer you wait. You need to put somebody you trust in charge of this task (probably yourself). It will be painful, expensive and thankless, but if you ignore this problem, you will regret it.

There. I’ve been waffling on about hangovers, and warranties and build systems, and I was afraid that the central message of this blog might be getting lost. Whatever else you get out of this blog entry, remember that the topic of OSS licensing concerns you.

In a previous entry, I’ve described how we needed to tame Maven, and then harness its build life-cycle to help check the correctness of our builds. The principal reason behind our need to maintain our own Maven repositories and lock them down, was our concern over accidentally ingesting a GPL, or similar, license. The cost involved in putting that build system together was significant, and the ongoing cost of maintaining and auditing those repositories will be significant as well. Despite all this, we’re still using OSS. Why? Because the cost-benefit analysis still works out. There are just too many excellent OSS frameworks out there to ignore – and some of them are simply better than any closed source alternative, assuming one exists. But again, the message is clear. Nothing is new under the sun. Nothing comes without a price tag attached. The price of ‘free’ software, like freedom itself, is eternal vigilance.

, , , ,

  1. #1 by Walter Higgins on December 8, 2008 - 11:46 am

    Taking the hangover analogy further, you could say using public repositories for maven is like drinking from a party punchbowl … that’s been spiked with LSD. Your build will get really introspective, spend hours focused on the innards of some obscure jar, then fail for no apparent reason.

  2. #2 by Brendan Lawlor on December 8, 2008 - 5:47 pm


    This is turning into quite the seasonal theme, isn’t it!?

  1. GPL Round 1: FSF vs Cisco at DeCare Systems Ireland Blog

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: