[Fiware-oasc-etsi] Revised version of ToR ready for submission

[Mulligan, Catherine E A]

Hi All,

In my previous life (Ericsson in Stockholm), I worked extensively with standardisation in 3GPP, ETSI and also a little in OMA.  I worked for a short while on both telecom APIs and Open API telecom standards.

I have never heard of an API being subject to royalties either - but to be honest ETSI is FRAND.  Full stop.

What would need to happen is the API components would be released as open source under e.g. GPL or another appropriate open source mechanism (and this is something that the ISG should definitely have as part of its agenda - where it is appropriate to release this as open source).  There is precedent for this in both ETSI and 3GPP.

I have also checked with my husband (who is an Ericsson "Expert" in Standardisation and System Architecture) regarding ETSI's perspective on this.  There is precedent for FRAND and open source and the ISG should try to investigate how to handle this.

I therefore recommend either a phone call to ETSI to ask this or an email to ask for advice on how to phrase this in the ISG document.

They have definitely heard the question before - e.g. around royalty free codecs.

We definitely need to ensure that e.g. Cities are able to implement the APIs if they want to in order to connect systems into the standardised interfaces.  Without this, the market will fall over; we have seen this a number of times previously.

In short - we are all in agreement about what we want to achieve (cost free APIs) but we need to ask advice about how to write it in the document.

Best,
Cathy

--
Dr Catherine Mulligan
Research Fellow
Associate Director, Imperial College Centre for Cryptocurrency Research and Engineering

OASC Standardisation // oascities.org<http://oascities.org/>
Director and Co-Founder of Contextualised // http://www.contextualised.com/
+ 44 753 888 7477
c.mulligan at imperial.ac.uk<mailto:c.mulligan at imperial.ac.uk>


From: <fiware-oasc-etsi-bounces at lists.fiware.org<mailto:fiware-oasc-etsi-bounces at lists.fiware.org>> on behalf of Juanjo Hierro <juanjose.hierro at telefonica.com<mailto:juanjose.hierro at telefonica.com>>
Date: Saturday, 13 August 2016 at 10:59
To: Lindsay Frost <Lindsay.Frost at neclab.eu<mailto:Lindsay.Frost at neclab.eu>>, "franck.le-gall at eglobalmark.com<mailto:franck.le-gall at eglobalmark.com>" <franck.le-gall at eglobalmark.com<mailto:franck.le-gall at eglobalmark.com>>, "fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org>" <fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org>>
Subject: Re: [Fiware-oasc-etsi] Revised version of ToR ready for submission


  I would agree with highlighting the word "and royalty-free" and even highlight the topic in the body of the mail to send.   This is an important matter and we have to make ETSI clear what we pretend.

  However, we don't agree this is a topic about which we should "ask for advice".   If we seek for advice, ETSI may come saying that they would advice specs are not royalty-free and then what?

  I believe that we shall highlight this matter and point out that we understand that "public and royalty-free" regarding specs will comply with ETSI IPR, but we want to confirm this with them.  We should also elaborate on the rationale for that.

  Again, we will by no chance be successfull in the market if we end up producing API specs that are not public and royalty-free.   This is the principle that any relevant body involved in specifications of open standard APIs adopt (W3C, OMG, ...).   Nothing to say about APIs that become de-facto standards relying on the fact that their development is bound to open source initiatives (which, regarding de-facto standards, is actually a trend).

  For the avoidance of doubts, the scenario we want to avoid is that any organization joins as member or participant, starts to contribute to the spec, and then suddenly surprise all of us claiming licensing rights (i.e., payment of royalties) to potential implementors of the specs based on their contribution.   And they would have the right to do so if specs are expected to be bound to FRAND terms (i.e., ambiguous enough regarding payment of royalties).   This would kill immediately the chan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20160813/9b2c952f/attachment.html>