[Mark Parsons]

Hi all,
We haven’t got much comment yet on the policy so far, although there was some discussion of CC0 vs. CC-BY in the comments to the process document.
Tony just sent some comments from his legal team though. I respond to some of them below and I ask you to read them carefully.
A major point is that we don’t address patents, which is something we should discuss. Another point is if we are to allow CC0 and CC-BY, who decides which to use? I think the WG, but there could be some discussion.
I will be setting up a telecon to review all the comments soon.
cheers,
-m.
Begin forwarded message:
From: Tony Hey
Subject: FW: [rda-outputs-ip] Policy out for comment
Date: February 12, 2014 at 6:16:14 PM MST
To: “Parsons, Mark (***@***.***)”

Cc: “Berman, Fran” , “John V Wood (***@***.***)”
Mark
Here are some comments from our Open Technology Group and our legal team on the RDA outputs and IP policy.
I hope they are helpful …
Best wishes
Tony
Comments on Copyright versus Patents
At a high level, RDA appears to be establishing an IPR policy that is focused only on copyright, and not patents. In general, copyright for specifications is less of a concern than patents. Without a patent policy, there is ambiguity and uncertainly around the patent landscape associated with implementing RDA’s work product. This is both bad for implementers and for RDA, as it will introduce impediments to adoption. Best practice would be for RDA to adopt a patent policy. An example for consideration include the ISO/IEC/ITU-T Common Patent Policy.
The policy they reference is reasonably simple and seeks to avoid submarine patents. I think we could be simpler and say that RDA doesn’t hold patents and that anyone contributing to an RDA Recommendation must disclose any known patent or any known pending patent application. If the patent holder does not allow unrestricted use of the patented material, it may not be part of an RDA Recommendation.
Comments on Core Policy
This document defines the types of outputs, the IP management policy and the contributions process. In general the document seems fine.
In general, the policy is perhaps weakly stated and nested throughout a number of documents with overlaps and duplication, raising the risk of contradictions and sync issues. The hierarchy / relationship / precedence of all of these documents is not clear, leaving it open to interpretation and controversy. For example, it references a document that it “encourages” members to adhere to: “Norms for contributing to and using RDA products” which talks about licensing commitments and states: This document is related to the RDA Outputs and IP Policy and the Process and Criteria for RDA Recommendations.
I can clean this up and be more clear about the relationships.
It is particularly unclear how all of the governing body members are determined. For example, how are the Steering Committee and Council members determined? Are they appointed, elected, acquired positions based on contributions or membership level….? Are all governing bodies made up of representatives from academia, or does industry have some influence? Etc.
This need not be addressed her it is covered in other documents.
A couple of specific points:
• There is a preference for open source licenses of the “BSD family”
o Does this mean BSD-like (i.e. permissive) or BSD and Modified BSD only?
Can someone clarify?
• Recommendations undergo formal review by both the TAB and the Council and must be endorsed accordingly
o In addition to a lack of clarity over how these bodies are created, it is noted that these bodies are relatively small in terms of representation. There is a potential for a bottleneck here. This is partially addressed through review periods that are time bound..
o Taking common practice in open source software it is rare to find groups outside of those making the contribution having final authority over the contribution itself. Would the RDA be better served by having the Tab and Council in a purely advisory role, leaving the technical oversight to the WGs and IGs?
An interesting point that TAB and Council be strictly advisory. Thoughts?
Comments on Criteria for RDA Recommendations
This document defines the process and criteria for recommendations. It seems well defined and complete. Areas that may warrant additional scrutiny from those who have a better understanding of our strategy are:
• “Recommendations must… Require ongoing maintenance and versioning, i.e. they are not necessarily static and must be kept current to be persistently useful.”
o The first occurrence of “must” and one of “not necessarily” seem to be in conflict here
o Who is responsible for this? (see related comment on the norms below)
• TAB review is 2 weeks, member review is 4 weeks, but Council review is 6 weeks: to evaluate the submitted Recommendation on political issues and to give comments. It seems odd the political review takes so much longer than the technical reviews, but maybe that’s realistic in this environment.
• The “appropriate license or waiver” for the Recommendation isn’t attached until after approval by the Council and is the responsibility of the Secretariat. How is the appropriate license or waiver determined?
We can clarify all this. The comment on the review periods is apt.
Comments on Norms for Contributing to and using RDA products
No significant issues with this document. This is essentially a social policy and thus could be debated for months. With that in mind I have a few minor points of potential improvement…
• It’s not clear whether the CC-BY 4.0 or CC0 is at the option of the publisher or consumer of data
o This bullet refers to the “RDA outputs policy” perhaps make this a link to the appropriate para in the policy (which does clearly describe the options)
• “RDA contributors agree that, if requested, they will make reasonable efforts to provide additional information about their contributed materials to facilitate their use.”
o This may be a deterrent to contributors since it requires an unbounded time commitment from the contributor, some may also have an issue with defining “reasonable”
o Taking common open source software practice as a model we see there is typically no expectation of subsequent contributions, the goal is to encourage subsequent support by making it beneficial for the contributor, would a similar model work here?
• e.g. Apache contributor agreement says “You are not expected to provide support for Your Contributions, except to the extent You desire to provide support.”
From
I could go either way on this. I don’t think “reasonable” support is too much to ask, but I see their point.
• The requirement to notify of errors may also be a deterrent, although in this case it is somewhat bounded by the fact that a contributor is only likely to discover an error if they are still working with that data
I disagree. This is very reasonable, especially since these are only norms.
• “RDA users agree that they will endeavor to contribute back to RDA through RDA processes any modifications or adaptions of RDA Recommendations to help ensure ongoing interoperability and compatibility.”
o This would appear to be in conflict with the “typical” license (CC-By 4.0 or CC0) which have no such requirement.
It is not in conflict, it is supplementary to. Indeed CC0 suggest there be associated community norms
o The mixed messages here may be confusing, perhaps rephrase this as something like “RDA users recognize that by contributing back to RDA through RDA processes any modifications or adaptions of RDA Recommendations they help ensure ongoing interoperability and compatibility. To this end users agree to contribute back wherever possible.”
This wording is fine.

Discussion