Closing out RDA Outputs policy

11 Mar 2014

Dear Output Policy friends,
Sorry for the long hiatus. Somehow, when RDA hired a Secretary General, it didn’t make my life any easier :-)
I think our policy is in good shape, but we need to finalize things. Please read and reply within the next week. So I can make sure the policy gets on the agenda for the Council meeting in Dublin.
Note also that Puneet Kishor from Creative Commons volunteered to set up a BoF in Dublin on Open Licensing. This will also give us an opportunity to explain the policy and its rationale. See https://www.rd-alliance.org/node/1419/revisions/2259/view
Regarding the policy itself, we still need to consider the comments from the Microsoft Research legal team. See details below.
I made some revisions to the policy, that I think address all the comments except for a couple points:
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.
I propose we add a clause saying:
"RDA does not hold patents. Anyone contributing to an RDA Recommendation must disclose any known patent or any known pending patent application they hold that may restrict the open use of the RDA Recommendation. If the patent holder does not allow unrestricted use of the patented material, the material may not be part of an RDA Recommendation.
Agree?
· Recommendations undergo formal review by both the TAB and the Council and must be endorsed accordingly
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, but we did have a charge to address what RDA endorses. We are not releasing s/w but nor are we releasing formally vetted standards. RDA Recommendations are maybe more akin to references. They have some vetting but you can use them as you see fit.
I do not think we need to revise, but I would appreciate any thoughts you all might have.
cheers,
-m.
On Feb 13, 2014, at 7:03 AM, Mark A. Parsons
<***@***.***> wrote:
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.

  • Juan Bicarregui's picture

    Author: Juan Bicarregui

    Date: 12 Mar, 2014

    Mark,
    I get "Access Denied" on link you gave to the Open Licensing panel. Should it be this link:
    https://www.rd-alliance.org/groups/wiki/plenary-3-open-licensing-scienti...
    or
    https://www.rd-alliance.org/node/1419/
    I agree that we need to say something about patents. The text you give may be enough for now. As well as the ISO/IEC/ITU-T Common Patent Policy, the W3C Patents Policy and Royalty Free License are worth looking at: http://www.w3.org/Consortium/Patent-Policy-20040205/
    I agree with you on the role of TAB/Council on approving recommendations. Note that if the work of the group is done in the open, the work can be picked up by others at any time if they wish (irrespective of when/if the official stamp is put on it).
    Juan.
    - Show quoted text -From: Mark Parsons [mailto:***@***.***]
    Sent: 11 March 2014 21:18
    To: RDA Outputs and IP Task Force
    Subject: [rda-outputs-ip] Closing out RDA Outputs policy
    Dear Output Policy friends,
    Sorry for the long hiatus. Somehow, when RDA hired a Secretary General, it didn't make my life any easier :-)
    I think our policy is in good shape, but we need to finalize things. Please read and reply within the next week. So I can make sure the policy gets on the agenda for the Council meeting in Dublin.
    Note also that Puneet Kishor from Creative Commons volunteered to set up a BoF in Dublin on Open Licensing. This will also give us an opportunity to explain the policy and its rationale. See https://www.rd-alliance.org/node/1419/revisions/2259/view
    Regarding the policy itself, we still need to consider the comments from the Microsoft Research legal team. See details below.
    I made some revisions to the policy, that I think address all the comments except for a couple points:
    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.
    I propose we add a clause saying:
    "RDA does not hold patents. Anyone contributing to an RDA Recommendation must disclose any known patent or any known pending patent application they hold that may restrict the open use of the RDA Recommendation. If the patent holder does not allow unrestricted use of the patented material, the material may not be part of an RDA Recommendation.
    Agree?
    * Recommendations undergo formal review by both the TAB and the Council and must be endorsed accordingly
    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, but we did have a charge to address what RDA endorses. We are not releasing s/w but nor are we releasing formally vetted standards. RDA Recommendations are maybe more akin to references. They have some vetting but you can use them as you see fit.
    I do not think we need to revise, but I would appreciate any thoughts you all might have.
    cheers,
    -m.
    On Feb 13, 2014, at 7:03 AM, Mark A. Parsons
    <***@***.***> wrote:
    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.
    --
    Scanned by iCritical.

  • Mark Parsons's picture

    Author: Mark Parsons

    Date: 12 Mar, 2014

    Thanks Juan. Sorry about the link. The first one you sent is the correct one for the BoF
    https://www.rd-alliance.org/groups/wiki/plenary-3-open-licensing-scienti...
    What do others think about patents?
    -m.
    Sent from my iPad
    On Mar 12, 2014, at 3:40 AM, "JuanBicarregui" <***@***.***> wrote:
    Mark,
    I get “Access Denied” on link you gave to the Open Licensing panel. Should it be this link:
    https://www.rd-alliance.org/groups/wiki/plenary-3-open-licensing-scienti...
    or
    https://www.rd-alliance.org/node/1419/
    I agree that we need to say something about patents. The text you give may be enough for now. As well as the ISO/IEC/ITU-T Common Patent Policy, the W3C Patents Policy and Royalty Free License are worth looking at: http://www.w3.org/Consortium/Patent-Policy-20040205/
    I agree with you on the role of TAB/Council on approving recommendations. Note that if the work of the group is done in the open, the work can be picked up by others at any time if they wish (irrespective of when/if the official stamp is put on it).
    Juan.
    - Show quoted text -From: Mark Parsons [mailto:***@***.***]
    Sent: 11 March 2014 21:18
    To: RDA Outputs and IP Task Force
    Subject: [rda-outputs-ip] Closing out RDA Outputs policy
    Dear Output Policy friends,
    Sorry for the long hiatus. Somehow, when RDA hired a Secretary General, it didn’t make my life any easier :-)
    I think our policy is in good shape, but we need to finalize things. Please read and reply within the next week. So I can make sure the policy gets on the agenda for the Council meeting in Dublin.
    Note also that Puneet Kishor from Creative Commons volunteered to set up a BoF in Dublin on Open Licensing. This will also give us an opportunity to explain the policy and its rationale. See https://www.rd-alliance.org/node/1419/revisions/2259/view
    Regarding the policy itself, we still need to consider the comments from the Microsoft Research legal team. See details below.
    I made some revisions to the policy, that I think address all the comments except for a couple points:
    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.
    I propose we add a clause saying:
    "RDA does not hold patents. Anyone contributing to an RDA Recommendation must disclose any known patent or any known pending patent application they hold that may restrict the open use of the RDA Recommendation. If the patent holder does not allow unrestricted use of the patented material, the material may not be part of an RDA Recommendation.
    Agree?
    · Recommendations undergo formal review by both the TAB and the Council and must be endorsed accordingly
    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, but we did have a charge to address what RDA endorses. We are not releasing s/w but nor are we releasing formally vetted standards. RDA Recommendations are maybe more akin to references. They have some vetting but you can use them as you see fit.
    I do not think we need to revise, but I would appreciate any thoughts you all might have.
    cheers,
    -m.
    On Feb 13, 2014, at 7:03 AM, Mark A. Parsons
    <***@***.***> wrote:
    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.
    --
    Scanned by iCritical.
    --
    Full post: https://www.rd-alliance.org/closing-out-rda-outputs-policy.html
    Manage my subscriptions: https://www.rd-alliance.org/mailinglist
    Stop emails for this post: https://www.rd-alliance.org/mailinglist/unsubscribe/1443

  • Mark Parsons's picture

    Author: Mark Parsons

    Date: 18 Mar, 2014

    OK, having heard no objections, I have added the clause on patents. I now consider this to be the final recommended policy, which I will put before Council in Dublin.

    cheers,
     
    -m. 

submit a comment