On the one hand we are speaking of the numerous and varied licensing conditions that have evolved around the sharing of “Open source software” defined as:

“… computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software.” (Source Wikipedia)

And on the other hand we speak of “RAND standards development patent policies” that provide for “Reasonable and Non-Discriminatory” (RAND)  (see e.g. Abanet.org) licensing terms and conditions (including possible royalties) that might comprise a license covered by an assurance of a license from the holder of an essential patent to a particular standard.

This is to remove from our discussion the term “open standard” which can be confused with, but is distinctly different than either of the previous. We shall leave discussion what is an “open standard” for another day.

What is the problem? Some in the OSS community contend they are disadvantaged by RAND standards development patent polices where patent owners are allowed to seek reasonable royalties (and/or other reasonable terms and conditions) in licensing patents that are essential to practice the standard. They observe that OSS may be foreclosed from inclusion in standards employing RAND patent policies due to several elements generally understood to define OSS (Source Wikipedia):

“… 1. Free Redistribution

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.”

and

“… 3. Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.”

A generalization is just that, and all generalizations are suspect.

Nevertheless one such recent generalization about OSS which brought to me a smile, this by Gene Quinn:

“But too many open source regimes are like the Borg of Star Trek fame, or a little like the Mafia. Once you are a member you simply cannot get out. With too many open source regimes once you join and take then anything that you produce must be free to be taken by other members of the consortium. It really is akin to a patent deal with the devil, and ignores human tendencies” (Source IPWatchdog.com)

I believe Quinn is observing whatever improvements might be made and contributed will be difficult if not impossible to monetize as Intellectual Property and that this contrasts with human nature to desire rewards for individual efforts.

Another important generalization is that there are important distinctions among OSS licenses. Not all open source licenses are necessarily in conflict or incompatible with RAND patent licensing (including royalties). Rather than being a conflict between the Open Source definition and RAND, the tension instead comes from certain patent licensing restrictions which are included in some Open Source licenses and RAND.

Välimäki and Oksanen observe*:

“… popular open source have a built-in termination mechanism that does not allow the development of software that requires any kind of royalty payments for third party patents. In more technical wording, GPL and LGPL are incompatible with patent royalties: if there is a patent for some software invention and that patent is not licensed for free to everyone forever, it is not possible to develop free software for that invention.”

They continue however:

“To be precise, not all open source licenses have such patent clauses. For instance the popular BSD license lacks one.”

Is this about a problem or a matter of differing goals? Distinctions exist between the goals of OSS and standards. A goal of OSS generally is that of permitting users to study, change, and improve the software. A goal of standards generally is about creating compatible or interoperable implementations and NOT about permitting multiple and varied changes. Andy Updegrove stated this succinctly in assessing a “non-assert” patent pledge concerning a standard:

“The pledge only relates to “compliant” implementations, which does run afoul of the open source right to change anything. From a standards point of view, that serves a purpose, as it furthers the spread of interoperable implementations, which is what standards are all about. That works well from that perspective, but may leave some open source advocates less happy.” (Source Consortiuminfo.org)

Carrying forward the notion that OSS actually describes a diversity of licenses, others here correctly opined: “all open source licenses are not created equal. “ There are upwards of 75 OSI “approved” open source licenses in use today (however dozens other non-approved licenses, see Opensource.org). It is all in the details; how well the current Oracle – Google patent dispute illustrates this point! In its complaint, filed August 12 2010 (see Scribd.com) with the U.S. District Court for the Northern District of California, Oracle said Google’s Android operating system software consists of Java applications and other technology. As such, it infringes on one or more parts of seven different patents. When Oracle purchased Sun Microsystems in 2009, it acquired Java.

“Sun, though it amassed thousands of patents, was one of the biggest backers of freely sharing programming technologies. Though Sun cut licensing deals to sell Java, it offered free versions under what the industry calls open-source licenses.” (Clark and Tuna on Wall Street Journal)

Some have questioned how could Oracle now seek to enforce its patents in Java (as it has with respect to Google) and at the same time support organizations with strong positions that such commonly used standards as Java should be available without any royalties?

“However, Oracle’s patent infringement suit against Google is also an aggression against the notion of open standards. Java should be an open standard, and according to Oracle-backed organizations such as the OFE and ECIS, such standards would have to be made available on a royalty-free basis.**” (Source Fosspatents.com)

Why should it come as a surprise that businesses strive to maximize their potential value? In standards setting the term for this behavior is, “enlightened self interest”. Exactly how Oracle makes its Google case is a matter for the attorneys and juries; however, the answer may lie in the concept of multilicensing:

“The practice of distributing software under two or more different sets of terms and conditions. This may mean multiple different licenses or sets of licenses. … When software is multi-licensed, recipients can choose which terms they want to use or distribute the software under.” (Source Wikipedia)

These snippets from Why Has Oracle Sued Google? from the “land down under” indicates there may be details within Sun’s original commitments that make these commitments consistent with the current Oracle litigation.

“This appears to be the story of a clever strategy by Sun/Oracle to monetise intellectual assets (patents, copyrights, and other intellectual capital embodied in the Java platform) through open-source licensing … This strategy gives Oracle the best of both worlds: freely available development platforms to encourage widespread adoption and standardisation; and commercial licensing in the most lucrative (high volume) market segments”

What is the lesson? This could be about a real problem when advocates from one side promote government intervention to their advantage and to the disadvantage of the other when a balanced analysis leads to a different conclusion. Should policy makers try to influence the conditions for different development and business models through standardization policy?

The global voluntary consensus standards community has a long and generally successful experience with the application of RAND standards development patent policies. The earliest such text from the predecessor to the current 2010 patent policy (see ANSI) of the American National Standards Institute was nearly 80 years ago in 1932:

“That as a general proposition patented designs or methods should not be incorporated in standards. However each case should be considered on its merits, and if a patentee be willing to grant such rights as will avoid monopolistic tendencies, favorable consideration to the inclusion of such patented designs in a standards might be given.” (Source GTW Associates)

The notion that any “RAND standards development patent policy” discriminates against certain OSS is not a matter of “discrimination” in the text of such a RAND standards development patent policy. It is a matter that some self-created elements in some of the OSS licenses make it impossible for the software subject to those licenses to meet at the same time the RAND standards development patent policies that have existed for decades.

Regulators and policy makers around the world face complex questions when contemplating government actions and rules affecting standards setting or use. Now with appeals in the US for “open government” it may seem at this time of government budget deficits that standards based on OSS or that royalty free licensing policies at SSOs merit attractive consideration. The Government of India recently proposed Draft Policy on Open Standards for e-Governance including such text as, “… the patent claims necessary to implement the Identified Standard shall be available on a Royalty-Free basis for the life time of the Standard.“

Regulators and policy makers around the world take heed. Such government actions are not as simple as they might at first appear. There are many factors bearing on the choice by a standards developer of its patent policy. Standards Developing Organizations balance many and often conflicting interests and needs of their members and users of their standards in making this choice. In some cases the market corrects such mistakes that SDOs may make in this regard (resulting in the standard failing to gain acceptance or market share) and the standard or standards developer becomes irrelevant.

Government policy makers contemplating actions to alter the rules affecting standards setting should use extreme caution and they should treat as circumspect claims by participants that open source software is disadvantaged by the RAND regime, long employed across a multitude of standards development organizations.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

*Mikko Välimäki and Ville Oksanen, “Patents on Compatibility Standards and Open Source – Do Patent Law Exeptions and Royalty-Free Requirements Make Sense?”, Sept 25 at http://www.law.ed.ac.uk/ahrc/script-ed/vol2-3/valimaki.asp.

** Here is use of the term “open standard” to define presumably a standard where patents are exluded or available royalty-free but where there is ample room for misunderstandings.

This article is co-authored by Anne Layne-Farrar and Daniel Garcia-Swartz (bio Here)

As fellow commenter Stacy Baird notes in his contribution to today’s discussion, all open source licenses are not created equal – hard line licenses, like the GPL, place more restrictions on users and thus create tensions with RAND/FRAND that don’t otherwise exist. Indeed, open source and IPR protected software frequently coexist quite peaceably.

While proponents of OSS famously said some time ago, “Information wants to be free”, restrictive OSS licenses unfortunately have the opposite effect. In fact, the more restrictive the OSS license, the less information flow is possible. It is difficult to measure the cost paid for the road not taken, but it is likely non-trivial.

The potential negative effect for firms that rely on OSS with highly restrictive licenses derives from the self-imposed reduction of choice. When organizations rely on the GPL or other similarly restrictive licenses for a specific product, they are precluded from incorporating into that product software that involves royalty payments. The pool of innovation from which they can draw is therefore limited. This reduction in choice is not a problem only if we assume that all software involving royalties is inferior, less innovative, and less relevant than readily available OSS software free of all IPR payments. The moment that we admit that some proprietary software may offer solutions not otherwise available, or available only in a less efficient or lower quality form, then we must also admit that a price is indeed paid by restricting the pool of contributions from which an OSS program can draw.

But the effects are surely more wide spread than that. In particular, it is our experience that many firms that rely on IPR protection shun standard setting organizations with open source leanings. Here the issue is not that existing software solutions protected by IPR are being precluded from inclusion in open source products, but rather that software solutions are not developed at all because the firms that would develop them are leery of OSS entanglements. This second effect exacerbates the first.

A related third effect in the form of uncertainty will emerge in at least some instances. To see the price that uncertainty over IPR and OSS can impose, consider Google’s recent announcement of an “open and free” video format, VP8, “with the goal of creating a standard that anyone can use without paying royalties.”*   The controversy began almost immediately after Google’s announcement. Specifically, MPEG LA announced that it was already working on creating a patent pool with patents that read on the VP8 standard. As the technology underlying VP8 is allegedly not owned by Google and thus is not under Google’s control, neither is the standard’s royalty-free status. Despite any reassurances that Google may make, risk averse firms appear to be avoiding the standard until its status is clarified – the opposite effect that Google was striving for.

The bottom line seems clear: tension between IPRs and OSS is bound to impose some economic costs. Most likely, the presence of strict OSS licenses in a standard setting context will result in reduced innovation and less consumer choice. When uncertainty is thrown into the mix, the cost can include delayed adoption of a standard. These effects appear to be greater the greater the reliance on more restrictive licenses, like the GPL, as opposed to more accommodating ones, like the BSD.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

* See “Google’s New Open Source Standard May Never Be Free”", Technology Review, May 26, 2010

In many ways, our forum topic this month addresses that issue. Stacy says: The answer lies in licenses: not the patent licenses, but certain open source software licenses. James says: Demands for royalties are becoming rarer, in our own domain.

My thoughts specifically to these two comments are as below. I also extend this discussion with implications for the future.

1) Open source licenses are not incompatible with IPR: Open source licenses are admittedly complex but they come down to one basic principle. (No, it is not about ‘free’ or ‘paid’). Essentially, Open source licenses come down to the ability to modify and distribute derivative code. The two positions are: Either you have to contribute back any modifications to the original code and redistribute the modifications as per the original license (copyleft) OR you can ‘keep’ and distribute the modifications and add any conditions (IPR, payments etc) to the modifications as long as you indicate the original license of the code and do not violate anyone else’s IPR. The two best known examples of the two perspectives for Open source licenses are GPL v 3 (copyleft) and Apache.

The Apache License, does not require modified versions of the software to be distributed using the same license. In every licensed file, any original copyright, patent, trademark, and attribution notices in redistributed code must be preserved (excluding notices that do not pertain to any part of the derivative works); and, in every licensed file changed, a notification must be added stating that changes have been made to that file.

This means there is no conflict between the Apache license and IPR, patents, payments etc.

2) Demands for royalties increasing depending on domain: In the domain I work with (mobility, convergence, sensor networks etc), we do see increasing (and not less) IPR issues. Mobile technology always had to deal with IPR right across the stack (network, device, services etc). My point is: When it comes to hardware and firmware integration (SW-HW interface), IPR has always played a role and it is getting more significant as the entire mobility sector gains in significance. Many of the royalty free arguments arise from the ‘software only’ domain. This may not be valid going forward especially as implementations become more complex and they span software and hardware with blurring boundaries (see below).

Implications:

As Open source matures, here are some of the implications as I see them: (there are many more but I choose three for brevity and focus)

1) Transparency is the key – not Open/Closed

2) Community engagement and trust

3) Blurring the lines between software and hardware

TRANSPARENCY IS THE KEY – NOT OPEN/CLOSED: Today, the biggest challenge for Open source is not the business model or IPR, (the Apache license certainly provides that) but that of trust and transparency. Most people today recognize the difference between Governance models vs. development models. I can explain this simply as: The leverage of control for open source is not who can change the code but rather whose changes will be accepted into the core product. Take the example of Android. The development model is open sourced (anyone can see the code and change it) but the Governance model is (ultimately) managed by Google i.e. if developer A and developer B both modify a specific code segment, the governance model (Google) decides which changes are to be included in the core product. This can be perceived as a barrier depending on the trust, transparency and engagement of the provider. Certainly, the traction gained by Android demonstrates that there is a degree of Trust in Google and indeed benefits for the licensees.

However, staying with Android, last week saw something much more complex i.e. the lawsuit between Oracle and Google over Android. The crux of this lawsuit arises from Sun’s original Java supposedly ‘open source’ terms and is explained by David Vellante via Gigaom which I summarise as follows:

In the license there is a “Classpath Exception” which is a crucial provision that allows developers to link their code to Java without the need to fall under a GPL license—meaning developers can make their own licensing terms and not be bound by GPL. Sun only included the Classpath Exception for the core Java platform – it’s not included the mobile edition.

This meant that it was really neither open nor closed source but rather a lack of transparency on the part of Sun which Oracle is attempting to monetize post its acquisition of Sun. Which brings us to the second point: Why would anyone want to ‘open source’ in the first place?

COMMUNITY ENGAGEMENT AND TRUST: Open source, by definition, needs engagement with the community (specifically with developer communities). Community engagement can occur at many levels. Many successful products have developer programs and the product itself is not open sourced.

Historically, this has worked well for many products. There are two commercial reasons for ‘open sourcing’ a product.

a) Extending the product along unpredictable directions: The first is to extend the product along unpredictable directions. This is the benevolent reason for open sourcing a product. Your product becomes a platform. Others can add value to the product by adding features. This works because the rate of change of products is now too fast. It means that the community ‘morphs’ the product in directions which you (as product owner) could never have anticipated. This could gain you competitive advantage because you gain an early market lead by allowing the community to shape your product in a direction that is beneficial to the community itself(who are often the users/customers of your product)

b) Getting traction for a challenger product: This is often the hidden reason for open sourcing a product. The real reason for open source is to get developer traction for a ‘challenger’ product. Would a Java community develop if Sun launched a proprietary software language? Who would buy license it from (what was mainly) a hardware/server company? So, Java had to ‘appear’ to be open sourced to get community traction.

It is interesting to see the love/hate relationship between open source product owners and the community. Sun clearly misled the community on how ‘open’ its source really was. Following the Oracle lawsuit, Google has suddenly developed a love for the open source Java community, which it had hitherto ignored in favour of its own Android community. Oracle, which has never open sourced its products, has a developer program but no record of any serious engagement with the Open source community. The ASF (Apache software foundation) represents the open source community in the minds of people but does not seem to have any real say in this game (which is between big corporations like Oracle and Google)

BLURRING THE LINES BETWEEN SOFTWARE AND HARDWARE: I said before that the boundaries between hardware and software are being blurred. In future, this will get more interesting when we get into the realms of Open source hardware. Today, one of the hottest products in the open source community comes from a university in Italy – Arduino. A trailer for a documentary for Arduino got 75,000 views in one day. Arduino comes from a university setting. It does not have the baggage from other corporate open source products with hidden agendas. Yet, developers can create commercial products from Arduino because it supports the LGPL license. The hardware is also completely hackable i.e. open and modifiable. This indicates to me that the boundaries are going to get a lot more complex and blurred both for HW/SW but also the management of IPR will be more complex

This is a much longer post that I originally thought and I could add much more but I will stop now.

Based on the above, my only conclusion is: We are going to see a lot more complexity, variety and increasing maturity when it comes to Open source and IPR.

Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/

The alliance – which boasts a customer base of more than 3 billion people though members such as Vodafone, AT&T, China Mobile, China Unicom, Orange, LG, Samsung and Sony Ericsson – will work independently of the GSMA to create a platform and distribute mobile and internet apps, although the GSMA is a supportive and active participant. In a statement, Rob Conway of the GSMA said that the WAC “…will build a new, open ecosystem to spur the creation of applications that can be used regardless of device, operating system or operator”.

While proudly claiming lofty ambitions of openness and interoperability, it is clear that the alliance is a direct move by telecoms against Apple’s App store which has come to dominate the mobile software application market. The App store was launched roughly 2 years ago and has an estimated 99% market share. As of June 2010, there are over 225 000 applications available, over 5 billion total downloads have been recorded and over US$1.3 billion in revenue has been generated for both Apple and 3rd party developers (with a 30%/70% split). Comparatively, the second largest distribution platform, the Android market, has just 80 000 applications.

Whether the initiative is based upon a need for cross-platform compatibility or a desire for a slice of Apple’s significant pie, it seems destined to failure for a number of reasons:

Firstly, vertical integration, while fragmenting the market, is in many ways the foundation for its success. By providing a localized standard and a single, unified product line, the App store guarantees applications which are streamlined and optimized for the iPhone.

The Android market on the other hand suffer from significant fragmentation within the platform, due to the vast difference across devices running the same OS. Similarly the WAC covers a myriad of different devices, user interfaces, display resolutions, which will surely dilute the projects implantation.

Secondly, the initiative is in many ways behind the curve as the continued move towards web based applications, a platform accessible from all modern mobile handsets, will ultimately render the WAC obsolete. For instance, Google offers mobile optimized web applications for Gmail, Google Reader, etc rather than native iPhone applications in the App Store. Furthermore, HTML5 promises to make the Web ever more integrated and mobile friendly.

Most importantly however is that WAC, a unified giant with 25+ company voices, will be at great risk of being out maneuvered by the single and unified visions/voices of Apple, Google, or any other platform dedicated distribution channel.

There is a curious paradox which we are seeing increasingly. We see closed systems built on open standards and open source. I illustrate the phenomenon giving three instances below (Apple and Facetime, Open source and the Cloud and SPDY – the proposed new protocol from Google to replace HTTP). I seek comments on these.

APPLE AND FACE TIME

Face time is a mechanism on the new iPhone 4 devices for person to person video calling. Face time includes a whole slew of Open standards (source imtc blog) including H.264, AAC, SIP, STUN, TURN, ICE, RTP, and SRTP. For instance, H.264 is a video compression standard; AAC is an advanced audio coding standard, SIP (Session Initiation Protocol) is the de-facto standard of IP Communications solutions, including both Voice and Video communications; STUN, TURN and ICE are typically used together to support Firewall and NAT traversal functionality; RTP (Real-time Transport Protocol), is used in Voice and Video over IP implementations to carry over real-time media; SRTP supports encryption, message authentication and integrity and is widely used in both IP Video and Voice implementations.

Thus, we have a wide range of open and industry standards but collectively, the Apple Face time system is closed and not interoperable. By that, I mean the system can only be used to make video calls to another person on iPhone version 4 (not even previous versions of the iPhone) on wifi (cellular connections will not do!). This totally goes against the principles of network effects and interoperability but nevertheless it is a system getting a lot of traction in the press whereas the many previous attempts to create a standardised person to person video calling from standards bodies like 3GPPP are yet to be accepted by the industry commercially from (3GPP R4 onwards).

CLOUD AND OPEN SOURCE

There has been a lot of discussion for the Cloud computing and Open source. But much of it is vendor driven and does not really address the core principles behind the issue. Hence, it was interesting to see this blog from James Urquhart – The intersection of open source and cloud computing.

To summarise the key discussion in the above blog: (emphasis mine)

1) The definition of IT infrastructure has shifted significantly in the last 15 years or so, and much of that term now encompasses software as well as hardware. Operating systems have long been considered infrastructure in the world of client-server. Middleware and data bases, such as J2EE application servers and relational database management systems have also been largely described as common infrastructure.

2) A very common practice in enterprise IT organizations is to create standard builds of key software infrastructure stacks, to create a common operations framework on which application code is the only variant–at least in theory.

3) As many of these infrastructure components shifted to open-source options, they received a tremendous amount of attention from application developers. The reason for this was two-fold. The first was the fact that these projects were available for download for free–a characteristic the average developer loves in tools and infrastructure. The second is that developers were free to manipulate the entire software infrastructure stack if they so chose–though most rarely, if ever, actually did so.

4) Developers who wanted to play with infrastructure code were able to do so for two reasons: Firstly, the source code and instructions for building the software were freely available for manipulation on the developer’s own system and secondly, the developer could then build and deploy the software on said system to test and then utilize any changes.

5) What changes in cloud computing is that deployment of infrastructure software is strictly under the control of the cloud service provider. If I’m a user of Google App Engine, for example, I can’t go into the source code for their management systems, change something to suit me, and push it out to the wider Google service environment. Of course, we want it that way–it would be ridiculous to allow anyone who wants to change the way App Engine works to affect all other users of that environment. The security implications alone make that completely unreasonable, much less the other operational problems it would present.

6) Which means that the only users of open-source infrastructure projects in the public cloud are the cloud providers. They may see themselves as responsible users of open source and contribute back, or they may not. In any case, the incentive for the average application developer to delve into infrastructure code is weakened, if not outright removed.

This last point is critical – there is no real incentive for the average developer to contribute code to open source cloud initiatives and even if they did so, there is no guarantee (ex the Google App Engine example above), that such changes would be accepted. Thus, open source and cloud have some incompatibilities by the above perspective.

SPDY – THE NEW PROPOSED OPEN SOURCE REPLACEMENT for HTTP from Google

Google wants to speed up the Web by ditching HTTP and replacing it by a new protocol called SPDY. In a nutshell (source Wikipedia), SPDY is a TCP-based application-level protocol for transporting web content. Created by Google, the goal of SPDY is to reduce web page load time. This is achieved by prioritizing and multiplexing the transfer of several files so that only one connection per client is required. All transmissions are SSL encrypted and gzip compressed by design (in contrast to HTTP, the headers are compressed too). Moreover, servers may hint or even push content instead of awaiting individual requests for each resource of a web page.

This is all well and good but as the ars technica article points out there are some issues:

1) Mandatory use of SSL is not always needed: So should we all praise Google and switch to SPDY forthwith? Not quite yet. With the mandatory SSL encryption and gzip compression, SPDY will hit server and client CPUs much harder than traditional HTTP. Of course HTTP also runs over SSL in many cases, but there’s also lots of content out there that doesn’t need encryption. Making SSL mandatory is a strange move that has the potential to increase the number of people who don’t bother getting a proper certificate for their server, meaning that users will become even more blasé about ignoring the resulting security warnings. This, in turn, would pave the way for more man-in-the-middle attacks.

2) SSL on small devices: On small devices, SSL slows down the communication significantly, and because it can’t be cached, SSL-protected sites are often slower on big machines as well. The extra CPU cycles also mean that more servers are needed to handle the same number of clients.

3) Designed by web people rather than network people: It also looks like this protocol is designed by Web people, rather than network people. How the IETF applications area will respond to this effort is a big unknown. For instance, one thing that isn’t mentioned in the protocol specification is how a browser knows that it should set up a SPDY connection rather than an HTTP connection. Are we going to see SPDY:// in URLs rather than HTTP://? That wouldn’t work with browsers that don’t support the new protocol.

Some more comments:

1) Traditionally, bodies like IETF did not replace protocols wholesale. Rather, they added features incrementally thus providing a backward compatibility path to existing users.

2) The protocol may be open source but I expect that the governance model is still managed by Google. This has implications to which features are chosen to be implemented in the protocol.

3) The ‘network’ guys who may not be very happy with this could create their own version of the protocol and could also ‘open source’ it under their own governance model. This will create two versions of the protocol – both ‘open sourced’.

4) Historically, funding for the Internet protocol development came directly or indirectly from bodies such as the National Science Foundation and DARPA and companies did not get involved in low level protocols – open sourced or not.

While it is good to talk of evolution of HTTP, much more thinking needs to be done about the mechanism of this change and the belief that it is open source may not be sufficient in itself.

CONCLUSION

In all these cases, the interpretation of Open vs. Closed is relative. It depends on perspective. It also ties to innovation. The conclusion, if any, is that this is a scope for debate and that the previous, relatively simple demarcation between Open vs. closed may not be so clear with Cloud, Mobility and other emerging domains

1) When governments favour one or the other standard/company, as they did for Baidu in this case, the results are never good. We need competition and market forces to drive innovation. The current state of play in China is: we have no competition in the search engine market and hence potentially little incentive to innovate (even at 33 %, Google’s market share was substantial). The customers are the real losers.

2) International factors are more complex. To its credit, Baidu claims that it had a greater understanding of the local market. Also, China is not the only market where Google has a low market share. That distinction goes to the Korean market with Naver which has a market share of over 70 %, compared to 2 % of Google – which demonstrates that there may be some merit in the complexity of local/non English claim which Baidu makes

3) Search engine technologies are mostly proprietary. No one talks of ‘open standards’ for search engines. The only known instance of an open algorithm search engine Wikia search which called itself ‘a free and open-source Web search engine operated by ‘for-profit’ company’ died a lonely death with 0.000079 % market share.

4) Finally, as we know from the Telecoms industry, China has tried to influence standards in the Telecoms domain roaming by promoting TD-SCDMA instead of the more widely used W-CDMA standard. This leads to practical difficulties – for example for roaming customers.

To conclude, China – Google offers an extreme example of Government involvements in ICT roadmap but the same happens to a lesser degree globally. Ultimately, that cannot benefit the customers.

Defining ‘Open’ is one thing, Defining ‘Open Business models’ is more complex and sometimes contradictory. So, the challenge is to think of Open business models on the basis of the ‘Open memo’. Let’s consider the example of Vinton Cerf referenced in the memo who defined the TCP/IP protocols that are the foundation of the Internet. TCP/IP is a textbook case of Network effects. However, note that in this case, there was a complete separation of the network effect and it’s business model. In contrast, there is a subtle but important difference when an organization creates a network effect through the Open philosophy (which Google has done), but at the same time seeks to ‘harness’ the benefits from that network effect (which is different from TCP/IP approach). The above point is the main reason for the contradictions that we see in the memo which others have also pointed out.

Gartner has a very interesting take on this in a blog called the Truth of Open in response to the memo. Gartner says:

Openness is by and large a strategy to reduce operating costs and remove supply chain dependencies. Open is not a revenue engine in its own right. In that regard, Rosenberg’s observation about sustaining competitive advantage through closed system are still valid. The only real change is that organizations are increasingly understanding how to balance both closed and open systems.

The truth is that closed systems still win. Open systems, practically speaking, are basically good for making others lose. The art of business in the 21st century is figuring out how to open up your suppliers’ and competitors’ business while keeping yours tightly sealed. And in that endeavour Google has proven highly successful.

In my view, the crux of creating a business model based on the Open philosophy lies in maintaining a leverage of control or in creating a barrier to entry. So, how many ways can we create a business model based on ‘Open’? Here is my list. Happy if you can suggest more.

a) Open source governance models: I have said this before Open is the new closed? – Bringing transparency to Open source by separating Open source licensing models i.e. Open source governance models are quite different from Open source development models and governance models are often ‘closed’.

b) Making others lose: As the Gartner link refers above, Open systems are a competitive strategy to reduce costs. In an extreme case, that involves making costs equal to zero. Better still if someone else is charging money for the same (software) product (Note that the model cannot work with hardware i.e. the incremental production costs of software are zero. Which helps leverage the model)

c) Abstraction: This is the classic business model for network effects i.e. create the value at a higher level of abstraction (in this case advertising). However, note that this model has two parts: First you must create the network effect and more importantly, you must then maintain a leverage of control. In this case, the leverage of control is through the search algorithms so as to lead the Google dance and make your partners follow. It is interesting that the memo says that the search algorithm is closed because it could be ‘gamed’, which is a direct contradiction on the Open (source) philosophy i.e. Linus’s law “given enough eyeballs, all bugs are shallow.”

d) Contradictions: Often you have to live with contradictions if you want a business model for Open. For instance, I would have loved the ability to tweet from Google reader. But I don’t think that this feature is forthcoming since Google and Twitter are competitors … unless Google acquires Twitter…

e) Scale: can be a competitive advantage. The Internet was supposed to ‘get rid of the middleman’, in reality, after the dust of the last decade has settled, there are only one or two massive intermediaries in each sector (Google/Amazon/Ebay etc)

f) Speed of execution for users (not customers): Like scale, speed of execution also offers a competitive advantage especially if the products are accepted by customers. In many ways, acceptance by the customer is the real evidence of success as the memo also implies i.e. the ability to create products that are accepted by the customer. However, there is a caveat here; in reality, we have ‘users’ and not ‘customers’ since most people do not pay for the services. Since the service is free, it creates users and not customers leading to greater speed of execution and a platform that helps to reinforce other products creating a competitive advantage

g) Metadata: Metadata (and not data) is the real driver to the business model. Thus, there is a lot of data flowing through in street view, scanned books, maps and mobile but it is the metadata (derived from the data) which is the foundation of the business model.

So, that’s all I could think of.

Last week, I visited India and my tech-savvy six year old was on Google maps showing his grandparents his ‘route to school’ on Google maps. He is very familiar with Google maps and can navigate it far better than I can. This indicates that: In the end, customers will neither know nor care about most of the above if they like the product/service.

This is both good and bad; the privacy implications of Cloud, Metadata etc are only now being realised. Altruism aside, it will be interesting to see how Open systems business models evolve from Open systems themselves. Comments welcome!