DRAFT Fair Use Policy for using Metadata and Content

[Nick Piggott (RadioDNS)]

Hello,

At our Automotive and Broadcaster Workshop, the issue of "Fair Use" of metadata and content provided using RadioDNS' standards was raised.

In response, RadioDNS has started work on a Fair Use Policy document, and we are circulating this first draft for comments.

This document is not intended to be a licence or a contract document, but we would expect that the licences that broadcasters offer manufacturers would not contradict the principles laid out in the Fair Use Policy.

Your comments are welcome into this email thread, OR by email directly to the project office at feed...@radiodns.org

Best regards

Nick Piggott

Project Director

[James Cridland]

Readers may benefit from https://groups.google.com/forum/#!topic/radioepg-developers/acEnO8q7Bo8 - a post which discusses the "identifier codes" in more detail. (A search on the RadioDNS website itself won't help you, yet).

I have privately fed back a number of points, but would especially ask for clarity around the use of "will" in this document which, in many cases, appears to really mean "may". RFC 2119 is a lovely thing.

Have a lovely day everyone.

//j

[Nick Piggott (RadioDNS)]

Hello

Since the original distribution, we're received a number of comments directly to the project office (feed...@radiodns.org).

Two clarifications will be made for the next version:

* The Fair Use Policy doesn't restrict use of metadata and content in any way, but an end-user should probably check uses not described in the Fair Use Policy.

* The Fair Use Policy doesn't enforce licensing or use of client identification keys. It just says that *if* a manufacturer would like to get a licence or a client identification key, they can be reasonably confident a broadcaster will give them one.

We're waiting to hear from you. If you want to make changes, please contact us.

Nick

[James Cridland]

When will the next distribution be published?

As I've said privately, I'm very concerned about a number of points in this document: it seems a retrograde step for this organisation.

Open technology means nothing if the data is closed. I'd be keen to see its next iteration. Could you confirm its timeframe?

//j

[Nick Piggott (RadioDNS)]

Hello

We've been working on the next draft today, taking into account plenty of feedback. I would expect circulation in the next couple of days.

Nothing published in a technical standards document can affect the rights of a broadcaster in their own content.

Nick

--
--
You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to
radiodns-develo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-develo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--

Nick Piggott

Project Director

RadioDNS

www.radiodns.org // @radiodns // +44 (0) 1600 888335 // +1 (850)-888 8335

RadioDNS Limited is a not-for-profit company owned by its members, and registered in England and Wales with number 08818015. The registered office is 96a Curtain Road, LONDON, EC2A 3AA.

[Nick Piggott (RadioDNS)]

Hello,

Thank you to everyone who has commented on the first draft of our proposal to define an acceptable use for broadcaster supplied metadata and content.

As a result the document has been renamed to "Guidelines for Broadcaster Supplied Metadata and Content for Broadcast Radio Services". The aim is the same, but the name better reflects the intention.

Version 0.02 is attached, and we're still asking for comments and feedback, either by comments in this thread or by email to the project office - feed...@radiodns.org

Please comment by Friday 4th November 2016.

Best regards

Nick Piggott

Project Director

On Tuesday, 6 September 2016 10:59:06 UTC+1, Nick Piggott (RadioDNS) wrote:

[James Cridland]

This is a significant rewrite, and I'm grateful to you and the Steering Board for listening to feedback. You have made it much clearer, and clarified both the intent of the document and the thought processes that have made it necessary.

My feedback, made public here to aid discussion and agreement, is:

0. Preamble

a. As per my previous feedback to you, "Manufacturers" needs defining in this document, to make it clear that it applies to anyone either manufacturing a broadcast radio receiver (i.e. "a radio") or a software developer producing an application for a broadcast-capable device (i.e. a RadioDNS-capable app in an FM/DAB equipped mobile phone). It is currently unclear whether a software developer is explicitly covered by this document, and the current wording would seem to exclude this use. Given the relative development costs and times, I would suggest that RadioDNS is well-served by welcoming software developers as early users of the technology.

1. Metadata and content should be used to improve the radio experience for a listener using a broadcast radio device

a. RadioDNS is intended to not have a central database of individual stations, instead relying on discovery via BroadcastURIs and the DNS system. If a manufacturer is based in Germany, it's unlikely that this manufacturer is going to be instantly able to check licensing requirements for a small radio station in Malaysia, since that station's SPI details are only accessible if you know the BroadcastURI for the station. How can a manufacturer be able to ensure that it has signed licence terms with all broadcasters? Does RadioDNS plan to offer a one-stop shop for manufacturers to contact broadcasters who require licences? If not, could you describe the procedure to ensure a manufacturer is not inadvertently operating unlicenced?

b. RadioDNS is intended to be a service accessed in a programmatic fashion. It is unrealistic (and in many ways technically difficult) to expect manufacturers to periodically have to manually check every single SPI document to check licensing terms. Perhaps this is documented somewhere - but is there a standard to indicate licence requirements in the SPI document in a standard format that can be automatically checked?

c. Should a manufacturer wish to operate in a "non-typical scenario" as documented on page 2, the process I describe in this document para 1 a) would leave manufacturers operating outside the terms of these guidelines, but unable to contact broadcasters to "contact them directly for agreement" - since a manufacturer would be unable to know who to contact - particularly if there is no licence requirement. Does RadioDNS plan to offer a one-stop shop for manufacturers to contact broadcasters who require contacting directly for agreement in a non-typical scenario? If not, could you describe the procedure to ensure a manufacturer is not inadvertently operating outside these guidelines?

3. "Broadcast and streaming should be used correctly"

a. The SPI document contains broadcaster preferences for order of bearer use; yet has no differentiation for use-case. A mobile phone on a 4G signal has a clearly different use-case than a hifi home unit on a robust 200MB connection. As currently written, if a broadcaster has a 24kbps DAB+ signal but a 192k MP3 stream over IP, a manufacturer of a hifi home unit is unable to correctly choose the 192k MP3 stream to offer the best quality reception for the users of the unit. In some cases, the poor audio quality may lead to customer dissatisfaction or a unit to be returned to the purchaser. Appreciating that this document is intended to control bandwidth use for broadcasters, is the intention of this document to ask manufacturers of home hifi units to contact broadcasters directly for approval of metadata in this way?

b. "Minimise the time connected to the stream" is a little vague. Current best-practice switches quickly away from DAB to IP when the signal fails, but requires a solid DAB signal to be present for a continuous two minutes or so before it switches back - to avoid jarring switching. Is two minutes a "minimal time", or is the intention to ensure time on IP is set to be in seconds rather than minutes in this use-case? Manufacturers would expect some certainty so as to not inadvertently operate outside the guidelines, and it would be helpful to clarify.

Again, I'm grateful to you for the clear work that has gone into this document. With the issues above, though, I remain concerned at the amount of work this devolves onto manufacturers, many of whom already need to spend significant development costs to implement RadioDNS on their devices. While I appreciate broadcasters wish to retain rights in their metadata, the requirement to "contact broadcasters directly for their agreement" is, it seems to me, currently unworkable in practice and add some significant risk to responsible implementation by manufacturers.

I'm confident that these points can be fixed by the RadioDNS team, and look forward to a further revision of this document: it's an important one for the future of the organisation and for implementation of RadioDNS in general, and shouldn't be hurried.

//j

[Nick Piggott (RadioDNS)]

Hello,

Thank you for the very comprehensive and thoughtful feedback.

We're collating all the points for discussion, so this gives us plenty to work with.

I'll address the licensing issue now, as I think that's something that we aren't able to influence.

RadioDNS can't seek, nor is it being given, the rights to licence (or sub-licence) individual broadcasters' metadata and content, nor do we feel that we can successfully impose a standard licence. The rights situation isn't changed by these guidelines; manufacturers ought to be getting permission to use metadata and content, regardless of the method they're using to acquire it. In that respect, we don't see that these guidelines worsen the current situation. We do believe by describing some use cases which, by consensus, a majority of broadcasters will tacitly approve to, it significantly lessens the urgency with which manufacturers feel they need to seek licences, possibly to the point where they defer that indefinitely. I'm not sure how that compares with how manufacturers handle the situation currently?

We would hope, that if broadcasters do want to issue licences, they'll make those licences compatible with these guidelines.

We'll come back to you on the other points.

Thanks,

Nick

--
--
You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to
radiodns-develo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-develo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Cridland]

Thank you, Nick, for your swift response.

I understand that broadcasters wish to control their metadata, and your document is a pragmatic approach to allow broadcasters to have certainty of how their data is to be used. I'm trying to ensure that manufacturers can comply with these guidelines and easily get a licence, and/or gain agreement for metadata to be used outside of these use-cases.

"How this is currently handled?"

Manufacturers of a non-RadioDNS DAB or an FM set don't need any licences to decode DAB or RDS metadata, nor are they requested to "contact [broadcasters] directly for agreement" if they wish to make an FM/DAB radio that operates outside of any guidelines.

An internet radio directory run on behalf of a manufacturer is a central database. A responsible manufacturer can go through that list and check with every broadcaster that their inclusion is acceptable, or choose to only add stations who have given explicit permission. In the real world, as you're aware, most manufacturers list all broadcasters, check with some larger and important broadcasters that their listing is okay, and take a calculated risk that others are okay with it all.

RadioDNS impacts IP, DAB and FM; and there is no central database by design - RadioDNS Users and DNS entries are not open nor published. A responsible manufacturer has literally no list to work from, and no way of controlling who is "listed" on DAB or FM. A responsible manufacturer could seek to sign licences with all those that require them in return for richer data; and a super-responsible manufacturer who wishes to change one of the recommendations of the guidelines in their implementation would want to "contact [all broadcasters] directly for agreement". Without being able to get a list of current SPI files, or any understanding of which broadcasters are in the RadioDNS system, I don't see how they can.

I don't really wish to comment further while you assess feedback from others; and look forward to a further draft of this important document. Thank you for reading.

//j

radiodns-developers@googlegroups.com

To unsubscribe from this group, send email to

radiodns-developers+unsub...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-developers+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--

Nick Piggott

Project Director

RadioDNS

www.radiodns.org // @radiodns // +44 (0) 1600 888335 // +1 (850)-888 8335

RadioDNS Limited is a not-for-profit company owned by its members, and registered in England and Wales with number 08818015. The registered office is 96a Curtain Road, LONDON, EC2A 3AA.

--

--
You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to

radiodns-developers@googlegroups.com

To unsubscribe from this group, send email to

radiodns-developers+unsub...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-developers+unsub...@googlegroups.com.

[Nick Piggott (RadioDNS)]

Hello,

A reminder to please send us your comments (or add them to this thread) by FRIDAY 4th NOVEMBER 2016. (Which is this Friday).

We've had a lot of useful feedback already, but we want to keep this initiative moving as fast as possible.

Thanks,

Nick

[Nick Piggott (RadioDNS)]

Hello,

At the RadioDNS Steering Board on the 12th December 2016, we agreed to develop a Standard Licence for Metadata and Content use in hybrid radio, for the automotive environment

There's more information in this post.

Thank you to everyone who contributed thoughts and observations on the process.

Nick Piggott

Project Director

On Tuesday, 6 September 2016 10:59:06 UTC+1, Nick Piggott (RadioDNS) wrote: