___________________________________________________________________ Date: Fri, 19 Oct 2001 11:44:15 -0400 (EDT) From: "Michael L. Nelson" To: Steven Bird Subject: Re: Machine-readable rights information Steven, Ugh... part of me really wants to stick my head (back) in the sand and pretend this doesn't exist ;-) However, this is perhaps *the* single issue that will decide the full long term impact of OAI, so I'm glad that you stood against the tide on the telecon and insisted that this issue is too important to be ignored. I've read your white paper and think this is an excellent summary of the issues. I especially like the recasting of open source problems into the DL realm. Comments: 1. In the "forks with lockout" issue, "software example", shouldn't it be "takes B's clients" ? 2. A potential "meta"-issue -- what happens if the IPR of the metadata changes over time? If "free" things become somehow restricted, this has serious implications for the SP. (note that our entire discussion to date assumes DPs are "good" and SPs are "bad", but it can go the other direction too.) 3. In the proposal section, a central registry for metadata IPR is being discussed. Just FYI, this is going in the opposite direction of the groups current feeling re: registries (not that this means a central registry in this case is wrong). Perhaps it should be handled like metadata schema definitions -- the OAI site can hosts a handful of the most commonly used IPR definitions, and sites should have the capability of creating and pointing to ones that reside elsewhere. 4. Suppose we introduce the notion of metadata IPR definitions, defined and handled the same way we do metadata formats (names, .xsd files, etc.), supplanting the current method of free-text fields Some issues that I can think of: - make it a required (or optional?) element in the Identify response? how do we handle a DP having records employing multiple metadata IPRs? - make a new verb - ListMetadataIPR ? - make it an argument for the harvesting verbs? (like metadataPrefix is currently a required argument?) - suggest that DPs provide this as a "pre-defined" set? - put another element in the metadata record "header" ? - require that the definition be present in the Dublin Core field "Rights" ? (this would actually help the issue of changing IPR, since this would explicitly be a change in the metadata) I have some opinions about which are better ways to implement this, but I understand the purpose of these documents are presenting choices, not stricly recommending implementations. But I see the larger level of recommendations as you stated: 1. Do nothing (which is actually not a complete disaster, but does put a speed limit in place) 2. Do something 2.1 Build an IPR solution / definition into the protocol (so yucky I don't even want to consider it) 2.2 Treat IPR as just a slightly more bloody then the metadata wars, and piggy-back on other projects / movements I see 2.2 as the only reasonable way out of the tar pit of IPR. The trick will be coming up with the lightest weight implementation. I hope this helps. Let me know if I can do anything else. regards, Michael --- Michael L. Nelson NASA Langley Research Center m.l.nelson@larc.nasa.gov MS 158, Hampton, VA 23681 http://mln.larc.nasa.gov/~mln/ +1 757 864 8511 +1 757 864 8342 (f) ___________________________________________________________________ Date: Sat, 20 Oct 2001 07:55:30 +0100 (BST) From: Andy Powell To: Steven Bird Subject: Re: Machine-readable rights information Steven, thanks for the chance to comment. I do have some comments - unfortunately, I am just about to start travelling to Japan for the DC workshop/conference. I'll try and put some thoughts down in an email and let you have them on Monday/Tuesday. In particular, I would like to consider the use of ODRL (OPen Digital Rights Language) in the context of your white paper. ODRL is a http://odrl.net/. An example of its use alongside DC metadata (but not in OAI-MHP) is at the end of http://www.ukoln.ac.uk/metadata/resources/dc/dc-xml-guidelines/ But you get the idea of what it might look like. I would have thought ODRL statements could be placed in the container in each record and/or within the container in an Identify response. Regards, Andy. -- Distributed Systems and Services UKOLN, University of Bath, Bath, BA2 7AY, UK a.powell@ukoln.ac.uk http://www.ukoln.ac.uk/ukoln/staff/a.powell Voice: +44 1225 323933 Resource Discovery Network http://www.rdn.ac.uk/ Fax: +44 1225 826838 ___________________________________________________________________ Date: Fri, 19 Oct 2001 05:23:11 -0700 From: billn To: Steven Bird Subject: Re: OAI and intellectual property rights I've taken a quick look at the paper, and reviewed the discussion. I'll definitely want to propose some input here, but you first need to define: 1. Rights to what: * The raw data * The OAI metadata * The Full metadata set * Combinations of the above 2. What kind of use: * Private, personal, not for profit * Educational / research * Commercial, restricted use * Commercial, any use 3. What I see as minimums are: * You must not restrict access to the OAI metadata set (This defeats the whole OAI approach) * You must acknowledge both source (of metadata) and author/affiliation (This prevents/deters IP theft) * You must state a default IP policy in machine accessable terms (This forms a base policy for all items unless overriden) 4. Tools needed: A Definitions for items 1 & 2 B Standard, automatic logging of all metadata (MD) harvesting C Secure registration for all MD harvesters (Registration for restricted access must be protected) D Secure access for all harvesters that want access to restricted data (This does not prevent open harvesting, but enables enforcement of more restrictive terms) E Standards for actions taken by source & harvesters (When IP rights/restrictions & harvester desires conflict) We need to handle the situation where some sources will have both open and restricted areas or groups of data sets. This will be simpler if they separate the different permission areas into separate OAI archives rather than handle the complexity of multiple permission types in one OAI archive. Item 3 is required for all OAI compliant archives, and must be either a standard choice for automatic processing or a non-standard that requires specific agreements and secure/restricted access. Under Tools, all sites need A, B & E. Sites that have restricted use will need the facilities of C & D to implement their restrictions. Without C & D, no site can be sure their restrictions are being met. This separates OAI supported archives into two distinct sets: Unrestricted and Restricted. It will be *necessary* for sites using OAI that need restrictions to implement C & D. Otherwise, they cannot assure those who agree to the restrictions/costs that others will not bypass them and make them valueless. This will be essential for OAI to work in a commercial environment. It is important, no, critical to the success of OAI that commercial use can coexist with free. In all cases, the OAI metadata is free access, but the other parts (see 1.) may be restrictd in various ways. Thus both free and commercial access may benefit from the broader distribution of metadata without the loss of commercial income from the other MD and raw data. I see I've rambled on here at more length than I planned. I'll give some more thought to this issue, but please let me know what you think of this first cut. Best regards, Bill Nicholls