Thanks very much to Ute Decker for taking minutes.


  1. Erwin Tenhumberg (SAP)
  2. Michel Lacroix (EC)
  3. Francisco Mingorance (BSA)
  4. Ute Decker (BSA - Minutes)
  5. Rigo Wenning (Moderator - W3C)
  6. Trond Arne Undheim (OFE)
  7. Earl Nied (Intel)
  8. Shane Coughlan (FSFE)

Summary of Actions:

  • Ute Decker to provide a replacement paragraph for achieving interoperability outside standardization organizations. (Rigo will adapt and put in and note diverging opinions)
  • Erwin Tenhumberg to provide a position of SAP whether software has special requirements on standardization by email
  • Trond to send a suggested action on a study concerning specificities on software
  • Earl to send criteria determining Intel's choice for RF or FRAND regimes as far as they can be disclosed.
  • Trond to send a paragraph that is less technical and exposes interoperability as a general principle
  • Rigo to send email asking about opinions whether software has specific requirements in standardization and if yes, what those requirements are.


Until today, only a corrected version of his statement was received from Bernd Geiger. There were no other comments on the issues as set out in the document.

Rigo announced that the document is due for 13 March and that we have one week to send proposed trends and barriers and actions. Deadline for input will be 12 March. Rigo will edit the report on 7/8 March and people should look at the new Draft on Monday 9 March.

Ute Decker wanted to drill down a bit further on the question why OSS has so much trouble with FRAND standards. Shane Coughlan repeated some points from the FSFE statement and added that one of the major inhibitors is the absence of sublicensing in FRAND licenses. As OSS is supposed to be given to third parties that can also alter the code, the lack of sublicensing possibilities hinders the OSS way of producing software. After debate, a study on this subject may be a suggested action that could find consensus.

BSA remarked that the report is currently missing some depth on how interoperability is achieved in the market place and the role of standards - BSA will send a paragraph with more details that can replace the basic remarks in the report

All participants agreed that this group should make clear in the report that referencing and recognition of Specifications of Fora and Consortia is a consensus position of all stakeholders of this group. The text in the report should be amended in that regard.

Rigo reported from the ICT Standardization Steering Group and asked, whether the Group can be more specific to software. This triggered a bigger discussion as it is assumed that the recognition of software specifics would require more careful consideration of patents on those software standards. BSA did not like the distinction as software is ubiquituous in e.g also in embedded systems. There is no definition of software that would allow to distinguish software from other ICT things. OFE disagreed as there are specific interoperability needs in software and those have to be taken into account. Trond suggested to have a study on what is specific to software interoperability and what requirements are needed. Rigo made a distinction between interoperation (of devices) and interoperability (APIs, formats, function calls, libraries) that are specific to software. Francisco offered to send the list of Standards compiled by BSA for the EIF discussion (all FRAND) and wondered which of those would be a software standard. The dispute turned around whether the subject is sufficiently mature to suggest a study as a possible action. Erwin Tenhumberg was asked to send his position by email, whether SAP thinks that software is a special case and would have specific needs in terms of standardization. The group agreed that it would be good to get feedback from all and Rigo was tasked to send a request to all members of the group via email. Earl Nied said that Intel does not distinguish between software and non-software. He gave the example of a CPU instruction set that could be emulated in software. The patent on the instruction set would also cover the software emulation. Earl continued to say that RF makes sense in specific market situations where FRAND made more sense in other situation, independent on whether confronted with software or hardware, so there could even be RF on hardware, but also FRAND on software depending on the market and task. Rigo asked Earl to convey the criteria that determine Intel's choice on whether a RF or FRAND model is chosen in email back to the group as far as it can be disclosed. Earl said that the decision depends on the value and use of the patent and that it is a multi-dimensional decision that is not always focused on royalties. Intel had cases where they haven't asked for royalties even though the standard was under FRAND.

The discussion brought us back to the question of royalty collection vs networking effects. There was an agreement that networking effects are very important in the standardization and also in the debate and that the report has not put sufficient emphasis on them.

Seeking for more areas of agreement, the group turned to the ex-ante discussion. Again, Earl invoked that not everything can be solved with an ex-ante approach. General mandatory ex-ante could jam a system because of the negotiations necessary in the beginning and where a participant required to make a price does not yet understand the business model. It would not solve the issue of stacked patents for the implementation of a device (sometimes hundreds of patents for one device) as ex-ante alone does not solve the coordination issue and would not cover patents that touch a certain implementation but is not essential to the standard. He also said there are limits to transparency where companies do not understand yet enough to make an informed choice about pricing. Also it is not obvious to determine the number of patents reading to the standard up front as there may be too many of them from all kinds of sources. Would the ex-ante price given still hold in face of the discovery of 20 more patents that are needed to build the technology? Earl concluded that ex-ante would be a very useful tool, but that the use of this tool has to be determined depending on the situation and not generally mandated.