This is a spin off of #2145437: Should d.o. adopt a policy for projects that are serving their own ads when installed and if so, what should that policy be? That issue went down many paths and I don't believe that I made my thoughts very clear and that led to a lot of confusion. This is an attempt at taking a simpler approach to the question.
There have been a couple of decisions made in the past:
#847952: Suspend CVS account for Kaltura (spyware) Made a stance that a hidden iframe is unacceptable.
#847944: Privacy policy for contributions A decision was made that a policy specifically against spyware wasn't needed. In comment #17 it was stated that any software tracking users habits, that isn't it's specific purpose, should not be allowed.
From the original issue there are maintainers that would like to include tracking code within their product. It is my understanding that they feel this should be allowed as long as it is stated up front.
While I understand that policies can allow maintainers to use loopholes around them, a lack of policy can create inconsistent implementations and create animosity when the perception of inconsistency occurs.
Maybe a good starting point is https://drupal.org/comment/3184172#comment-3184172 says that "the purpose of allowing users to access the CVS repository is not to allow them to grab information from any web site running their module" is this true? Does this mean no modules should be allowed to track users habits?
Comments
Comment #1
robertdouglass commented@rednahead - or an alternative approach would be to say that there are ample bodies of law that set good standards for data protection, privacy, and guidelines for using marketing tools. For example, these: http://www.ico.org.uk/for_organisations/privacy_and_electronic_communica...
It would be much easier to point to an agreeable body of law and recommend that the software hosted on Drupal.org needs to comply with such regulations. After all, it will have to out in the wild as well.
For the record, any module where you enter an API key and call a web service, such as Mollom, Salesforce, Google Analytics, etc., is tracking user behavior. The most important question is whether the software user is made aware of this tracking and sanctions it. That is the role of a privacy statement, a terms of service, etc.
Comment #2
Anonymous (not verified) commentedHello,
Can anyone really say, for example, what the sharethis module is sharing (in terms of user habits and website statistics) and with whom it is sharing this info. I wasn't aware that there was any sharing of info going on using this module, yet when I had to clear all caches, I saw the sites that a website I am building connected to when using this module - quite a few sites in Reston, VA ...
Comment #3
redndahead commentedI believe there is a difference between modules that track the website owner and ones that track the website users. I believe modules that track the website users are excluded from this because the website owners purposefully installed those modules to do those tasks and we don't decide what people do with the software that is provided. The ones I've seen that track the website owners are the ones that seem too cause more concern from people. This is what I think this issue should focus on.
I think the link that Rob provided is very good and maybe something we can point to. I still believe something that should be made clear is if it is ok that we distribute software from d.o. that doesn't allow people to use it unless consent is given. And again this is for tracking the site owner not the users of the site.
Comment #4
robertdouglass commented@redndahead - I again believe that Ryan was right in the previous thread that it's up to you to first establish why it is not OK.
Comment #5
robertdouglass commentedPS you're already confusing your own issue with a question that is completely different than the title says.
is a different question than
Which topic do you want to focus on in this thread? The installation workflow of distributions? Or the collection of data generated by using the software?
And please also justify why it is important to split between site users and administrators when considering this topic?
Comment #6
redndahead commentedI believe I did justify it:
I believe they go hand in hand. I think the policy would/should reflect the workflow. My guess is there isn't an official policy, so I'm stating my belief on what should be in the policy. I certainly don't expect when someone says there isn't a policy that we close this issue and start another one.
I also think you continue to misrepresent my stance. I don't believe tracking users is bad, I believe tracking users without the option to opt-out is bad and that's what I meant about consent. My responses are written towards this narrowly focused topic. Maybe another day I'll take up the flag on why I think it's awful that d.o. is distributing software that is restricting people from installing it for reasons other than the gpl v2 license.
Comment #7
robertdouglass commentedAs the Product Owner of Commerce Kickstart, I'm happy to announce that we've listened to user feedback and have initiated a change that let's people installing the software opt out of content delivery:
https://github.com/commerceguys/commerce_kickstart/pull/4
This issue does not require a Drupal.org policy change. Responsive product owners will take user feedback into consideration and improve the product. That is the right way.
Thanks,
Robert
Comment #8
robertdouglass commentedI believe this issue is fixed, and that no Drupal.org policy is needed.