Dear Juanjo, dear all, Juanjo emailed me at 17:01, expressing a strong desire to arrive at a text which expresses "royalty-free" and is easily acceptable to ETSI and potential CIM members. I try to provide one below for you all to consider. Work in the CIM ISG will follow an implementation-driven approach, as opposed to a "design by committee" approach, and it will be focused on agile delivery. The development will be backed by experience obtained through open source implementations. Group Specifications of the CIM API and of CIM Data Models developed within the CIM ISG will be public and CIM ISG Members and Participants agree to follow ETSI IPR Policy. In addition, CIM ISG Members and Participants agree that, in order to maximize the acceptance of the standards and to collaborate with open-source software platforms (such as FIWARE and other EC or global projects), any of their IPR contained in their contributions, which is essential IPR for the CIM API or the CIM Data Models developed within CIM ISG, will be licensed for that usage by them on a royalty-free basis (so-called RAND-Z). Of course this is without the benefit of lawyers' advice, but I hope it will meet with all Founding Members' approval, at least until ETSI comments on the wording. /Lindsay ________________________________________ Dr. Lindsay Frost, Chief Standardization Eng. frost at neclab.eu<mailto:frost at neclab.eu> Mobile +49.163.275.1734 NEC Laboratories Europe, Kurfürsten-Anlage 36, D-69115 Heidelberg, Germany. Reg. Headoffice: NEC Europe Ltd, VAT DE161569151 Athene, Odyssey Business Park, West End Road, London HA4 6QE, Reg. in England 2832014 From: Mulligan, Catherine E A [mailto:c.mulligan at imperial.ac.uk] Sent: Samstag, 13. August 2016 19:55 To: JUAN JOSE HIERRO SUREDA Cc: Lindsay Frost; franck.le-gall at eglobalmark.com; fiware-oasc-etsi at lists.fiware.org; Martin Brynskov Subject: Re: [Fiware-oasc-etsi] Revised version of ToR ready for submission OK, please just ask them - they will probably already have example text for situations like this. //C -- 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: JUAN JOSE HIERRO SUREDA <juanjose.hierro at telefonica.com<mailto:juanjose.hierro at telefonica.com>> Date: Saturday, 13 August 2016 at 15:33 To: Cathy Mulligan <c.mulligan at imperial.ac.uk<mailto:c.mulligan at imperial.ac.uk>> Cc: 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>>, Martin Brynskov <martin.brynskov at oascities.org<mailto:martin.brynskov at oascities.org>> Subject: Re: [Fiware-oasc-etsi] Revised version of ToR ready for submission 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/ + 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 ________________________________ 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/20160815/8efe3e78/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy