Re: the atom:copyright element
At 01:08 05/05/09, Tim Bray wrote: On May 7, 2005, at 3:29 PM, Robin Cover wrote: 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'. +1 +1 here too.Regards, Martin.
Re: the atom:copyright element
Antone Roundy wrote: On Sunday, May 8, 2005, at 10:08 AM, Tim Bray wrote: On May 7, 2005, at 3:29 PM, Robin Cover wrote: 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'. +1 +1 from me too. +1 as well. -- Thomas Broyer
Re: the atom:copyright element
Sunday, May 8, 2005, 9:28:08 AM, you wrote: 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. [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
Re: the atom:copyright element
On Sun, 8 May 2005, Roger B. wrote: A rights description might talk about trademarks, registered 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. Robin: In my opinion, the only place an atom:copyright should appear 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 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 [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 --
Re: the atom:copyright element
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
Re: the atom:copyright element
On May 7, 2005, at 3:29 PM, Robin Cover wrote: 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'. +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. 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'. 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
Re: the atom:copyright element
On 9/5/05 12:18 AM, Graham [EMAIL PROTECTED] 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.
Re: the atom:copyright element
On 9/5/05 12:18 AM, Graham [EMAIL PROTECTED] wrote: What other rights can be associated with content? Habeas Corpus? The right to bear arms? trademarks? moral rights (not just attribution)? e.
Re: the atom:copyright element
On 8 May 2005, at 5:50 pm, Eric Scheid wrote: would atom:rights be the appropriate container for declarations like foo is 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
Re: the atom:copyright element
On 5/8/05, Graham [EMAIL PROTECTED] wrote: 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. 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
Re: the atom:copyright element
On 9/5/05 3:30 AM, Bob Wyman [EMAIL PROTECTED] wrote: 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. +1
Re: the atom:copyright element
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 horrid idea, though. We have a SHOULD NOT against machine readable licensing information for a reason. Agreed, a URI is essentially machine readable (if it links to a well- known address) and therefore a bad idea. Graham
Re: the atom:copyright element
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] 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. 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 PROTECTED] uncertaintydivision.org
Re: the atom:copyright element
On May 8, 2005, at 19:45, Eric Scheid wrote: On 9/5/05 12:18 AM, Graham [EMAIL PROTECTED] wrote: What other rights can be associated with content? Habeas Corpus? The right to bear arms? trademarks? 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 PROTECTED] http://hsivonen.iki.fi/
Re: the atom:copyright element
On 5/8/05, Bob Wyman [EMAIL PROTECTED] wrote: 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... I knew from the moment I met you that you were destined to become a corollary to Godwin's Law... 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... 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
Re: the atom:copyright element
On Sun, May 08, 2005 at 03:18:23PM +0100, Graham wrote: 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 PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
the atom:copyright element
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) copyrightCopyright (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
Re: the atom:copyright element
At 6:29 PM -0400 5/7/05, Robin Cover wrote: 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'. 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. 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. 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 name 'atom:rights', as argued below, could enhance 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 implications that may emerge from use of the term (copyright). 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, like 'rightsDescription=URI'. 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. 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. 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
