Subject: the "atom:copyright" element

From: Robin Cover <[email-masked]>
Date: Sat, 7 May 2005 18:29:12 -0400 (EDT)

The publication of a new Implementation Guideline by the
Open Archives Initiative (OAI) compels me to suggest once
again [1], as Norm Walsh [2], Bob Wyman [3], and others have
done before, that the name 'atom:rights' would be better
than the (current) element name 'atom:copyright'.

Since this element name change is not likely to have any
secondary ramifications that would affect other areas of
the format design, it should be harmless. Using the element
name 'atom:rights', as argued below, could enhance
interoperability and avoid some unforeseen and unintended
legal implications that may emerge from use of the term
("copyright").

The term "copyright" has an established legal meaning -- or
rather, set of established legal meanings, in various
languages and jurisdictions, whereas "rights" is capable of
a generic meaning that extends to the rights of readers
(consumers) as well as to the rights of authors (creators). Why
should the Atom spec support the latter and not the former?

I agree with 99% of earlier list postings [0] to the effect that:
DRM is a snakepit; we don't want to come anywhere near it; DRM
patent terrorism is a scourge; rights management constructs
per se DO NOT belong in the Atom design, etc.

So, I do not advocate 'atom:rights' over 'atom:copyright' because
I want Atom to support rights management (enforcement), but
because I think using 'atom:copyright' gives privilege to the
wrong set of stakeholders, and potentially leads to a
legal mess. The label "rights" has no clear association with
intellectual property law(s); by its genericity, it would
allow for and support the (established) concept of "IP rights
claim + prohibition against copy/reuse/CreateDerivativeWork",
which roughly == "copyright", while allowing other concepts like
"you're free to use this, please include some kind of
attribution for the source, thanks!"

Stated otherwise, a declaration like (version -08 example)

"<copyright>Copyright (c) 2003, Mark Pilgrim</copyright>"

serves the need of an author to assert IP ownership
and to (possibly) discourage certain -- but unclear -- uses
of the embedding Atom entry/feed.  A declaration
"<copyright>... </copyright>" does nothing to encourage
syndication, or to clearly communicate that the content
of an Atom feed/entry may be re-used freely, by permission.

Two other major initiatives have recognized that rights
properly belong to users/readers as well as to authors,
and have registered this opinion in the technical design of
XML markup vocabularies: the Open Archives Initiative (OAI)
[4] and Dublin Core Metadata Initiative (DCMI) [5].
OAI supports a model for federated databases and
unified search engines that access archives at hundreds
of digital libraries and archive centers; DCMI's
"Dublin Core metadata" model has been adopted for use
in many HTML, XHTML, and XML markup applications.
Formal specifications from both organizations allow
generic "rights" markup elements that contain free-form
text as well as by-reference (URI) pointers to resources
that document the relevant "rights" -- which users are
free to consult or ignore.

I believe the Atom spec can do this similarly (and
minimally) with an 'atom:rights' element in place of
'atom:copyright'. It can do so optimally by allowing
one (optional) generic URI reference to a resource
that documents the "rights" statement(s) from the
creator of an Atom feed/entry.  Something non-legal,
like 'rightsDescription="URI"'.

I predict that if the Atom spec does not make this
kind of accommodation to support this widely attested
requirement, multiple (incompatible) ad hoc solutions
will be invented, alongside widespread "abuse" of the
'atom:copyright' element.  Surely, "multiple (incompatible)
ad hoc solutions will be invented" ANYWAY, but providing
the basic markup construct in the Atom syntax spec would
point users in the right direction, rather than leaving
them directionless.

In making this request for WG reconsideration of the
appropriateness of the element name 'atom:copyright', I
respect the fact that the The Atom Syndication Format
specification is in last call [6], "near that finish
line" and "onto the last lap" [7].

Thanks,

Robin Cover
OASIS
XML Cover Pages
http://xml.coverpages.org/

PS [Bob Wyman,] Note that I have not referenced the
Creative Commons or (machine-readable) "licenses" at
all in the above. While I approve of both, I think
any such use should be a decision left to an Atom
author -- and I do not think it should be the role
of the Atom spec designers to positively *prevent* an
Atom author from referencing a machine-readable license
in an unambiguous manner if s/he wishes to do so. Surely,
enabling an Atom author to clearly declare her/his
intent is preferable to enforcing "intentional prose
ambiguity" through spec constraints.

====== Excursus on OAI and DCMI models for "rights" ======

I would *NOT* recommend modeling any Atom design after
the OAI and DCMI designs, specifically, and I would *NOT*
suggest that Atom recommend any behavior with respect
to processing of assertions made in connection with an
'atom:rights' element instance. My point is that other
public initiatives have not felt the need to capitulate
to the implied threat from DRM vendors to the extent
of saying "we cannot allow Atom authors to express
anything that even smells like "rights" lest we be
sued for DRM patent infringement."  The DRM world is
indeed a snake pit, if not also a den of thieves
(RMS: "DRM is theft"), but arguably, that reality can
hardly be used to justify a one-sided Atom model which
predicates legal rights of content owners and denies
the right to predicate the rights of readers.

Having clarified that I'm not suggesting an Atom replica
of the OAI and DCMI designs, let me summarize both, cribbed
from news stories I composed earlier

1. Open Archives Initiative

==================================================================

The OAI Protocol for Metadata Harvesting (OAI-PMH) has now
become the most widely adopted approach for publication of
both "data" and "metadata" by online digital libraries and
archive centers. A list of registered OAI conforming
repositories (perhaps not current) identifies some 286
digital library projects using this federated database
approach, and the OAIster Digital Library Production Service
at the University of Michigan stores some 5,366,375 records
of digital resources from 472 institutions.

The essence of the open archives approach is "to enable access
to Web-accessible material through interoperable repositories
for (meta-)data sharing, publishing and archiving. OAI
develops and promotes a low-barrier interoperability
framework and associated standards based upon open protocols.
In the OAI model, a data provider maintains one or more
repositories (web servers) that support the OAI-PMH as a means
of exposing metadata; a service provider issues OAI-PMH
requests to data providers and uses the metadata as a basis
for building value-added services.

According to the online tutorial, OAI-PMH provides "a simple
technical option for data providers to make their metadata
available to services, based on the open standards HTTP
(Hypertext Transport Protocol) and XML (Extensible Markup
Language). The metadata that is harvested may be in any format
that is agreed by a community (or by any discrete set of data
and service providers), although unqualified Dublin Core is
specified to provide a basic level of interoperability. MARCXML,
METS, and OLAC are also popular supported formats. The OAI-PMH
protocol is based on HTTP with support for flow control.
Request arguments are issued as GET or POST parameters.
OAI-PMH supports six request types, known as verbs; responses
are encoded in XML syntax. OAI-PMH supports any metadata format
encoded in XML, and OAI-PMH defines a single XML Schema to
validate responses to all OAI-PMH requests."

The new OAI Guidelines document specifies the mechanisms by
which rights expressions can be conveyed at three different
levels representing OAI-PMH data model entities: the record
level, the repository level, and the set aggregation level.

At the record level, metadata returned in OAI-PMH ListRecords
and GetRecord responses "is packaged in <record> elements. Each
<record> may include one or more <about> containers that
provide information about the metadata. A rights expression can
be associated with the metadata by including an optional
<rights> package in an <about> container. The specification
defines an XML schema to which such <rights> packages must
conform. The schema allows for actual rights expressions to be
specified by one of two mutually exclusive alternatives: in-line
within a <rights> package, or by-reference via a URI of a
network-accessible rights expression. In the by-reference
encoding, there are no restrictions on the nature of the
resource referenced by this URI; however, to facilitate machine
processing, it is recommended that an XML formatted rights
expression is accessible via the <rightsReference> URI."

==================================================================

2. Dublin Core Metadata Initiative (DCMI)

http://dublincore.org/usage/decisions/2004/2004-01.Rights-terms.shtml

In June 2004, the Usage Board of the Dublin Core Metadata
Initiative (DCMI) announced approval of the rights-related terms
"License" and "Rights Holder" in machine-readable metadata
declarations; "license" as a refinement of "dc:rights".

The proposed standard of practice for encoding formal rights
declarations identifying IP owners and machine-readable licenses
provides a basis for distributed de-centralized rights management
systems. Use of Dublin Core specifications and Creative Commons
licenses involves no royalty or usage fee, as is true also for
the XML-based Open Digital Rights Language (ODRL).

The Dublin Core Metadata Initiative is "an open forum engaged in
the development of interoperable online metadata standards that
support a broad range of purposes and business models." The Dublin
Core Metadata Element Set is a standard for cross-domain information
resource description, implemented in markup languages perhaps more
widely than any other metadata specification. Version 1.1 has been
endorsed as ISO Standard 15836-2003, NISO Standard Z39.85-2001,
and CEN Workshop Agreement CWA 13874.

The new DCMI term "license" is an element-refinement for "rights"
and provides for reference of a legal document giving official
permission to do something with the resource. The DCMI recommended
best practice is to identify the license using a URI. Examples of
such licenses can be found at the Creative Commons web site.

====================
References
====================

[0] Atom Syntax list, circa 92 postings on copyright/DRM
http://xml.coverpages.org/AtomCopyright.html

[1] RCover, earlier request for element name "rights", 
http://www.imc.org/atom-syntax/mail-archive/msg04048.html

"You missed nothing.  I did not intend to propose formalizing
machine readable rights statements.  My principal intent was to
suggest use of the term "rights" and to allow a URI reference.
My secondary objective was to point out that the use of
"copyright" (as a sole designator, label) is prejudicial in
favor of legal formulations that deny the right to
copy/reuse/CreateDerivativeWork.

[3] Norman Walsh  Mon, 24 May 2004 14:04:44 -0400
http://www.imc.org/atom-syntax/mail-archive/msg03942.html

[3] Bob Wyman
http://www.imc.org/atom-syntax/mail-archive/msg04060.html

"I wholeheartedly agree with you that "rights" would be better
than "copyright". All to often, people think that copyrights
are the only rights that need to be dealt with. It simply isn't
so.

[4] Open Archives Initiative (OAI)
http://xml.coverpages.org/ni2005-05-06-a.html
http://xml.coverpages.org/OAI-RightsExpressionSpec.html

[5] Dublin Core Metadata Initiative (DCMI)
http://xml.coverpages.org/ni2004-07-09-a.html
http://dublincore.org/usage/decisions/2004/2004-01.Rights-terms.shtml

[6] The Last Atom Issue ("last lap")
http://www.tbray.org/ongoing/When/200x/2005/05/04/Last-Atom-Issue

[7] Atom Format spec Last Call
http://xml.coverpages.org/ni2005-04-20-a.html
http://xml.coverpages.org/draft-ietf-atompub-format-08.txt
http://xml.coverpages.org/atom.html#atompub08

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 May 2005 15:46:33 -0700

>than the (current) element name 'atom:copyright'.

As before, -1. In fact, I would prefer to remove atom:copyright from 
the core before we make a post-last-call move to substitute a 
less-defined element such as atom:rights.

>the format design, it should be harmless.

Fully disagree. Later, you suggested that the renamed element would 
have a URI that pointed to the rights asserted by the author. That 
has a *lot* of effects, including the need for someone to resolve 
that URI before republishing the content in another feed, and storing 
the resolution of that URI with a copy of the contents (so that that 
author can't change the contents and then come after you). That is 
far from harmless.

>  Using the element
>interoperability

Sorry, I didn't see anything in the rest of the post that showed how 
this could increase interop. Please be specific here. To me, you 
can't get much more interoperable than an unstructured, 
human-readable, free-text blob such as atom:copyright.

>  and avoid some unforeseen and unintended

Legal FUD doesn't help here. The current atom:copyright entry has no 
properties different than allowing someone to type in whatever 
human-readable copyright notice they want in an HTML document. If 
someone is comfortable with asserting a copyright, they can; if 
they're not, they don't have to.

>Something non-legal,

Please explain how "rightsDescription" is "non-legal" while 
"copyright" is legal. Seriously, I don't see how they can be 
differentiated. If you claim particular rights, that's a legal 
assertion of the same strength as claiming a copyright.

>point users in the right direction, rather than leaving

This goes back to the question of what goes into the core and what is 
done as an extension. I would strongly support the latter because, as 
you posit, people will disagree on how they should be able to assert 
rights. Coming up with a single extension structure that will keep 
everyone happy will take a lot of wrangling, but the effort would 
probably be worth it.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Robin Cover <[email-masked]>
Date: Sat, 7 May 2005 20:43:38 -0400 (EDT)

> author can't change the contents and then come after you). That is 

I distinguished between minimal and optimal: minimally, I simply asked
for 'atom:rights' in place of 'atom:copyright'.  How is that harmful
(other than to existing implementations that people don't want to
change)?

As I envisioned both the minimal and optimal encoding, a user is
not under any obligation to read (parse out) the meaning of the
"human-readable, free-text blob" of textual content in the
'atom:copyright' element -- or did I miss some Atom statement about
compliance?  My understanding is that users of Atom feeds/entries
are at liberty to either consult or ignore the free-text blob --
not required to behave in some particular way in relation to some
copyright claim that may or may not be stated coherently in
<copyright>...</copyright>

Certainly, in the case of any (I said, "optional") URI reference,
which would be part of an optimal solution but not required by
the minimal element name change: I do not envision any *need* for
anyone to resolve any URI.  Its intent would be to provide a
mechanism for unambiguous reference ONLY for parties that wished
to use this mechanism for resource discovery and other purposes.

> human-readable, free-text blob such as atom:copyright.

OK, "interoperability" may not have been the best term.  I mean
interoperability in terms of programs that look for a particular
kind of factoid in some predictable place.  The alternative is
a hundred and one kinds of adhockery thrown into the free-text blob;
a URI reference would be generically "see also, if you care to",
but also "the license is here, for users that want to fetch
licenses, that's what you'll see if you dereference the URI."

> they're not, they don't have to.

No legal FUD intended: I think it's common consensus that the
word "copyright" is a legal term related to intellectual property
law.  The term "rights" is not because it can mean moral rights,
civil rights, etc. etc.  The term "rights" certainly can subsume
"copyright," and so, this makes sense:

<rights>Copyright (c) 2003, Mark Pilgrim</rights>

However, I ask you, does this make sense:

<copyright>The corporate entity that owns this Atom document as
its intellectual property does not wish to be identified by name,
but I, although not the owner, certify that I am empowered to
declare that you may legally display the text in your browser,
and print it on paper, and display it on any website under your
control, provided that you are an employee of a company having
fewer than 20 employees as of 2005-05-03.</copyright>

It's a silly example, intended to remind that declarations about
rights may be of greater interest with respect to the particular
uses and and particular users of information -- none of which is
(as I understand copyright law and practice) covered by "copyright"
law per se.  But of course, IANAL.

> assertion of the same strength as claiming a copyright.

I only meant that "copyright" is a legal term, and that
"rightsDescription" is not inherently a legal term, because it
could be used of many kinds of rights that are not "legal."

To make the point clearer (WRT this optional attribute
name, hypothetical, only on the optimum solution), the
label could be 'seeAlso'

as in seeAlso="http://example.com/myStuff"

> cat myStuff

<html><head><title>MyStuff Plea for Funding</title></head>
<body><p>I worked on this a ong time, so if you use it
in some public setting, please contribute to my PayPal
account #9586956, but if you're poor, that's OK, just
use it for free.</p></body></html>

> everyone happy will take a lot of wrangling, but the effort would 

The "optimal" solution that's usef by OAI and DCMI, but also
by many others, is actually quite simple, because it's not
intended to be used for enforcement; there's no need to
agree on how to assert rights, in detail: just point to the
resource via a URI.

I think this is why, irrespective of Atom designers' attempts
to stop this, people will invent a lot of solutions that use
URIs, as in (John Panzer)

http://www.imc.org/atom-syntax/mail-archive/msg13901.html

<q>

<link rel="license" class="moz-txt-link-rfc2396E" 
href="http://creativecommons.org/licenses/by/2.0/">
"http://creativecommons.org/licenses/by/2.0/" />

</q>

I don't know if 'license' is registered yet, but this will probably be
one of the cleaner solutions, amongst many dirty ones, most of
which ignore the proposed single extension structure.

Thanks for your feedback.

--

---

From: Graham <[email-masked]>
Date: Sun, 8 May 2005 01:35:53 +0100

> (other than to existing implementations that people don't want to

Because "copyright" is the better understood and more widely used  
term. "rights" is meaningless.

> fewer than 20 employees as of 2005-05-03.</copyright>

Yes. The "corporate entity that owns this document" would be the  
copyright holder, non?

Is that a Che Guevara t-shirt you're wearing?

Graham

---

From: Robin Cover <[email-masked]>
Date: Sat, 7 May 2005 21:41:39 -0400 (EDT)

> term. "rights" is meaningless.

The designers of Dublin Core and OAI-PMH didn't think so: that's
why they adopted markup elements spelled "rights"

http://dublincore.org/documents/dces/

"Element Name: Rights
Definition: Information about rights held in and over the resource.
Typically, Rights will contain a rights management statement for the 
resource, or reference a service providing such information. Rights 
information often encompasses Intellectual Property Rights (IPR), 
Copyright, and various Property Rights. If the Rights element is absent, 
no assumptions may be made about any rights held in or over the resource."

OAI-PMH

http://www.openarchives.org/OAI/2.0/guidelines-rights.htm#record_level

See the XML schema there.

> Yes. The "corporate entity that owns this document" would be the  

I assume so, but that wasn't the point. The point was the same as
that made by Dublin Core in its definition of the rights element
(above):  "Rights information often encompasses Intellectual
Property Rights (IPR), Copyright, and various Property Rights..."

A "rights" description might talk about trademarks, registered
trademarks, service marks, and so forth: different from copyright.

Cheers,

-rcc

--

---

From: "Roger B." <[email-masked]>
Date: Sun, 8 May 2005 03:28:08 -0500

> trademarks, service marks, and so forth: different from copyright.

Robin: In my opinion, the only place an atom:copyright should appear
is at the feed level, as an assertion of ownership of the feed
document itself. Rights statements relating to individual entries
should live within the content, particularly references to trademarks
and the like.

So I guess I'm -1 on atom:rights.

--
Roger Benningfield

---

From: David Powell <[email-masked]>
Date: Sun, 8 May 2005 12:27:31 +0100

Sunday, May 8, 2005, 9:28:08 AM, you wrote:

> document itself.

[Disregarding the name and legal meaning of the element...]

What about entry documents though, surely they should be allowed a
copyright statement?

If I understand it correctly, I agree with Bob Wyman's view: "It's all
about the Entries, Stupid!". Despite the structure of Atom Feed
Documents putting atom:feed at the root, I see feed containment to be
just one of many pieces of optional metadata about entries.

atom:feed elements currently contain either:

  a) metadata about the feed

or

  b) metadata about the feed and contained entries, which can be
  overridden within atom:entry

I don't think that we should expand this to

  c) metadata about the feed and contained entries, which can't be
  overridden within atom:entry

-- 
Dave

---

From: Robin Cover <[email-masked]>
Date: Sun, 8 May 2005 10:27:49 -0400 (EDT)

> > trademarks, service marks, and so forth: different from copyright.

Isolating this statement creates a misrepresentation of the argument
for using the label "rights".  The quoted statement is a reminder that
"copyright" is only ONE kind of "right" typically treated as
intellectual property right.

However, the more substantive argument for using the label "rights" is 
that users nowadays want to express an intent about permissions for
usage (particular usages, in particular usage contexts, by particular
classes of corporate entities, with particular financial restrictions,
etc), and these expression for permission fall outside the realm of 
"copyright."

I made a survey of the major metadata specifications in use, as well
as a number of syndication formats: most of them formally recognize the
difference between "rights" and "copyright" with respect to digital
works.

I won't bother this Atom list with a list of such specifications/standards,
beause it's (apparently) irrelevant.  One example, might help, in case the
examples already given (Dublin Core, dc:rights etc, and Open Archive
Initiative) [1] are unclear.  A new example is IPTC's NewsML [2].

Here's a summary of NewsML followed by a summary of the NewsML 
documentation explaining why the markup language uses a 'RightsMetadata'
markup element, and not just 'copyright'

NewsML, according to the developers, is "the versatile
News Markup Language for global news exchange. NewsML is
designed to provide a media-independent, structural framework
for multi-media news.

It's used by Business Wire, Reuters, and many others (e.g.,
Agence France Presse, ANA, ANSA, Japan Newspaper Publishers
& Editors Association NSK, JCN Newswire, MarketWire, PA News,
PR Newswire, SDA/ATS, The Irish Times, United Press International,
Wall Street Journal Online).

NewsML can be applied at all stages in the (electronic) news
lifecycle. Typical use would include: (1) in and between
editorial systems; (2) between news agencies and their
customers; (3) between publishers and news aggregators; (4)
and between news service providers and end users."

Hopefully, it's obvious why Atom and NewsML often appear in the
same list of technologies for news syndication.

NewsML and Atom both have markup elements for "metadata";
NewsML has a few more than Atom's 15x, but the idea is the
same: there's "content" and "metadata" (about content).

In the NewsML documentation for metadata markup elements, the
distinction is made between "copyrights" and "usage rights":
arguably, forcing all "rights" information into "copyright"
is suboptimal, as well as simply incorrect with respect to
bodies of law that govern these concepts.

NewsML documentation: [4]

"4.1.1 Classes of metadata

NewsML divides the world of Metadata at the NewsComponent level
into four classes:
1) Administrative Metadata: information about a package of news
   objects, or about the creation of the content contained in or
   referenced by the constituents of the NewsComponent.
2) Descriptive Metadata: information about the content contained
   in or referenced by the constituents of the NewsComponent.
3) Rights Metadata: information about the copyrights and usage
   rights of the content contained in or referenced by the
   constituents
4) Miscellaneous: other metadata...

The RightsMetadata element contains information about the
rights pertaining to the constituents of a NewsComponent, and
any relevant usage rights that have been granted by the
copyright holder to other parties."

There's the difference, as articulated by NewsML, very similar
to the markup terms used by Dublin Core, OAI-PMH, and a large
number of other syndication/metadata formats: "copyright" is
a narrow legal term that distinct from usage rights and other
kinds of rights that are commonly expressed for Internet resources.

> is at the feed level,

Interesting: the Atom spec does not seem to share this point of view,
if I have read it correctly

Cheers,

-rcc

> as an assertion of ownership of the feed

[1] http://www.imc.org/atom-syntax/mail-archive/msg14944.html
[2] http://www.newsml.org/pages/index.php
[3] http://www.newsml.org/pages/whouse_main.php
[4] http://www.newsml.org/IPTC/NewsML/1.2/documentation/NewsML_1.2-doc-Guidelines_1.00.pdf

--

---

From: Graham <[email-masked]>
Date: Sun, 8 May 2005 15:18:23 +0100

Robin, are we actually talking about any rights here beyond the  
rights to copy (which includes display and redistribution)?

> The quoted statement is a reminder that "copyright" is only ONE  
> kind of "right" typically treated as intellectual property right.

What other rights can be associated with content? Habeas Corpus? The  
right to bear arms?

Take your agenda elsewhere.

Graham

---

From: Tim Bray <[email-masked]>
Date: Sun, 08 May 2005 09:08:43 -0700

> than the (current) element name 'atom:copyright'.

+1

Speaking as a publisher, Robin's proposal meets my needs better then 
what we have now.  The legal advice I've received is that in many cases 
it's not necessary to assert copyright, unless it's being claimed by a 
party other than the other.  On the other hand, I think many online 
publishers will want to specify various kinds of licensing and rights 
statements.  Right now, 4.2.4 of format-08 says "The "atom:copyright" 
element is a Text construct that conveys a human-readable copyright 
statement for an entry or feed."  Well, this fails to meet the needs in 
the very common case where you don't want to talk about copyright but 
you do want to talk about re-use limitations and so on.  On the other 
hand, if you want to specify some details about the actual copyright, 
<atom:rights> is an OK place to do so.

> like 'rightsDescription="URI"'.

Once again, speaking as a publisher who's not a lawyer, I find it very 
helpful to use widely-shared rights statements by reference - in my 
case, Creative Commons.  So having a standardized URI to point to 
whatever I'm using would be a value-add for me.

Once again, I'm not speaking for implementors, but for authors and 
publishers.  Robin's suggestions would be of benefit to that community. 
  -Tim

---

From: Eric Scheid <[email-masked]>
Date: Mon, 09 May 2005 02:50:29 +1000

On 9/5/05 12:18 AM, "Graham" <[email-masked]> wrote:

> What other rights can be associated with content?

Robin, Tim: 

would atom:rights be the appropriate container for declarations like "foo is
a trademark of (some third party), used with permission"

e.

---

From: Eric Scheid <[email-masked]>
Date: Mon, 09 May 2005 02:45:17 +1000

> What other rights can be associated with content? Habeas Corpus? The

trademarks?

moral rights (not just attribution)?

e.

---

From: Graham <[email-masked]>
Date: Sun, 8 May 2005 18:02:10 +0100

> a trademark of (some third party), used with permission"

How about an atom:footnote element? The biggest flaw in atom:rights  
and atom:copyright is the absence of any hint for either publishers  
or consumers as to how it's meant to be displayed.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sun, 8 May 2005 13:14:08 -0400

> or consumers as to how it's meant to be displayed.

That's a feature. I don't see any point in arguing over "rights" vs.
"copyright". It's just a text blob, so "rights" is fine. The URI is a
horrid idea, though. We have a SHOULD NOT against machine readable
licensing information for a reason.

Robert Sayre

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 8 May 2005 13:30:18 -0400

First, let me say that I am a *very* strong supporter of
intellectual property rights... I have always made my income by "selling" my
intellectual property and I consider the anti-IPR proponents and "Free
Software" evangelists to be no better than thieves or communists... Also, I
am listed as sole inventor on four patents dealing with DRM and I have a
number of pending applications in the works today... Having said that:

	If writers and publishers are provided with mechanisms to attach
"rights" or DRM-like information to Atom entries or feeds, we are likely to
discover that they will mistakenly assume that software will actually take
some note of their statements and use those statements while processing
entries. I believe, however, that it is exceptionally unlikely that Atom
processors will, in fact, process such rights statements. There are many
reasons for this and I've outlined them in numerous posts in the past. The
most important are:
	1) There are no useful, open and unencumbered standards for
expressing limitations to rights in a machine readable fashion. (Note: CC
does *not* support "limiting" rights.)
	2) The DRM space is carpeted with patents and it is unlikely that
people will find an unencumbered DRM method for at least another 10 years or
so.
	3) Authors and publishers are notoriously bad at understanding the
legal implications of what they are saying concerning IPR and will often
limit rights more than they expect.
	4) The cost of upgrading every Atom processor to handle rights
"properly" and without legal risk will make it virtually impossible for
people to build the kind of quick-and-dirty processors that exist today.
(i.e. before you could release your latest PHP-hack, you'd have to get legal
review...)
	5) We'll make it legally dangerous to build software that *reads*
Atom feeds. Thus, it will only safe to write software that creates Atom
feeds. The result will be reduced innovation in the space and potential
domination by a small number of "feed readers" who are able to demonstrate
legal compliance.
	6) We're likely to "pollute the stream" by creating a babel of
rights languages and legal traps that will choke off the Blogosphere.
	7) We risk a situation where some aggregator will obtain preferred
access to an encumbered DRM technology and then evangelize its use among
authors and publishers. The result might be that all feed readers who don't
use the method are forced to either go out of business to avoid the legal
attacks of irate users or they will be forced to pay license fees to the
patent holders. This would not be difficult to orchestrate...
	We should studiously avoid encouraging people to believe that
software management of rights is possible in the open internet until some
time in the future when someone identifies a formal standard which is
demonstrated to be unencumbered by patents.
	If people really insist on providing more encouragement to the
"rights management" folk in the Atom spec, then let us *please* include
something like the following in the specification in order to discourage
people from believing that processors will actually head the content of
their DRM statements:

	"Publishers MUST NOT expect that processors of atom feeds or entries
will, in fact, modify their behavior based on any content provided in or
linked to by this element."

		bob wyman

---

From: Eric Scheid <[email-masked]>
Date: Mon, 09 May 2005 03:54:56 +1000

+1

---

From: Graham <[email-masked]>
Date: Sun, 8 May 2005 18:57:09 +0100

On 8 May 2005, at 6:14 pm, Robert Sayre wrote:

> That's a feature.

The thing is, I have no idea where to put the atom:copyright content.  
It might be a short "(C)2005 Robert Sayre" like you see at the bottom  
of every web page, or it might be a shouty "FOR PRIVATE USE ONLY"  
thing intended to be displayed prominently, or it might be wordy  
licensing text, etc etc. As a publisher, I wouldn't know what to put  
in there other than by seeing what kind of things other people are  
putting, which kind of undermines having an Atom spec. Some  
clarification in this area is needed.

> The URI is a

Agreed, a URI is essentially machine readable (if it links to a well- 
known address) and therefore a bad idea.

Graham

---

From: James Aylett <[email-masked]>
Date: Sun, 8 May 2005 18:55:42 +0100

On Sun, May 08, 2005 at 09:08:43AM -0700, Tim Bray wrote:

> Speaking as a publisher, Robin's proposal [atom:rights not
> atom:copyright] meets my needs better then what we have now.

I'm +1 on atom:rights instead of atom:copyright. atom:copyright
strikes me as very limited in scope, and I agree that actually I don't
care terribly much about asserting copyright ownership, but do care
about asserting usage rights.

For instance, in one situation I have to deal with on a semi-regular
basis, it is impossible to state what the copyright ownership of some
content is. (It's a complex multi-author situation with lots of
implicit and historical relationships, but very few formal contracts.) 
However the use rights are accepted by all parties, so making
statements about copyright ownership isn't worthwhile. And at the end
of the day, as one of the parties with vested interest in the content,
I only care about what other people are allowed to do with it.

[Rights statement by URI reference]
> whatever I'm using would be a value-add for me.

I'm -1 on getting this into Atom core. The utility of creative commons
can be satisfied by using type='xhtml' and putting appropriate anchors
in the text. However the Atom feed itself should, IMHO, contain a
concise statement that is as complete as practical.

(This doesn't mean you'll cover every possible case, but it does mean
that you shouldn't rely on dereferencing a URI for important
points). Saying "I'm using CC 'Attribution, No Derivatives,
Non-Commercial'" and pointing to the CC URI is fine, but saying
"follow this URI for rights info" and nothing else isn't.

I'm concerned that making an explicit URI part of the right elements
would encourage people to shift the balance the wrong way here.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Tim Bray <[email-masked]>
Date: Sun, 08 May 2005 11:48:35 -0700

On May 8, 2005, at 10:30 AM, Bob Wyman wrote:

> Software" evangelists to be no better than thieves or communists...

Hey Bob, please refrain from throwing gasoline around near open flames. 
  Thank you.  -Tim

---

From: James Aylett <[email-masked]>
Date: Sun, 8 May 2005 19:52:39 +0100

> clarification in this area is needed.

My feeling is that we can't impose significant constraints on what the
clients do with the data. Something like "Atom consumers SHOULD
include a way to display the rights statements; publishers MUST NOT
assume that such a display will be given prominence." (The terminology
is probably wrong here.)

What this means to client implementors is that, beyond providing a way
for end users to get at the rights statements, they don't have to bend
their interface or program design towards the rights issue. Since
we're not trying to come up with any kind of mandatory rights
declaration, this strikes me as the right balance.

In my view, a shouty "FOR PRIVATE USE ONLY" would be better placed in
the content itself, at the beginning. While this doesn't make sense
logically, it seems the only viable tradeoff that has any real
utility.

James

---

From: Henri Sivonen <[email-masked]>
Date: Sun, 8 May 2005 22:51:58 +0300

>> What other rights can be associated with content? Habeas Corpus? The

If your lawyer tells you that you need to recite some legalese about 
trademarks, wouldn't (s)he tell you to put the legalese where people 
will see it with the trademarks--ie. in the content?

> moral rights (not just attribution)?

Can you give an example of a jurisdiction where it is useful to declare 
moral rights in a way other than indicating the author? Do you have a 
jurisdiction in mind where the moral rights can be vested in an entity 
other than the author who is a natural person?

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Robin Cover <[email-masked]>
Date: Sun, 8 May 2005 17:08:11 -0400 (EDT)

On Sun, 8 May 2005, Bob Wyman wrote:

+1.  In spirit, I think I agree with what Bob says below.  My mistake, in
trying to agree with Bob's statement that DRM "is a snake pit" [1] lead me
to overreach and say unnecessary things about DRM.  I also support the
foundation of law with respect to IP, and even if I disagree with
some particulars, I respect its force.

[1] http://www.imc.org/atom-syntax/mail-archive/msg13896.html

> number of pending applications in the works today... Having said that:

Personally, I would wear none of the labels "anti-IPR proponent", "thief",
or "communist" agreeably; even if I allow that communism is to be allowed
as an experiment, the experiment seems largely to have failed.  But: enough
of this! and Bob is to be forgiven for responding to some words which I
should not have uttered.  I apologize, Bob.

> processors will, in fact, process such rights statements.

I agree that Atom processors will not (properly) process rights 
statements, whether the term 'atom:copright' or the term 'atom:rights'
is used.  Furthermore, I fail to see how Atom processors reasonably could 
be enjoined to properly process rights statement if the assumption be
that "properly process" means compliance with legal norm in various
jurisdictions. No way: it's never been done before, to my knowledge,
even in commercial DRM software.

I therefore concur with Bob that the Atom spec should include some
statement of the kind he proposes:

  "Publishers MUST NOT expect that processors of atom feeds or 
   entries  will, in fact, modify their behavior based on any content
   provided in or linked to by this element."

I agree with this no matter whether the name of an/the element 
(attribute) be "copyright" or "rights" or something similar.

> There are many

Granting that CC is in no way a standard, and that its chief role is not 
to express prohibitions against use (otherwise granted as right), I 
probably agree, if "unencumbered" means "nowhere on the radar screen of
any pure-play DRM company in search of possible patent infringement."
Therefore, I advocated no use of any such (putative) standard.

> people will find an unencumbered DRM method for at least another 10 years or

Very possible, and for this very reason, some LARGE corporate bodies are
seeking to deploy access/security/rights solutions using unencumbered 
specifications like XACML and SAML (and others) in place of the "DRM methods"
where minefields hide 20 patents per square inch.

> limit rights more than they expect.

Thank you! I agree.  Many people will not understand what is meant, in
the large, if some explicitly declares (rather than leaves implicit)

<copyright>Copyright (c) 2005 John Q. Public</copyright>

Creative Commons, now being internationalized to respect different legal
conventions, was designed to counter *precisely* the problem Bob
identifies: that people (using 'copyright' statements) indeed
"limit rights more than they expect."  And Creative Commons strongly
disavows any interest in DRM: its goal is to encourage permissions,
not rights limitations.

This is one of the reasons, though not the chief reason, why I would
not approve of a specification that provided the <copyright> element
and **no other markup element** as the sole authorized/structured/labeled
means for an author to declare that his/her work "may be used freely".

> (i.e. before you could release your latest PHP-hack, you'd have to get legal

Agree: I cannot imaging Atom processors being equipped to properly handle
rights "without legal risk"; that includes processing of content in
the <atom:copright> element as well as content in any similar element
like <atom:rights>.

> domination by a small number of "feed readers" who are able to demonstrate

I'm not sure what Bob fears as being legally dangerous: legal danger
comes into play, as far as I can see, more from <atom:copright>
than from <atom:rights>, if any legal danger is material.

An explicit statement in the Atom spec indicating that "processors are
not required (SHOULD NOT, MUST NOT be required) to read and act upon
possible claims in the xxxx(copy(rights)) element" should be adequate. 

> rights languages and legal traps that will choke off the Blogosphere.

In my opinion, the Babel will begin if the Atom spec is delivered
without any clear provision for users to clearly express their intentions 
and preferences with respect to (re-use) of Atom documents on the web.
Giving them an appropriately-labeled element and a URI reference
("for further information") is a reasonable beginning.

> patent holders. This would not be difficult to orchestrate...

I don't understand the ingredients which make this risk palpable, but
if it's a real threat, it's a threat no matter what the Atom spec 
prescribes and proscribes.  Generic-label markup elements will not create
this risk.

> demonstrated to be unencumbered by patents.

Agree 110%.  And for this reason, among others, the Atom spec should be
clear that it does not intend to support "software management of rights."

On other hand, I believe that the right to express, in English or in any
natural language, or in equivalent straight-forward markup notation,
one's preferences and intents about the use of digital content -- has
to be a foundational human right.  If we believe it has become legally
risky to declare our intent and our wish, we have forfeited our right
to live in a free society.

> linked to by this element."

I've seen no evidence of "rights management" folk near the Atom spec -- 
and I certainly do not qualify.  I agree that some kind of statement
like the above should be used to clarify expectations about any kind
of (copy)rights expression used in Atom documents.

Cheers,

Robin

--

---

From: Mark Pilgrim <[email-masked]>
Date: Sun, 8 May 2005 22:14:53 -0500

> Software" evangelists to be no better than thieves or communists... 

I knew from the moment I met you that you were destined to become a
corollary to Godwin's Law...

> Also, I
> number of pending applications in the works today...

I don't suppose any of those would have anything to do with
syndication, would they?

Sing it with me now:

"We all live in a Wyman submarine,
Wyman submarine,
Wyman submarine (patent)..."

-- 
Cheers,
-Mark

---

From: David Nesting <[email-masked]>
Date: Sun, 8 May 2005 22:35:01 -0500

> What other rights can be associated with content? 

I intend on utilizing and publishing feeds internal to my company.
While the information in the feed may be considered "copyrighted", it's
really my company's information classification that's the overriding
piece of information that I need to attach to the feed (and/or the
entries, individually).

In other words, how do I attach a "proprietary" label to a feed or
one of its entries?  (Keeping in mind that I may have a "proprietary"
summary for a resource that itself is more restrictive--say, "secret".)

I intended to use the copyright tag for that, because its semantics seemed
closest to what I need.  But now that someone else brought the issue up,
I figured I'd offer my opinion.

David

-- 
 == David Nesting WL7RO Fastolfe [email-masked] http://fastolfe.net/ ==
 fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882  C41F 3065 57D9 832F AB01

---

From: Antone Roundy <[email-masked]>
Date: Mon, 9 May 2005 08:38:44 -0600

>> than the (current) element name 'atom:copyright'.

+1 from me too.

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 09 May 2005 23:26:28 +0200

>>> than the (current) element name 'atom:copyright'.

+1 as well.

-- 
Thomas Broyer

---

From: Eric Scheid <[email-masked]>
Date: Tue, 10 May 2005 11:07:30 +1000

+1

---

From: Robert Sayre <[email-masked]>
Date: Mon, 9 May 2005 21:26:28 -0400

+1 to atom:rights without a URI attribute. Leave it a text blob.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 10 May 2005 15:20:47 +0900

>> than the (current) element name 'atom:copyright'.

+1 here too.    Regards,   Martin.