Standards and Patents (Educating colleagues)

Usually, I do not write twice about the same thing. And usually I am not very disciplined about blogging.

However, after my last blog entry, I have had multiple twitter interaction with a twitter user (@DrPantera). And finally I have decided that I have to post something that should serve as general standards education.

I want reproduce every interaction (which, by the way are in Spanish) but just give some general ideas. During our twitter discussion this user said:

• Only Microsoft can implement ISO/IEC 29500.
• It is nonsense standardizing a tool that only one company can implement.

I think both assertions are false. Firstly, I will explain why.

ISO/IEC 29500 defines a set of standard files format. So, it is not appropriate to speak about implementing the ISO/IEC 29500. What somebody can implement is a tool to produce, read, process, render (or whatever) files in such a format.

Anyway, the real argument was that as some parts of the format are protected by patents, only the patent holder (Microsoft in this case) can implement it. I argued, that another company could license the patent. The counterargument is that only licensed companies would implement. That's right, that is how business work.

As the discussion was going on. I thought that instead of speculating the right thing was to go the right source: ISO.

Reading this page about Standards and Patents in the ISO Website was crystal clear:

First: ISO, IEC and ITU have a common patent policy. I am not a lawyer, read it yourself to be sure. However what I interpret in short is that if a deliverable contains provisions depending on a patent there are 3 options: either the patent holder agrees to negotiate licenses free of charge or the patent holder agrees to negotiate licenses with charge or the provisions are removed from the deliverable. In all cases license negotiations need to be on a nondiscriminatory basis on reasonable terms and conditions.

Second: What model applies to ISO/IEC 29500? Well in the same page there is en Excel file with all the current standards and associated patent holders. OK. What doest it says about 29500? There are patent notes at the name of Microsoft and the entry is marked with an "F".

What does the "F" means. Literally: <"F" = Prepared to grant a license free of charge>.

By the way, according to the same sources:

• ISO/IEC 14496-14 (MP4) is related to a patent from Apple (US Patent numbers 6,134,243,6,453,355).
• ISO/IEC 15444-3 (JPEG) is related to a patent from Apple (6,134,243).
• ISO/IEC 32000-1 (PDF) is related to a patent from Adobe Sytems Incorporated 
• ISO/IEC 11172 series (MP3) is related to patents from very long list of companies.
• ISO/IEC 14496-10 (MP4) is related to patents from another long lsit of companies.

Most of those patentes do not have the "F", so you need to negotiate a patent licensing and eventually pay for it.

There is an important point on all this. There are some things that we have been forgetting for a long time in Higher Education of Computer Professionals.

FIRST: An engineer must always be as agonostic as possible. This means that if possible he/she must go to the right sources to get the right information. Moreover, making claims only based on available date is included both in IEEE and ACM code of Ethics.

SECOND: Understanding of standards is essential to any Computer or Software Engineer these days. It is important to understand the technical issues in the standards. But as I have shown this is not enough. It is important also to understand which is are the rules of standards bodies, how different stakeholders are represented (or sometimes underrepresented) in standardization, which are the standardization procedures.

THIRD: A basic knowledge of law is also very important. I have shown here that sometimes national laws may enforce the use of a standard. It is also very important that we as engineers are able to understand the implications of intellectual property and the role of patents (where applicable).

And coming back to our code of ethics, I feel that this post is writteng according to item 10 of IEEE Code of Ethics (to assist colleagues and co-workers in their professional development and to support them in following this code of ethics), and similar provisions in the ACM code of ethics and in the ACM Software Engineering Code of Ethics.

IMPORTANTE NOTICE: If you find that anythin of this post is not true or has any inacurracy, please, contact me and I will correct it inmediately.

Standards and Open Standards

When I write something about standards, usually is about C++. This post is not the case, so if you were reading this looking for C++ info, stop now.

A few hours ago, a good friend of mine (@jmdodero) wrote this tweet:

El MAP dice que docx es abierto! Standards for ES Public Administrations http://www.boe.es/boe/dias/2012/10/31/pdfs/BOE-A-2012-13501.pdf …

In English: "The Spanish Public Administration ministry says that docx is open! Standards for ES (Spanish) Public Adminstrations". The link points to an official document from the Spanish Government approving the Technical Standard of Standards Catalogue Interoperability. In essence this document establishes a list of standards to be used for the Spanish Public Administration.

I'll save you the legal details. However one of the items in the list is:

• Category: File formats - Image and/or Text.
• Common Name: Strict Open XML
• Formal Name: ISO/IEC 29500-1:2012 Information technology -- Document description and Processing languages -- Office Open XML File Formats -- Part 1: Fundamentals and Markup Language Reference - Strict
• Type: Open
• Version (minimum accepted): 2012
• Extension: docx, xlsx, pptx

A few minutes later. I answered:

ISO/IEC 29500-1:2012 y ECMA-376. Las dos públicamente disponibles = estándar abierto. ¿Cuál es el problema?

In English:

IOS/IEC 29500-1:2012 and ECMA-376. Both publicly available = open standards ¿What is the problem?

I should not be a typical suspect. I mean, I run a Linux laptop and 2 android devices. Many know that I think that the best editor is vi (vim is ok, too) and a really like LaTeX. However in a few minutes I got the following answers:

• @jdgarciauc3m when you save a document in MS Office 2010 […] you are not saving them in the advertised OpenXML format This document will hence NOT be properly readable by other software http://t.co/AeohSarn
• @jdgarciauc3m que no existe ninguna implementación del standard, ni siquiera MS Office lo soporta
• There exists no implementation of the standard, even MS Office does not support it.

Well, I thought that it was time to clarify what a I think. I'll try to do so:

Question 1: Is ISO/IEC 29500-1:2012 an open standard?

Well, this is the easiest question. By definition any ISO/IEC standard is an International Standard. I could explain this in more detail, but for now let's agree on this.

The definition of "Open Standard" is "a standard that is publicly available". As any other ISO standard, ISO/IEC 29500-1:2012 is available from www.iso.org.

Question 2: Does MS Office 2010 fulfill the ISO/IEC 29500-1:2012?

I hope not.

Surprised?

It is almost impossible that a product shipped in 2010 fulfills a standard that has been approved in 2012. The only possibility I see is that people at Microsoft had a time machine. And, I do not think they have (otherwise sometimes they would have made different business decissions), but, paraphrasing Michael Ende, that is a different story and must be told in a different time.

Question 3: If there is no existing implementation of the standadrd does it make sens to put it in the catalogue?

Yes. Let me explain why.

First. No one implements a file format. What one can implement is a tool for processing files (generate them, render them, ...) in such a format. However it may be true (I do not know and I do not mind), that no existing tool correctly processes the format.

What the Spanish official document is saying is that if a public agency wants to receive text documents from another public agency or a citizen, it must say which formats is willing to accept. By the way, ODT (ISO/IEC 26300:2006) , PDF (ISO/IEC 32000-1:2008) and PDF/A(ISO/IEC 19005-1:2005 and ISO/IEC 19005-2:2011) are also in the same list.

So, the point is. We have a format in the list and when some tools are available it is possible that an agency includes in the list that format.

I still do not see the problem.

Important news for the C++ Community

C++11 has been a major step for the C++ community. However, we need to do much more in the forthcoming years to help developers prodece better and faster software.

I recommend all of you interested in C++ to see Herb Sutter's talk this Friday:


The Future of C++ 
Friday, November 2, 2012
12:45pm (U.S. Pacific Time)

Probably, for those of you in Europe the time is not the best. In any case, it will be available for download a couple of days later. 

Let me tell you, that there will be at least one important announcement for C++ community.

To throw or not to throw: That is the question

While having dinner with some colleagues. We had an interesting discussion on the usefulness of throwing exceptions from libraries.

The discussion lead to comments on two books:

• C++ Coding Standards: 101 Rules, Guidelines, and best practices. By Sutter and Alexandrescu.
• API Design for C++. By Martin Reddy.

As I remember the conversation the statement was more or less "A (well designed) API should not throw". My first thougt was that some time had passed since I read both books and that I did not remember the rule to be so severe. So I decided to go back and read again the books. First of all let me say that I enjoyed a lot reading both of them. C++ Coding Standards is an excellent book and I am really willing to see when Sutter and Alexandrescu release a C++11 update of the book. C++ API Design is a good book. Although I may have some concerns on specific parts of it, I like it. And I have used some chapters in an invited course I gave on software design and patterns in C++.

Now, let's go to the topic.

A lot has been said about exceptions in general as an error reporting mechanism. One of my colleagues found conflicting the following advices/rules:

• Prefer exceptions to report errors. This is guideline 72 from Sutter and Alexandrescu.
• Don't allow exceptions to propagate accross module boundaries. This is guideline 62 from Sutter and Alexandrescu.

At first sight, it seems that both rules are conflicting. Are they? As some imprecise reference on API design for C++ was also done. I decided to go first to this one. I did not really find anything in Reddy's book against the usage of exceptions in general. What Reddy does is to provide good suggestions if you provide error reporting through exceptions in your library. To be fair, it also states that "Google forbids the use of exceptions in their C++ coding conventios because most of their existing code is not tolerant of exceptions". However that does not seem an argument against the usage of exceptions.

Now, let's go back to rules 62 and 72 from the C++ Coding Standards book. I will start with rule 72. I usually prefer this rule and I usually report errors through exception. The key rationale is that it easily allows to make a separation between the point were the error condition is detected and the point where the error condition is handled. This is generally what happens when a library does not know what to do when it detects the error.

Exceptions exhibit advantages over returning error codes:

•  Exceptions can't be silently ignored.
•  Exceptions propagate automatically.
•  Exceptions handling removes error handling and recovery from the main line of control flow.
•  Exception handling is a very good alternative for reporting errors from constructors and operators.

Some general disadvantages may be identified:

• Writing exception safe code is not easy for beginners and special care must be taken in destructors.
• Having exception compiler flags activated may lead to larger executable sizes. And in some platforms to minor performance penalties. However as even the standard library may throw exceptions it does not seem practical to deactivate those compiler options. And if the flags are activated the performance penalty is very low or even zero.

And finally let's got to the conflictive rule 62. If I read it as an absolute rule I am told that I should not propagate exceptions outside a module. My first answer was: "Well it depends on what you call a module". So I decided to read again rule 62.

I found out that Sutter and Alexandrescu name several things as a module. Their general definition is any cohesive unit of release maintained by the same person/team and consistently compiled with the same compiler and settings. Several grain size apply:

• A single object file delivering a single class.
• A single shared/dynamic library

As I read rule 62 and go through the summary I find an "unless". So the rule really says:

"Don't allow exceptions to propagate accross module boundaries unless you control the compiler and compiler flags used to build both sides". 

Now I got it. The reasoning behind the rule is that there is no standard for ABI. That is Application Binary Interface is dependent on compiler vendors and platforms.

So we have the following cases:

1. Applications using static linking. In that case you do not need to bother you can throw exceptions as they are needed.
2. Applications using dynamic linking in which the dynamic library and the client code are compiled by the same team, or tat least use the same compiler and the same compiler flags. I do not see a problem here either.
3. Applications using dynamic linking in which the dynamic library are distributed in binary format and/or are compiled with different settings. That is the case where we cannot have the luxury of propagating exceptions.

Is there any other reason to avoid the usage of exceptions? Well. Yes. There are.

Some specific guidelines for high integrity safety critical software may exclude using exceptions for different reasons. But that's a diffeent story.

A partir de ahora, también en inglés

En el pasado he recibido peticiones de poner en inglés alguna entrada de mi blog. Me sorprendió la verdad.

Mi primer impulso fue poner un plugin de google-translate. Sin embargo algunas cosas no acabaron de funcionar. Especialmente cuando empecé a poner código C++ en las entradas.

Conclusión. A partir de ahora algunas entradas las pondré en inglés.