- From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
- Date: Tue, 9 Feb 2010 23:31:36 -0000
- To: "Dan Connolly" <connolly@w3.org>, "www-tag" <www-tag@w3.org>
- Cc: "Jonathan Rees" <jar@creativecommons.org>, "Thinh Nguyen" <thinh@creativecommons.org>, "Rigo Wenning" <rigo@w3.org>, "Daniel Glazman" <daniel.glazman@disruptive-innovations.com>, "Yves Lafon" <ylafon@w3.org>
Thank you for the update. I hope that the three use cases I provided in [1] eventually benefit from appropriate legal opinion, or at least a formal position to put the arguments on more solid ground. For what it's worth, I view URIs like openings to a building. Some are obvious (front door, home page), some are less obvious but still public (delivery entrance, linked pages), some are visible but take some effort to find (maintenance hatch, node on site map), some are present but take more ingenuity to find (entrance via next-door, url?pageid=1234), some are special entrances with restrictions (cat flap, captcha protected page) and some are quite obviously reserved (penthouse elevator with key, pages requiring authorized sessions). There's a relationship between the amount of effort required to gain entry, and your right to enter. [I stretched the simile a bit, I know, but I'm trying to find a "common sense" position on URIs that might appeal to the wider public.] Unless there is something specific in a HTTP transaction, the representation of the resource that you get in response to a HTTP request is yours, and you are free to do anything with it. Typically that means rendering it in a browser that the author had anticipated, but increasingly the response can be rendered in alternative ways, which may not have been anticipated by the author. Of course, the response may carry constraints too (e.g. copyright notices) and it is fair to expect that recipients will respect such constraints. Framing somebody's site, as one might in a phishing scam, would therefore be seen as "wrong". But what about framing fragments of your site within the search results of a popular search engine? The authors of early Web pages, which still exist in the Web, could not have known about search engines. Nor would they have anticipated intermediate transcoders that adapt the content to mobile devices and other "strange" browsers. Can we assume that it is OK to adapt the content in this way? Does the fact that the URLs are in public confer such rights on us? If not, then a lot of search engines and mobile users are going to find themselves in legal hot water. However, I caution against confusing copyright issues with the implied rights that come with a public URL. I think the sensible position to take is that URLs (and their use in a HTTP transaction) confer the most generous rights, while all other mechanisms (copyright, access codes etc) seek to restrict them. This is better than assuming you start with no rights, and have to find explicit granting of rights in order to do anything, because if you do this then you'll effectively shut down the Web. The Web cannot work if your default position is that you have no rights with respect to what happens when you use HTTP (as intended) to dereference a URL. Anyway, I'm way out of my comfort zone here. Which is why I threw the matter (once more) at the feet of the TAG. ---Rotan. [1] http://lists.w3.org/Archives/Public/www-tag/2009Oct/0031.html -----Original Message----- From: Dan Connolly [mailto:connolly@w3.org] Sent: 09 February 2010 18:44 To: www-tag Cc: Jonathan Rees; Rotan Hanrahan; Thinh Nguyen; Rigo Wenning; Daniel Glazman; Yves Lafon Subject: Re: URIs, deep linking, framing, adapting and related concerns On Thu, 2009-11-12 at 15:15 -0600, Dan Connolly wrote: [...] > http://www.w3.org/2001/tag/group/track/actions/322 > > I'm working with Rigo and others to find people qualified > to research the legal as well as technical aspects. > > A somewhat arbitrary estimate on when I'll have news is > end of January. The search for qualified (and *available*) writing resources continues. I bumped the due date back to 2010-03-23 in tracker; perhaps we'll have more news then. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Tuesday, 9 February 2010 23:33:17 UTC