Liability for Cybersecurity Issues with Software Code -- Director Easterly

Jen Easterly recently made a very important speech at Carnegie Mellon University.  Jen is the Director of the U.S. Cybersecurity and Infrastructure Security Agency (CISA).  She is well-liked and known in the technology industry generally and has worked hard to address many of the difficult issues facing the United States concerning cybersecurity.  In her comments, she tackles the thorny issue of the quality of software code that is produced—both private and open-source code.  The creation of increased liability for software manufacturers may be a game-changer.  I’ve pasted her entire speech below because it is that good and worth reading in full.  Here are her comments:

Unsafe at Any CPU Speed:

The Designed-in Dangers of Technology and What We Can Do About It

Good morning. Thank you to President Jahanian for that warm introduction and to everyone for joining me today on this Monday morning. It’s wonderful to start the week off with this incredible community.

I can’t think of a more fitting location for this discussion than Pittsburgh, a city built on innovation, imagination, and technological transformation; and Carnegie Mellon University, one of the world’s most renowned educational institutions, home to one of our nation’s top undergraduate computer science programs and top engineering programs, but also, to so much more. Let me share a few of my own favorites:

• The first smile in an email was created by research Professor Scott Fahlman, which launched the emoticon craze
• CAPTCHAs—or completely automated public Turing tests to tell computers and humans apart— (how many of you knew what that stood for?) were developed here by Professor Luis von Ahn and his colleagues, used to help prevent cybercrime
• Wireless research conducted at CMU laid the foundation for now ubiquitous wi-fi
• CMU is home to the nation’s first robotics lab; and of course, home to the Software Engineering Institute, the first Federal Lab dedicated to software engineering. SEI established the first Computer Emergency Response Team, or CERT, in response to the Morris worm—that became the model for CERTs around the globe, and of course was a key partner in the creation of US-CERT in 2003, the precursor to CISA’s Cybersecurity Division.

But the partnership between CMU and CISA goes well beyond technical capability – to what I consider the most important aspect of technology – People. The CISA team is full of amazing CMU alumni like Karen Miller who leads our vulnerability evaluation work and Dr. Jono Spring, who is on the front lines of our vulnerability management work – both are here with me today.

Finally, I wanted to come here because CISA and CMU share a common set of values—collaboration, innovation, inclusion, empathy, impact, and service. And of course, a shared passion for our work.

So, now that you know why I am here, I want to start with a story.

At 2:39 pm on a chilly but sunny Saturday, just six miles off the coast of South Carolina, an F-22 fighter jet from Langley Air Force Base fired a Sidewinder air-to-air missile to take down a balloon—the size of three school buses—that had drifted across the United States. The deliberate action came after a tense public standoff with Beijing and intense media scrutiny about the Chinese “spy balloon.”

The response and surrounding attention to the issue, reinforced for me a major challenge we face in the field of cybersecurity—raising national attention to issues much less visible but in many ways far more dangerous. Our country is subject to cyber intrusions every day from the Chinese government, but these intrusions rarely make it into national news. Yet these intrusions can do real damage to our nation—leading to theft of our intellectual property and personal information; and even more nefariously: establishing a foothold for disrupting or destroying the cyber and physical infrastructure that Americans rely upon every hour of every day—for our power, our water, our transportation, our communication, our healthcare, and so much more. China’s massive and sophisticated hacking program is larger than that of every other major nation – combined. This is hacking on an enormous scale, but unlike the spy balloon, which was identified and dealt with, these threats more often than not go unidentified and undeterred.

And while a focus on adversary nations—like China and Russia—and on cybercriminals is important, I would submit to you that these cyber-intrusions are a symptom, rather than a cause, of the vulnerability we face as a nation. The cause, simply put, is unsafe technology products. And because the damage caused by these unsafe products is distributed and spread over time, the impact is much more difficult to measure. But like the balloon, it’s there.

It’s a school district shut down; one patient forced to divert to another hospital, a separate patient forced to cancel a surgery; a family defrauded of their savings; a gas pipeline shutdown; a 160-year-old college forced to close its doors because of a ransomware attack.

And that’s just the tip of the iceberg, as many—if not most—attacks go unreported. As a result, it’s enormously difficult to understand the collective toll these attacks are taking on our nation or to fully measure their impact in a tangible way.

The risk introduced to all of us by unsafe technology is frankly much more dangerous and pervasive than the spy balloon, yet we’ve somehow allowed ourselves to accept it. As we’ve integrated technology into nearly every facet of our lives, we’ve unwittingly come to accept as normal that such technology is dangerous-by-design:

We’ve normalized the fact that technology products are released to market with dozens, hundreds, or thousands of defects, when such poor construction would be unacceptable in any other critical field. 

We’ve normalized the fact that the cybersecurity burden is placed disproportionately on the shoulders of consumers and small organizations, who are often least aware of the threat and least capable of protecting themselves. 

We’ve normalized the fact that security is relegated to the “IT people” in smaller organizations or to a Chief Information Security Officer in enterprises, but few have the resources, influence, or accountability to incentivize adoption of products in which safety is appropriately prioritized against cost, speed to market, and features. 

And we’ve normalized the fact that most intrusions and cyber threats are never reported to the government or shared with potentially targeted organizations, allowing our adversaries to re-use the same techniques to compromise countless other organizations, often using the same infrastructure.

This pattern of ignoring increasingly severe problems is an example of the “normalization of deviance,” a theory advanced by sociologist Diane Vaughan in her book about the ill-fated decision to launch the space shuttle Challenger in 1986.  Vaughan describes an environment in which “people become so accustomed to a deviant behavior that they don't consider it as deviant, despite the fact that they far exceed their own rules for elementary safety.”

When it comes to unsafe technology, we have collectively become accustomed to a deviance from what we would all think would be proper behavior of technology manufacturers, namely, to create safe products. Dr. Richard Cook, a software engineer and system safety researcher popularized the complementary idea of an “accident boundary”—that is, the point of maximum risk that organizations can tolerate beyond which you have an “accident,” like an intrusion. Organizations try to move their operations away from the accident boundary. In cybersecurity, we might see them conduct employee awareness training for phishing, deploy multi-factor authentication, or buy expensive security tools. But what if the very design of technology products caused our operations to always be right up against the accident boundary through no fault of our own? What if no reasonable amount of money, or employee training could fix that, and an accident was inevitable because of the design of the product? It’s as if we’ve normalized the deviant behavior of operating at the bleeding edge of the accident boundary. This is the current state of the technology industry—and we need to make a fundamental shift if we want to do better. And we must do better. So, the question is: How? What if we changed how we think about cyber-attacks and where to focus our attention? What if we thought more about not just a superficial “root cause,” but the multiple contributing factors to a breach? Fortunately, history proves to us that we can—and indeed must—change the way we collectively value safety over other market incentives like cost, features, and speed to market. For the first half of the 20^th century, conventional wisdom held that car accidents were solely the fault of bad drivers. This is very similar to the way we often blame a company today that has a security breach because they did not patch a known vulnerability. But, what about the manufacturer that produced the technology that required so many patches in the first place? We seem to be misplacing the responsibility for security and compounding it with a lack of accountability. Today, we can be confident that any car we drive has been manufactured with an array of standard safety features—seatbelts, airbags, anti-lock brakes, and so on. And that’s because we know they work—quite simply, these features prevent bad things from happening. They save lives. Indeed, cars today are designed to be as safe as possible—for example, to absorb kinetic energy by crumpling and thus raise the occupants' chances of survival. Cars undergo rigorous testing and crashworthiness analysis to validate these design elements. No one would think of purchasing a car today that did not have seatbelts or airbags included as a standard feature, nor would anyone accept paying extra to have these basic security elements installed.

Unfortunately, the same cannot be said for the technology that underpins our very way of life. We find ourselves blaming the user for unsafe technology. In place of building in effective security from the start, technology manufacturers are using us, the users, as their crash test dummies—and we’re feeling the effects of those crashes every day with real-world consequences. This situation is not sustainable. We need a new model. 

A model in which we can place implicit trust in the safety and integrity of the technology products that we use every hour of every day, technology which underpins our most critical functions and services. 

A model in which responsibility for technology safety is shared based upon an organization’s ability to bear the burden and where problems are fixed at the earliest possible stage—that is, when the technology is designed rather than when it is being used. 

A model that emphasizes collaboration as a prerequisite to self-preservation and a recognition that a cyber threat to one organization is a safety threat to all organizations. 

In sum, we need a model of sustainable cybersecurity, one where incentives are realigned to favor long-term investments in the safety and resilience of our technology ecosystem, and where responsibility for defending that ecosystem is rebalanced to favor those most capable and best positioned to do so.

What would such a model look like?

It would begin with technology products that put the safety of customers first. It would rebalance security risk from organizations—like small businesses—least able to bear it and onto organizations—like major technology manufacturers—much more suited to managing cyber risks.

To help crystalize this model, at CISA, we’re working to lay out a set of core principles for technology manufacturers to build product safety into their processes to design, implement, configure, ship, and maintain their products. Let me highlight three of them here:

First, the burden of safety should never fall solely upon the customer. Technology manufacturers must take ownership of the security outcomes for their customers.

Second, technology manufacturers should embrace radical transparency to disclose and ultimately help us better understand the scope of our consumer safety challenges, as well as a commitment to accountability for the products they bring to market. 

Third, the leaders of technology manufacturers should explicitly focus on building safe products, publishing a roadmap that lays out the company's plan for how products will be developed and updated to be both secure-by-design and secure-by-default.

So, what would this look like in practice?

Well, consumer safety must be front and center in all phases of the technology product lifecycle—with security designed in from the beginning—and strong safety features, like seatbelts and airbags— enabled right out of the box, without added costs. Security-by-design includes actions like transitioning to memory-safe languages, having a transparent vulnerability disclosure policy, and secure coding practices. Attributes of strong security-by-default will evolve over time, but in today’s risk environment sellers of software must include in their basic pricing the types of features that secure a user’s identity, gather and log evidence of potential intrusions, and control access to sensitive information, rather than as an added, more expensive option.

In short, strong security should be a standard feature of virtually every technology product, and especially those that support the critical infrastructure that Americans rely on daily. Technology must be purposefully developed, built, and tested to significantly reduce the number of exploitable flaws before they are introduced into the market for broad use. Achieving this outcome will require a significant shift in how technology is produced, including the code used to develop software, but ultimately, such a transition to secure-by-default and secure-by-design products will help both organizations and technology providers: it will mean less time fixing problems, more time focusing on innovation and growth, and importantly, it will make life much harder for our adversaries.

In this new model, the government has an important role to play in both incentivizing these outcomes and operationalizing these principals. Regulation—which played a significant role in improving the safety of automobiles—is one tool, but—importantly—it’s not a panacea.

One of the most effective tools the government has at its disposal to drive better security outcomes is through its purchasing power. The Biden Administration has already taken important steps toward this goal in establishing software security requirements for federal contractors and undertaking an effort to adopt security labels for connected consumer devices like baby monitors and webcams. It will continue to pursue this goal through the implementation of the initiatives called for in the President’s May 2021 cybersecurity executive order, such as developing federal acquisition regulations around cybersecurity.

The government can also play a role in shifting liability onto those entities that fail to live up to the duty of care they owe their customers. Returning to the automotive analogy: the liability for defective auto parts now generally rests with the producer that introduced the defect even if an error by the driver caused the defect to manifest. This was reflected in class action litigation against the Takata Corporation, where the company’s defective airbags tragically caused over 30 deaths after often minor collisions. Consumers and businesses alike expect that products purchased from a reputable provider will work the way they are supposed to and not introduce inordinate risk. To this end, government can work to advance legislation to prevent technology manufacturers from disclaiming liability by contract, establishing higher standards of care for software in specific critical infrastructure entities, and driving the development of a safe harbor framework to shield from liability companies that securely develop and maintain their software products and services. While it will not be possible to prevent all software vulnerabilities, the fact that we’ve accepted a monthly “Patch Tuesday” as normal is further evidence of our willingness to operate dangerously at the accident boundary.

In addition, the government can play a useful signaling role in acknowledging the good work that technology manufacturers are doing today because they recognize that owning the security outcomes of their customers is the right thing to do to ensure the safety of those customers.

Encouragingly, an increasing number are taking important steps in the right direction—

from adopting secure programming practices to enabling strong security measures by default for their customers. I’ll highlight a few.

With respect to secure programming, it’s been a relatively well-kept secret for many years, but around two-thirds of known software vulnerabilities are a class of weakness referred to as “memory safety” vulnerabilities which introduce certain types of bugs related to how computer memory is accessed. Certain programming languages—most notably, C and C++— lack the mechanisms to prevent coders from introducing these vulnerabilities into their software. By switching to memory safe programming languages—like Rust, Go, Python, and Java—these vulnerabilities can be eliminated. Java, of course, was invented by CMU alumnus James Gosling. As one example, Google recently announced that “Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language” – specifically Rust – and that “there have been zero memory safety vulnerabilities discovered in Android’s Rust code.” That’s a remarkable result.

And it’s not just Google. Mozilla, who created Rust, has a project to integrate Rust into Firefox. Amazon Web Services has also begun building critical services in Rust—noting not just security benefits but also time and cost savings.

The nonprofit Internet Security Research Group is another good example. Work done under their Prossimo project led to support for using Rust in the Linux kernel, an important milestone given that the Linux kernel is at the heart of today’s internet. If the Internet Security Research Group can have such success on a limited budget, think about what big corporations can do.

Now consider some examples of security defaults: Apple says that 95% of iCloud users enable MFA. Metrics for other services are hard to come by, but Twitter reports that fewer than 3% of its users use any form of MFA. Microsoft reports that only about a quarter of its enterprise customers use MFA and that only about one third of their administrator accounts use MFA. While the Twitter and Microsoft stats are disappointing, the companies are doing a service by helpfully releasing data on MFA adoption publicly.

Apple’s impressive MFA numbers aren’t due to random chance. By making MFA the default for user accounts, Apple is taking ownership for the security outcomes of their users. By providing radical transparency around MFA adoption, these organizations are helping shine a light on the necessity of security by default. More should follow their lead—in fact, every organization should demand transparency regarding the practices and controls adopted by technology providers and then demand adoption of such practices as basic criteria for acceptability before procurement or use. Manufacturers must be transparent about their processes and their quality and safety. They must run transparent vulnerability disclosure policies, giving legal protection to security researchers who report vulnerabilities, letting those researchers talk publicly about their findings, and taking care to address root causes of those vulnerabilities.

Here at CMU, the Software Engineering Institute has done some great work on this, including by publishing the CERT Guide to Coordinated Vulnerability Disclosure. Other community efforts like disclose.io have done a good job laying out template language for vulnerability disclosure policies which companies can adopt. 

Dropbox is one strong example of mandating transparency from vendors. In 2019, they overhauled their vendor contracts to include security requirements, holding vendors to the same level of security that Dropbox holds itself to. This includes actions like requiring vendors and their employees to use MFA, allowing Dropbox to perform security testing of the vendors’ systems, and requiring vendors to publish vulnerability disclosure policies with legal safe harbor. They even open-sourced their contract requirements so that other organizations could adopt and modify them. I encourage other organizations to follow Dropbox’s example and start demanding transparency from their vendors. At CISA, we’ve been working through ways that we can support radical transparency in technology software in products. For example, we’re focused on advancing the use of Software Bill of Materials, or “SBOMs,” the idea that software should come with an inventory of open-source components and other code dependencies. Effective use of an SBOM can help an organization understand whether a given vulnerability affects software being used in their assets and provide greater confidence in a manufacturer’s software development practices.  We must applaud and encourage any, and all progress, while also recognizing the need to do more. Because as we introduce more unsafe technology to our lives, we increase our risk and our exposure exponentially—and this threat environment will only get more complex.  While we play our role from a government perspective, and technology companies increasingly embrace their role in putting consumer safety first, universities have an important role to play in achieving safe technology products. Indeed, one of the main reasons I wanted to come to CMU is because of the strength of your computer science and software engineering programs—because this is where the next generation of software engineers and innovators are learning their craft. For the professors here this morning, you are responsible for the education of some of our nation’s brightest young minds and for the knowledge they bring into the working world. If that world is going to be one where the technology products that we all rely on are safe, it must be a world where our new graduates show up to work with fluency in, and a bias towards, memory safe programming languages. A world where incentives, tools, and training are readily available to help organizations migrate key libraries to memory safe languages. Imagine that by 2030, memory safety vulnerabilities are almost non-existent. Attackers are unable to find and use memory safety vulnerabilities, dramatically raising the cost of an attack, and stopping all the terrible things I talked about earlier? How did we get there? I think a major part of the answer to that question is that “we figured out how to make memory safe languages ubiquitous within universities nationally, and globally.” I know that sounds like a lofty goal but let’s talk about some possible steps to get there. I’ll highlight four key areas for your consideration.

First, could you move university coursework to memory safe languages?

• As an industry, we need to start containing, and eventually, rolling back the prevalence of C/C++ in key systems and putting a real emphasis on safety.
• How can we tackle this challenge? What if we start a formal program – with material funding, incentives for professors, goals, an executive sponsor, and metrics – to migrate course materials to use memory safe languages? This includes ensuring that C and C++, when taught, are treated as dangerous, regardless of how pervasive they are in existing codebases.
• In that vein, I’d like to give kudos here to CMU for offering CS 112— an introductory programming course taught in Python taken by many students across the university. Introducing students to the benefits of programming in a memory safe language is a key step forward.

Second, could you weave security through all computer software coursework?

• There’s often a knowledge, skills, and experience gap between new hires and what is needed at their first jobs. Some of the larger companies have security training for new hires to ensure they understand how to code safely, always with an intelligent adversary in mind. Meanwhile, just one out of the top twenty undergraduate programs in computer science requires a security course as a graduation requirement. Which one? UC San Diego. As it stands, at most schools, a student can earn a computer science degree without learning the fundamentals of safety and security. I urge every university to make taking a security course a graduation requirement for all computer science students. Better still, don’t just make security a separate class, but make it part of every class.
• I’d like to recognize CMU for being a leader here, integrating security for its core classes. Freshmen taking CS 122, for instance, learn about memory safety bugs like buffer overflows. I’d love to see how we can help standardize this kind of education into curricula across the country.
• Civil, mechanical, and electrical engineers all take a substantial course load around thinking critically about safety: from understanding tolerances and safety margins to rigorously analyzing failures, safety is a critical part of engineering education. Skills for reliably and securely engineering computer software are critical parts of national security. We must work together to instill these skills into the engineers who will manufacture our future technology.
• CMU also deserves credit for its focus on software as an engineering discipline. CMU researchers have made significant contributions to advancing the state of the art in software engineering and programming language design. I challenge you to think about how to go further in making that work accessible to all students and integrating it deeper into the standard computer science curriculum.

Third, how can you help the open-source community?

• Are there opportunities to migrate CMU sponsored open-source projects to memory safe languages? To require all published research code to be written in memory safe languages? To build research opportunities and hands-on classroom learning around enhancing the safety of key open-source projects? The open-source commons is a key foundation of our software ecosystem and universities are well suited to invest in making sure that foundation is up to code.

And finally, could you find a way to help all developers and all business leaders make the switch?

• Can we create better tooling for migrating to memory safe code from legacy code bases? Are there ways to make formal verification of software safety easy to deploy at scale? These questions have drawn research attention for decades, but they are only growing in importance as software is further embedded into the very foundations of our society. More tactically, you can help produce clear technical guidance—in partnership with CISA—on how developers can radically improve the quality and safety of their code.
• You can partner also with your colleagues here in the business school on management guidance to help business leaders understand what it takes to reinforce a culture of embracing safety and security as a matter of product quality.

These are big challenges, but ones that deserve our full attention. Steps taken today at this university and universities around the country can help spur an industry-wide change towards memory safe languages and add more engineering rigor to software development which in turn, will help protect all technology users. It’s critical that students have a strong bias to build safety into every system, which will pay dividends in the long run.

Finally, to all the students in the room.

Given the catastrophic costs of cyber-attacks affecting American businesses, governments, and citizens, we need future leaders like you to find ways to turbocharge the transformation to memory safe systems, and more broadly to systems that we know to be secure by design.

There are many ways you can help solve these challenges. Maybe you go work at a tech company—or even start your own—and write memory safe code, focused on advancing the principles of security we discussed today. Remember that you should take pride in the safety of the code you write—think of it as “part of your brand” as an excellent software engineer.  And maybe you take what you learn today and help educate your fellow students on security and encourage your peers to write memory safe code.

Or maybe you decide to come work with us at CISA. We have several CMU alums that did just that. We need talented individuals like you all to help build our team as we continue to increase our capabilities, and most importantly, to help us forge a new approach around technology product safety. My team is here today, and I’d encourage you to stop by their table to talk with them if you want to learn more about working at CISA. One common value we share with you all is that we all put our heart into our work.

As we started with a story, I want to end with one, though this is less a story than a tale—a cautionary one at that.

Imagine a world where none of the things we talked about today come to pass, where the burden of security continues to be placed on consumers, where technology manufacturers continue to create unsafe products or upsell security as a costly add-on feature, where universities continue to teach unsafe coding practices, where the services we rely on every day remain vulnerable. This is a world that our adversaries are watching carefully and hoping never changes.

Because this is a world where another unprovoked invasion of a peaceful country by another much more powerful adversary—an adversary that has watched and learned from the endless missteps of Russia in its criminal war against Ukraine—might very well be coupled with the explosion of multiple U.S. gas pipelines; the mass pollution of our water systems; the hijacking of our telecommunications systems; the crippling of our transportation nodes—all designed to incite chaos and panic across our country and deter our ability to marshal military might and citizen will.

Such a scenario of attacks against our critical infrastructure in the event of a Chinese invasion of Taiwan is unfortunately not terribly far-fetched, but it is one we can prevent, if we come together, collectively as a nation, across our businesses and across our universities, to put our heart into the hard work of achieving safe, secure, and resilient infrastructure for the American people. 

Thank you again for the opportunity to speak with you today; I look forward to continuing the conversation with Professor Mayer and hearing your thoughts.

Cloud Computing: Winners and Losers

I continue to ponder various points about cloud computing that were raised in a session on the subject in which I participated earlier this week. I paid particular attention to the presentation of a senior technical person, with extensive experience in cloud computing at a research lab operated by one of the world's leading high tech companies. His words got me to thinking about who might the winners and losers in a cloud computing-dominated world.

By way of quick summary, let us characterize cloud computing as the provision of various computer-related services where the user makes use of services accessible from a remote site instead of from the user's own IT resources. The underlying idea is that such sevices should be provided as a ultility analagous to electricity and water. While the concept was first floated in the 1960s, it entered the mainstream only in the last decade due to a series of hardware, communication, software and financial considerations. Two aspects are particularly noteworthy.

First, the user need no longer take software licences for which he pays regardless of whether the the software is actually is being used. Instead, under the SaaS model ("software as a service"), the user in principle need only pay for the software services that it actually uses (in actuality, it appears that this is not precisely the case, but the "software on demand" model is close enough for our purposes.) Second, the remote cloud computer centres serve to replace the need to maintain full-scale IT centres on-site. This is done by maintaining immensely large computer centres manned by the most skilled IT personnel, thus enabling the user to tap into these computer centres for a variety of their data services (so-called "platform as a service" and "infrastructure as a service").

Against this backdrop, who might win and who might lose? Permit me to propose the following list.

The Winners

1. Manufacturers of hardware and communications equipment--They will be called upon to provide the computer centres with the necessary equipment to support and expand these facilities.

2. Manufacturers of various hand-held devices--One of the claimed reasons for the recent attractiveness of cloud computing is the explosion of hand-held devices, which in principle permit connectivity anytime, anywhere. The popularity of these devices will be enhanced by the ability of their users to acess usable applications on the fly. The ability of the computer cloud to provide these contents will be a major determinent in how successful this hand-held revolution will actually be.

3. Users--There has long a been a feeling that users of computer software pay for software that in effect rests unused most of the time. When licensing models were based on payment per CPU, or user, or computer station, there was no ready way for users to free themselves from this model. When software is longer stored within one's local IT system, then the possibility is created for users to pay only for the software that they actually use.

4. Owers of the computer centres--It is Amazon.com that is widely attributed with first seeing the commercial possibility of making use of excess capacity in its computer centres to provide storage and access capablities. Whether true or not, it appears that a number of computer-related entities--e.g,, Amazon.com, Google, Microsoft and IBM--will come to dominate the infrastructure for cloud computing.

The Losers

1. Current software licensing models--Pureyors of software licensing may be challenged to find the kind of metric for charging users for the use of their software that will be as lucrative as the current model.

2. In-house IT departments--One of the claims is that local IT departments are both expensive to maintain and too often do not attract the calibre of person required to provide the necessary support. Whether that is true or not, the expansion of cloud computing may lead to a reduction of in-house IT positions.

3. Open source software--By some accounts, cloud-computing will only strengthen the hand of proprietary software, protected by copyright and patent, at the expense of software development under the open source model. Thus, while cloud computing may encourage cooperation at the user level, it does nothing to undermine, and may even strengthen, the hand of the proprietary software industry.

I am certain that there will be additional potential winners and losers in the cloud-computing world. In any event, it will be interesting to see how cloud computing plays out in the years to come.

More on winners and losers here

Open Source and Biotechnology: Whither or Whether Ideology?

I venture to say that most of us are well aware of the fault lines between proprietary and open source software. Proprietary software is characterized by keeping source code secret together with contractual restrictions on the use of the software, plus a reliance on the negative right aspects of copyright and other relevant IP law. Open source, to the contrary, rests on collaborative development and disclosure of source code, subject to various terms and conditions.

Less well-known is the effort to adopt the open source model to subject matter other than computer software. A particularly interesting effort in this regard is the use of open source principles in connection with biotechnology. A useful summary can be found in an article by the prolific and distinguished Professor Robin Feldman (left) of the University of California Hastings College of Law and Kris Nelson (a member of the Class of 2009 of the same school) that appeared in the Fall 2008 issue of the Northwestern Journal of Technology and Intellectual Property, "Open Source, Open Access, and Open Transfer: Market Approaches to Research Bottlenecks."

The authors discuss what they call Open Source Technology and Open Science. While the proponents of these variations of open source software are aware of the differences between the underlying subject-matter of software and biotechnology respectively, there appears to be a belief that that there is enough common ground to speak of both areas in a roughly similar fashion.With respect to Open Source Technology, there are two general categories. The first is described as focusing on bioinformatics ("the application of computer software and methodologies to solve biological problems"). The second category is marked by a move from the specific focus of the software interface to an effort "to ensure that the biotechnology tools required for research and innovation are openly available."

In particular, this second category centres on solving biotech-related problems in what the authors call "underserved communities." By this the authors mean communities with limited financial resources, with the result that there is an inability "to navigate the maze of patent rights and licensing necessary to engage in the targeted research." Stated otherwise, this approach intended to enable projects to deal successfully with the daunting problem of patent thickets.

Examples of projects of this kind are: (i) the HapMap Project here (a multi-country project researching genetic differences, with the goal of a certain mapping the human genome); (ii) CAMBIA here (expanding access to biological research, with a focus on disadvantaged communities); and (iii) the Public Patent Foundation here (aimed at solving the problem of patent thickets by establishing patent pools with open accessible patent rights to the participants of the program).

The authors point out several salient differences between Open Source licensing and the biotech variety:

1. Open Science is based on patent rights, which will sooner or later become public knowledge at some point. The same cannot be said of software under Open Source.

2. The resource requirements of Open Science, with an emphasis on sophisticated lab equipment, favor large organizations.

3. The very fact that Open Science is based on patent rights, while Open Source is based on copyright, means that each arrangement will reflect that particular aspects of the underlying legal right.

The authors conclude, with perhaps a tinge of understatement, that "Open Science Systems have not always matched their initial expectations." Perhaps the problem lies in the expectations themselves. When one considers the history of open source software, one is struck by the unique combination of ideology and technology that came together to forge "the movement". It is not at at all clear that this combination exists with respect to biotechnology, with the possible result that ideology may be the driving force, sometimes in an exaggerated and less than helpful fashion. That said, I have virtually no direct experience with open source arrangements in the biotech context. Perhaps my own views on the subject are themselves driven by my own ideological predilection on the subject.

iPhone, G1 and the IP Angle

Those of you who been called upon to teach IP to MBA students come to understand, sooner rather than later, that the preferred course offering is not simply Introductory IP Lite. The challenge is to find a way of connecting between IP and the broader business concerns of the MBA curriculum.

With that in mind, I draw your attention to Stephen Wildstrom's article entitled "Nipping at IPhone's Heels", his Oct. 6th contribution to his weekly column in Business Week under the name of "Tech & You." The article is a review by Wildstrom about challenges to Apple since its summer 2007 launch of the iPhone. In particular, Wildstrom points to the announcement of the T-Mobile G1 in September 2008, based on Google's Android operating system (see my blog of October 15th, "Android Takes Form"), and new product offerings by Research in Motion, aka the purveyor of the BlackBerry.

In short, Wildstrom described the Apple-Google combat as follows:

"Apple set this whole competition in motion by building a single, excellent smartphone within an ecosystem that it controls totally, including the right to approve all third-party software. In contrast. Google is pushing an open platform, meaning any handset manufacturer can design hardware that runs Android."

Mortal Combat of Another Kind

Having an initial look at the G1, Wildstrom concluded that the hardware is a bit of a disappointment. The software, on the other hand, is the object of praise. He attributes this to the attempt by developers "to tear down the walls that divide applications." Not surprisingly, the notion of "search" plays a central role in the design of the G1. Thus, the notion of "search", which lies at the heart of the Google enterprise, appears to be brought together with a tendency of software developers to be responsive to users' need rather than providing a top-down approach that dictates the user experience.

I really cannot evaluate to what extent Wildstrom's observations are on point. More interesting for me is the question of whether the features of the G1 described by Wildstrom are a function of the IP, open source model adopted by the Android? Or, stated otherwise, is the design of the iPhone, hardware or software, a function of the IP model adopted by Apple?

G1 and the Android Platform: Does IP Matter?

I am trying to work out responses to these questions before I take to the podium in January for my next foray into the realm of MBA teaching. If any of you out there has any suggestions, I would be most welcome to hear them.

OPEN SOURCE: WHO IS MAKING MONEY?

The romantic lore about the open source movement sometimes hides the fact that there are business models out there attempting to cash in on the freely available (and modifiable) software programs. The iffy state of the business side of the open source world was discussed in an August 18th article that appeared on the online service of Business Week magazine. Entitled "Open Source: An Open Question for Red Hat and Others," the article discussed a variety of points worth mentioning.

Since Red Hat is widely identified with the business side of the open source world, let's begin with it. The good news is that Red Hat saw a 32% increase in quarterly sales for the most recent period, to $157 million dollars. That translates into a 7% increase in profits. So why the bearish position of Wall Street analysts about Red Hat? According to the article, the bears on the Street continue to express concern about the slowing growth rate of the company.

At least two major reasons are cited for this sluggish growth. First, companies like Red Hat are more tech-support companies rather than purveyors of must-have technology. Second, brand awareness of their products remains low, apparently even so for a company supposedly as well-known as Red Hat.


So is anyone making out like a bandit in the open source space? Surprisingly perhaps, the article suggests that the winners are the traditional high tech goliaths--such as IBM, Hewlett-Packard, Oracle and Intel. Their success is based on taking advantage of the desire of companies to make increasingly lavish (and free) use of open source products by selling these companies complementary hardware, databases and consulting services to the open source products.

For instance, IBM sells billions (yes, billions) of dollars of hardware, middleware and services that are connected with open source programs. Oracle, the database giant, has made Linux a lucrative platform for its products. And the list goes on.

The bottom line here is the painful truism that, for open-source companies, just because their products enjoy large markets does not not mean they are currently enjoying commensurately large commercial success. Linux is free, IBM software is not. Guess who wins commercially, at least for the present. Investors and Wall Street are paying careful notice.

The bears on the Street are taking notice.