Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)

From: "John Panzer" <[email-masked]>
Date: Wed, 6 Sep 2006 09:29:06 -0700

Bob Wyman wrote:

...

The most
interesting cases will be those licenses that attempt to assert limitations
to rights which would normally be considered to be granted to consumers of
feeds. Such rights would include things like "Fair Use" and "implied
licenses." It is *vitally* important to our community that we ensure that
such restrictive licenses are not encouraged or facilitated by this rfc.

This is a critical point.
Without this, implementors cannot safely
ignore licenses they don't understand (falling back to things like
"fair use" if they can't find any licenses that grant additional
copying rights).  This means that implementors would likely have to
drop feeds containing new licenses on the floor, meaning that new
license schemes would never be deployed.

...
Thus, it would seem that the only effective use of the license link
is to grant rights not to restrict them.

Yes.  Given the current
murky and complicated legal situation with implied licenses, fair use,
etc., granting explicit and well defined rights is a huge win for
everyone.

The second sentence in 1.1 is:

Nor can a license associated with a feed or entry
restrict or forbid access to, redistribution, aggregation,
caching and display of those items by third party
intermediaries such as search engines and so-called
"online aggregators".

This second part of 1.1 is stating support for the theory that the
act of publishing data in the Atom format creates an "implied license" for
the limited purpose of syndication and lists a number of processes which are
considered to be part of the syndication process. Hopefully, my discussion
of the first sentence explains what this is all about.
My only suggestion for this sentence is that it might be less
strongly worded. Given that the law in this area is not settled, it might
make sense not to say "Nor can a license... restrict..." Rather, it might be
more accurate to say something like: "It is believed that a license ...
cannot restrict...."

How about (IANAL of
course):

"Nor can a
license.... restrict or remove any implied copy or usage rights which
would otherwise exist in the absence of the license."

The intent being that adding a license, or a new type of license, is
always safe:  If what you're doing with content is allowable, if the
feed provider adds a license, it is still allowable.

-John Panzer

---

From: Wendy Seltzer <[email-masked]>
Date: Wed, 06 Sep 2006 14:23:10 -0400

>>such restrictive licenses are not encouraged or facilitated by this rfc.

Restrictions on fair use couldn't be imposed unilaterally by license, 
but only by a contract (fictionally accepted by click-wrap, or 
actually negotiated and accepted).

The concern about limiting implied licenses is important, though.  By 
definition, an implied license is one that's presumed from the 
context of an offering and by the absence of a contrary explicit 
license.  If as a factual matter, many people have been acting based 
on implied licenses of broader scope than either fair use or what 
would be chosen in an explicitly linked license, then you might say 
it's better not to provide this encouragement to link licenses at all 
(and hoping that time and general practice will morph those implied 
terms into fair uses).

If the rfc encourages people to add licenses, it opens up the 
possibility that their explicit terms will contradict and override 
what has previously been implied.

>>
>This is a critical point.  Without this, implementors cannot safely 
>Yes.  Given the current murky and complicated legal situation with 
>implied licenses, fair use, etc., granting explicit and well defined 
>rights is a huge win for everyone.

I don't think there's a legal mechanism for telling people "you may 
only use this format if you grant a license equally or more 
permissive than X."  (at least none short of patent claims on the 
format itself...)

--Wendy

>How about (IANAL of course):
>
>"Nor can a license.... restrict or remove any implied copy or usage 
>rights which would otherwise exist in the absence of the license."
>

--
Wendy Seltzer -- [email-masked]
Visiting Assistant Professor of Law, Brooklyn Law School
Fellow, Berkman Center for Internet & Society
http://cyber.law.harvard.edu/seltzer.html
http://www.chillingeffects.org/

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 6 Sep 2006 16:04:08 -0400

Wendy Seltzer wrote:
> The concern about limiting implied licenses is important...
> If the rfc encourages people to add licenses, it opens up
> the possibility that their explicit terms will contradict
> and override what has previously been implied.
	This is precisely why I have normally argued against adding rights
and licenses mechanism to Atom and other formats. Unfortunately, it is has
been a losing battle (Atom has <rights/>) so, I'm now trying the tack of
attempting to get explanatory text and weakness in the language in order to
mitigate some of the damage that might be caused.
	Oddly, I think part of the push for these dangerous licensing
mechanisms is the result of success of Creative Commons. We may be seeing
that a movement intended to expand rights will indirectly create a situation
where rights are more easily restricted. People really like the CC mechanism
for granting rights and as a result want cleaner and better understood means
for associating Creative Commons licenses with their content. Unfortunately,
an unintended consequence of satisfying this desire to publish CC licenses
might be that it becomes easier and more common for folk to publish
restrictive licenses.
	Readers of this thread might be interested to see that Denise Howell
has been discussing very similar issues on her new Logarithms blog.[1][2]
I've put some comments in there and have also responded in length concerning
what I, as a non-lawyer, consider some of the implied licenses that attach
to RSS/Atom syndicated content.[3]

	bob wyman

[1] http://blogs.zdnet.com/Howell/?p=17
[2] http://blogs.zdnet.com/Howell/?p=18
[3] http://www.wyman.us/main/2006/09/magazine_or_mus.html

---

From: Karl Dubost <[email-masked]>
Date: Thu, 7 Sep 2006 13:55:53 +0900

> license schemes would never be deployed.

People with legal background will confirm or not, but "fair use"  
doesn't exist in the same way in all countries.

Offering a mechanism to provide licensing information is good.
Encouraging a *legal* fallback mechanism is bad, very bad.

IMHO, when the implementors do not understand the licenses, they have  
no rights to do things with content (because it's highly dependant of  
local laws)

-- 
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: Elliotte Harold <[email-masked]>
Date: Thu, 07 Sep 2006 09:31:31 -0400

Karl Dubost wrote:

> IMHO, when the implementors do not understand the licenses, they have no 
> rights to do things with content (because it's highly dependant of local 
> laws)

Ignorance of the law is no excuse. Implementors have the rights they 
have under the applicable set of laws, irrespective of whether or not 
they understand those rights.

-- 
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: Thu, 07 Sep 2006 07:22:36 -0700

> no rights to do things with content (because it's highly dependant of  
That's why I said 'things like' "fair use".  Our legal department has 
been having fun with this topic over the past several months.  I do 
agree with you that encouraging people to provide licenses is good.  I 
think that there are fallback mechanisms whether or not we encourage 
them.  I think that a fallback mechanism -- implied rights to copy for 
limited purposes -- is a good thing, and whatever gets specified should 
not work against it.  It's an unfortunate fact that the available 
mechanisms are 'squishy' and vary with local laws, but they are better 
than nothing, which seems to be what you advocate.

More practically, if every feed reader and processor has to be modified 
to understand a license before the license can be used in published 
feeds, the ability to deploy and experiment with licenses will be 
drastically reduced.  Which drastically reduces the utility of having 
licenses.

(Let's say that  Doc Searls somehow discovers a license that would deny 
sploggers more than implied rights to his content while allowing liberal 
use for others[1], and deploys it.  Are you saying that all of his 
readers' feed software would have to drop his feed content until they're 
upgraded to understand the license?)

[1] http://doc.weblogs.com/2006/08/28

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 7 Sep 2006 17:28:04 -0400

John Panzer asks of Karl Dubost:
> (Let's say that  Doc Searls somehow discovers a license that
> would deny sploggers more than implied rights to his content
> while allowing liberal use for others[1], and deploys it.
>  Are you saying that all of his readers' feed software would
> have to drop his feed content until they're upgraded to
> understand the license?) [1] http://doc.weblogs.com/2006/08/28
	I think John's question can be (aggressively) rephrased as: "Can Doc
Searls, by inserting a license in his feed, 'poison' the entire syndication
system that we've built over the last few years?" (i.e. Can he do things
that make it unsafe or illegal for people to do things which the syndication
system was intentionally built to permit and which he knew were being done
before he willingly inserted his content into the syndication network?) I
don't think so.
	As argued in other messages, I strongly believe that we should not
do anything that hinders or conflicts with the establishment or recognition
of a limited implied license to syndicate content which is formatted using
RSS/Atom and is made openly available on the network. (An interesting
question, of course, would be: "What does it mean to 'syndicate'?")
	In any case, there is a general problem of "proper notice" here. As
mentioned before, there is nothing special about an optional IETF protocol
extension. This subject of inserting licenses in content should be discussed
in a general sense -- not limited to this specific protocol extension. 
	A vital question to ask is: What is proper notice of the presence of
a license? No IETF standard has the force of law. Readers are not obligated
to understand or even take note of the license links. Thus, no one using it
should be able to have any expectation that readers will take note of it any
more than they would of many other possible means of inserting licenses or
references to them in content. Publishers and consumers should both be
working on the assumption that normal copyright exists (i.e *all rights
reserved*) except where there are fair use privileges of implied licenses
that weaken the *all rights* default.)
	If we were to allow or encourage any one mechanism to associate
restrictive licenses with content, we establish a precedent that would allow
or encourage others as well. Any other "standards group" or informal
collection of one or more persons could decide to define a new mechanism --
just like the IETF did. At that point, no reader could safely consume
content since no matter how many mechanisms they supported there might be
some others that they didn't know about. The issue here is about proper
notice... How can we obligate folk to respect licenses that they have no
means of discovering?
	We should also ask: "At what point does a restrictive license become
operative?" Imagine that I decided that reading (copying) of my feeds by
commercial organizations was to be prohibited. Could I bar such copying by
putting a license in the content itself? Of course, if I did, that means
that in order to discover that copying was not permitted the reader would
have to actually do the thing which is prohibited. Clearly, even if there
was some way to put effective restrictive licenses in content, there would
have to remain some "implied license" exceptions to the *all rights"
provision of copyright.
	We are all best served by an assumption that copyright leaves "all
rights" reserved to the publisher and that only "fair use," "limited implied
license to syndicate," and "explicit license grants (like CC)" limit the
totality of those rights. With this in mind it might be best to change from
a "license" link to a "rights-grant" link... In other words, frame this link
type as something which can *only* be used to broaden rights, not restrict
them.

	bob wyman

---

From: John Panzer <[email-masked]>
Date: Thu, 07 Sep 2006 19:50:56 -0700

Wendy Seltzer wrote:

> definition, an implied license is one that's presumed from the context 
> of an offering and by the absence of a contrary explicit license.  If 
> as a factual matter, many people have been acting based on implied 
> licenses of broader scope than either fair use or what would be chosen 
> in an explicitly linked license, then you might say it's better not to 
> provide this encouragement to link licenses at all (and hoping that 
> time and general practice will morph those implied terms into fair uses).
>

That's a worrying Heisenburg effect.

> only use this format if you grant a license equally or more permissive 
> than X."  (at least none short of patent claims on the format itself...)

No, but I think there may be a technical mechanism for saying "this 
particular extension only lets you grant rights with each new license 

>> feed provider adds a license, it is still allowable.
There is a parallel with the principle of substitutability [1] in 
software engineering, which allows extension while maintaining desirable 
invariants (in this case, the ability to what one would naturally expect 
to do with a feed).

[1] http://en.wikipedia.org/wiki/Liskov_substitution_principle

-John Panzer
http://abstractioneer.org

---

From: James M Snell <[email-masked]>
Date: Fri, 08 Sep 2006 08:21:59 -0700

I think the discussion around this has been absolutely excellent.  Lots
of very good information and perspectives.  At this point I need to stew
over things for a few days and think about how to proceed with the
extension.

In addition to the several technical changes that I may end up making to
the specification, I am thinking now that a detailed description of the
non-technical issues surrounding this spec would be a great addition to
the document.  I'm just not sure I'm qualified to write such a thing myself.

- James

---

From: Thomas Roessler <[email-masked]>
Date: Mon, 11 Sep 2006 12:40:10 +0200

On 2006-09-08 08:21:59 -0700, James M Snell wrote:

> I think the discussion around this has been absolutely excellent.
> Lots of very good information and perspectives.  At this point I
> need to stew over things for a few days and think about how to
> proceed with the extension.

The last call for this spec is ending today...  I'm wondering a bit
what the next step (if any) between you and Lisa (as the shepherding
AD) needs to be in order to make sure that this goes as you intend
it to go.

-- 
Thomas Roessler   <[email-masked]>

---

From: James M Snell <[email-masked]>
Date: Mon, 11 Sep 2006 07:24:35 -0700

I talked with Lisa a bit about this next week.  I'll be working on
iterating the draft based on this conversation and will request another
last call once it's ready to go.

- James