To put a little money where my mouth is here is a patch that shows the changes that I would like to see based on this issue on d.o. #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?

It adds a checkbox to the splash page that enable and disables dfp.

CommentFileSizeAuthor
#2 screenshot.jpeg67.56 KBredndahead
#1 2147389-d7-1.patch3.08 KBredndahead

Comments

redndahead’s picture

StatusFileSize
new3.08 KB
redndahead’s picture

StatusFileSize
new67.56 KB

Adding a screenshot of the splash screen.

rszrama’s picture

Status: Active » Closed (won't fix)

I do appreciate your willingness to put your money where your mouth is here, but I hope you can understand why I might close this at this point. : P

I did review the patch, though, and aside from it not conforming to our current vision for Commerce Kickstart 2.x, I'm not sure it's the best user experience. If the user chose to install Kickstart 2.x without DFP installed, there'd be no point to forcing their agreement to the privacy policy at all. : )

Despite me defending our position as best as I know how, I do want this to be clear here: your feedback (and feedback from others) on this issue is being heard and will definitely be taken into consideration in any future development of this distribution. We made this decision knowing there would be people who would not approve the user agreement (and therefore not install Kickstart 2.x), but at this point, we still perceive the benefits of DFP in the installer to be the default behavior to outweigh the costs of lost usage.

You asked in #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? if I honestly believe d.o should allow projects to do what Kickstart 2.x is doing, and my obvious response is yes. I do not believe anyone's use of d.o as a distribution platform should mean they cannot do what we are doing so long as there is complete disclosure of any potential tracking through third party webservices. I was the strongest voice in our company in this regard, because I do feel strongly that while we should be free to make unpopular decisions, ostracizing potential users of the distribution, we should only be free to do so if we are fully disclosing what we are doing. The hows, whys, and to what benefits are irrelevant.

I do think I understand what your vision for projects hosted on d.o is and why this rubs you the wrong way, but I beg to differ. I believe the principles of freedom in the open source software world would actually support our position - developer freedom paired with responsible disclosure. I don't think d.o, when used as an infrastructure tool, should be enforcing a philosophy re: a developer's preferred user experience, though I do think it should have policies that protect users from harm / malicious code. I do not believe what we've done here harms anyone or is malicious in its implementation (or intent).

While it's not directly related to the GPL or to the Drupal community itself, you might consider the position of Creative Commons with respect to free cultural works, http://creativecommons.org/freeworks, the correlation being that restricting commercial usage (in our case, that includes but is not limited to using DFP to communicate with users by default in the installer) actually contradicts free culture.