I'll try but will depend whether I can setup a VoIP call from the wifi in the hotel I'm staying. That's why I was aiming at sending an email. Cheers, Juanjo Juanjo from iPhone El 13 ago 2016, a las 8:49, Mulligan, Catherine E A <c.mulligan at imperial.ac.uk<mailto:c.mulligan at imperial.ac.uk>> escribió: Hi Juanjo, That's great sorry didn't realise martin was on the list:) Can I suggest you just make a quick phone call on Monday to the guys at ETSI and let us know what they say about wording? Best, Cathy Get Outlook for Android<https://aka.ms/ghei36> On Sat, Aug 13, 2016 at 1:31 PM +0100, "Juanjo Hierro" <juanjose.hierro at telefonica.com<mailto:juanjose.hierro at telefonica.com>> wrote: Hi Cathy, Sounds like we are on the same page but a few comments ... Again, "public and royalty-free" is an example of FRAND terms, IMHO. Therefore, saying that we go for "public and royalty-free" API specs should not be seen as going against the ETSI IPR policy. This has to be one point in our argumentation. We may also elaborate on the rationale: why we need that API specs be "public and royalty-free (e.g., without this, as you say, our intent will fall over). I agree on seeking for advise to ETSI on how to write this in the ToR, but not seeking their advise about whether API specs have to be "public and royalty-free" or not. It is us who know what we want (as you say, for example cities need to ensure that they can implement the APIs without royalties). It is not them. I guess we agree here but want to double-check. Delivery of "public and royalty-free" specs of the APIs by ETSI does not necessarily require that there will be an open source reference implementation also under the scope of the ETSI ISG. This topic was previously discussed with them and, despite as you say there some precedents about open source projects within ETSI, their advise was to avoid that approach because a) it would not be needed for publishing technical specs and b) would take a much longer path until approval. Of course, we may add to our argumentation that the formula of "public and royalty-free" specs of the APIs is required to allow existence of open source reference implementations, which is something that the market demands. But going up to the point that development of such open source reference implementation should be under the umbrella of the ETSI ISG activities would mean going too far ... If it is confirmed that we are all on the same page, I will come with a text proposal for the body of the message to be sent with the rationale going for "public and royalty-free" specs of the APIs (and I guess data models as well) and seeking for their advice on how to properly capture that in the ToR. Then we discuss that text amont us and when agreed, we can submit it to ETSI. Cheers, -- Juanjo P.D.: BTW, Martin Brynskov is in the fiware-oasc-etsi mailing list, so no need to copy him if your concern was he may not be in the list. On 13/08/16 12:24, Mulligan, Catherine E A wrote: 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> http://www.contextualised.com/ + 44 753 888 7477 c.mulligan at imperial.ac.uk<mailto:c.mulligan at imperial.ac.uk> From: <<mailto:fiware-oasc-etsi-bounces at lists.fiware.org>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 <<mailto:Lindsay.Frost at neclab.eu>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 ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20160813/31a5fed9/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy