CiviCRM on civicrm.org Acceptable Use Policy

This is just a draft, so it's not yet in effect.

Background

On the CiviCRM Community Advisory Group 2/09 conference call, it was decided to setup CiviCRM on civicrm.org in order to "eat our own dog food," i.e. use CiviCRM to help organize and communicate with the CiviCRM community itself. Since there are potential privacy and annoyance implications to allowing the community access to a repository of its own members' contact info and tools to e-mail them en masse, an AUP working group volunteered to draft an acceptable use policy.

Currently that working group consists of Wes Morgan, Roberto Santiago, Brian Shaughnessy, and Michael McAndrew.

AUP Draft

Information in the CiviCRM database is collected by a number of different individuals working with CiviCRM and collected automatically through registrations for CiviCRM events, subscriptions to CiviCRM mailing lists, and other potential contact forms.

The use of any information collected in the CiviCRM installation on www.civicrm.org will adhere to the following acceptable use policies:

• Data will only be used for CiviCRM related activities, or carried by or on behalf of CiviCRM.
• Data will only be used in ways that would be reasonably expected by those people whose data is in the database. For example, registering for an event would not imply listing in a donor directory, and subscribing to a specific topical mailing list would not imply general donation solicitations.
• Administrative access is limited to the CiviCRM core developer team and the advisory group. The core development team retains the right to restrict access to any member of the advisory group or to the group as a whole.
• Because of the relatively open access policy, the database should not be used to store sensitive information on individuals (including, but not limited to, social security numbers, financial account information, passwords, etc.). If an individual requests removal of any or all of their data from the system, it is the responsibility of the first person to receive such a request to do so, provided they are capable of complying with the request. If they are not able to comply, they are to forward the request to the core team for follow-up.
• All e-mail addresses and messages must be handled in such a way that we don't send unsolicited bulk e-mail, a.k.a. spam. Unsolicited messages to individuals are fine (i.e. not bulk), and solicited bulk messages are fine (i.e. they interacted with us first and we made it clear they were joining a mailing list at that point, what it would be used for, and how to unsubscribe).
• Any and all contributions received through the CiviCRM instance on civicrm.org will be handled with the utmost confidentiality. No user will share the name or amount of any contribution with any unauthorized user, or use such information for purposes outside of their explicitly intended purpose.
• Any violation of these rules will result in suspension or termination of your access to CiviCRM on civicrm.org. The core developers have the final say in any and all disputes, and reserve the right to publicly report any such violations.

We will also put this text near-by any place we post the AUP: "To report a violation of these rules, send an email to abuse@civicrm.org. The CiviCRM core team will monitor this address and review any complaints."

Discussion

Brian: My initial thinking is that we basically are defining three tiers of Civi users (as it relates to privacy issues). Core team (they can have segmentation within that group if they choose), the advisory group, and the authenticated website user (I'm thinking about things like the list of users available in the forums). And the big question is how does the advisory group fit into the picture as it relates to potentially "seeing" more sensitive data through Civi for end users.

There's probably two parts to this equation - What can the AG see, and what privacy policy have AG members agreed to that will constrain their use of any privacy data they have access to.

Wes: I like the draft AUP language (written by Michael) because it's short and simple. But should we include a point that adhering to this AUP is required to have access to the civicrm.org Civi instance, and how we'll deal w/ violations?

I think our AUP needs to accomplish the following things:

1. Defines who is and is not allowed to use CiviCRM on civicrm.org (could be all-or-nothing or it could define tiers as Brian suggested).
2. Defines what is permitted and what is not for those allowed to use the Civi instance.
3. Explains any responsibilities users of the Civi instance must agree to (such as not sharing any data in the database with third parties).
4. Explains how violations will be handled.

Dave G: A few thoughts ..

• We need to make sure the AUP is clearly disclosed to folks who interact with CiviCRM features on the site (event reg, contributions, mailing list signup, etc.)
• We may email event-related / follow-up info to folks who register for events. Do we need to disclose that in some way?
• RE: Violations - removing access to back-office CiviCRM functions seems like a reasonable "consequence". Maybe we would also announce the violation "publicly" as an added disincentive??

Xavier: The rules are simple and sane, my background inclines me to add a feed-back look at two levels :

• Obviously everyone having access to the back-office should agree to stick to the rules, and agree that when in doubt, they ask the advisory board if the usage is deemed OK, and eventually that will lead to clarification of the rules
• When rules are changed, everyone is informed and can choose at anytime to remove themselves
• If any user receive an email or any kind of interaction through this db they think is inappropriate, they should have a clear way of complaining (eg abuse@civicrm). The core has the right to disable the access of the offender on the spot (I'd say of any user), and discuss the case with the advisory board.
• If the misbehaviour is proven real and not "accidental", sure it can be made public including who screwed it up, explaining how it won't happen again, feathers and tar and all that jazz

I think we have enough now, we shouldn't overcomplicate it, basically the ones having access to the back office should be responsible enough and understand that this is about civicrm community, and behave accordingly.

Brian: Few things --

• I think we add something explicit regarding contributions. Seems like emails and contributions are likely the two most sensitive areas. Actually, why would any AG folk need to handle contributions at all?
  • "Any and all contributions received through the CiviCRM instance on civicrm.org will be handled with the utmost confidentiality. No user will share the name or amount of any contribution with any unauthorized user, or use such information for purposes outside of their explicitly intended purpose."
• How about a statement re: email to the effect that all backend users recognize all activities must be in accordance with the CAN-SPAM act (that's U.S. only, right? still a decent basis to work with).
  • "Administrative users will respect the privacy of contacts recorded in the CiviCRM instance on civicrm.org. That particularly includes the use of emails provided by users. Administrative users acknowledge that any use of email addresses must adhere to the CAN-SPAM act, regardless of the locale of the administrative user or contact."

I tend to get a little wordy when I type, so some of that text may be overkill.

Joe:

• I think I'd prefer for removal or changes of the data to be the responsibility of a 'privacy officer or their delegate' so that requests get treated in a consistent way. Two people being responsible is better than everyone getting spammed. A role email like 'privacy@civicrm.org' could be forwarded as appropriate.
• following up on Xavier's "When rules are changed, everyone is informed and can choose at anytime to remove themselves", put in policy that it may be changed from time to time, and that it is the responsibility of users to come to view any changes. We're not going to send a message to everyone, and they may not have access to the email stored on file.
• Does CiviCRM core team use consultants or outsource anything, or might it? Usually there is some provision in these things to allow that, and to bind anyone to whom access to the data is allowed.

Wes (in response to Joe):

• I think I'd rather not create a lot of new responsibilities for individual people for something that may not even be an issue. An example of how one of us could "comply" with a removal request could be to send someone a link to the page where they can do that themselves (unless they've already tried and ran into problems). Does that seem workable for now? If it proves to be a problem, we can re-visit.
• I agree on the rule change thing. People on the advisors list should "Watch" the AUP wiki page so they are informed of changes. I'm not sure we need to add anything specific to the AUP about this. AUP's change, and there are ways to track those changes already built-in to the system. Hopefully this won't really be an issue either.
• It doesn't seem like consultants or any third-parties would need access to these data. But maybe I'm being overly simplistic about this? The core devs can speak to this better than I can, though.

Joe (in response to Wes):

• I agree there are likely not going to be many requests. In my experience having 10 or 20 people share responsibility is less likely to work well than one or two. I'm also likely channelling legal requirements in Canada and elsewhere for every organization to have an individual that is responsible and to whom complaints can be made. Not a big deal, it's your draft.
• I am more concerned about potential liability issues for the organization if it wants to change the policy but has not way to do so without informing people and getting their consent to the change - people from whom it has collected information but with it cannot communicate either because it doesn't want to spam or no longer has accurate emails that get through spam filters. You don't want to be hamstrung, and you do want to dot your i's and cross your t's legally on this kind of stuff. That's why it's important to go into the AUP.
• If they are doing anything that involves gaining access rights to the production database it would be an issue. Drafting the policy to handle a short-term contractor now seems advisable, rather than operating in way that is not legal, or having irritating constraints later, or needing to quickly change this policy, or forgetting to do it before handing out an account.
• Picky points, but still advisable, is my sense. FWIW, my wife Lisa Austin is a Privacy Law prof at the University of Toronto.