Sometimes open source ideals make for the strangest–and most wonderful–bedfellows. We met Dr. Vandana Shiva–physicist, scientist, environmentalist, and activist–several years ago. Her work saving seeds and protecting traditional knowledge in the farming industry parallels the openness, transparency, collaboration and freedom of open source ideology. Her simple, clear explanation of why knowledge should be shared–and the devastating results should it be hoarded–is part of the essential truth that makes the work we do so incredibly important. But don’t take our word for it.

Get more information about Dr. Shiva’s work.

Red Hat® Enterprise Linux® 4 was released on February 15th, 2005. This report takes a look at the state of security for the first four years from release. We look at key metrics, specific vulnerabilities, and the most common ways users were affected by security issues. We will show some best practices that could have been used to minimise the impact of the issues, and also take a look at how the included security innovations helped.

This report is an update to the three-year risk report published in Red Hat Magazine in February 2007.

1. Introduction

2. Vulnerabilities

2.1. Vulnerability Counts

2.2. Critical Flaws

2.3. Expanding “days of risk”

2.4. Riskiest packages

2.5. Advisory Workload

3. Threats

3.1. Exploits

3.1.1. Kernel exploits

3.1.2. Browser exploits

3.1.3. Other user-complicit exploits

3.1.4. PHP exploits

3.1.4. Servers and services exploits

3.2. Worms

4. Conclusion

5. Further Reading

6. About the Author

1. Introduction

We measure the overall risk of running Enterprise Linux 4 as a function of two factors; the vulnerabilities and the threats. Our first section covers the security vulnerabilities found in packages that are part of Enterprise Linux 4 and the advisories that address them. Our second section covers the threats by examining actual exploitation of those vulnerabilities through exploits and worms.

All the data used to generate this report, tables, and graphs, apply to Red Hat Enterprise Linux 4 AS from release day, 15 February 2005 to 14 February 2009 unless otherwise stated.

2. Vulnerabilities

At first sight it may appear that Red Hat have released a lot of updates for Enterprise Linux 4; in the last twelve months publishing a total of 107 security advisories to address 251 individual vulnerabilities. But in reality this is by far a worst-case metric, as it treats all vulnerabilities as equal, regardless of their severity and assumes a system that has installed every available package – which is not a default or even a likely installation.

With the release of Enterprise Linux 4, we started publishing severity levels with package errata to help users determine which advisories were the ones that mattered the most. Providing a prioritised risk assessment helps customers to understand and better schedule upgrades to their systems, being able to make a more informed decision on the risk that each issue places on their unique environment. Red Hat rates the impact of individual vulnerabilities on a four-point scale designed to be an at-a-glance guide to how worried Red Hat is about each security issue.

2.1. Vulnerability Counts

There are four variants of Red Hat Enterprise Linux 4; two targeted at server solutions with Enterprise Linux AS and ES, and two targeted at client solutions with Enterprise Linux WS and Red Hat Desktop. The package set available in Enterprise Linux WS and Red Hat Desktop is a subset of that available in Enterprise Linux AS.

During Enterprise Linux 4 installation, the user gets a choice of installing either the default selection of packages, or making a custom selection. Table 2 shows the vulnerability counts, normalised by CVE name, for some selected configurations.

A default install of Enterprise Linux 4 AS was only vulnerable to ten critical flaws in the whole four years. This is because most of the critical flaws have been in web browsers and their plug-ins: Firefox and Mozilla/SeaMonkey packages are not installed by default on distributions intended for server systems.

Client systems (Enterprise Linux WS and Red Hat Desktop) do include Firefox, Mozilla, and Helixplayer by default, leading to 126 critical vulnerabilities. A custom installation of AS, selecting every available package, would yield a system affected by the maximum possible number of critical vulnerabilities for the four years, 130.

For the purposes of this study we consider the worst-case scenario, a version of Red Hat Enterprise Linux 4 obtained on the day of release. During the first four years, six Update releases were made (Update 1 in June 2005, Update 2 in October 2005, Update 3 in March 2006, Update 4 in August 2006, Update 5 in May 2007, Update 6 in November 2007, Update 7 in July 2008). The Update releases are similar to a “service pack” and contain a roll-up of all security advisories. So, for example, a user who installed Enterprise Linux 4 in August 2008 would use Update 7 and be affected by only a subset of the issues. We’ve also counted vulnerabilities not advisories; it’s usual for a single security update of a package to fix a number of vulnerabilities at the same time, so the number of advisories and updates needed to be installed is far lower.

Tip

You can cut down the number of security issues you need to deal with by carefully choosing the right Enterprise Linux variant and package set when deploying a new system, and ensuring you install the latest
available Update release.

2.2. Critical Flaws

Vulnerabilities rated critical severity are the ones that can pose the most risk to an organisation. By definition, a critical vulnerability is one that could potentially be exploited remotely and automatically by a worm. However we also stretch the definition to include those flaws that affect web browsers or plug-ins where a user only needs to visit a malicious (or compromised) web site in order to be exploited. Since the vast majority of critical severity issues occurred due to web browsers or plugins, this is why there is such a difference between the number of critical issues that affects a default install of Enterprise Linux 4 AS and WS.

For the purposes of the severity classification we ignore what privileges the attacker would be able to gain: a remote root compromise via something like Samba would be of a much higher risk than a user-complicit Firefox flaw that results in running code as an unprivileged user, but both would be rated as critical on this scale.

To help qualify the risk we’ve split up the critical vulnerabilities into those that require some minimal user interaction to be exploitable (such as if a user visits malicious web page), and those that require no user interaction at all (and therefore could potentially be exploited by a worm).

For Enterprise Linux 4 AS with every package installed, Table 3 summarises all critical issues, and Table 4 breaks out the critical, non-browser flaws.

We’ve included in these tables the “days of risk” metric. This is commonly defined as the number of calendar days it takes for a vendor to produce updates that correct a flaw after the flaw is first known to the public.

Fixes for 87% of critical flaws were available from Red Hat Network the same day or next calendar day after public disclosure of the flaw. This fast response time is a deliberate goal of the Red Hat Security Response Team and forms an essential part of reducing customer risk from critical flaws.

2.3. Expanding “days of risk”

The “days of risk” metric has it’s limitations and so it isn’t particularly useful for comparing different software vendors against each other. The software that makes up the Enterprise Linux 4 distribution is open source, so we’re not the only vendor shipping each particular application. Unlike companies shipping proprietary software, Red Hat is not in sole control over the date each flaw is made public. This is actually a good thing and leads to much shorter response times between flaws being first reported to being made public. It also keeps us honest; Red Hat can’t play games to artificially reduce our #8220;days of risk” statistics by using tactics such as holding off public disclosure of important flaws for a long period, or until some regularly scheduled patch day.

A more useful metric to help assess risk would also take into account the amount of time that each issue was known to the vendor in advance. As part of our security measurement work since Enterprise Linux 4 we’ve been tracking how the Red Hat Security Response Team first found out about each vulnerability we fix. This information is interesting as it can also show us which relationships matter the most to us, and identify trends in vulnerability disclosure.

For each of the 1269 total vulnerabilities, across every package in Enterprise Linux in the 4 years, we determined if the flaw was something we knew about a day or more in advance of it being publicly disclosed, and how we found out ^[1] about the flaw. The results are summarised in Figure 2 and Figure 3.

Red Hat knew about 51% of the security vulnerabilities that we fixed at least a day in advance of them being publicly disclosed. For those issues, the average notice was 21 calendar days, although the median was much lower, with half the private issues having advance notice of 9 days or less. Figure 4 shows the distribution of notice periods in more detail.

2.4. Riskiest packages

In our work tracking and fixing vulnerabilities it sometimes seems like we produce a security advisory for the same packages every month. We therefore analysed Enterprise Linux 4 to find out which packages were
responsible for the most vulnerabilities, weighting them ^[2] to take into account their severity. The results are shown in Table 5, which lists the top 10, ranked across all four years.

These top 10 packages together totaled 79% of all the weighted vulnerabilities. The kernel, cups, php, krb5, and samba packages are part of the default installation of Enterprise Linux 4 AS.

Tip

You can reduce the number of vulnerabilities that will affect your systems by removing packages that you don’t need or don’t use, particularly those that have the worst security history. For example, if you don’t use thunderbird on a machine you could just remove the package.

2.5. Advisory Workload

In previous reports we’ve graphed the vulnerability workload, a measure of the number of vulnerabilities that security operations staff would need to worry about every day, weighted by severity. But the actual effort in maintaining an Enterprise Linux system is more related to the number of advisories we released, rather than the number of vulnerabilities: A single Firefox advisory may fix ten different issues of critical severity, but takes far less total effort to manage than ten separate advisories each fixing one critical Samba vulnerability.

Our Advisory Workload index gives a measure of the number of important advisories that users would need to worry about every day. The higher the number, the greater the workload, and the greater the general risk represented by the vulnerabilities addressed. This workload index is calculated in a similar way to the NIST workload index.

For a given month, Advisory Workload = weighted number of advisories ^[3] / days in the month. A workload of 1.0 would mean one important advisory a day.

Figure 5 shows the advisory workload index for a installation of Enterprise Linux 4 including every package. The initial peak during the first month looks surprising, but is easily explained, as the packages for Enterprise Linux 4 had a code freeze a few months prior to release. This led to a backlog of security issues that were fixed with updates on the date of release. The small peak in August 2005 aligns with the release of Update 1, and the other peaks align with Update releases or months during which there were several Firefox and SeaMonkey
updates.

Tip

Cut down on the number of alerts you receive. Register your systems with the Red Hat Network to get customised notifications for security updates for the packages your systems have installed. If you want to see all security updates for every Enterprise Linux version and package, subscribe to enterprise-watch-list mailing list as well.

3. Threats

The first part of this report analysed the total vulnerabilities found affecting Enterprise Linux 4. But to get a better evaluation of platform risk we also need to take into account the threat. This part therefore looks at
exploits and worms written to take advantage of the vulnerabilities.

Red Hat is continually developing technologies to help reduce the risk of security threats, and a number of these were consolidated into Red Hat Enterprise Linux 4. The most significant technologies were SELinux and
Exec-Shield. Exec-Shield is a project which includes support for the No eXecute (NX) memory permission, simulating NX via segment limits, Position Independent Executables (PIE), gcc, and glibc hardening. For more details, a table of the major security technology innovations in Enterprise 4 is available.

3.1. Exploits

An exploit is the way that an attacker makes use of a vulnerability. The Red Hat Security Response Team monitor numerous sources to track which vulnerabilities are being exploited. For this report we compiled a list of the publicly available exploits for the vulnerabilities that affected the first four years of Enterprise Linux 4.

We are interested in those exploits that have the potential to cause remote damage to the confidentiality or integrity of a system and we therefore don’t include exploits for vulnerabilities that are limited to a denial of service (affecting availability). We do, however, include exploits which are labeled “proof of concept”. A proof of concept exploit may only cause a crash or not quite work properly without modification, but in theory the vulnerability could be exploited properly leading to greater consequences. These proof of concept exploits often show techniques that a skilled attacker can turn into a full exploit.

We found exploits for 59 vulnerabilities for the first four years. 24 (40%) of these exploits are for buffer overflow vulnerabilities where in most cases the Exec-Shield technology should help prevent remote exploitation due to protections such as ASLR and enforcement of a non-executable stack.

3.1.1. Kernel exploits

The public exploits for the Linux kernel lead to one of two consequences: either a local unprivileged user can cause the machine to crash, or a local user can gain privileges.

We found exploits for nine vulnerabilities that had the potential to allow an unprivileged user to gain privileges on an unpatched Enterprise Linux 4 system. Of the nine, one required the target system to be using bluetooth drivers (CVE-2005-0750), another was exploitable only on systems with more than one CPU (CVE-2005-0001), one affected only x86_64 architectures (CVE-2007-4573), and one required a writable sgid directory (CVE-2008-4210).

The remainder (CVE-2006-3626, CVE-2006-2451, CVE-2005-0736, CVE-2004-1235, and CVE-2005-0531) could work on any default, unpatched system. Some of those exploits need unpublished source code adjustments in order to work against an Enterprise Linux 4 kernel.

3.1.2. Browser exploits

Around of quarter of the public exploits we found were for flaws in web browsers; and all but three targeted the Mozilla suite (Mozilla, Firefox, Thunderbird). These are detailed in Table 6. For each exploit, any resultant code execution would be limited to being run with the same rights as the user that is running the vulnerable browser. It is best practice to never use a web browser or email client as root. Some of these exploits are also blocked if JavaScript is disabled.

3.1.3. Other user-complicit exploits

The next class of exploits are those we term ‘user-complicit’, in that they need some involvement from the victim to be exploited. Some examples of user involvement would be opening a malicious file with a vulnerable application, or viewing an instant message from an unknown user. Table 7 lists the exploits we discovered that require some user involvement.

3.1.4. PHP exploits

During March 2007 the “Month of PHP bugs” uncovered a number of issues, some of which affected the PHP packages as distributed with Enterprise Linux 4. The PHP interpreter does not offer a reliable sand-boxed security layer (as found in, say, a JVM) in which untrusted scripts can be run, so any script run by the PHP interpreter must be trusted with the privileges of the interpreter itself. Therefore, in analysis of these issues, exploits which relied on an “untrusted local attacker” were not classified as security-sensitive since no trust boundary was crossed.

This leaves us with the exploits shown in Table 8. These exploits rely on the victim having PHP scripts installed that use the vulnerable PHP functions in a particular way or with untrusted data. In each case the default SELinux targeted policy for Apache would restrict what a successful exploit is able to do.

3.1.5. Servers and services exploits

Our final class of exploits are those that affect server applications and services, in Table 9. These are the most serious threats.

Tip

The way to reduce your risk from exploits is to make sure your systems have all applicable security updates installed. The Red Hat Network can help keep track of this.

3.2. Worms

Worms take advantage of vulnerabilities in order to compromise systems, then use the compromised system to seek out other systems to infect. By our definition, any vulnerability that could be exploited in this way would be classed as severity critical. In the first section of this report we listed every vulnerability that was rated as critical severity and showed that only a subset of those vulnerabilities could be actually used by worms. This is because we also class as critical some browser vulnerabilities where a victim has to take action (for example visiting a malicious web page) and therefore are not exploitable by a worm.

Worms affecting Linux platforms have been quite scarce in the last few years, and the anti-virus vendors who track malware recorded only two (although some variants of each exist) during the four year period of this study:

• Linux/MARE was discovered in November 2005 and was a worm that spread by exploiting a flaw in PHP-Nuke. PHP-Nuke is not shipped as part of Red Hat Enterprise Linux.
• Linux/Lupper was also discovered in November 2005 and was a worm designed to exploit CVE-2005-1921, a flaw in the PHP PEAR XML-RPC server package exploitable through a number of third party PHP applications. None of the affected third-party applications were shipped as part of Red Hat Enterprise Linux. Additionally, a PHP update in July 2005 fixed the underlying flaw in PHP. Even users that had not patched were also protected from this worm by the default SELinux configuration.

Without critical vulnerabilities to allow attackers to remotely exploit machines, we saw attackers instead try to focus on exploiting weak configurations. During the period of this study we tracked attempts by attackers to exploit machines with stolen passwords and brute-force password tools. The tools simply looked for internet-accessible SSH services they could connect to, then tried to log in with lots of combinations of common usernames and passwords. Restricting access to SSH remotely, moving the SSH daemon to a different port, and making sure all your users have strong passwords or use key authentication are all useful defenses against this particular attack.

4. Conclusion

The aim of this report was to get a measure of the security risk to users of Red Hat Enterprise Linux 4 during the first four years since release. We’ve shown that although on the surface it looks like Red Hat released a large number of security advisories, many of them do not apply to usual or default installations, and only a very small subset are a high risk. We’ve shown:

• A default installation of Enterprise Linux 4 AS was vulnerable to ten critical security issues over the first four years
• A customised installation of Enterprise Linux 4, selecting every package, would have been vulnerable to 114 critical browser security issues, and 16 in non-browser packages in the four years. 87% of those vulnerabilities had fixes to correct them available from the Red Hat Network within one calendar day of them being known to the public
• Red Hat knew about 51% of security issues affecting the first four years of Enterprise Linux 4 in advance. The average time between Red Hat knowing about an issue and it being made public was 21 days (median 9
  days)
• We found public exploits for 59 vulnerabilities that could have affected a customised full installation, although the majority relied on user interaction or non-default settings. Attempts to use many of the exploits would be caught by standard Enterprise Linux 4 security innovations
• The most likely successful exploits allowed a local unprivileged user to gain root privileges on an unpatched Enterprise Linux 4 machine
• Two worms targeting Linux systems were found during the four years, but both affected third party PHP applications not shipped in Red Hat Enterprise Linux 4. In addition, an update to PHP released over three months before one of the worms was released protected systems that had installed the third party applications

It would be foolish to draw conclusions about the future state of security in Red Hat Enterprise Linux 4 solely on the basis of this analysis of the past, however what we’ve tried to do is to enumerate the level of vulnerability and threat and hence overall platform risk. Red Hat treats vulnerabilities in our products and services seriously and the policies of the Red Hat Security Response Team are specifically designed to reduce the risk from security vulnerabilities:

• We place an emphasis on providing the fastest possible, highest quality, turnaround for critical vulnerabilities. We have a Security Response Team distributed globally which can draw on significant Engineering and Quality resources to get the things that matter the most fixed quickly
• We release updates for critical and important security issues as soon as possible rather than batching them into monthly or quarterly updates
• We provide transparency in the handling of vulnerabilities, our methods, and our metrics

All of the raw data used to generate the statistics in this report along with some tools to analyse them are available from the Red Hat Security Response Team. We also provide other tools and data that can help security measurement including CVE mappings for all our advisories and OVAL definitions.

5. Further Reading

• What’s new in security for Red Hat Enterprise Linux 4
• Vulnerability Types for Enterprise Linux 4
• Security Features in Red Hat Enterprise Linux and Fedora Core
• SELinux: A New Approach to Secure Systems
• Red Hat Enterprise Linux 4 Security Guide
• Statistics and data from the Security Response Team

6. About the author

Mark J Cox lives in Scotland and is Director of Red Hat Security Response. Over the last 14 years, Mark has developed software and worked on the security teams of some of the most popular open source projects including Apache, mod_ssl, and OpenSSL. Mark is a founding member of the Apache Software Foundation and the OpenSSL project, and a board member of the Mitre CVE project. In his spare time he finds geocaches with his family and occasionally plays music.

Red Hat Enterprise Linux 5.3 was released today, around 8 months since the release of 5.2 in May 2008. So let’s use this opportunity to take a quick look back over the vulnerabilities and security updates we’ve made in that time, specifically for Red Hat Enterprise Linux 5 Server.

The chart below shows the total number of security updates issued for Red Hat Enterprise Linux 5 Server as if you installed 5.2, up to and including the 5.3 release, broken down by severity. I’ve split it into two columns–one for the packages you’d get if you did a default install, and the other if you installed every single package (which is unlikely as it would involve a bit of manual effort to select every one). So, for a given installation, the number of packages and vulnerabilities will probably be somewhere between the two.

For a default install, from the release of 5.2 up to and including 5.3, we shipped 45 advisories to address 127 vulnerabilities. Seven advisories were rated critical, 21 were important, and the remaining 17 were moderate and low.

For all packages, from the release of 5.2 up to and including 5.3, we shipped 61 advisories to address 181 vulnerabilities. Seven advisories were rated critical, 28 were important, and the remaining 26 were moderate and low.

The 7 critical advisories were for just 3 different packages:

1. Five updates to Firefox (July, July, September, November, December) where a malicious web site could potentially run arbitrary code as the user running Firefox. Given the nature of the flaws, ExecShield protections in Red Hat Enterprise Linux 5 should make exploiting these memory flaws harder.

2. An update to Samba (May) where a remote attacker who can connect and send a print request to a Samba server could cause a heap overflow. The Red Hat Security Response Team believes it would be hard to remotely exploit this issue to execute arbitrary code due to the default enabled SELinux targeted policy and the default enabled SELinux memory protection tests. We are not aware of any public exploit for this issue.

3. An update to OpenSSH (August), provided to mitigate an intrusion into certain Red Hat computer systems. The attacker was able to sign a small number of tampered packages, but they were not distributed on the Red Hat Network. We classified this update as critical to ensure any tampered packages would be replaced with official packages.

Although not of critical severity, also of interest during this period were the spoofing attacks on DNS servers. We provided an update to BIND (July) adding source port randomization to help mitigate these attacks.

Updates to correct all of these critical vulnerabilities (as well as migitate the BIND issue) were available via Red Hat Network either the same day or one calendar day after the issues were public.

In fact, for Red Hat Enterprise Linux 5 since release and to date, every critical vulnerability has had an update to address it available from the Red Hat Network either the same day or the next calendar day after the issue was public.

To compare this with the last updates, we need to take into account that the time between each update is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:

Red Hat Enterprise Linux 5 shipped with a number of security technologies designed to make it harder to exploit vulnerabilities and, in some cases, block exploits for certain flaw types completely. For 5.2 to 5.3 there were two flaws blocked that would otherwise have required updates:

1. A double-free flaw in unzip. The glibc pointer checking limited the exploitability of this issue to just a crash of unzip, a client application, which does not
have security implications. No security update was needed.

2. Two format string flaws in c++filt. The format string protection caused these issues to have no security implications. No security update was needed.

This data is interesting to get a feel for the risk of running Enterprise Linux 5 Server, but it isn’t really useful for comparisons with other versions, distributions, or operating systems. For example, a default install of Red Hat Enterprise Linux 4 AS did not include Firefox, but 5 Server does. You can use our public security measurement data and tools, and run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.

See also: 5.1 to 5.2 risk report

The State of Things is a show produced by North Carolina Public Radio. This week host Frank Stasio interviewed James Boyle, a Duke law professor and co-founder of the Center for the Study of the Public Domain, about his new book The Public Domain. Boyle explains how the public domain is getting smaller and smaller and the ways modern copyright laws are strangling accessibility to 20th century culture.

• Listen to the interview
• Download the book, appropriately being distributed under a Creative Commons BY-NC-SA license

And speaking of Creative Commons, have you taken their non-commercial survey yet? If not, the deadline’s been extended. They want to understand how people feel about the term “noncommercial use.”

• Read the Creative Commons blog post
• Take the survey

With 1.4 billion people connected, the Internet is the greatest collaborative network that mankind has experienced. One of the consequences of the growth of this network is a shift in the way knowledge is being created and distributed. As we move to an interconnected world, the balance of power is shifting from old, proprietary models of knowledge creation to the open source model that emphasizes collaboration and sharing. From management gurus to consulting firms to leading business schools, everyone is taking note of this new phenomenon that goes by various names like ‘Collaborative Innovation,’ ‘Open Innovation,’ or ‘Distributed Co-creation.’

The open source movement has pioneered the Collaborative Innovation trend, and it is no surprise that the rapid growth of the Internet and the equally rapid growth of the open source community have mirrored each other. The Linux® operating system and Wikipedia website are both good examples of open source projects that embody the ideals of Collaborative Innovation. And those in the technology industry aren’t the only ones to take notice. Policy makers and corporate leaders in all markets are exploring how this powerful trend can be harnessed for social and economic development.

Let us take Linux as an example. In September 1991, Linus Torvalds released 10,000 lines of source code under the General Public License (GPL). The GPL gives users four freedoms:

1. The freedom to run the program, for any purpose
2. The freedom to study how the program works, and adapt it to your needs
3. The freedom to redistribute copies so you can help your neighbor
4. The freedom to improve the program, and release your improvements to the public, so that the whole community benefits

Over the years, thousands of volunteers contributed to the code released by Torvalds. It is estimated that Linux now has around 100 million lines of source code and that the commercial value of this source code is approximately eight billion dollars. ^[1] This represents an enormous wealth of knowledge that is freely available.

The innovation that is possible through the efforts of thousands of people collaborating on the Linux source code is a powerful (and constantly growing) advantage for open source software. In the next few years, we may see the pace of innovation in open source outstrip anything that proprietary vendors and their closed group of paid programmers can produce.

Explaining this phenomenon, Tim O’Reilly says that, “Sustained innovation is no longer just about who has the most gifted scientists or the best equipped labs. It’s about who has the most compelling ‘architecture of participation.’”

Henry Chesborough, author of the book Open Innovation explains the contrast between the open and closed innovation models with this chart:

The term “Collaborative Innovation” may be new, but the concept and the practice have been part of Red Hat’s corporate philosophy since the company’s inception. For 15 years, Red Hat has applied this framework to successfully compete with proprietary software vendors who have built multi-billion dollar empires using the closed innovation model. The Fedora® Project is a prime example of Red Hat’s Collaborative Innovation strategy. Red Hat engineers work with the open source community to develop cutting-edge technologies for Fedora. When these innovative technologies mature, they are incorporated into Red Hat® Enterprise Linux.

By working with smart people inside and outside Red Hat, the company is able to create a transparent, cost-efficient model of technology development. Despite having just 2,600 employees, Red Hat has been able to build and provide world-class solutions that are deployed in demanding environments like the New York Stock Exchange and the Federal Aviation Administration as well as large government and private deployments across the world. While Red Hat does not generate all of the code that makes up Red Hat Enterprise Linux, the company is able to create value by providing services, training, and support around open source software. This is no mean feat considering that the primary operating system competitor is a deeply entrenched company that employs more than 50,000 people.

Eager to take full advantage of its possibilities, thought leaders across the world are applying the collaborative innovation model in areas like content (Wikipedia), medicine (Open Source Drug Discovery), scientific publishing (Public Library of Science), flexible copyrights (Creative Commons), and many other areas. Red Hat’s greatest contribution to the Collaborative Innovation movement–so far–has been its success in building a business model around open source software that can be replicated in other fields. With the Internet becoming an integral part of our lives, Collaborative Innovation is set to become one of the most important aspects of our future.

Related links

• Design Thinking, part 1 and part 2

About the author

Venkatesh Hariharan is Corporate Affairs Director at Red Hat and works on open source, open standards, and other policy issues. He is interested in the impact of technology on society. He co-founded IndLinux.org in 1999 and pioneered localization of Linux to Indian languages. He blogs at www.osindia.blogspot.com and his photos are at www.flickr.com/photos/venky7.

John Halamka, CIO of Harvard Medical School and Beth Israel Deaconess Medical Center, was one of the keynote speakers at this summer’s Red Hat Summit. In this video, he explains how open source is critical to the healthcare industry and talks a little about his implanted RFID chip. Learn more about how Beth Israel saved $200,000 and reduced downtime to nearly zero.

It has always been possible to solve the puzzle of Red Hat’s success in the software business. By piecing together Red Hat’s open source ecosystem methodology for their own understanding, many businesses have had an eye on Red Hat in how to organize their open source development practices. The idea of community and enterprise editions, for example, owes a lot to the split of Red Hat Linux into Red Hat Enterprise Linux and the Fedora Project.

Yet, there is a difference in how Red Hat started and grew compared to how some newer companies are running their open source-based business. Many offer closed source and proprietary add on components as part of their enterprise offering. Red Hat has always avoided this practice, striving to ship only 100% open source.

As the Fedora Project has grown, it has continued to pioneer open business practices that complement the open development methodology. The business model of taking the best from Fedora to support for seven years as Enterprise Linux lends itself to absorbing other practices from the Fedora community, ones outside of software. In every area, such as software packaging, documentation, translation, and marketing, Fedora’s open and highly visible work develops methodologies that affect the way Red Hat does business into the future.

It is not good enough to just act in this open, visible way. The open source model gains strength from community growth. The size of the community contributes to the quality of the software. This is in the best interests of everyone, including those who are paying actual staff to work actual hours on free software. Especially those people, as they get a force multiplier from efforts in the community, rather than going the road alone.

If it is a good idea to learn and grow business practices from community influence, wouldn’t the rest of the open source methodology concepts apply? The more pioneers of open business practices who are following an open source methodology, the stronger their work is.

One example of this is in the connection between EPEL, RHX, and ISVs. As the Fedora for ISVs page explains, there are a number of valuable gains to be had. By bringing your open source development work out more in to the community, you gain increased awareness, reduced maintenance burden, and a serious head start on the next version of Red Hat’s supported products.

This week, folks from RHX and Fedora’s Community Architecture teams are going to be at OSCON, talking with open source ISVs about getting their software in to Fedora. A strong point we are making is the chance to absorb and contribute to the open business practices, which are centered around the open source we hold in common, strengthed by all our contributions.

Remember Barton George? If you kept up with our Summit posts, then you’re familiar with Sun’s Linux guy, who was all over Boston blogging, podcasting, and interviewing. He’s back home now, but still putting together podcasts from his trip. Catch the two newest ones: Talking with Zmanda’s CEO, Chander Kant and Chattin’ with The Linux Foundation’s Executive Director, Jim “Led” Zemlin.

Also just in from the Red Hat News blog: One of our legal counsel penned a reader’s guide to the Firestar settlement. Totally worth reading if you’re at all interested in IP, licensing, and–in particular–the defensibility of the GPL.

It’s once again time for you to help us shape our web presence–not just here at Red Hat Magazine, but for the whole of redhat.com. Your opinions. Five minutes. Be heard.

Red Hat is committed to providing you with the information, tools, training, downloads, and contacts you need–fast and at your fingertips. As a part of our efforts to continually improve your online experience, we’d like for you to share your thoughts and opinions with us in a short, five-minute survey. No registration or personal information is required.

>> Take the survey

The information you provide will be used to help us determine:

• The general profile of people using our site
• Which aspects of our websites work well for these users
• Which aspects of our websites need improvement
• What updates we should make to our web properties and how to prioritize them to meet the needs of the users

Thank you for your time.

Authors: James Bessen and Michael J. Meurer
Publisher: Princeton University Press
Publication Date: March 2008

Patent Failure examines the current state of the American patent system based on the way it has traditionally been treated–as a type of property system. Using the yardstick of property rights and the economics they influence, Bessen and Meurer analyze the costs and benefits of patents to innovators. Their qualification: “If the estimated costs of the patent system to an innovator exceed the estimated benefits, then patents fail as property.”

The authors rightly point out that many of the criticisms of the patent system are anecdotal. We’ve all heard about the peanut-butter-and-jelly patent. So what are we to base reforms on then? Patent Failure answers that with empirical evidence, largely economic, but also from history, international comparison, and legal precedent. The book focuses quite a bit (some might say a bit too much) on the claims brought by E-Data, now a decade-old case.

For quite a few years, patents have been lumped in with the completely different systems of trademark and copyright under the title “intellectual property.” And, as the authors point out, the quotation marks have fallen away. Many, if not most, people now assume patents are property. But for certain industries, namely software, patents fail as a property system.

So what should we do?

That “for certain industries” part is a sticky point. I have to admit, it’s easy for me, and I suspect others, to forget that patents can work quite well outside of software. But because that’s where the controversy is, that’s where the media is, and so it’s the failures we hear about. Bessen and Meurer do plenty to build a separation, often making exceptions for chemical and pharmaceutical patents. Those types of patents come much closer to passing the patent-as-property test than software.

The authors then devote chapter 9 to “Abstract Patents and Software,” the entirety of which you can download as a book preview. They point out that “no other technology has experienced anything like the broad industry opposition to software patents that arose during the 1960s.” That is to say, this unprecedented opposition is coming from within the industry the patents ideally help protect. Software developers oppose patents on their own work. You simply cannot draw the same fence around the property lines of software patents the way you would around the property boundaries of the land you own. The authors conclude:

[Software patents] play a central role in the failure of the patent system as a whole. Any serious effort at patent reform must address these problems and the failure to deal with the problems of software patents–either with software-specific measures or general reforms–will likely doom any reform effort.

Like not giving away the end of the movie, I’ll leave it to you to read and form your own opinion of their recommendations that follow that chapter. You can also read excerpts and some interesting discussion about the book on PatentlyO, a patent law blog.

And if you’re interested in hearing more about the authors’ ideas firsthand, Michael Meurer will be presenting a session about Patent Failure at the Red Hat Summit on Thursday, June 19 at 11:30.