Heartbleed, an Apache License Business Model Failure?
The ancient Romans brought us many ingenious inventions. The Roman civilization had the potential to start an industrial revolution, but eventually this revolution never happened. What went wrong? One of the important inhibiting factors was the existence of slavery: why invent machines when a free source of work force is ubiquitous?
Heartbleed, a tale of two errors
The two year old HeartBleed bug that was recently discovered in OpenSSL and that affects millions of internet users, reveals a similar problem that could have a serious impact on the way we look at open source software.
Companies such as Cisco have built expensive applications on top of OpenSSL. Security consultants have been paid good money to guarantee that OpenSSL was safe. But the OpenSSL project itself was driven by a core of only four unpaid volunteers.
The German engineer Robin Seggelmann is now taking the blame for the error. His code was verified by Dr. Stephen Henson who overlooked the bug. It would be unfair to blame these two individuals for the problems caused by Heartbleed. They made two mistakes. The second mistake was a minor error in their code. Although this error took huge proportions, they should be forgiven for that error. Their first mistake was their choice to make their code available under the Apache Software License. That mistake is more problematic.
What is at the root of the Heartbleed problem?
Security has always been one of the "unique selling propositions" for open source software versus closed source software. Software is written by humans, and humans make errors, therefore errors in software are inevitable, regardless of whether the source code is open or closed. However, by making the source code available to anyone who wants to read it, there is the implicit expectation that errors will be detected and corrected before those bugs can do any damage.
Linus' Law, named after Linus Thorvalds, the developer of the Linux kernel, states: "given enough eyeballs, all bugs are shallow." That law has now failed: despite the many hands that were using OpenSSL, the code was viewed by only two pairs of eyes.
In his statement, Seggelmann says that OpenSSL has never received substantial support:
"Unfortunately, despite very wide distribution and use by millions of users, OpenSSL does not have adequate support. In spite of its many users, there are very few who actively participate in the project."
This is confirmed on several blogs:
"this team has a reported budget for all of their work of less than a million dollars, and through the course of this week —which you'd think would be a fairly important week for them— they have received $841 of donations. Which is sad. There's a section on the site here that says, if you give more than, I think, it's $20,000, we'll put your logo on our home page. There are no logos. No-one is giving these guys money."
For the exact numbers, read Of Money, Responsibility, and Pride. If you don't feel sad after reading this testimony, there might be something wrong with you.
The average executive in the IT industry (the Joe Six-pack CTO) might wonder: "How is it possible that large companies aren't pumping more money into such a crucial piece of software?" Unfortunately, it's the same Joe Six-pack who keeps on saying: "Why would we ever pay for our use of open source software? Isn't open source free as in free beer?"
No, it isn't. Somebody has to feed the fish!
Using Open Source and contributing nothing in return is unwise. Supporting your open source communities isn’t charity, it’s good business.
If you're not supporting open source, you shouldn't expect anyone else doing it!
Do you need to pay for open source software?
Whether or not open source software can be used without paying a fee, depends entirely on the open source license that was chosen by the developers of the software. OpenSSL was released under the Apache Software License (ASL). This is a very permissive license. It allows anyone to use the software in a commercial context without any substantial restrictions or obligations. I often refer to the ASL as the Apache Slavery License, because it's as easy for third parties to make money using Apache software as it is difficult for the original developer to make a living writing the very same software. In my opinion, there's something inherently wrong with the ASL. The ASL doesn't feel honest.
Developers who consciously choose the Apache license usually don't do so out of common sense; they choose the ASL because of the propaganda distributed by the Apache Software Foundation. While the original ideals of this foundation are noble, corporate cynicism has made many of these ideals moot: "Why would we ever pay for software if we can obtain it for free?" But who will write new software if nobody pays for it?
A couple of weeks ago, I attended the Open Source Think Tank. A famous multinational corporation sent a record number of attendees (5) to the conference and almost all of them were legal people. I overheard a conversation of these five attendees where one person told the other one: "You could be considered being an engineer." To which this person replied with indignation: "I'm most certainly not!" It's as if engineers belong to a lower caste. Is this what happens when software isn't merely considered to be free, but also for free?
Experience has taught me that the AGPL provides a much better service as far as open source ideals are concerned. Unfortunately, people using the AGPL often get the cold shoulder in the open source world.
I started my own open source project in 2000: iText. iText was initially available under a permissive license (LGPL/MPL). After years of hard work, iText was used by Google, IBM, Amazon, HP, and many other companies, great and small. In spite of this "success", I didn't make money with iText at that time. Maintaining the project was hell because I had to combine it with my day job and I didn't have any resources to invest in further development. I feel the pain of the OpenSSL developer. I've been there before. I can assure you: it wasn't fun.
In 2009, I changed the iText license to the AGPL. The AGPL license is often called a "viral" license: most of the software that touches AGPL'ed software should also be released as AGPL software too. This makes it virtually impossible to use AGPL software in a commercial context.
iText was used by many companies to create value, but when I changed the license to the AGPL, I was blamed for every possible sin in the world. Rumors were spread that iText was no longer free software. That's complete and utter nonsense. The AGPL increases freedom in the sense that software using iText now also has to be free.
People also claimed that you can't use iText in commercial applications anymore. That is also untrue: if you want to use iText in a commercial context, you can do so, provided that you purchase a commercial license.
If you want something for free, offer your own software for free. If you don't want to offer your software for free, purchase a license for your use of other software. It's as simple as that!
Why is having a business model important?
Five years ago, iText was maintained by less than a handful of developers who "tinkered" the software after their regular working hours. Fortunately, these days are now behind us. Thanks to customers such as HP, IBM, Xerox, and many others, we can now recruit developers to work on the software full-time. The source code is still open, but as opposed to projects based on the Apache Software License, there is a business model in place that creates jobs and that allows us to allocate resources for continuous innovation.
The Heartbleed incident is bad for open source:
- Network World: Who's to blame for 'catastrophic' Heartbleed Bug?
- PC World: Is open source to blame for the Heartbleed bug?
- The Register: OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts
- Net Security: The effect of the Heartbleed bug on open source projects
- ...
My own heart bleeds when I read these articles, because I've spent 15 years on open source and I'm really passionate about it.
Please let's keep software open and free, but let's abandon the idea that software is gratis once and for all. When developers aren't compensated for their work and therefore don't have sufficient resources to put in place a quality assurance system, you inevitably create Heartbleed disasters. Open source can be used to create value, but that will only work if you also sustain that value.
I can already predict how third parties will try to recuperate the damage caused by Heartbleed. They'll cry for more financial support for software foundations, more money for security consultants, more audits by third parties,... But who will plead for the developers? Who will defend engineers when they are frowned upon as if they belong to a lower caste? Dear colleagues, let's not beat ourselves up. Let's emancipate and take charge!
I've said it before and I'll say it again: Good engineers build great technology; great engineers also create a sustainable business model. Based on my 15 years of experience in open source, I know that it's almost impossible to create a sustainable business model based on the Apache Software License. Just like slavery was at the root of the rise as well as the decline of the Roman Empire, the ASL is at the root of the rise of open source, but it could also turn out to be the cause of its decline.
Maybe I'm exaggerating. I admit that this rant is inspired by the way I've been treated by a couple of Apache Software die-hards in the past. But please consider my conclusion: stay away from any open source project that isn't supported by a healthy business model. When creating value, also think about sustaining value. Sustaining value means that you invest in the tools you use, for instance by paying for your use of open source software.
Author Bio
Bruno Lowagie is the original developer of iText, an open source PDF library first released in 2000. He's also the author of the “iText in Action” books, published by Manning Publications. Together with his wife, he founded iText Group (2008), a company with subsidiaries in the US (2009), Belgium (2011), and Singapore (2015). The couple grew the business from start-up to exit. He wrote a book about his journey as an open source developer and entrepreneur: “Entreprenerd: Building a Multi-Million-Dollar Business with Open Source Software.” Today, Bruno and his wife invest in Belgian technology start-up companies. [More...]
- Tags:
- AGPL license
- Apache Software Foundation. Apache Software License (ASL)
- Bruno Lowagie
- closed source software
- dual-license open source business model
- Heartbleed bug
- iText
- iText Group
- LGPL
- Linus Thorvalds
- Linus' Law
- MPL
- open source business models
- open source software (OSS)
- Open Source Think Tank
- OpenSSL
- permissive licenses
- Robin Seggelmann
- Roman Empire
- Stephen Henson
- sustainable business models
- viral licenses
- Login to post comments
Comments
Panhandling is not a sustainable open source business model
This is one of the best articles we have come across that addresses the fundamental issues of the Heartbleed OpenSSL bug. Another article is Stop laying the blame for Heartbleed on open source by Simon Phipps. Bruno Lowagie is correct in that the core problem is that the OpenSSL project did not have a sustainable open source business model. Therefore it could not fund the required engineering work to ensure that all bugs were found and cleaned up. He is very harsh on the Apache License. We disgree on that part of his analysis. There are tens of thousands of successful open source projects using the Apache License. Open source licenses are like tools. The fist question has to be: What is the sustainable business model for thsi project? And then adopt the open source license that supports that business model.
We are reprinting Lowagie's blog post in Open Health News as this is a critical issue that has to be addressed by all open health software projects in particular. This is an area where the lives of people are depended on the software. Thus it is incumbent on all open health project to make sure that the software is properly maintained and works as expected. That requires funding, which requites a sustainable business models for the projects. And for those that use and benefit from open health solutions, we agree with Lowagie's point "Sustaining value means that you invest in the tools you use, for instance by paying for your use of open source software."
Roger A. Maduro, Publisher and Editor-in-Chief, Open Health News.