W3C home > Mailing lists > Public > public-html@w3.org > May 2009

Re: [whatwg] Helping people seaching for content filtered by license

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 09 May 2009 12:24:37 +0200
Message-ID: <4A0559E5.9070300@gmx.de>
To: "public-html@w3.org" <public-html@w3.org>
Ian Hickson wrote:
> One of the use cases I collected from the e-mails sent in over the past 
> few months was the following:
> 
>    USE CASE: Help people searching for content to find content covered by
>    licenses that suit their needs.
> 
>    SCENARIOS:
>      * If a user is looking for recipes of pies to reproduce on his blog, he
>        might want to exclude from his results any recipes that are not
>        available under a license allowing non-commercial reproduction.
>      * Lucy wants to publish her papers online. She includes an abstract of
>        each one in a page, but because they are under different copyright
>        rules, she needs to clarify what the rules are. A harvester such as
>        the Open Access project can actually collect and index some of them
>        with no problem, but may not be allowed to index others. Meanwhile, a
>        human finds it more useful to see the abstracts on a page than have to
>        guess from a bunch of titles whether to look at each abstract.
>      * There are mapping organisations and data producers and people who take
>        photos, and each may place different policies. Being able to keep that
>        policy information helps people with further mashups avoiding
>        violating a policy. For example, if GreatMaps.com has a public domain
>        policy on their maps, CoolFotos.org has a policy that you can use data
>        other than images for non-commercial purposes, and Johan Ichikawa has
>        a photo there of my brother's cafe, which he has licensed as "must pay
>        money", then it would be reasonable for me to copy the map and put it
>        in a brochure for the cafe, but not to copy the data and photo from
>        CoolFotos. On the other hand, if I am producing a non-commercial guide
>        to cafes in Melbourne, I can add the map and the location of the cafe
>        photo, but not the photo itself.
>      * Tara runs a video sharing web site for people who want licensing
>        information to be included with their videos. When Paul wants to blog
>        about a video, he can paste a fragment of HTML provided by Tara
>        directly into his blog. The video is then available inline in his
>        blog, along with any licensing information about the video.
>      * Fred's browser can tell him what license a particular video on a site
>        he is reading has been released under, and advise him on what the
>        associated permissions and restrictions are (can he redistribute this
>        work for commercial purposes, can he distribute a modified version of
>        this work, how should he assign credit to the original author, what
>        jurisdiction the license assumes, whether the license allows the work
>        to be embedded into a work that uses content under various other
>        licenses, etc).
>      * Flickr has images that are CC-licensed, but the pages themselves are
>        not.
>      * Blogs may wish to reuse CC-licensed images without licensing the whole
>        blog as CC, but while still including attribution and license
>        information (which may be required by the licenses in question).
> 
>    REQUIREMENTS:
>      * Content on a page might be covered by a different license than other
>        content on the same page.
>      * When licensing a subpart of the page, existing implementations must
>        not just assume that the license applies to the whole page rather than
>        just part of it.
>      * License proliferation should be discouraged.
>      * License information should be able to survive from one site to another
>        as the data is transfered.
>      * Expressing copyright licensing terms should be easy for content
>        creators, publishers, and redistributors to provide.
>      * It should be more convenient for the users (and tools) to find and
>        evaluate copyright statements and licenses than it is today.
>      * Shouldn't require the consumer to write XSLT or server-side code to
>        process the license information.
>      * Machine-readable licensing information shouldn't be on a separate page
>        than human-readable licensing information.
>      * There should not be ambiguous legal implications.
>      * Parsing rules should be unambiguous.
>      * Should not require changes to HTML5 parsing rules.
> ...

Out of curiosity, where do the requirements below come from?

"* License proliferation should be discouraged."

I agree that License proliferation is problematic, but it seems to be an 
totally orthogonal issue.

"* Shouldn't require the consumer to write XSLT or server-side code to 
process the license information."

Why single out XSLT? And what has server-side code to do with this?

"* Should not require changes to HTML5 parsing rules."

I understand that it's not desirable at this point to change the parsing 
rules, but I have a hard time understanding how it gets into this 
requirements list.

BR, Julian
Received on Saturday, 9 May 2009 10:25:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:03 UTC