The “Open Source Standard” Oxymoron

Recently I explained why the forthcoming Accellera UVM Standard will not be released under an open source license.  UVM will have an open source reference implementation associated with it, but the actual UVM Standard will not be open source.  After the blog was posted, some people reasonably complained that I did not really explain the differences between Standards and open source, and that I was much too cursory in why I deem “open source Standard” to be an oxymoron.  In response to these comments, I replied that a more detailed examination of the issue would be forthcoming.  This is it.

First, “Standard” is short for “standard definition”.   Different sorts of items may be standardized, e.g., a unit of measurement like the meter, protocols for a type of communication like the 802.11 standards, or a design language like SystemVerilog.  In every case, the definition of an item must meet the following four criteria to be a full Standard:

• Completeness. There ought to be no need to look outside the definition, except to other Standards from which this Standard is derived.
• Unambiguity. The definition must not leave an expert reader of the Standard unsure of the Standard developers’ meaning on any point.
• Stability. The definition must be valid for a substantial period of time during which users of the Standard can rely on the definition not changing.
• Owned. There must be a person/group in charge of the definition to whom defects, e.g., ambiguity, can be reported, and who will determine when and how the definition will be updated.

Of course, many Standards, including EDA Standards, fall short in meeting some of the above criteria– ambiguity is particularly problematic.  However, whatever their particular failings, any Standards setting entity must have the intention of meeting the stated criteria to be legitimate.  Indeed, all of the EDA Standards groups of which I am aware do strive to meet these criteria.

Note also that there is no mention in the above list of the openness of the Standard’s making process– a good Standard could be declared by Imperial fiat.  Nor is there any requirement for a formal Standards organization to be involved.  A Standard could be defined within a single company, have no validity/visibility outside of that company, but could still be a fine company Standard.

Finally, there is no uniqueness requirement for Standards.  One of the “funny lines” that I have heard far too often is “Standards are great because we have so many of them to choose from”.  My (generally muted) response is: “What’s your point?”  For example, both NEMA and EESTI have developed Standards for electrical plugs (for the US and most of Continental Europe, respectively).  The fact that their plug Standards are very different does not make them any less Standards.  If you have a device with a plug that meets the EESTI plug Standard, that device will be able to be used without adapter in any EESTI compliant socket.  It might, as a matter of fact, be better for only a single Standard to exist in a particular technology area/market, but that is not an issue directly related to Standardization itself.

Unlike Standards, open source IP (software, hardware, documentation…) is very much defined by the license under which it is released, rather than characteristics of the IP itself.  For example, the Open Source Initiative has developed a very good set of criteria with which open source software must comply.  Note that all of these criteria, except the second, refer to characteristics of the license under which open source software must be released.  An open source license, for example, must allow for unencumbered re-distribution of both the original software and any derived works.  The license must not discriminate against any person, groups or field of endeavor, and so on.  In general, almost all of the OSI’s criteria are focused on the terms under which the open source software is released.

The outlier is the OSI’s second criterion.  This is not about a license, but about the required presence of source code in an open source release– which makes sense given that this set of criteria comes from a software organization.  I would generalize this requirement to read that open source IP must be delivered in a “modifiable” form.  To see how this “modifiable” criterion applies beyond the software case, consider the UVM User’s Guide.  This document is available in MS Word format under the Apache 2.0 open source license as part of the UVM release (and, as such, is easily modifiable).  On the other hand, it would have been inappropriate if this document had been released in PDF form under Apache 2.0, since it would then not have been easily modifiable.

I shall not go through the exercise here of generalizing all of the other OSI criteria to make them apply to open source IP in general, since such generalizations ought to be fairly obvious.  Rather, I want to focus on the overarching thrust of these criteria: the ability of the open source licensee to modify the licensed open source IP, and re-distribute the “derived works” without significant restrictions.  The Holy Grail for most developers/distributors of open source IP would be a sort of viral reaction, where open source licensees take the original IP, modify it to add significant improvements and redistribute the resulting IP to other developers.  The developers receiving the derived works would in turn make further significant improvements, redistribute the results, and so on.  In an ideal world, all of these improvements would be periodically collected (“swept up”) into an updated single open source release, and the process could begin again.  As anyone who ever confronted the multitude of Linux releases can attest, this rarely happens, but the intention remains.

Now, let’s compare open source IP with Standardized IP.  Looking at the four criteria I proposed above for a true Standard, there is no reason why the specification of open source IP cannot be complete and/or unambiguous.  Of course, completeness and unambiguity is rarely a focus of open source developers.  However, neither criterion can be excluded a priori by the nature of open source.  Furthermore, most (if not all) open source “groups” have an ownership group—for example, Linus Torvalds still owns the core Linux.

The real difference between a Standard and open source IP lies in the “stability” criteria.  A Standard is by its very nature fixed until its owner(s) changes it. It is this stability that allows users to rely on the definition at the core of the Standard.  Open source IP, on the other hand, is by its very nature “open”. While there may be a core version owned by some group, the glory of open source IP is the fact that it may be modified and redistributed pretty much at will.

There is an irreconcilable divide that has been drawn here. In short, any Standard that is allowed to be freely modified and redistributed, even if such modifications are required to be clearly identified, has its status as a “Standard” severely eroded.  Similarly, any purported open source IP, which does not allow free modification and redistribution, has missed fulfilling several critical open source criteria.

That is why I say that “open source Standard’ is an oxymoron.

In closing, I would point out that I have not addressed the issue as to whether non-open source software can ever itself be a Standard.  I also have not discussed why/when/how long software (open source or not) ought to accompany Standards as “reference implementations”.  These will all be addressed in later releases of this blog.