A Wonderful Discussion
Richard Bejtlich wrote a very complementary review of Geekonomics on Amazon.com:
The future of software is legal
I would like to thank Richard for taking the time and the effort in writing his review. As an author, I am grateful for this. I am especially grateful when those who voice their praise (and reservations) are both thoughtful and meticulous in their choice of words. Richard was exemplary in this respect. I welcome his comments as important additions to the discussion.
Richard noted two aspects of Geekonomics he felt detracted from the book's message:
1) the book fails to adequately differentiate between safety and security; and
2) the chapter on open source demonstrates fundamental misconceptions that unfortunately detract from the author's message.
Indeed these are areas that need more discussion not only to clarify any misunderstandings, but because Richard’s remarks touch on broader aspects that call for deeper discussion regardless. Besides, Richard brings up some good points in his review that deserve time and attention.
There is a lot to talk about in this post, so, as courtesy, you might consider refreshing your beverage and getting comfortable. This is a rather long post, but not unnecessarily so. Also, for readability I’ve divided this post into sections highlighting its more salient points.
- Safety and Security
- The Vulnerability Tax
- Open Source: Binaries Are Not Easy to Read
- Open Source: The Misconception of First-time Innovation
- Open Source: The Threat of Project Foreclosure
- Open Source: Personal Liability
- Conclusion
With that housekeeping out of the way, let’s dig in. I hope you enjoy the discussion.
Safety and Security
Quoting Richard directly from his Amazon post:
Rice believes the governing issue in software security is the need to reduce vulnerability. The problem with this approach is that life is vulnerability. It is simply too difficult to eliminate enough vulnerability in order to reduce risk in the real world. …
Consider now the issue of safety vs security. The author makes comparisons using the London sewer, various aspects of driving, and the New York subway system. Especially in the first two cases, these are exclusively issues of safety, not security. What is the difference? Safety incidents happen because a system fails. Security incidents happen because an intelligent adversary exploits a system. The outcome of the London sewer and driving cases would be much different if the Nazis were bombing the sewer system or Mad Max was shooting at cars or blowing holes in pavement. In short, the author cannot suggest that an approach that works against a safety problem is going to succeed against a security problem. Security problems are more dynamic because the threat perceives, adapts, and returns in ways unexpected by the victim.
Richard makes some very good points. Let’s break this down into bite-sized bits.
First, I do indeed believe software vulnerabilities must be reduced in order to reduce malicious exploitation of those vulnerabilities by adversaries. I believe this for very good reasons which I explain shortly.
Second, I agree that life is vulnerability. I have no argument with this point of view. Life is fragile and I would dare say that each of us understand the truth of this in our bones. Where I take issue is that such a statement does not sufficiently distinguish between vulnerability inherent in existence and vulnerability induced by defect. The first is unavoidable, the second is. It is this second aspect of vulnerability that is the focus of Geekonomics.
What Richard highlights here is what I believe to be an especially pernicious and commonly held misunderstanding in the story of software. To reiterate Richard’s statement, “The outcome of the London sewer and driving cases would be much different if the Nazis were bombing the sewer system or Mad Max was shooting at cars or blowing holes in pavement."
Other security experts have voiced this notion also, including Andy Steingruebl of SecurityRetentive:
“Let’s be clear to distinguish between the different scenarios though[referring to safety and security]. As has been repeatedly pointed out cars are designed to be “safe” under “ordinary” operating conditions. They are not designed to be “safe” from a malicious adversary. A car won’t stop someone from deliberately ramming you in the area of the car most likely to cause personal injury. It won’t be safe if someone cuts the brakes, loosens all the wheel nuts, etc. Heck, it won’t alert you to those situation either”.
Life is fragile. So are the constructs of men. If the Nazi’s were bombing the London sewer system, it would inarguably crumble against the onslaught. If hooligans were smashing windshields and shooting cars, the vehicles would undoubtedly be damaged and, along with it, potentially the passengers. The quality of the sewer system – or the safety of a vehicle – would be moot in such situations. Bombs and crowbars have a tendency to nullify construction quality or safety devices to a certain extent. This is not in question.
But as I call out early in Geekonomics, software fundamentally challenges our analogies. No single analogy serves the discussion of software completely. To quote directly from Geekonomics (page 16):
“Cement is an imperfect analogy for software, but so too is just about everything else, which means analogies used to understand software tend to break quite easily if over-extended…This does not mean that software cannot be understood, simply that significantly more mental effort must be applied to think about software in a certain way, in the right context, and under the relevant assumptions.”
In other words, if the analogy does not "work," we must abandon it and find a new one. Geekonomics is chock full of analogies because of this. The problem with the above quotes is that the sewer system and car analogies were over-extended and were not abandoned. So taking Richard's and Andy's comments at face value, they’re right: The quality of cement in no way applies directly to its ability to withstand a Nazi bombing. An intelligent adversary is indeed difficult to combat. The safety (and quality) of the sewer system are moot when attacked by a Nazi bomb. Build a tougher sewer and the Nazis build a bigger bomb. But let’s apply this same logic to the story of insecure software and see how the analogy is fatefully over-extended.
To apply the analogy of Nazi bombs to the software world means that cyber attackers are capable of creating the equivalent of “software bombs” that allow attackers to arbitrarily “blow up” any targeted software application. This is, in fact, what bombs do. A 500 pound bomb works just as brilliantly against a high-quality, safe car as it does against a carefully designed building, train, ship, or sewer system. A crow bar works just as brilliantly against the windshield of a Lexus as it does against the windshield of a Mercedes. The nice thing about bombs and crowbars in the physical world is that they do not have any versioning issues. But this is not the case in the story of software.
For instance, exploit code such as Code Red (an exploit that targets Microsoft’s web server) does not work against a Linux machine. Why not? Because there is no corresponding weaknesses in the Linux software that allows it to be exploited by Code Red.
In essence, Linux is immune and impervious to Code Red because the Code Red “bomb” does not exploit a Linux manufacturing defect. In order to exploit a Linux vulnerability, an attacker must find a defect in the Linux software that the Linux community failed to discover themselves. Similarly, if the Microsoft web server did not have that particular vulnerability (e.g. Microsoft avoided the defect in the first place), Code Red would not have been built. There is a tight relationship between a software exploit (the “bomb”) and the software vulnerability it exploits.
Subsequently, the construction quality of a London sewer system or a vehicle would matter greatly if the example above were also the case in the physical world. Nazi bombs would only work against manufacturing defects found only in the London sewer system. If the New York sewer system used another form of cement or had different weaknesses, the Nazis would have to build an entirely different bomb to specifically exploit the weaknesses found in the New York sewer system. In either case, it would behoove the cement manufacturers in New York and London to get their cement "right" in the first place. This is an important realization. In the absence of a manufacturing defect, the effectiveness (and impact) of corresponding exploit code (the bomb) all but disappears.
This is critical to understand when discussing software assurance. We do not see exploits (bombs) for a software application that does not have a corresponding vulnerability. If the over-extended "Nazi bombing sewers" analogy were applied to the software world, this would mean a single “software bomb” such as Code Red could be used as effectively against Windows XP as against iTunes, Salesforce.com, or Linux just as a 500lb bomb in the physical world can be used as effectively against an arbitrary car, building, or sewer system.
If such were the case, software would never be “secure” and would always be susceptible to attack no matter software’s level of quality or safety. Cyber attackers could attack any computer system arbitrarily regardless of the existence of software weaknesses. This simply isn’t true in the story of software. Security researchers are looking for vulnerabilities in order to construct bombs that specifically work against a discovered vulnerability.
Let me put this another way: cyber attackers cannot build bombs (exploits) in the absence of a software defect (see side not below). Remove the manufacturing defect, and exploits (of software vulnerabilities) become moot to a large extent. This is, of course, why the information security community so diligently tells people to patch their systems…to remove the defect and thus remove the impact of a possible exploit.
SIDE NOTE: Arguably the closest thing we have in terms of a “software bomb” is network denial-of-service attacks which, in the case of the network, works against any computer system by exhausting network bandwidth (or the capacity of the computer’s network card), but does not necessarily “exploit” the software directly (I’m thinking more in terms of malware infecting a machine. There is plenty of room for discussion here).
To re-quote Richard:
…the author cannot suggest that an approach that works against a safety problem is going to succeed against a security problem.
In fact, that is exactly what I suggest based on the above reasoning. If software were truly like cement, lack of manufacturing defects in software would do nothing to mitigate the impact of bombs. But this is not the case. There is a direct relationship between the vulnerability and “the bomb” in the story of software. Building "safe" software is a monolithic endeavor that includes quality, safety, and security. Getting the stuff right in production matters. The issue is about software assurance, not necessarily information insurance which I believe Richard is alluding to.
Software is attacked. Why? In large part because of preventable manufacturing defects that software manufacturers have little incentive to remove before placing the product into the global stream of commerce. Software manufactures would have us believe that it is sophisticated cyber attackers that are arbitrarily "dropping bombs" on our systems or smashing the wind shields of our computers when, in fact, vulnerabilities in software are specific invitations to exploitation.
The crazy thing of it is, Nazi’s and hooligans are not needed to break our windows in the story of software. Windows are already broken by the manufacturer at the factory; we just don't know how many.
In the absence of a software vulnerability, it is not possible to build a corresponding software bomb (as far as we know). So the intelligence of our adversaries really lies in their ability to discover manufacturing defects that software manufacturers failed to discover themselves and, in the case of phisphing attacks, tricking users into visiting websites containing malware that exploits vulnerabilities in victim's desktop computers.
Does squeezing out all software defects (if this were possible) remove other security concerns surrounding information assurance and the larger issues of security? Of course not. And I do not imply that is does. But I would argue that it helps. Reduce the number of defects, vulnerabilities, weaknesses (whatever you would like to call them) and the risk equation changes substantially, but not totally. Build a better firewall and yes, attackers will attack you with more sophisticated attacks. In comparison, build better software and the incentive to directly attack software diminishes.
Software vulnerabilities communicate a message of disorder into the world of cyberspace. This message promotes greater disorder and invites more serious and more sophisticated forms of crime. As with broken windows, software vulnerabilities are invitations. Unlike broken windows, software vulnerabilities are delivered by the manufacturer, not created by hooligans. This is why I believe software vulnerabilities must be reduced in order to prevent malicious exploitation by adversaries and to reduce more serious forms of crime and espionage.
Vulnerability is a fact of life; it is inherent in existence. But vulnerability induced through preventable manufacturing defects does not have to be.
The Vulnerability Tax
The second (minor) area where Richard over-extends an analogy and does not abandon it regards the vulnerability tax. To quote Richard directly:
Why weren't auto makers taxed for "unsafe" cars? If cars were being bombed on the highway, would auto makers be taxed?
In this case, the analogy of “cars being bombed” does not entirely fit because when I speak of a vulnerability tax, I treat vulnerabilities like pollution – an inevitable part of the manufacturing process and an entirely different analogy.
The pollution analogy helps us to understand that perfect software is not possible (just like pollution free manufacturing is not possible). We can still do something about it, however.
Without a carbon tax, manufactures have little incentive to reduce carbon emissions thus making the global environment worse off. Likewise, without an equivalent tax for software vulnerabilities (or something like it), manufacturers have little incentive to reduce “vulnerability emissions” thus making the environment of cyberspace worse off.
Arguably, the “cars being bombed” analogy is over-extended here: Manufacturing defects in automobiles do not elicit a corresponding bomb or crowbar to attack the defect like it does in software (as discussed at length above). As such, taxation of a manufacturer due to adversaries dropping bombs is nonsensical not because taxation is inherently nonsensical, but because the analogy is over-extended.
But we can rescue the “cars being bombed” analogy to a certain extent. To reiterate the discussion above, without a software defect, a corresponding exploit is almost impossible to build (as we understand it today). How then to discourage bomb building? Tax vulnerabilities to create greater incentive to reduce the number of bombs. Fewer vulnerabilities possibly means fewer incentives to build bombs and the advantages attackers gain by “dropping” them.
One final point needs addressing: Why aren’t auto makers taxed for “unsafe” cars? In fact, they are. The tax is applied when an auto manufacturer chooses to make an unsafe car. How? Car buyers tend to shy away from vehicles with low NHTSA safety ratings, thus making it more expensive for the manufacturer to make an “unsafe” car (which does not sell as well) than to make a “safe” car (which sells very well in comparison). Also, auto makers are not insulated from liability which imposes another tax should they choose to put a defective car into the global stream of commerce.
The “unsafe tax” then, manifests itself in the form of lower sales for vehicles with lower safety ratings or through court-awarded damages. To avoid the “unsafe tax” manufacturers make better quality and safer cars. In fact, nearly 90 percent of all cars in the United States are four or five-star rated. This is a direct consequence of auto manufacturers attempting to avoid the “unsafe tax.”
The problem with software at this point in time is that buyers cannot choose between “safe” and “unsafe” software because there is no safety/security rating. In other words, “good” and “bad” software are indistinguishable by market participants. This makes it relatively inexpensive for software manufactures to flood the market with “bad” software because there is not a corresponding loss in sales as there is for auto-manufactures.
There is much to work out in the vulnerability taxation model. Arguably, while a vulnerability tax seems unworkable now, it does not need remain that way. It requires plenty of (more) discussion to discover what may, in fact, work.
Opens Source: Binary are Not Easy to Read
Richard states the following:
As far as open source goes (ch 6), the author makes several statements which show he does not understand the open source world. First, on p 247 the author states "While a binary is easy for a computer to read, it is tremendously difficult for a person -- even the original developer -- to understand." This is absolutely false, and the misunderstandings continue in the same paragraph. Reverse engineering techniques can determine how binaries operate, even to the point that organizations like the Zeroday Emergency Response Team (ZERT) provide patches for Microsoft vulnerabilities without having access to source code!
Given the target audience of Geekonomics (non-technical, business), I carefully choose to omit discussion of binary decompilation. Richard brings up a good point, though I consider it a technical nuance outside the primary focus of Chapter 6. Let’s talk about it here.
A software binary is not easily read by a human. How do I know? Because a majority of software developers do not know (or need to know) assembly language.
For the benefit of less-technically experienced readers of this blog, computer chips (or microchips) need instructions to do work. These instructions come in the form of operation codes - otherwise known as "op codes" - such as push, pop, add, sub(tract), shift left, shift right, and so on. The sequence of these op-codes is the totality of a shipped software application (a software binary). The microchip executes these instructions and thus accomplishes work.
Once upon a time, the only way to write software was in assembly. More advanced languages like C and C++ (known as 3rd generation languages) allowed developers to write code much more easily and intuitively than does assembly language. A software compiler translates human readable source code into machine-readable instructions, or op codes. As such, direct experience with assembly language is much less common now than “in the old days.”
Does this mean software binaries cannot be read by humans? No. Tools like SoftICE, IDAPro, and others allow us to reverse engineer binaries to figure out what they do. But because we have tools like these does not mean binaries are easily readable by a majority of the populace.
In fact, I would argue, based on my own experience, that if I gave the machine instructions (the op codes) of a given software application to the software developers who wrote the original software application, it might be days before they would recognize these instructions as coming from their own application (even if they knew assembly). Might some developers figure it out quickly? Sure, but many would not, and have not. This is what I meant when I stated, "While a binary is easy for a computer to read, it is tremendously difficult for a person -- even the original developer -- to understand”.
The fact that binaries can be read does not mean it is easily readable for a majority of market participants. Once upon a time @stake tried to write a binary analysis tool to check commercial software for vulnerabilities. The tool, and many like it, are chock full of inconsistencies not because the tool is necessarily bad, but because trying to figure out what a binary actual accomplishes can be quite cumbersome and difficult.
In short, the binary format forestalls the ability to reconstitute op-codes into the original source code thus making binaries much more difficult for a human to understand. This is, of course, why open source promotes the benefits of open source…because it is easier to understand and modify an application with the original source code than by market participants taking the time and effort to reverse-engineer a binary and then byte patch it.
At base, shipping software in binary form is simply a delay tactic on the part of commercial/proprietary software manufacturers. It is an effective tactic nonetheless. Can binaries be reverse-engineered? Certainly. How else do we figure out how malware works or get to play games for free by reversing the registration algorithm (or find vulnerabilities in the first place)?
But it is not necessarily a common skill set because 3rd, 4th, and 5th generation languages have reduced the need to know assembly among a vast majority of developers. It is also a skill that is not easily learned. Even when it is learned, it can be time-consuming and expensive in both time and resources to undertake. And that is really the advantage of shipping binaries for proprietary software manufacturers. If everyone could read assembly language and intuitively understand what it does, well, then, binaries would not be tremendously difficult to read, we would not need higher level languages to increase our productivity, and the advantage of shipping binaries would disappear. But this is not the case.
Open Source: The Misconception of First-time Innovation
Richard comments on first time innovation:
Second, on p 248 the author states "The essence of open source software is the exact opposite of proprietary software. Open source software is largely an innovation after-the-fact; that is, open source software builds upon an idea already in the marketplace that can be easily replicated or copied." On what planet?
On this planet. The following except is from Forbes magazine, quoting Larry McVoy.
The Open Source Heretic.
…Yet after all these years,[Larry] McVoy has come to believe that the open source business model, which is all the rage these days among computer makers like Hewlett-Packard and IBM cannot generate enough money to support the development of truly innovative software programs…McVoy understands open source as well as anyone on the planet…
But McVoy says it is simply not possible for an innovative software company to sustain itself using an open source business model. "The other problem is that the services model doesn't generate enough revenue to support the creation of the next generation of innovative products. Red Hat has been around for a long time--for a decade now. Yet try to name one significant thing--one innovative product--that has come out of Red Hat."
To be sure, a few open source companies are successfully generating revenue and even (possibly) profits. But none of them generates enough money to do anything really innovative, says McVoy, 43, an industry veteran who has developed operating system software at Sun Microsystems, Silicon Graphics and Google.
"The open source guys can scrape together enough resources to reverse engineer stuff. That's easy. It's way cheaper to reverse engineer something than to create something new. But if the world goes to 100% open source, innovation goes to zero. The open source guys hate it when I say this, but it's true."
The viewpoint espoused in Geekonomics is based not on a personal misconception of the open source world, but on recognized criticisms of open source practices by technology members both within and outside the open source community.
Is it possible for open source model to be innovative? Absolutely. Plenty of other articles espouse how the open source model supports all sorts of innovation. Whether open source is a strong first-time innovator in the software world however, is open to debate as McVoy's comments demonstrate.
Regardless, whether open source is a strong first-time innovator or not, open source software exhibits the same tendencies as commercial vendors in releasing preventable defects into the global stream of commerce. This is the issue of greatest concern to me. I would tend to argue that innovators should innovate on this issue, and not on another desktop or operating system variant. But the incentives must be different in order for this to happen.
Open Source: The Threat of Project Foreclosure
The next comment by Richard is:
Third, on p 263 the author states "[O]pen source projects are almost always threatened by foreclosure," meaning if the developer loses interest the users are doomed. That claim totally misses the power of open source. When a proprietary software vendor stops coding a product, the customers are out of luck. When an open source software developer stops coding a product, the customers are NOT out of luck. They can 1) hope someone else continues the project; 2) try continuing the project themselves; or 3) hire someone else to continue developing the product.
I believe I understand what Richard is trying to say here. Open source gives companies options they would otherwise not have with proprietary software vendors. Companies can hope to find another volunteer developer with the same “itch” as the one that abandoned the original project. Also, companies can choose to take on the project themselves or hire someone else to do so. But what if company cannot do any of the above? The fourth option might be:
4) Be grumpy.
The presence of options does not remove the threat of foreclosure. Option 4 is still possible. Foreclosure is always a threat for any endeavor, but perhaps more so in the open source world because of the idiosyncrasies of individual volunteer developers. Of the 130,000 or so projects on SourceForge, only a few hundred are active. That is a lot of foreclosure. Of those projects that are active, profit margins are thin as McVoy calls out in the Forbes article thus questioning the sustainability of any given open source project. The threat of foreclosure is still very real unless the project has a deep-pocketed benefactor. Hope does not necessarily make a good business model for those choosing to use open source software.
But Richard touches a much broader issue that needs addressing. While the argument “we provide life cycle options proprietary vendors do not” sounds reasonable, it is far from economically vibrant.
At bottom, the argument for “the power of open source” is actually an economically backwards model. In other words, the “benefit” of open source software is that everyone is poorer because of it. This is hardly a benefit. This statement may sound incomprehensible at first, but let’s look at the “life cycle options argument” from an economic perspective to understand why the “benefit” of open source, as stated above, perhaps is not.
When a commercial (i.e. proprietary) software manufacturer stops coding a project it is most likely because it no longer makes financial sense to do so. I would argue that companies are not in the habit of killing profitable endeavors arbitrarily, so killing a less-profitable project is necessary to pursue other projects that are more profitable. This behavior is economically efficient. Markets are in the habit of producing what people want, not what they need. Why should a manufacturer put resources into a product for which there is no compelling demand and therefore no potential profits? It may sound heartless, even greedy, but it is one the reasons why we have more products than we can ever imagine and an economy that is robust, deep, and wide.
A failed (or defunct) product is actually good news for the market because resources that were tied up in the old product’s production are now free to be used in other places. This is very important for economic progress. Labor and capital can be moved to more productive pursuits. More liquidity in labor and capital can potentially mean a more responsive market. In general, this is good for consumers. But what about specifically?
Are the buyers of a now-defunct or failed product out of luck?
You bet. But consumers as a whole are better off because now labor and capital is available to make more appealing (and more profitable or more fulfilling) products elsewhere.
Look at it this way, a very important reason why a person can buy a new 2008 Honda Accord is because Honda stopped making 2007 Honda Accords. A very important reason why a person can buy a new DVD player is because some manufacturer somewhere stopped making VHS players. A very important reason why I have an iPod is because Apple stopped making its less profitable products.
Markets respond to demand and forsake less profitable endeavors. This model leads to economic vibrancy for everyone even though individual consumers might appear to be worse off at first.
Based on the "options argument" above, the notion that when an open source software developer stops coding a product the customers are NOT out of luck, is ruinous. Why? Because this practice transforms demand into need, and this makes everyone worse off.
Under the "options argument," instead of abandoning a defunct product, companies are encouraged to bind their labor and capital in less productive pursuits; that is, assigning time and resources into keeping a defunct project alive.
The customer is NOT out of luck precisely because the customer must now find a developer to satisfy their need for a new project leader or developer. Everyone else is worse off precisely because of this. The customer unfortunately picked a project that, for one reason or another, is now defunct. Instead of abandoning the defunct product, the customer must now invest in maintaining a declining status quo (as newer better products come out, status quo inevitably goes down).
Given the incentives model of open source, developers commit to a project to “scratch an itch” or to build "geek cred." When a software developer forgoes pursuing her “itch” it is probably because of a number of factors, one of those factors potentially being that she longer sees any advantage in doing so. Something better came along...she saw demand in another spot, money to be made pursuing something else, or another itch that needed to be scratched, and so the current project is laid to rest. This is the great strength of open source: labor liquidity to the extreme. But as I stated in Geekonomics, it may also be one factor for open source’s undoing. Let’s find out why.
For another software developer to satisfy the customer’s need, its means that this very same replacement developer is not available to satisfy market demand for better, more fulfilling products somewhere else. This robs other more promising software projects of labor as well as robs the market of better products.
When demand is reduced (that is, demand is downgraded into need), every one in the market is worse off because of it. This means products that could be made are not because labor is tied up in a pursuit that is no longer meeting a demand. So the need is met, but to meet the need, something else must be forsaken.
What is that something else? Demand for other things. It’s hard to tell exactly what might be forsaken because we cannot predict the future. But we can guess from past circumstances. If Apple did not forsake its less profitable products, would it have created the iPod? The simplistic answer is “no.”
Think about it this way: A need is a diversion of demand. Demand creates new products; it enriches our lives and expands the economy. Need simply attempts to maintain status quo. There is nothing wrong with need. We all have needs that must be satisfied to one extent or another. But as an economic model, need is far from vibrant and enriching. It is more Soviet than anything else.
Under the “options argument,” thousands of people can keep the software-equivalent of a 1960s Chevy or half-complete kit car on the roadway even though the car is less efficient, less safe, and robs other manufacturers/projects of valuable labor.
So I would tend to argue the “power of open source” is not nearly the benefit the “options argument” suggests. It is good for some companies. This is not in doubt. But it can also potentially rob the market of labor, capital, and future products. As such, everyone is just that much poorer because of it.
So, if a commercial vendor forecloses a project, some consumers are screwed, yes. If an open source project is foreclosed, the adopter might not be screwed, true. But everyone else is. In light of this, life-support for defunct projects should be rightly questioned as a benefit.
I have no issue with the "options argument" when a given open source project is meeting demand largely because options 1, 2, and 3 are moot in such circumstances. New developers must be found to meet the market demand.
In the end, markets make what we want, not what we need. Does this mean we ignore need? No. But it is not a pathway to greater wealth. The power of open source is its ability to aggressively meet new demand through its extreme labor liquidity, not to provide life-support for products in which demand has ebbed.
Open Source: Personal Liability
To close out the open source discussion, Richards’s final comment is:
Finally, if the author is worried about open source projects not having an organization upon which liability could be enforced, he should consider the many vendors who sell open source software.
This is true. The liability argument in Chapter 6 was more focused on personal liability and the comments from the UK story it was pulled from. Indeed, liability can be assigned to open source vendors, as is suggested in Chapter 5.
Conclusion
Wow. That was a long read. I hope it was informative (as well as enjoyable). Richard provided great points for discussion and I’m grateful for his thoughts.
Geekonomics cannot and does not attempt to answer all questions regarding security in general and software assurance in particular, but I agree with Richard, it is powerful that we can have the discussion at all.
