Once More unto the Breach

There is NOTHING Wrong with the IETF IPR Policy

David Berlind reported that Larry Rosen has sent a letter to the IETF raising concerns  "regarding the formalization of a policy that paves the way for patented technologies to become IETF standards."

We went through this debate two years ago when OASIS revised their IPR policy.  These are GOOD policies.  A salient quote from that two year old post:

The customer of a standards organization is its members. The standards organization is a market oriented discussion forum where like-minded expert and experienced participants come together to agree on a specification that will enable multiple implementations of something.  In a perfect world it expands the overall market for a technology by creating a commodity of one component of that technology market.  This is why there are so many different standards organizations spanning the multifaceted marketplace.  If you're a member of OASIS, then join the discussion, debate the question, and vote.  If you're not a member, you aren't a customer, and you don't actually have a say.  That is the way standards works.

Most of the people that develop standards are vendors.  Consumers want standards because they understand successful standards have multiple implementations, and that will mean competition.  But they typically have little to do with developing the standards because they have neither the technology expertise nor the inclination.  They don't care what the standard is, but they do care that it exists. 

The customers of the actual standard are its implementors, but the key here is that interested implementors participate.  This is no different than the community of interest involved in a free or open source software project. 

The engineers and developers in standards organizations are generally funded by vendors and universities and these organizations are intellectual property owners. 

Larry raises his concerns with RFC3978. The more interesting document is RFC3979 ("Intellectual Property Rights in IETF Technology").  There are a couple of key quotes reflecting the extreme sanity of the group of people that have successfully delivered (and continue to deliver) the standards that enable people to read this post.  The most interesting sections are:

• 4.1  No Determination of Reasonable and Non-discriminatory Terms
• 6.5  What Licensing Information to Detail in a Disclosure
• 8.   Evaluating Alternative Technologies in IETF Working Groups

I've included the full sections below for reference.  These are eminently reasonable rules for the engineers and developers that come together to develop the standards that define our on-line life.  They reflect the reality of the marketplace, and the deep experience this organization has through 20+ years of developing these critical standards.

Standards do not happen in a vacuum.  They happen in processes that are under the microscope to ensure fair play and participation during their development, and to ensure sufficient transparency to prevent vendor collusion.  They happen in a marketplace of vendors competing for customers at a point when the technology has matured and can best be abstracted.   

Some of these participants have intellectual property.  (Some of those same intellectual property holders are free and open source software contributors.)  If you prevent them from participating through onerous rules, then two things happen and neither is good. 

First, you lose critical engineering experience and expertise and the resulting standard (therefore all its implementations) will be poorer for it.  Second, you force them to sit outside waiting for the standard to land such that they can tax it.   Having them in the standards working group negotiating in transparent conversations is a much better situation for everyone involved.

Pax. 

The interesting bits of RFC3979:

4.1.  No Determination of Reasonable and Non-discriminatory Terms

   The IESG will not make any explicit determination that the assurance
   of reasonable and non-discriminatory terms or any other terms for the
   use of an Implementing Technology has been fulfilled in practice.  It
   will instead apply the normal requirements for the advancement of
   Internet Standards.  If the two unrelated implementations of the
   specification that are required to advance from Proposed Standard to
   Draft Standard have been produced by different organizations or
   individuals, or if the "significant implementation and successful
   operational experience" required to advance from Draft Standard to
   Standard has been achieved, the IESG will presume that the terms are
   reasonable and to some degree non-discriminatory.  (See RFC 2026,
   Section 4.1.3.) Note that this also applies to the case where
   multiple implementers have concluded that no licensing is required.
   This presumption may be challenged at any time, including during the
   Last-Call period by sending email to the IESG.

6.5.  What Licensing Information to Detail in a Disclosure

   Since IPR disclosures will be used by IETF working groups during
   their evaluation of alternative technical solutions, it is helpful if
   an IPR disclosure includes information about licensing of the IPR in
   case Implementing Technologies require a license.  Specifically, it
   is helpful to indicate whether, upon approval by the IESG for
   publication as RFCs of the relevant IETF specification(s), all
   persons will be able to obtain the right to implement, use,
   distribute and exercise other rights with respect to an Implementing
   Technology a) under a royalty-free and otherwise reasonable and non-
   discriminatory license, or b) under a license that contains
   reasonable and non-discriminatory terms and conditions, including a
   reasonable royalty or other payment, or c) without the need to obtain
   a license from the IPR holder.

   The inclusion of licensing information in IPR disclosures is not
   mandatory but it is encouraged so that the working groups will have
   as much information as they can during their deliberations.  If the
   inclusion of licensing information in an IPR disclosure would
   significantly delay its submission it is quite reasonable to submit a
   disclosure without licensing information and then submit a new
   disclosure when the licensing information becomes available.

8.  Evaluating Alternative Technologies in IETF Working Groups

   In general, IETF working groups prefer technologies with no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.

   Over the last few years the IETF has adopted stricter requirements
   for some security technologies.  It has become common to have a
   mandatory-to-implement security technology in IETF technology
   specifications.  This is to ensure that there will be at least one
   common security technology present in all implementations of such a
   specification that can be used in all cases.  This does not limit the
   specification from including other security technologies, the use of
   which could be negotiated between implementations.  An IETF consensus
   has developed that no mandatory-to-implement security technology can
   be specified in an IETF specification unless it has no known IPR
   claims against it or a royalty-free license is available to
   implementers of the specification unless there is a very good reason
   to do so.  This limitation does not extend to other security
   technologies in the same specification if they are not listed as
   mandatory-to-implement.

   It should also be noted that the absence of IPR disclosures is not
   the same thing as the knowledge that there will be no IPR claims in
   the future.  People or organizations not currently involved in the
   IETF or people or organizations that discover IPR they feel to be
   relevant in their patent portfolios can make IPR disclosures at any
   time.

   It should also be noted that the validity and enforceability of any
   IPR may be challenged for legitimate reasons, and the mere existence
   of an IPR disclosure should not automatically be taken to mean that
   the disclosed IPR is valid or enforceable.  Although the IETF can
   make no actual determination of validity, enforceability or
   applicability of any particular IPR claim, it is reasonable that a
   working group will take into account on their own opinions of the
   validity, enforceability or applicability of Intellectual Property
   Rights in their evaluation of alternative technologies. 

 

Repeating History: The OSDL and Free Standards Group Merge

[Update (2007 Jan 25, 20:35):  Stephen O'Grady and I are generally complementary in our thinking, but more aligned.  Here's his excellent analysis. I think I'm showing my age.]

Monday saw the announcement of the creation of the Linux Foundation by merging the Open Source Development Lab (OSDL) with the Free Standards Group (FSG).  Jim Zemlin, the executive director of the FSG is now executive director of the entire organization.  The news link is here.  The interesting thing here is that we are watching history repeat itself in this technology generation. 

In 1984, the BISON group (Bull, ICL, Siemens, Olivetti, Nixdorf) evolved into X/Open. It's purpose was to be a specification and certification organization supporting applications portability around the European UNIX system vendors.  Over time the X/Open Portability Guide (XPG) was born, aligned with the ISO/IEEE POSIX standards, and evolved into the Single UNIX Specification and the UNIX branding program in 1995. 

[The IEEE POSIX work started in 1985, delivered the first standard for applications portability in 1988, and then began forwarding work into ISO for subsequent standardization in 1990 and 1992, and onwards.  Remember the UNIX standardization efforts, lovingly referred to as the "UNIX Wars" were about standardizing the mini-computer away from DEC.]

In 1988, Sun and AT&T began discussions as the Archer Group about an aligned UNIX offering.  (The Archer Group became UNIX International.)  This provoked DEC, IBM, DG, Siemens, Apollo, Nixdorf and HP to form the Open Systems Foundation (OSF).  They quickly adopted their own specification for applications portability on UNIX, which also immediately aligned with the POSIX standards.  [I'm sure rumours that "OSF" stood for "Oppose Sun Forever" weren't true.]

The more interesting aspect of the OSF, however, was their desire to deliver a shared operating system, and OSF/1 was launched.  DEC later used OSF/1 as the core of a future release of Ultrix, and IBM having contributed technology from AIX to help build OSF/1 also back ported parts of the technology into AIX. 

All of the OSF vendors differentiated the platform offerings on things other than the operating system.  It was a perfectly reasonable thing to collaborate and share the engineering costs of the kernel development. 

Eventually UNIX International collapsed, and even Sun joined the OSF.  There was substantial overlap in the membership of the two organizations over time, and some members started acquiring other members.   

So we had two organizations with substantially the same vendor members spending big sponsorship dollars to each organization each year.  One was a specification and branding (certification) organization, and the other was developing a shared operating system kernel. Each organization was a not-for-profit. 

In 1996, the two organizations were re-organized and thrust together to form the Open Group (TOG).  DEC had collapsed by then -- UNIX had won.  It was a more efficient way at that time to manage the costs of complementary programs. 

Each organization was formed for a very specific market purpose.  Over time, the purposes broadened, but eventually the sponsoring members of each came to re-focus the organizations on the core expertise and value proposition they had each started.  Once the market need changed, they were streamlined further into one organization by their respective overlapping members. 

Eventually OSF/1 faded away.  Hardware architectures were evolving and the costs were commoditizing.  PC-based hardware was going "up market" into the server space.  This meant Microsoft was evolving their desktop juggernaut into NT and into the server world. 

Linux was maturing to the point where there really could be a single royalty free kernel.  Every vendor had one, so to speak.  The Linux Standards Base (LSB) was formed in 1999 as a grass roots effort to support -- wait for it -- applications binary portability.  It too centered on the mature standards work that is still maintained as the ISO/IEEE/TOG Single UNIX Specification (with the original ISO POSIX work at its core).  It evolved into the Free Standards Group, with the classic list of vendors sponsoring it, and the certification and branding programs have developed.  During this period the OSDL was created as a hub for the kernel development by the [substantially] same list of vendors. 

I have long teased friends at the OSDL that they are the OSF of this technology generation.  (For the most part, the vendor list hasn't changed all that much at the core.)  And with this week's news we've come full circle.  There is nothing particularly sinister in the overlap histories.  It's just how maturing technology markets evolve and standardize. 

Jim Zemlin will certainly have his work cut out for him, just as Allen Brown did when he moved from managing director of X/Open to COO of TOG.  The specification and branding side of the house is never sexy, but it's incredibly important.  The linux kernel development housed at the OSDL is much better evolved in this technology generation than the OSF/1 experiment or the unwieldy tree of UNIX distros.  The organizational missions align nicely. 

Congratulations, Mr. Zemlin!

Open Source Software, and Standards, and IP in One Lesson

I've posted my basic deck on free and open source software economics, standards, and IP.  This is what I use as the starting point for any education I do.  It was last used in Beijing in November, 2006.  A friend kindly translated it into Chinese.  I'm happy to host any other translations people care to provide.  If you send email to me, I'll send you the original .odp file.  All I ask is that you translate directly, and that you claim your work as the translator on the cover slide. As always, distributed under a Creative Commons license.

• Open Source Software, and Standards, and IP in One Lesson (English, PDF 562.5K)
• 开放源代码软件, 标准, 与知识产权 (Chinese, PDF 694.2 K)

开放源代码软件, 标准, 与知识产权

A friend at Sun Microsystems (Dr. Dennis Ding) kindly translated my presentation that I used on a couple of occasions in Beijing last November into Chinese.  Here are the first couple of slides.

内容

• 阐述自由和开放源代码软件（FOSS）、标准和知识产权之间的经济关系
• FOSS在经济学意义上没有任何神秘之处——规则没有改变，但是准则可能有所不同

认识开放源代码软件

• 只是一种软件
• 只是一种经济现象
• 只是一种商业模式
• 只是一种软件许可方式

在开发高质量软件、建立社区、协作或软件许可方面并没有“新”的地方

开放源代码软件, 标准, 与知识产权 (PDF 694.2K)
"Open Source Software, and Standards, and IP in One Lesson" in English (PDF 562.5K)

Conformance and Certification: The ODF Standard and Microsoft's Office Open XML Specification

Excellent posts are appearing over the past 10 days on interesting and apparent contradictions in the Microsoft Office Open XML specification, their related patent promise, and the resulting effects on the ISO standards process.   (All are listed at the end of this post.)

Indeed, ECMA perhaps should be a little embarrassed that they passed the specification in ballot if such contradictions exist, but at 4000+ pages, one perhaps can be a little forgiving.  (Hopefully they evolve their process to adjust in the future for such outrageously large submissions from their members.)

I've pointed out elsewhere:

• Standards exist to enable and encourage multiple implementations, regardless of the forum in which they are created.  They benefit the consumer.  A vendor specification, regardless of whether it has gone through a formal standards process exists to encourage multiple add-ons to a single implementation, i.e. it benefits the vendor.
• Microsoft chose the most expensive worst possible way to deal with the ODF standard, and they will ultimately lose the battle because the standard with the most implementations historically wins in the marketplace. 

That said, huge concern and uncertainty exists for what's going to happen going forward with respect to ISO and Microsoft's ECMA specification, and the future of ODF. 

I'm going to take a slightly different view here.  ECMA has already approved the specification.  One can imagine that the Microsoft marketing and standards engines are in full gear, and Microsoft execs, Office spokespeople, and field account execs are faithfully espousing:

• "Microsoft Office 2007 is standards compliant.  ECMA International is a recognized international standards organization, with participation from IBM, HP, Intel, Adobe, and dozens of other companies."  [Subtext: It must be a good standard for all our partners and competitors to have passed it in a fair-minded international standards process.]
• "Indeed, ECMA International has submitted the standard to ISO for fast track approval as an international standard, and the process will complete in 2007."  [Subtext:  It's so good, that they have recommended it for FAST track at the world's premier standards body.]
  

I would be surprised if Microsoft's Massachusetts team isn't already lobbying to have the new "standard" included in the ITD reference architecture alongside ODF.   Regardless of the merit of ISO accepting the document, however, buyers will be staring the nasty rhetorical beast in the teeth.  So what is a procuring organization to do?

Historically at the federal level in the United States, the National Institute of Standards and Technology (NIST) developed Federal Information Procurement Standards (FIPS). These FIPS contained the description of a standard (perhaps developed elsewhere like ANSI or ISO), and what it would take to use that standard in federal government procurements.  The FIPS would also outline any certification testing requirements that NIST felt were warranted, and indeed for U.S. government procurement NIST [wisely] continued to put its money where its mouth was and developed the test suites that were used.  This was back in the days when the head of NIST was a civil servant instead of a presidential appointment, and the organization thereafter devolved into politics and destroyed many of these "boring" testing programs.

But it was an excellent example of a working model to solve concerns here. 

Standards organizations are best designed to develop specifications into consensus oriented standards.  They serve implementors directly.  They serve the marketplace indirectly by laying the specification foundation for producing lots of implementations. 

It is up to the parts of the marketplace that [economically] care about true conformance to define the certification process that fits the situation.   It could be the procuring side of the marketplace (as with the historical NIST programs), or the implementing side of the marketplace (as with the X/Open-Opengroup certification programs). 

So supporters of ODF (and by this I mean implementors) need to choose the organization that best represents their needs, and deliver a proper certification process.

The ODF Alliance is a likely candidate for at least defining the certification criteria and being the keeper of the certification "brand" so to speak.  Its recognized purpose is to promote the use of the standard, and document its use to support procurement.  Perhaps the Opengroup has a role to play because it has the pre-built infrastructure to support testing and certification on behalf of the ODF Alliance. 

OASIS is excused -- it's the standards development organization.  At best, it defines the conformance criteria for its specification.  Remember, the marketplace needs to take appropriate economic responsibility for certifying that conformance. 

As long as the certifying organization doesn't lose sight of the goal, i.e. as long as it doesn't think certification is a Big Revenue Generator, then the numerous products and online services supporting ODF will be able to quickly demonstrate conformance and certify.  This gives procurement agents their first tool: a recognized brand to specify in their requests for proposals (RFP).  The certification brand becomes an easy short-hand for "that document format standards thing with many implementations."

Microsoft can easily replicate this, and indeed will need so to do to even be perceived to be on a par with the ODF certification world.  It won't matter that there may be truck-sized defects in their rapidly created certification process.  It likewise won't matter if they actually fail to maintain their ability to certify. [They cut the specification into ECMA before they finished the product.  Trust me -- it will have drifted.]  It won't even matter if their certification process is superior!  There will only ever be one implementation that can certify.  It will also be difficult to create the same perceived arms length distance from their certification process that ECMA gave them from the specification.   And it still won't matter. 

Bidders can certainly offer Microsoft Office 2007 plus its conversion tools to meet the ODF certification requirements of the RFP.  But it will have to stand against all the other native solutions for price, performance, and ease of use. 

Likewise, Microsoft or their partners could lobby to get the MOOX "standard" and its needed certification process onto the RFP, BUT the procurement agents now have a second tool.  They have the ability to require that any document format standard on the RFP must support a certification process with at least N certified implementations available at the time of the RFP. 

That will become the industry norm to meet in this space. 

"Standards" with only one implementation aren't.  The buying side of the marketplace has always recognized this and chosen the standard with multiple implementations over the specification with only a single implementation.  The ODF world has the ability to demonstrate this message in a way that meets the needs of customers, and the demonstration through a branded certification is much more powerful than unaligned vendor rhetoric. 

Go get 'em.

Links:

• Andy Updegrove's excellent analysis of the contradictions and their effect on the ISO standards process. 
• Sam Hiser analysis and discussion on the contradictions in the Microsoft patent license. 
• Bob Sutor covers the technical specification contradictions with links to the relevant places.
• Groklaw has indepth coverage to set the context of Microsoft's promises.  It is tempting to take this as simple Microsoft bashing, but the deeper problem this post emphasizes is the problems a vendor faces in the marketplace once trust has been broken.  There are good links throughout. 
• Rob Weir really kicked it all off when he start going deep on the technical contradictions in the Microsoft specification. 

Open Standards, IPR and Innovation Conference, Beijing 2006

The China National Institute of Standardization and Sun Microsystems co-hosted a one day conference on "Open Standards, IPR and Innovation" in Beijing.  I was an invited speaker.  The event's goal was to bring together a set of speakers that would provide different perspectives and practices on how standards and intellectual property rules play together inside and out of China, such that China can determine what will best work for them. 

There is obviously a reasonable amount of tension between a handful of countries and China when it comes to claims of piracy, and as China's economy continues to grow, that tension has broken out in the standards arena as well with competing standards for such things as RFID technology and WiFi complicating the discussion.

The great thing about the conference was that one felt the Chinese speakers and attendees were definitely attending to learn, but it was NOT to learn how to be more "western", but rather to learn so as not to make the same mistakes.  The growing sophistication of business and business practices is palpable in Beijing in general, and definitely present at the conference.

One thing that was also surprisingly apparent was the lack of patience with the multinationals and their pricing, Microsoft in particular.  This was not an undercurrent in the presentations.  It was right out there in the open. 

I remember getting into the debate a few years ago while still at Microsoft.  Some managers took the position that countries like India would obviously want to mimic the  "American" success of companies like Microsoft.  The debate continues along the lines that India would obviously NOT want to use open source software because it's IP hostile, and they really need to build lots of proprietary software businesses because it's a demonstrated way to "make money" and grow the economy.  Of course they would want to do so on a Microsoft software platform.

First, open source software isn't IP hostile.  It depends upon strong IP law.  Second, countries such as India are service-based today, and that means EVERYONE gets to take home some money rather than focusing the wealth in the hands of a few.  (The last thing India wants is a return to the days of the Rajahs with a handful at the top.)  Lastly, (and this is the kicker), when you scale out the amount of economic growth that's taking place in countries such as India and China, the last thing they want to do is ship massive amounts of hard currency OUT of their economy to the U.S. for the privilege of developing software to improve business.  (And Microsoft is a veritable Hoover in its structuring of its subsidiaries.  No amount of in-country R&D re-investment can make up for the amount of money at risk here.)  Open source rules in a case like this.

Leap forward to China.  Same story.  Same debate.  Same mistaken thinking from the Western multinationals that somehow China wants to be like them or worse yet, ship all that money out of the economy (government perspective) or the market (corporate perspective).

I understand a naive Western marketing person's desire to believe that China is their next growth market but they fail to understand the economics involved.  This is why Linux rules here -- the cost of goods sold is significant when you add up the royalty payment times the population of customers.  I have held a Motorola Ming phone.  Developed in China for the Chinese market.  It is the sexiest little piece of hardware on the planet, and incredibly functional.  It's Linux-based. 

Why would Motorola want to send that much money in royalties to Symbian or Microsoft?  Yes, yes, I can hear the "we're so valuable" statements from those marketing managers already.   Frankly, I don't really want to read Word documents on a two inch by three inch screen.  The Ming is a work of art.  But I digress.

Several interesting items came out at the conference:

• China has its own document format standard called UOF.  It is somewhat consistent with ODF.  There is to be a convergence.  I learned at dinner one night that Red Flag has already built UOF support into Red Office, so hopefully the support will rapidly ripple back out through the OpenOffice.org community and the rest of the ODF supporting products will soon support UOF as well.  (Andy Updegrove also attended the conference.  He has made the connections and will hopefully have a proper article on UOF soon on his blog.)
• China is very respectful of IP.  They value patents.  They seem to be uninterested in supporting software patents.  They do however understand how patents might make a mess of the standards world, and are very interested in work like the new ex-ante based IPR policy from VITA.

This was the first event in which I've participated where there was simultaneous translation going on.  My slides needed to be handed in a week in advance such that they could be translated as well.  Wireless handsets were available so you could listen to the translation.  While one screen had the slide in English, the other had the Chinese slide.  Attendees and speakers simply worked in their native language.  It was fascinating to see it all just work.   

I've posted all my photos on flickr from the conference and the conference dinners.  I still need to get some names tagged, but it's a start.  All in all a great conference.  I learned a lot, and it was a privilege to participate.

Post to del.icio.us
digg it

www.flickr.com

This is a Flickr badge showing photos in a set called Open Standards, IPR, Innovation Conference. Make your own badge here.

Rambus, Patents, and Standards

The system DOES indeed work — just slowly sometimes.  Every once in a while I get embroiled in discussions with people that believe (a.) the sky IS falling with respect to patents and standards and hence (b.) we need to get all patent holders to forfeit their future business rights in overwrought and strict IPR policies within standards development organizations.  The Rambus abuse is universally the example of the danger, in a similar way that the SCO Group lawsuit is the singular data point extremists use when trying to spread open source litigation FUD. 

Occasionally I run into the debate that (c.) patents are so important in terms of value to a company that all other industry practices (e.g. standards, collaborative development, etc.) are subservient to this incredible tool, but these debates were typically inside Microsoft with its extreme IP fetish and can safely be ignored. 

The Rambus case is a classic case of submarine patents in a standards setting forum, cheating the rules, and litigating for fun and profit.  Today the U.S. Federal Trade Commission reversed its previous ruling and has slammed Rambus appropriately, stating that their practices were anticompetitive, and beginning the process of damage calculation.  Brilliant!  Here's the quotable bits:

... the Commission found that, through a course of deceptive conduct, Rambus was able to distort a critical standard-setting process and engage in an anticompetitive “hold up” of the computer memory industry. The Commission held that Rambus’s acts of deception constituted exclusionary conduct under Section 2 of the Sherman Act and contributed significantly to Rambus’s acquisition of monopoly power in the four relevant markets. The Commission has ordered additional briefings to determine the appropriate remedy for “the substantial competitive harm that Rambus’s course of deceptive conduct has inflicted.”

Here are the links:

• The FTC announcement is here.
• Andy Updegrove's excellent write-up is here, providing the historical background.  (Andy filed a friend of the court brief in this case, and has deep knowledge.)
• The FTC docket is here if you want the complete historical legal depth. 

I've long maintained that patents are simply tickets to negotiations. Occasionally the negotiations go awry.  Sometimes people abuse the rules.  In the end, the economics of the system works. 

Post to del.icio.us

OSCON 2006: Open Standards and the Open Source Initiative

The Open Source Initiative hosted a BoF last Thursday evening at OSCON 2006, and one of the primary topics of discussion was possible compliance criteria for an open standards requirement.  Lots of thought and effort has gone into developing a strawman proposal, and the discussion is just beginning.  I would strongly encourage you to participate in the discussion if you have a standards and open source background.  The discussion list sign-up is located at http://opensource.org/osr/. 

This issue has been simmering for a while now, all the way back through debates about the relationship between standards and open source, and comments from various open source participants about various standards development organizations' IPR policies.  The topic is coming back into the forefront. 

The rest of this post is the edited version of my first post to the OSI discussion alias.  I will happily entertain debate and discussion here, but would encourage your participation in the OSI discussions if you want to be heard in the outcome. 

First, let me state I agree with the goal of developing a clear statement supporting the ability to develop open source software implementations of standards.  Second, the following views and ideas were shaped over the years of participation in the POSIX/UNIX standards development process from the late 1980s.  (I'm still in recovery.)

I want to set the stage with a few definitions I keep in my head, so hopefully this is actually coherent.

Specifications and Standards:
A specification is simply a document describing some interface for interoperability.  Lots of companies publish specifications to enable customers and partners to better interoperate with their products.  In such cases, where the specification is published by a single commercial entity, it benefits the company by encouraging lots of add-ons.

A standard is a specification that has been put through some form of consensus process by a collection of interested parties.  It may be a formal government supported de jure process with checks and balances to ensure that the consensus isn't anticompetitive collusion. It may be an industry or trade organization (CBEMA, ECMA, IEEE) with a broad interest in an area, e.g. computing standards. It may be an industry group with narrower focus (e.g. OASIS, W3C, IETF).  The consensus process has rules that define such things as participation, acceptance, interpretation, amendment and withdrawal.

The economic purpose of a standard is to encourage and enable multiple implementations of the thing specified, i.e. it is the opposite of a company specification which benefits the company's own ecosystem.  A standard is designed to increase choice and benefit consumers.  A successful standard has to have multiple implementations that conform and interoperate.  If there's only one implementation, then it is just a vendor specification regardless of the process it was put through to receive a stamp of approval.

[For taxonometric completeness:

1. A de facto standard isn't.  A de facto standard is a technology that is so ubiquitous as to be "a standard in fact".  But it's typically controlled by a single vendor, i.e. not a lot of consensus involved.
2. A corporate standard is an ambiguous entity that may be selecting de facto technologies to simplify and narrow procurement choice, OR a reference to de jure standards that is designed to increase procurement choice.  Sometimes both.  Context is everything.]

Patents and Standards:
Patents exist to protect a single implementation of an idea. They serve a completely different purpose in the economic spectrum to standards which encourage multiple implementations.  Because of this, every standards organization has developed some form of IPR policy to attempt to survive the discovery of a patent in their midst, and indeed to discourage participants from embedding them so as to avoid such problems.

This does not mean there are not examples of industry standards groups being mirrored by trade organizations and relationships with patent sharing agreements. But within the standards organization itself, there is neither the legal bandwidth or financial depth to deal with them directly.  (And yes, some naive vendors would love to have a patent on a standard because obviously the world will want to beat a path to their door to pay a tax on the standard, but it seldom actually works out this way.)  

So here are my concerns per the current compliance criteria.

Criteria 1: The standard must include all details necessary for interoperable implementation.

This is tough.  Standards participants are there because of some level of experience and expertise (regardless of whether they are lone participants or corporately sponsored).  By definition the context of the discussions and debate result in a standard that has "holes" where things were simply "understood" by the participants.  This is why every formal organization needs rules to interpret and amend standards.  (Standards are actually living documents, but with a lifecycle more akin to trees than people.) English is an inexact language. 

As well, some holes are deliberate.  There is sometimes a fine line in relaxing the standard to allow implementation and conformance for as wide a set of participants as possible, without breaking the underlying interoperability model.  Without the IETF requirement of two independent and interoperable implementations, there is NO WAY TO KNOW if the standard includes all details necessary for implementation, or more exactly, all details necessary for interoperability.

Criteria 2: The standard must be freely and publicly available (e.g. from a stable web site) under royalty-free terms. 

I have no issue with this one per se, except that some of the core standards in our industry embodied in open source were expensive books in the past (e.g. ISO/ANSI C/C++, POSIX, UNIX, SQL).  REQUIRING this royalty free access seems a bit off.  Didn't stop us before.  Won't stop us in the future.

Criteria 3: All patents essential to implementation of the standard must be licensed under royalty-free terms. 

Today any standard can be shot by an idle patent from outside its community of interest, regardless of the occasional pathological abuse from within (i.e. Rambus), and regardless of the IPR policy in place.  Just like any community developed project licensed under an open source license.  No rules the OSI puts in place will change this.

You're asking me as a standards participant to agree to the terms for your  "open standard" definition, when I already have the ability to so declare through the standards orgs IPR policy or any public non-assert or covenant I make about my own patents, only to have it taken away by a non-participant at ANY time.  Why does this criteria have ANY value to me as a standards participant?

Criteria 4: There must not be any requirement for execution of a license agreement, NDA, grant, click-through, or any other form of paperwork to deploy conforming implementations of the standard.

By requiring no paperwork or click through to deploy conforming implementations of a standard, you just narrowed the definition of an "open standard" to only open source projects freely available on the web.  No product based on open source even fits if it has a support/maint contract in place.  And I think you would discover that if your definition of "open standard" excludes a standard that is properly implemented multiple times by closed source commercial products that interoperate, you'll be laughed out of the house of "open" by all participants in standards orgs the world over.

Criteria 5: Implementation of the standard must not require any other technology that fails to meet the criteria of these requirements.

The requirement that "open standards" implementations must not require any other technology that does not itself meet the open standards criteria dooms this to a utopian failure.  Many standards depend upon other standards.  If one at the bottom of the pile (or the end of the dependency list as the case may be) can invalidate the entire chain, I see no value as a standards participant to ever buying into your definition of "open standard".  It puts the implementation burden on me in such ways that I may not have control over it.  POSIX (IEEE) was based on C (CBEMA).  Different orgs, different rules of engagement, with different non-overlapping parties of participation.

The Term "Open":
The term "open" is perhaps a red herring here.  The term was polluted with respect to standards at least 15 years ago and customers and vendors alike have long memories.  We started with "standards", and the messaging battle moved to "open systems" to get away from the constraint of standards to which a vendor might have to actually conform and certify.  The term "open" was slammed onto "standards" to try to find yet more definitional integrity OR ambiguity, depending upon who you were. (Indeed we get to see the current fetish with marketing people and "open" in open source today.) 

Instead of trying to force a definition into a space where you are sailing into the teeth of the gale of mass vendor mass marketing that aligns with your goals only partially, and historical shoals on which to run aground, perhaps we can modify the terminology to suit the OSI need and to be readily defensible by the OSI.  What you really want is a "open source enabled standard", where regardless of the consensus process used to arrive at it, the product (i.e. the standard itself) can easily be identified as being implemented in open source software.

Implementation:
Culturally, you want standards organizations to adopt something similar to their IPR policy with respect to "open source enabled". You want each to have the simple ability to say that within their overall process of standards development, they can readily identify a standard as "open source enabled".

Participants in standards efforts are the customers of standards organizations.  As such, there needs to be the flexibility in the system to encourage the right thing to happen while preventing such a hard-line discussion that even should the OSI definition of "open standard" be adopted by the organization, the participants are sufficiently disenfranchised in how they meet their business needs that they move their standards setting efforts elsewhere.

Organizations as engineering-centric in their process as the IETF could create their own implementation by simply requiring one of the "at least two independent and interoperable implementations" be licensed under an OSI compliant license.  OASIS on the other hand could add an upfront step in the scope and reference terms of the working group similar to their IPR policy where the working group agrees to provide a reference implementation under an OSI compliant license. It wouldn't require every OASIS standard so to do, but rather gives their working groups the policy framework up front to declare their intentions for all to see (and OSS developers the encouragement to participate).

This gives vendor participants that support open source the ability to selectively support standards with open source implementations to competitive advantage, while still providing closed implementations themselves in other areas.

Those are the opening concerns and ideas.  Looking forward to the discussion.

Related Posts:

• Corwin's Razor and the OASIS IPR Policy (I discuss why I think the OASIS IPR policy was a good policy.)
• Standards and Open Source Software at OSBC (I discuss the economic connection between standards and open source and use ODF as a current example.)

Post to del.icio.us

ODF Acceptance, Microsoft's Big Lie, and a Standards Primer for Berlind

Last week saw some exceptional posting from Andy Updegrove on the "art of the big lie" and messaging battles between vendors supporting the Open Document Format (ODF) standard and Microsoft.  Andy does a fine job of calling the question, and brings an analysis to the story as a standards savvy lawyer that few journalists can in the rush to be "newsworthy".  David Berlind followed up calling the question on ISO and the value of standards in such a market contest between vendors.  Unfortunately, while Berlind's questions are the right ones, he doesn't necessarily have the background in standards to fill in the discussion accurately.  Even Gartner's analysts manage to get it wrong, assuming a 70% probability that ISO will refuse Microsoft's Office XML submission.  Let's set some ground work for the discussion.

ISO develops standards through its committees and working groups.  Member countries form delegations to such groups, through their national standards organizations (BSI, DIN, AFNOR, ANSI, etc.).  Each national group forms opinions and delegations through the participation of "experts" within the country.  A lot of these experts work for the vendors.  So you'll see coverage by large corporations like IBM and Sun by design.  (OASIS and ECMA membership to create the specification,  and then through various different national bodies to help encourage ISO adoption.)

It's a game of technology diplomacy, and in the end, after the dinners and meetings are over, the job is to expand one's area of economic influence and defend sovereign territory.  Microsoft tends to play the game poorly in so far as they don't necessarily invest to the depth that an IBM does in covering the board, nor do they appreciate that a diplomat is ultimately supposed to be invisible.  Fortunately (for the rest of us) they treat it too much like a direct market competition so their actions tend to be highly visible.  Their current standards strategy would tend to be patent focused since they appear to be rather (patent) lawyer heavy in the standards strategy team that is part of Legal and Corporate Affaires.  Again, they don't understand the economic dynamic.

The potential patent problems with Microsoft's proposed standard can't be fought at ISO or ECMA or any other standards development organization for that matter.  Standards and patents are orthogonal.

Standards exist in an economic system to encourage multiple implementations.  Patents exist in the economic system to protect a single implementation.  By definition these tools are focused on different economically conflicting jobs.   This is why every standards development organization needs rules about how to deal with patents.  It's not that they are encouraging the licensing of inbound property, but rather they need a way to handle the discussion of such intellectual property when they discover it in their midst, or to at least best prevent it from causing them grief from their own members by having the discussion up front.  (OASIS does actually have a great IPR policy at this point, because of how it forces the conversation.)  There is no economically feasible way to prevent an outside party with a patent from gumming up the works.

Microsoft will hammer away at their covenant not to sue with respect to patents and their Office XML formats, and ambiguity around which patents are covered under what circumstances.  So they likely can demonstrate to ISO that with their covenant they are well within ISO's IP policy and that this need not be a concern.  (Even the confusion they continue to engender around C#/CLI, patents, and the ECMA specs turned ISO standards, won't be a valuable example because no one could demonstrate that anyone is being hurt or that the confusion is a deliberate strategy.)

Then there's the issue with respect to competing standards. This too is a red herring.

While ISO certainly doesn't like to encourage competing or overlapping standards, they will not necessarily prevent them.  They are a standards development organization in place to ensure that the rules of development are transparent and followed.  It is not their role (nor do you ever want it to be) to manage the marketplace through determining the economic viability of a standard. 

They would be hard pressed to refuse to accept the fast track for the specification Microsoft drives through ECMA based on a scope that says "just like our yet to be delivered product".  That's not to say Sun and IBM participation won't seek to slow it down, and that would be a fine thing, but don't count on blocking the entrance of the standard.

A better way to tackle the problem may be to encourage procurement organizations to consider why they procure to standards.  Such organizations want the competition encouraged by multiple implementations, and the value in the innovation beyond the standard those implementations embody.  This is consistent with the rhetorical line Microsoft started with those same organizations when first realizing open source might threaten their control.  They helped establish the discussion that customers really want to procure against standards. 

But it first requires multiple implementations.

It is a very small step to encourage those agencies in their procurements to consider the measure of a standard's success to be the number of implementations of a standard against which they're procuring that presently exist versus promises from vendors of possible future implementations.  It opens the door for lots of demonstrations of interoperability between products, allowing the customer to make the decision based on other real world factors. 

It forces Microsoft to invest heavily in their relationships with the likes of Corel and Apple to try to cajole and arm twist other implementations of the Microsoft XML formats (which they won't be able to settle until they're ready to ship Office 12) or be caught being the only implementation of their own standard. 

A standard with only one implementation, regardless of the imprimatur of multiple standards organizations, is still a failure. 

Post to del.icio.us

Standards and Open Source Software at OSBC

I participated on a panel on the relationships between standards and open source software at the Open Source Business Conference in San Francisco yesterday, along with Bob Sutor (IBM), Tim Bray (Sun), Jason Matusow (Microsoft), and moderated by Andy Updegrove (Gesmer-Updegrove). (There are a few photos in a collection here, courtesy of Sun's OpenSolaris Community Manager, Jim Grisanzio.) I want to capture my notes on the primary economic relationships here.

When a market begins to mature, there comes a point when the incumbent vendor begins to over deliver functionality to their customers, faster than the customer can absorb it (and therefore the customer doesn't want to pay for it).  The technology space is mature enough at that point that the best integrated solution is no longer seen as the most valuable solution by the customer, and the technology space can componentize around a set of relevant standards. 

Customers want such standards, because they feel it will give them better choice.  The incumbent's competitors are only to happy to define standards to crack open the market away from the incumbent.  This is all pretty much straight out of Christensen's Innovator's Solution, with some personal observations based on past experience. 

This is where open source becomes relevant to the standards process.  Around what do the competitors choose to build a standard?  I would argue they choose a body of technology around which they have already collaborated for a period of time in the industry.  Because the collaboration has been happening, the vendors have existing practise and experience to determine what works or not.  The vendor marketing organizations even likely have certain "customers" they can build case studies around, because of various non-vendor participants in the collaborative space. 

• So when Digital Equipment Corp began over delivering on VAX/VMS faster than customers could absorb the new innovations, their competitors chose a large collaborative research project called UNIX that had existed for years to begin the standards base. 
• TCP/IP won over ISO OSI networking initiatives because the code base existed out of the DARPA and IETF experience. ("Rough consensus and running code.")
• In the content management world we're seeing this play out again as different vendors over deliver in the different content management spaces, and standards are appearing, rapidly adopted from the open source projects around which they have formed. 

And we're seeing this play out around Microsoft Office and the rise of the Open Document Format (ODF) standard.  Microsoft has over delivered to the bulk of their Office customers.  The customers are frustrated.  And Microsoft's competitors rallied around the OpenOffice project to act as a base from which to define ODF.  The next release of OpenOffice supported ODF. 

The interesting thing is the dilemma the incumbent faces.  They have to continue to deliver new product releases with new features and functions.  That's what Wall Street rewards them for doing.  And the incumbent is even brilliantly creating new innovations in the space and could be working feverishly to deliver them.  But the bulk of their customers are over served.  They can't eat the last round of innovations.  Why would they want to pay for the next round?  Remember, economically, innovation is a supply side activity — customers just want to buy solutions and they don't want to buy things they don't use regardless of how innovative they might indeed be.

So vendors use collaboratively developed technology bases (today often defined as open source projects) to act as a base for new standards work. 

Another part of the discussion that came out was around the purpose of standards.  Unfortunately this part of the discussion happened towards the end of the panel and I think parts of it were lost.

Standards exist to enable and encourage multiple implementations, regardless of the forum in which they are created.  It benefits the consumer.  Likewise, a vendor specification regardless of whether it has gone through a formal standards or consortia forum exists to encourage multiple add-ons to a single implementation, i.e. it benefits the supplier.  I have never liked the term de facto standard — it is really a de facto technology.  So in our case above, it is the incumbent's technology that is dominant in a market space. 

So a successful standard (measured economically) has many implementations.  A failed standard is one for which there is only one implementation.  In the ODF case, there are already a number of product implementations available, derived from the OpenOffice code base. In the Microsoft Office XML standards work underway at ECMA International, there is only the yet to be shipped Microsoft Office 12 product. 

Jason (rightly) called me out on this rather presumptuous observation, but in his explanation I thought I heard him say that Microsoft is defining the new Microsoft Office standard indeed to encourage multiple implementations, AND to encourage developers to innovate around the Microsoft Office document formats.  In the first case, it would be bad business to encourage multiple implementations of a product that is responsible for 50% of the revenue stream.  In the latter case, it's just another vendor specification  to benefit the vendor regardless of the standards imprimatur.

All in all a good panel discussion (despite Tim's comments that it could have been more exciting).  I look forward to continuing the debate, and would love people to comment with other examples of where a collaborative project has acted as the base of a new standards effort.