I’ve been reading Jochen Friedrich’s Open Blog: Tensions between IPRs and ICT standardisation – Need for action on all sides. Jochem raises some interesting points.
“5. The topic of ex ante declaration of licensing terms remains disputed. Yet, there seems to be a dividing line between software standardisation on the one hand and telecommunication on the other hand.”
No real surprises here: the points is that as long as the declaration requirements of each standards body (SDO or SSO) are clear and well-known – call it ‘Different folks with different yokes’ – industry and stakeholders will judge which body and which standard is most appropriate for addressing a particular problem/requirement. If a particular industry insists that RAND terms are essential for a particular technology and/or that ex-ante discolusre is not appropriate and as such will work with standard organization x rather than y, surely it will be the market and public procurement agencies who will decide whether they accept that, or whether they work with another standard, another body or another technology.
“7. The idea for a Software Interoperability Directive was brought forward that governs that standards for software interoperability should be available under terms and conditions that allow their implementation in open source.”
There is widespread agreement that it would be a mistake for any public authority to lay down interoperability rules based on specific technologies: “In order for system a and b to interoperate, thou shalt use product x.”
So we must be very clear in answering the question: “what’s the point of interoperability?”, in both senses of the question, “why bother?” as well “at which point, where, do we want/need interoperability?”.
The danger lies in focusing on interoperability between software: software changes all the time and attempts to have ‘tight-coupling’ between two code-bases is brittle and prone to failure. On the other hand, the needs and requirements (that software packages attempt to address) do not, or change much less frequently. It is ‘product features’ that address specific functional needs, not the whole shebang of a software package. What we really need to address therefore is interoperability of features.
We have one common model for that in software engineering, it is an API and we may need more, with greater take-up of distributed, SOA-based systems as well as so-called “cloud computing” solutions. Any developer or software corporation should be able to open up or protect its software codebase in line with its business model and corporate philosophy. If there are interoperability demands, these should be formulated in terms of providing open interfaces to features and feature sets rather than point-to-point, hard-wired interoperability – interoperability based on function, not form.