Subject: Copyright, licensing, and feeds

From: John Panzer <[email-masked]>
Date: Wed, 07 Jun 2006 13:17:26 -0700

After my earlier post about discoverability of related feeds, I realized 
that I had neglected to explain the background behind what I'm thinking 
about fully.  Here are all of the gory details:

http://journals.aol.com/panzerjohn/abstractioneer/entries/1338

I'm attempting to promote the use of explicit licenses in feeds, and 
Creative Commons is one great source of predefined licenses suitable for 
the kinds of things that people want to use feeds for today:

http://creativecommons.org/weblog/entry/5928

This is actually an interoperability issue:  If I need to consult my 
legal department before displaying the content of a feed to a user, it's 
likely to simply not happen.  Of course this is not fundamentally a 
technical problem, it's a social problem, but I'm trying to promote the 
technical underpinnings that will make social solutions possible.  A 
stable technical underpinning is one of the things that's necessary here.

-- 
John Panzer
System Architect, AOL
http://abstractioneer.org

---

From: Elliotte Harold <[email-masked]>
Date: Wed, 07 Jun 2006 18:04:44 -0400

> the kinds of things that people want to use feeds for today:

Creative Commons only covers a very small subset of what's needed for 
feeds. It's completely inadequate for something as simple as "Don't 
republish this. Period." Much less if you want to say things like, "You 
can republish it but the cost is one cents per page view, and I have the 
right to audit your books once per year."

-- 
Elliotte Rusty Harold  [email-masked]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

---

From: John Panzer <[email-masked]>
Date: Wed, 07 Jun 2006 15:20:38 -0700

Elliotte Harold wrote:

>> Creative Commons is one great source of predefined licenses suitable 
>> for the kinds of things that people want to use feeds for today:
>>
>
> republish this. Period." Much less if you want to say things like, 
> "You can republish it but the cost is one cents per page view, and I 
> have the right to audit your books once per year."
>
That's why I said "one great source"; all the mechanisms I'm 
recommending are 100% extensible. 

CC covers two major use cases for feeds:

(1) Republish but not for commercial use; you can't resell it, or sell 
advertising next to the content.  This covers for example the Engadget 
full text feed.
(2) Republish freely but maintain an attribution back to the source.  
This covers the Engadget excerpt feed, which is basically advertising 
for the main web site.

You're free to create your own licenses (but you'll need to pay your own 
lawyers) and put them on a web site, after which you can use <link 
rel="license"...> to point to them.  My servers will initially not 
understand those licenses, and will revert to "fair use only" type of 
usage, until we upgrade our code.

---

From: "M. David Peterson" <[email-masked]>
Date: Wed, 7 Jun 2006 17:43:53 -0600

Hey John,

In this example, does rel="license" represent a tagged reference or the URI
to the location of the license?

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: James M Snell <[email-masked]>
Date: Wed, 07 Jun 2006 16:56:44 -0700

I don't want to speak for John, but in the feed thread draft, it's both.
 The href is intended to be dereferenceable to retrieve some document
describing the license.

- James

M. David Peterson wrote:
> Hey John,
> 
> In this example, does rel="license" represent a tagged reference or the
> URI to the location of the license?
> 
> [snip]

---

From: Karl Dubost <[email-masked]>
Date: Thu, 8 Jun 2006 11:20:47 +0900

Le 06-06-08 à 05:17, John Panzer a écrit :
> I'm attempting to promote the use of explicit licenses in feeds,  
> and Creative Commons is one great source of predefined licenses  
> suitable for the kinds of things that people want to use feeds for  
> today:

+1

> This is actually an interoperability issue:  If I need to consult  
> my legal department

A bit more than that. As Elliotte said, there are a maelstrom of  
possibilities and not necessary easy to solve. These days, I'm  
blocking the access to *all* indexing bots (Google, Yahoo,  
technorati, etc.) because of the license issue. I had to fight with  
some of them.

When we choose CreativeCommons, Share A Like - No commercial user, we  
expect that no commercial use will be done. It means no data  
profiling, no advertisement, etc. As Elliotte said too, it can be  
opposite, as one's would want to license its content, you can use it  
but you have to pay me in returns.

* First simple solution: No commercial use.

   Aggregators, indexing bots, Re-bloggers, etc. MUST enforce the  
license. It means that a company like Technorati or Google could have  
a P3P declaration saying: "if your data under this license XYZ, we  
will not be able to index them." and not index them.
   A Web blog readers which would data mining with the feeds, could  
say: "Your data will not be used for commercial purpose when you are  
a paid subscriber."

Then it will be users to decide the type of licenses, services and  
subscriptions they are willing to accept. Respect of the contract.

* Difficult choice: Commercial use.

   Here it's very hard and we are entering in the nightmarish DRMs  
world. DRMs "could" be good if there were not mixed up with… TPM  
(Technical Protection Mechanism). There are efforts in this direction  
for Open DRMs

	http://www.openmediacommons.org/
	http://odrl.net/	

Which will not remove abuse :)

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

---

From: John Panzer <[email-masked]>
Date: Wed, 07 Jun 2006 21:45:12 -0700

Yes, I intended to refer to James' feed license extension:

http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/

(James, I think you meant "feed license draft" rather than "feed thread 
draft", right?  :) )

---

From: James M Snell <[email-masked]>
Date: Wed, 07 Jun 2006 21:55:21 -0700

Doh! Yes, sorry, I've had feed thread on the brain lately.

---

From: "M. David Peterson" <[email-masked]>
Date: Wed, 7 Jun 2006 23:40:22 -0600

Okay, cool... This is the first I've seen this, but that obviously nothing
of any great concern.

I guess my next question is the same as what what you, Elliotte, and Karl
have already made the primary focus of this thread,

* Beyond providing a way of referencing what license(s) applies to any given
entry, how does a machine determine "I am rendering ads on this page, so I
can't display the content of this feed, but I can render this feed because
the rules for this license allow me to display its content on a page
supported by ads?

* Does there exist a specification of any sort, that extends from XML
Schema, Schematron, RelaxNG, or similar, that would allow me to determine at
run time what rules apply to a given license, and based on the rendering
schema for any given page, determine which, if any, linked content can be
accessed and rendered as part of this page instance?

Is this where you plan to take this John, or have I missed the boat
completely?

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 8 Jun 2006 12:40:49 +0200

> Which will not remove abuse :)

Well, will anything short of not publishing your content?

I think the point of such an effort is to make life easier for
third parties who want to respect your wishes, not to make it
harder for third parties who are intent on violating them.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 8 Jun 2006 08:41:20 -0600

Very well stated, Aristotle!

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "John Panzer" <[email-masked]>
Date: Thu, 8 Jun 2006 15:33:39 -0700

> harder for third parties who are intent on violating them.

Aristotle -- Absolutely right.  I see an opportunity to make life easier 
for people who want to play by the rules, and I think there are some 
simple technical things we can promote to help do that.

Attempting to deal with people who choose not to play by the rules is a 
different, much larger, much less tractable problem.  I'm not trying to 
tackle that one, though feed licenses might be a building block.

-- 
John Panzer
System Architect

---

From: Karl Dubost <[email-masked]>
Date: Fri, 9 Jun 2006 14:06:05 +0900

> harder for third parties who are intent on violating them.

Agreed. And it's why my message (which was really badly written -  
fatigue) was separating the issue. It's a very important issue, and I  
really believe a clear spec, framework or let's say technical  
solution would improve the field. Definitely.

I would love to see that happening as soon as possible. It's a mix  
between social and technical issues. Finding interoperable solutions  
would help to soften the social issues and frustrations.

so again +1 a thousand of times ;)

---

From: Karl Dubost <[email-masked]>
Date: Fri, 9 Jun 2006 15:23:19 +0900

Reading the example from
	http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/
[[[
3.  The 'license' link relation

    An Atom link element with a 'rel' attribute value of 'license' is
    used to associate a copyright license with an Atom Feed or Entry.

    Atom entry, feed and source elements MAY each contain any number of
    license links but MUST NOT contain more than one with the same href
    value.  The IRI specified by the link's 'href' attribute SHOULD be
    dereferenceable to return a machine or human-readable representation
    of the license.

    Implementors should note that, unlike the Atom rights element, which
    specifies a human-readable statement of the rights held over a entry
    or feed, license links apply only to the informational content of  
the
    containing element.  That is, the presence of a license link  
relation
    within an Atom feed element does not extend a license over the
    various contained entry elements.  Likewise, the presence of a
    license link within an Atom source element does not extend a license
    over the informational content of the containing entry.
]]]

-- snell-atompub-feed-license-06.txt
http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/ 
#page-3
Thu, 13 Apr 2006 19:27:54 GMT

# Some questions about specific use cases

1. Feed composed with multiple sources with different licenses.
    When a feed aggregator creates a feed from different sources  
(feeds) with different licenses, what should be the license of the  
resulting feed?

    feed (license ???)
       entry (license A) from feed X
       entry (license B) from feed Y
       entry (license B) from feed Y
       entry (license A) from feed X
       entry (license C) from feed Z
       …

Defining the semantics of the attribute/element is cool, but on the  
side in the implementation it's not clear what should be by consuming  
products. As I said in a previous message, it's a tough problem.

2. Should there be a best practices document to invite tools  
developers to understand and implement licenses mechanism?  (As I  
understand it's not the purpose of this draft).

---

From: Eric Scheid <[email-masked]>
Date: Fri, 09 Jun 2006 17:40:14 +1000

>      entry (license C) from feed Z

either no license element at the the feed level (since every entry has their
own license), or maybe a license that refers to the collection (eg. you
could expose a license for your Top 10 List without necessarily claiming any
license for the 10 items in the list).

Interesting to think what different licenses might entail though: you could
deny breaking up your feed by no-deriv (which would only work to the limit
of fair use, ie. I could still cherry pick the occasional entry, although
the entry's license might still stop me). If someone were to publish their
Top 10 List, you could disallow someone re-aggregating it as a Top 5 List,
say. 

e.

---

From: "M. David Peterson" <[email-masked]>
Date: Fri, 9 Jun 2006 03:03:36 -0600

For the record, Karl, even though you felt it was poorly written, at a
personal level I didn't walk away with the feeling that your point was
anything other than a simple "no matter what we do, we're not going to keep
the world from abusing copyrights, but there's plenty of things we can do,
so lets do them."

My agreement with Aristotle's point, and from what I could tell (though
obviously I can't speak for Aristotle) Aristotle's reasoning for the
follow-up was to help clarify the direction and purpose of how this work
should be viewed and where the focus should be placed.  But either way, I
100% agree with his statement (as do we all! :) and wonder if this should be
clearly marked and noted in a centralized wiki somewhere (Creative Commons,
W3C) as the primary focus of the work done is this area?  I would happily
host one, but hosting a wiki isn't the problem.  Finding the right place to
host it is.

Any suggestions?

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Fri, 9 Jun 2006 03:28:48 -0600

resulting feed? <<

Very important point Karl!  Thanks for bringing it to the surface :)

side in the implementation it's not clear what should be by consuming
products. As I said in a previous message, it's a tough problem. <<

It *seems* that the category element with @scheme, @label, @term could act
particullary well in regards to allowing for a human readable definition, a
human/machine readable label, and a human but more importantly machine
readable scheme that could represent the "rules" definition file in which
could be parsed and used as the pass/fail method to determine which license
both can apply as well as which one best applies to the situation.

What I mean by this is that if there were three category elements in which
each contained @lable="license" [1], if a best practices doc suggested
ordering them from most confining to least (using a 100% commercial use >
100% non-commercial (or would that need to be the other way around to make
proper sense?) use pattern for ordering the category elements), then as soon
as they reached the point in which they passed all rules for a given scheme,
the machine could them stop processing schemes and move forward with the
rest of the processing based on the set of rules set forth in the current
"in-process" scheme.  T

his, of course, would suggest that the best way to build out the scheme file
would be to start with the pass/fail "questions" to then follow with what
can and can not be used as part of the final output.  Obviously from a
machine standpoint this would allow for the most efficient usage of XML as
there would be no need to climb up and down the tree looking for the next
set of processing rules once a 100% pass level has been reached.  This would
allow for forward only readers to be implemented, and would obviously work
well with the streaming SAX+ implementations.

Of course this leads nicely into...

developers to understand and implement licenses mechanism?  (As I
understand it's not the purpose of this draft). <<

Yes please! :D

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Fri, 9 Jun 2006 03:54:51 -0600

Lets try this again to everyone instead of just Karl :) (sorry for the
duplicate, Karl!)

And the file access problem is now fixed.
---

ooops... forgot to add the [1] footer.

I was intending this to be a question:  Can there be more than one category
element with the same value for label?  I need to look this up, but if
anybody knows off hand I would appreciate the time saved.

If they can not, then namespaces come into play to allow somehing like
license:cc-by-sa.  And yes, I have the code available to make easy the
problem with QNames in content.  In fact, if you access [1], [2] you can
probably figure out for yourself what I am refering to.  I would need to
customize the code base to be a bit more specific, but thats not a big issue
as its less then 10 minutes worth of coding.

One thing I just noticed when visiting the second link is that the source
files seem to be inaccessible.  I'll see what the problem is, and if
necessary place the files on another server and update that post
accordingly.  If you find they are unaccessible, this is why, although I am
going to look into this now, so by the time anyone other than those in
Europe+ read this, it should most definitely be fixed.

[1] :
http://www.oreillynet.com/xml/blog/2005/08/part_2_assets_atom_feeds_and_a.html
[2] :
http://www.oreillynet.com/xml/blog/2005/09/part_3_assets_atom_feeds_and_a.html

On 6/9/06, M. David Peterson <[email-masked]> wrote:
> his, of course, would suggest that the best way to build out the scheme
> file would be to start with the pass/fail "questions" to then follow with
> what can and can not be used as part of the final output.  Obviously from a

-- 
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: James M Snell <[email-masked]>
Date: Fri, 09 Jun 2006 07:02:38 -0700

> license for the 10 items in the list).

In the Feed License Draft, feed's a licensed independently of their
contained entries.  There is no interaction between the licenses.

- James

---

From: Eric Scheid <[email-masked]>
Date: Sat, 10 Jun 2006 14:17:59 +1000

> contained entries.  There is no interaction between the licenses.

Ah, no inheritance. Makes sense really, since if that was in the spec it
would fail for aggregators that are not aware of that inheritance.

e.