Re: [backstage] First BBC Backstage Podcast: DRM and the BBC
vijay chopra wrote: > (even if it's only one podcastl; what makes a downloadable audio file > into a podcast anyway??) If this is going to be a (semi-)regular occurrence, could we get a real RSS feed for it? Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] First BBC Backstage Podcast: DRM and the BBC
Dave Crossland wrote: > I also note that its been published in the free software, open > standard, cross platform ogg vorbis format as well as MP3, and hope > this demonstrates that such formats do indeed exist - As I said in the > show, I think that everything the BBC is publishing as MP3 can also be > made available as OGG :-) Indeed, thanks to the wonders of HTTP/1.1 content-negotiation you can probably transparently provide both without the user noticing... (This might require tidying up the URLs involved slightly, but I don't imagine that would be too problematic.) Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] First BBC Backstage Podcast: DRM and the BBC
Greetings, Interesting discussion - primarily useful for the "we don't have the rights" arguments that haven't been effectively aired until now. The reason for using DRM has often been stated thus: * We need to prevent our users from re-distributing content that we feed them. However, it now appears clear that the real reason is thus: * We have to be seen to be trying to do something to prevent our users re-distributing content. Given that no DRM scheme has _ever_ met the goal of preventing users re-distributing content, would it not be better for the BBC, consumers and pretty much everyone (except perhaps MS) in the long-run if the BBC simply denounced DRM as the snake-oil it is and refuse to deploy it? Indeed, this seems particularly pointless when I can simply point my desk antenna at the Crystal Palace transmitter and record the 20Mbaud H.264 1080p stream being broadcast in clear. Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] DRM and hwardware attitudes
Richard P Edwards wrote: > http://help.channel4.com/SRVS/CGI-BIN/WEBCGI.EXE/,/?St=19,E=0069424,K=4792,Sxi=17,CASE=1363 It really would be nice if website administrators would actually read and apply the principles in "Cool URIs Do Not Change" [0] ... (I'm not holding my breath, however.) Cheers, David [0] http://www.w3.org/Provider/Style/URI -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] First BBC Backstage Podcast: DRM and the BBC
James Cridland wrote: > Pointing out to rights-holders that "we're giving your content away > anyway" is probably going to be replied-to with "well, stop it". Distribution of content is a _feature_, not a bug. In such a scenario the BBC would presumably ask for their money back.. Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] An interview with Mark Taylor, Pres. of UK Open Source Consortium
Quick aside: you appear to have a very interesting UTF-8-encoded "From" name string: From: =?UTF-8?B?In46Jycg44GC44KK44GM44Go44GG44GU44GW44GE44G+44GX44Gf?= =?UTF-8?B?44CCIg==?= <[EMAIL PROTECTED]> ... which actually expands to (what appear to be) a number of interesting chinese glyphs! This may not be what you intended.. ~:'' ありがとうございました。 wrote: > the unfortunate fact is that open source is not above or beyond this > type of controversy. > > ie who funds the developers? > who are they developing for? Actually, at least in major open-source projects such as the Linux kernel, nobody cares. In such projects, you will often have many developers paid and working for the interests of various companies. Not only is this not a bad thing, however, it's actually very good as it results in a larger number of (presumably effective) developers working on developing the code-base full-time. The open-source development process is, at its core, evolutionary. Each developer works to build new revisions of a given project. If the new version is 'fitter' than the original, then those changes will be adopted. If the new version is inferior, it won't. In such a system, the more competent developers you have, the better. It doesn't matter that they're all trying to apply evolution pressures in different directions; the project as a whole will still benefit. > in many cases developers: > have little or no understanding of a 'public' audience. > actively refrain from user testing. These two points can be summarised as "open-source developers don't care about usability." And this demonstrably isn't true. Different tools are designed for different audiences; emacs, for example, is intended to be usable by developers - and it is. Similarly, Ubuntu, GNOME and other systems that _are_ intended for regular end-users have clearly seen a great deal of usability testing. > encourage feature creep Do you have any evidence that you can port to to demonstrate this? > design to impress their peers You say this as if this is a bad thing! > in some sense consumerism at least gives the end user some authority. To a degree, but it heavily depends on there being a free market with a number of competing alternatives. I'm not an economist, but it appears that, in computing, free markets generally cannot form if the interfaces used for data interchange are closed and/or proprietary; in such markets, one provider will eventually tend to dominate all of the others. For example: Operating systems: MS Windows tends to dominate (because nothing else can run Windows applications, as the ABIs/APIs are myriad and not fully documented); Office productivity suites: MS Office tends to dominate (because nothing else can read/write the proprietary file formats that Office uses.) To contrast: Web browsers: There are many web-browsers: Seamonkey, Firefox, Internet Explorer, Safari, Konqueror, Galeon, Lynx etc. (because the interfaces that such applications must support are well-documented.) Web servers: lighttpd, Apache, Nginx, IIS etc. (because the interfaces that such servers must support are well-documented.) .. and so forth. If there is a free market, then the consumer has influence. Note that in the case of the BBC iPlayer and other similar services from other broadcasters, the interfaces are not fully documented - and this is considered a feature! > as you may know, the web specifications created by W3C are far more > potent than the mere iplayer. I don't think I understand - how (and why?) are you comparing the W3C interface specifications and guidelines, which exist to ensure interoperability between different implementations, and the BBC's iPlayer, which is just one application? > The issues are similar though there are > more companies and corporations engaged in the project Than which project? The W3C? There have certainly been many more companies and corporations involved in the W3C specification development process than that of the iPlayer! Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] Ashley Highfield on iPlayer - 26min Interview
Hi, A very interesting interview - many thanks to Backstage and Ashley. A few thoughts: * It seems clear that all of the portability issues currently affecting the iPlayer beta are a direct result of the requirement for DRM specified at the design stage. If the DRM constraint _were_ relaxed, then it would be possible to exploit all of the existing standardized and open-source media encoding and distribution technologies and completely avoid the current cross-platform incompatibility problems. * One question I have is: why Kontiki? Given that the files being distributed are DRM-wrapped anyway, why not use something more mainstream such as Bittorrent? (Even with a DRM-wrapped payload, RSS feeds carrying BBC series as a set of .torrent files would be very cool!) * From the interview, it is clear that the reason that the current DRM requirements exist is because rights-holders did not want the end-user the to be able to redistribute content to others - because they fear would reduce the value of their other distribution channels. This appears to be faulty reasoning. First, the BBC are _already_ broadcasting all of their content, digitally and in the clear, in the form of RealPlayer streams, terrestrial radio and (HD) television broadcasts and also via internet multicast. Why is it useful to apply DRM to this one distribution channel, when anyone can ignore it and instead obtain a 20Mbit/sec HD digital copy encoded in a standard, well-defined encoding by pointing an antenna at Crystal Palace? Secondly, all evidence to date shows that DRM does not in fact prevent the redistribution of content by end-users -- indeed, the WMPv9 DRM scheme currently used by the iPlayer distribution service had already been broken before the Beta had even launched! * Rights buy-outs: it's not necessary to buy out the rights to putting on live shows, publishing books and many of the other functions mentioned by Ashley in the podcast in order to set up a functional, DRM-free iPlayer service. Moreover, his assertion that all of the downstream rights - for books and so forth - would become worthless if the shows themselves could be readily downloaded seems dubious. Indeed, the value of many related works - books, live shows, etc. - may well _increase_ significantly if the original shows themselves were more readily available. This is because making the content more readily available to the public would help the rights-holders to build a bigger audience for their other works. Indeed, it is partly for this reason that many book authors are now publishing the entire content of their works online under Creative Commons licenses. (This is basically the same argument the BBC made in the case of the Beethoven MP3 downloads which so worried other Classical music distributors.) * One of the things Ashley talks about is a potential new future distribution model which he hopes that technology will enable the publication of content "with no DRM" -- but distributed in an "intelligent wrapper" that is able to enforce a set of rules for how it should behave. I think someone needs to tell Ashley that the mythical future technology he's describing _is_ what the rest of us would call DRM! Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] Ashley Highfield on iPlayer - 26min Interview
Tom Loosemore wrote: >> First, the BBC are _already_ broadcasting all of their content, digitally >> and in >> the clear, in the form of RealPlayer streams, terrestrial radio and (HD) >> television broadcasts and also via internet multicast. > > all above are geographically bounded. So is access to the iPlayer service. > general users can't yet *easily* grab a broadcast stream and > copy/share a file internationally Of course, that doesn't matter - someone else will have uploaded a copy somewhere public that the general user can grab already. > Even UK pirate sites rely on very few expert cappers who do this by > hand, hence the relative scarcity of UK TV programmes on the darknets > compared to music. It is trivially easy, with current tooling, to automatically catalog, isolate from one another and transcode music tracks from CD. Anyone can basically belt-feed CDs into a PC and get iTunes to do everything for them. Recorded TV, unlike DVDs, would however require manual editing to edit out the commercial breaks, to set accurate start and end times, and selecting optimal transcoding settings. The tooling to do this isn't as usable and isn't as widely deployed among end-users. However, bandwidth capacity, storage and tooling will only improve. > right holders would argue that it's "enough" rather than "absolute" > deterrent which matters. They've already got copyright law with its current scope for enormous penalties to wield as a deterrent. DRM isn't a deterrent, its just obfuscation. And once one person's figured it out, it's not even that. >> * Rights buy-outs: it's not necessary to buy out the rights to putting on >> live >> shows, publishing books and many of the other functions mentioned by Ashley >> in >> the podcast in order to set up a functional, DRM-free iPlayer service. > > how so? You don't need to buy the rights to make and distribute e.g. Top Gear books if all you're trying to do is to distribute the TV show via the Internet. It's just not a legal requirement. >> Moreover, his assertion that all of the downstream rights - for books and so >> forth - would become worthless if the shows themselves could be readily >> downloaded seems dubious. > > agreed that worthless is an overstatement - but it's hard to argue > that they'll not be reduced, which is enough for most rights holders > to resist. The market for spin-off books, live shows, and many other related works will most likely go _up_ as a result of the wider distribution of the original programme. The right-holder's main concern is, I suspect, not that people will freely redistribute their TV-shows amongst one-another -- they do this already! -- but that people will stop buying their content on DVD and will instead build up their own large library of shows as they're broadcast, removing the need to fork out for the same content again. Which would then mean that DRM's ability to limit redistribution is only a secondary effect; the primary function here is to stop end-user from storage any downloaded content for longer than the 30 day window the BBC negotiated with the rights-holders. This is also why the announced Adobe streaming-only solution is also perfectly fine with the rights-holders - it'll include DRM that prevents users from saving streamed downloads permanently to disk. >> I think someone needs to tell Ashley that the mythical future technology he's >> describing _is_ what the rest of us would call DRM! > > i *think* he mean't to express a desire for standard machine-readable > means of attaching (if not enforcing) rigfhts to media. Kinda CC+ > without creative reuse? He clearly used the term "enforce" during the interview. To effectively enforce such constraints, it is necessary to prevent end-users from being able to copy and/or edit the original bitstream, and would thus - by definition - would be classified as DRM. (Otherwise, if the inability to add meta-data to distributed video content is the only thing preventing the BBC from dropping the current DRM requirement, then I can point them at a number of standard ways that they could do it..) Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
[backstage] What would you do? (Was: BBC tech chief: You Freetards don't matter)
vijay chopra wrote: > Of course, this raises the question, is he misleading deliberately, or just > misinformed? Considering his recent faux pas it's not much of a stretch to > believe he's not only misinformed, terminally so (I ascribe nothing to > malice that can be explained by eveyday incompetence). To paraphrase a famous saying, "Any sufficiently advanced incompetence is indistinguishable from malice." (With apologies to Arthur C. Clarke.) But, seriously, I do have a great deal of sympathy for Ashley's current predicament. If you had: * Negotiated distribution rights with large numbers of programme-makers, * Developed and deployed a large-scale, proprietary peer-to-peer distribution system for providing access to said programmes, * Developed the client-side programs and web- and server-side tooling to support such access, ... and then later realised that: * That the arguments for DRM that you'd previously accepted do not make sound technological sense, * The regulatory agency that you report to is indicating that the current platform support is insufficient, * That the proprietary technology choices that you'd made for the distribution and DRM components of your infrastructure are not portable to all of the necessary and ideal target platforms (Mac, Linux, smartphones, iPods, etc.), * You're being forced to publically defend the decisions that you'd previously made using the rationale you used at the time, and finding that the arguments you're making are unconvincing (at least to this audience), ... what would you do? So far as I see it, Ashley has only a couple of options: 1. Try to continue down the present course - procuring or developing DRM and/or distribution technology as necessary in order to satisfy both the BBC regulators' and the rights-holders' requirements. (See also: the recent Adobe Air streaming announcement.) Or: 2. Develop and advocate a major shift in strategy, that involves: - Dropping the design requirement for DRM on all distributed content, - Retooling the existing production infrastructure as necessary to support open distribution and content standards, - Either convincing the BBC legal team that they have the rights to distribute the programme-makers content sans-DRM under their existing broadcast / streaming agreements, -or- - Re-opening negotiations with the programme makers to secure internet distribution rights sans-DRM, -or- - Restricting the programmes that may be downloaded by the iPlayer service to in-house content that they clearly can offer for access by UK residents. Though option 2 seems, to me at least, to clearly be in the license-payer's (and our) interest - and a technically superior option - it's certainly a much higher-risk strategy from Ashley's perspective, and, politically, would most likely be a very hard sell to BBC management. At what point does option 1 become untenable? Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] Question for iPlayer's Future
Ian Forrester wrote: > Hi All, > > So in aid to try and change the negative thread in to something positive. I > was talking to some people today about iPlayer and what's happened. Anyway, > the person asked what would you do different if you were working on iPlayer > 2.0? Hi Ian, From what I understand of the development of iPlayer to date, you guys have been doing pretty much everything The Right Way. Most of the activity has been setting up the infrastructure driving everything behind the scenes -- large data storage clusters for digital media, clusters of transcoding servers for translation between formats, building sensible, feature-complete metadata structures for representing series / episode / clip structures -- and minting Cool URIs to represent each of these. All of this is good. The only real criticism that I could reasonably level at the current iPlayer project would be the streaming / download interfaces exposed to the general public. Because of the DRM requirement, you necessarily find yourself in the impossible position of trying deliver uncopyable digital content -- which, to quote Schneier, is like trying to make water not wet. The only rational strategy is to try to get the DRM requirement dropped. How you do that is up to you guys.. Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] iPlayer in Wii
Dave Crossland wrote: > The BBC-vs-ISP bandwidth issue could be resolved by the BBC dropping > DRM so that the ISPs can cache the data. The ISPs who are anticipating financial hardship are more concerned with the cost of bandwidth between their network and home ADSL users, and _not_ between their network and the outside world. This is because they are charged a metered rate by BT for all the traffic they relay over BT's ADSL network. Thus adding data caches to their network wouldn't solve their immediate problem. Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] BBC tells ISPs to get stuffed
[EMAIL PROTECTED] wrote: > I think the ISPs have a point ... the ADSL network is (currently) like a > collection of country roads (narrow and fairly slow) which the BBC is trying > to drive it's supersize juggernauts down. Actually, no -- that's a horrible misconception. BT's ADSL network is perfectly capable of supporting high-bandwidth services like the iPlayer. (If the current ADSL network can't cope, it's the ISPs responsiblity to upgrade it. That's what their customers are paying them for, after all.) However, many of those ISPs are operating with a broken economic model. Whilst these ISPs charge a flat-fee rate to their customers, they have to pay a *metered* rate to BT for sending data over their ADSL network. Previously, this didn't matter; most customers were only using a small fraction of the bandwidth available to them, which meant that those ISPs using BT's wholesale ADSL services could get away with it. However, as customers have started to actually *use* the high-bandwidth ADSL connections that they've purchased from their ISP, then those ISPs dependant on BT's wholesale ADSL service have seen their operating costs rise whilst their incoming remains static. And now, they're panicking. The BBC are simply a content provider on the Internet. They are not the only such provider, and you'd be a fool to bet that many more won't appear in future. Asking content providers like the BBC to subsidize the bandwidth costs incurred by ISPs for shipping data over BT's ADSL network is utterly crazy. Content providers already pay a lot of money to support *their* end of the Internet, why should they be charged for all of the other ends as well? Tiscali have no right to charge *me* for Internet service just because one of their customers accessed my website. Why should the BBC be any different? ISPs are *already* being paid by their customers to provide internet access. If they can't provide the service they've promised at the price that they charge, then they will fail, and their customers will switch to an ISP who can. There are several ways ISPs can try to adapt: * Put up the price they charge customers for Internet access so that it actually covers their operating costs. * Negotiate with BT / OFCOM to reduce the cost of sending data over BT's ADSL network. * Follow in the footsteps of Be, Bulldog et al and deploy their own network in BT's exchanges. (Also known as LLU, "Local Loop Unbunding.") * Pay someone else, such as Be or Bulldog, to setup and maintain an unbundled network for them.) So, in summary: 1. Network provisioning: The ADSL network is capable of meeting demand. (And ISPs are being *paid* by their customers to make sure that it will continue to do so.) 2. Economics: Many ISPs have been operating using an economic model which simply isn't sustainable any more. Those ISPs are now panicking. 3. Content providers already pay for the upkeep of the Internet backbone and their local connections. Tiscali have no right to charge _me_ for Internet service just because one of their customers accessed my web site. 4. ISPs who fail to adapt their economic model to reality will fail. This is the future, guys. Get used to it. Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] BBC iPlayer, loved by millions, disliked by a single US citizen
Thom Shannon wrote: > but any of that could change, since the bbc isn't controlled by market forces. Arguably, that's a feature, not a bug. Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London signature.asc Description: OpenPGP digital signature
Re: [backstage] [ORG-discuss] DRM Free BBC Content on GNU/Linux (Ubuntu)
Rob Myers wrote: > On Thu, Oct 30, 2008 at 6:53 AM, Vladimir Harman <[EMAIL PROTECTED]> wrote: >> hmmm...nice and positive news for the ubuntu friends, and me of course :) >> thanks to canonical for spreading the word :) the plugin works with totem >> only, or it works with other gnu/linux video applications>? > > My next action was going to be to ask backstage if anyone can provide > more information on this project. :-) Apparently, this is based on URIPlay (http://uriplay.org/), which was presented at the OpenTech 2008 conference last summer. Totem appears to be getting its (RDF) metadata from the BBC directly via the URL: http://open.bbc.co.uk/rad/uriplay/availablecontent ... so anything that can process that or do anything sensible with it should also be able to partake. (As the URL suggests, it looks like its under Rapid Application Development so I'd expect it could change at any point in the future. But this looks like wonderful progress from the BBC.) Cheers, David -- David McBride <[EMAIL PROTECTED]> Department of Computing, Imperial College, London - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
Re: [backstage] Using filters to manage mailing-lists (Was: Move to Mailman)
On Thu, 2010-03-04 at 15:41 +, Stephen Jolly wrote: > if $h_Sender: matches "owner-([a-zA-Z-.]*)@" and not delivered > then > save $home/mail/lists/$1 > endif > > Exim filter files are great. I similarly filter all mailing lists into different folders using a meta-mailing-list filter; mine's a little more complicated: > if not delivered > and ( $h_List-Id: matches "<([^>]+)>" # Mailman > or $h_X-Mailing-List: matches "([...@]+)@" # Majordomo > -- handles Kernel.org > or $sender_address: matches "owner-([...@]+)@" # Listserv > or $sender_address: matches "(.*)-request@"# (Old > majordomo listservs?) > ) > thensave mail/lists/$1 > if "$1:$tod_log" matches "([^:]+):(\d+-\d+)" > thensave mail/archive/lists/$1/$2 # Save a second > copy in > # > mail/archive/lists//- > endif > endif This means that when I get added to new mailing-lists, the new emails get filed away automatically rather than cluttering up my in-tray.. (Sadly, we're being migrated to a central Exchange service which isn't nearly so powerful. So far I've resisted by having a mail spool that's bigger than Exchange can handle...) Cheers, David -- David McBride Department of Computing, Imperial College, London signature.asc Description: This is a digitally signed message part
