[Policy] Define How We Ban Modules - Previously Banning unethical modules

clearly unethical

As defined by whom?

yeah... this is a slippery slope question for sure.

But Don’t let CAPTCHAs get in the way of your marketing goals! gives me the creeps-- what I hear is "Don't let a site owner's rules stand in the way of selling your crap to their users!".

I don't know how to phrase this in the form of a guideline-- but I don't think we really want to be in the business of helping folks distribute these types of modules for free.

First, the module in question is an API implementation and little beyond that, so it's up to you how you use it - to spam other sites or to test how spam-proof your site is.

Second, to use the module in question for spamming, one must possess at least as much knowledge as was probably needed to write it, so they could probably write that themselves (read: once again - this is no out-of-box solution).

Third, most spam is distributed from local machines, not from public hosts anyway.

Fourth, the module in question is used by 3 (three) sites [running 'check for updates automatically'].

Summa summarum: the module in question may seem nasty, but starting a witch-hunt could do more harm.

whoa... no one said anything about a witch hunt. Having a guideline to use during the module evaluation process and when issues like this are posted to the webmaster's issue queue is not even remotely a witch hunt.

And ease of use is really a straw man-- what matters is the purpose of the module, not how easy or difficult it is to do it. Same for usage statistics.

First off I am glad we are discussing banning the modules not the users. I agree that there is zero reason to host modules that foster spamming. I would like to hear kenorb's stance on this and the reasoning for him to provide the module. He seems like a very fine community member.

Another unethical type would be modules that promote hate speech or similar stuff, e.g. a module like the pirate module that would automatically change certain words to "nigger" or "faggot". This might sound ludicrous but who knows what might get vomited onto drupal.org.

+1 to #8. kenorb seems to have made a lot of contributions to the community, I'd love to hear kenorb's stance. But I particularly agree with dddave's second point; there's a lot of possible heinous stuff that someone could put up as a module...do we want to get in the business of removing them if they violate some guidelines? I say yes.

As someone who has been in the role of a community manager for a lot of nonprofits, and as someone who's been involved in the Drupal community for a long time (I started the Philadelphia, USA group and helped organize many of the camps there, and I'm now the frontend track chair for Drupalcon Portland) I can affirm that having a policy in place ahead of time is by far the position you want to be in.

Having to retroactively justify removing something that crosses the line is far more challenging within a community than collectively deciding what "crossing the line" entails before it ever comes up. For instance, see ReadWriteWeb's Guide to Online Community Management (slide 57), "Setting up guidelines ahead of time, for community members and employees, is important."

So if this particular module puts to specific a light on it, then perhaps we can reframe the question:

What types of modules WOULD drupal.org refuse to host?

The Drupal community might decide that there are no limits; that everything that passes the technical tests can be hosted. But that's a decision that should be made, rather than simply reverting to because no policy is in place.

We definitely have to tread carefully here. I'm very much against limiting people's abilities to do what they want.
However the exception to that is if what they want is to hurt others, especially if that is the only thing being accomplished.

Plus it's not like we're saying the module can't exist, just that it can't be on drupal.org.

In the case of death by captcha the idea, I hate the idea of spammers using such a thing to get around captcha. Spam is the devil.
However, I'm sure I can think of non-malicious uses for bypassing captchas (probably the 0.1%).
On the other hand, the module's description of "Don’t let CAPTCHAs get in the way of your marketing goals!" paints a picture of the author's intention for the module.

There aren't very many "unethical" modules around, so I don't think we need to make a policy against that class of modules. I'm firmly -1 to the idea of disallowing contribution on the basis that somebody's code doesn't adhere to some loosely defined code of ethics. We already have the DCOC which basically boils down to "Don't be an asshat", and I don't think we need anything more than that.

Also, this sounds like a case against a single module. So if that's the problem, let's address it. We don't need to layer on more policy that is up to interpretation.

BTW, if you have a list of modules which you would consider "unethical", please post them here so that we have something to go on other than a single module.

I'm totally in support of having an official policy against modules that encourage or enable abusive, discriminative or encourage prejudice against individuals or groups of people as pointed out in #8. Oppressive behaviour is completely against the ideal of Drupal and open source software in general.

Comment #10 makes sense to me in that making a clear policy ahead of time will be way easier than fighting fires retroactively after our first big "incident" - kind of like installing a firewall *before* you get yourself hacked :)

Modules that are basically just wrappers around existing APIs like this death by captcha are a bit too "grey area" for me as the module itself doesn't enable anything that wasn't already publicly exposed.

I'd also like to say that I'd be against any move to ban modules based on laws or cultural taboos that are restricted to a single area or nation. There's legit modules like http://drupal.org/project/bittorrent that could really be harmed by that.

We should also consider making the list as accurate as possible. For example, as Drave Robber said, for some module "it's up to you how you use it - to spam other sites or to test how spam-proof your site is". If a module tries to breach the security of a website, we should make sure all modules of this category have in an easily-seen part of the description a phrase like "This module was developed to help the administrators understand the security risks of their own website. It does not intend to help you breach the security of other websites.".

It would also be good if there were a way to let Drupal websites be aware of these modules. For example, if a module hits a website, it should also send with the request some information about the server or the domain name of the website in a certain pattern. We could also develop another module that would update its cache table from a drupal.org XML or something and would know which are these modules, which information are sent, what they do and at last store these unethical module requests in watchdog with a proper display of the information and of what they do.

netstat, nmap, wireshark
Fusker
John the Ripper
siege
metasploit
wget
Back Orifice

That is not all...

Yeah - an anti-anti-spam tool is on the far end of the grey spectrum, but it's still just a tool that *can* be used for evil.

I am a vicious anti-spam zealot, but I've still used all of the above apps in somewhat black-hat mode.

I don't see anything wrong with the Death by Captcha module. I'm not quite sure I see the point of the module, but that's another story completely.

What if the purpose of a module is 'evil', but it is possible to do 'good' with it?

And what if the purpose of a module is 'good', but it is possible to do 'evil' with it?

This discussion is currently going nowhere. Please come up with a list of modules that you wouldn't want to see hosted here, then we can see if we can come up with a list of requirements and agree on them. Everything else is just nonsensical.

I am postponing this issue until such a list has been made available.

I think #10 makes a good case for creating a policy beforehand. Perhaps this could/should be handled by the Community Working Group?

I think it is easier to make a policy once you know what people are talking about.

This reminds me of a famous discussion on defining a threshold test for obscenity which boils down to "I know it when I see it."

http://en.wikipedia.org/wiki/I_know_it_when_I_see_it

-mike

My experience is that defining policies is hoped to be a solution to the problem, but is rarely successful. They often take a lot of time (e.g. this issue so far) and then even once they are in place they become a roadmap of the specific behaviors that people should avoid. So, a malicious user will read the policy, find a loophole, and post their module. And then we have to invoke the "DCOC/Don't be an asshat" and argue about modifying the original policy.

I think in the past when there have been questionable modules a simple contact to the maintainer and asking them to rename it was sufficient (I forget the name, but it was basically a porn-site-stealer-builder that took images from other sites and put them into a gallery on a Drupal site).

I see this is currently "postponed" but I feel it should just be won't fixed.

For those interested in seeing this happen, feel free to draft a proposed policy somewhere else and list the modules you think should be affected. That can allow some concrete discussion.

There are, I'm sure, plenty of modules that I might find offensive, or could be used in offensive ways. But censorship -- a new set of rules above and beyond the DCOC and Drupal Coding Standards, not to mention legal guidelines -- isn't the answer. Censorship of modules in a slippery slope.

I recall several years ago there being a pr0n-related module I found particularly galling. IIRC, nobody banned it. It just faded into history, forgotten, irrelevant.

#25: exactly my thoughts

The only "unethical" modules and themes I support a ban of are those that mislead or cause harm to the person downloading them or violate a license.

#27 is of course a great point. I treminded me that we have this when you agree to using git.drupal.org:

To use Drupal's version control systems you must agree to the following:

• I will only commit GPL V2+-licensed code and resources to Drupal code repositories.
• I will only commit code and resources that I own or am permitted to distribute.
• I will cooperate with the Drupal Security Team as needed.
• I have read and will adhere to the Drupal Code of Conduct.
• I agree to the Drupal Code Repository Terms of Service.

So, we have a policy and it matches my expectations :)

#28 +1

As an extra data point, we have in the past kicked modules out for:

- GPL violations.
- Trademark violations. (Of someone else's trademark.)
- Spywire. ("phoning home" to some 3rd party service without informing the user.)

IMO all of those are perfectly good reasons to remove a module.

When you say "kicked out" I think

- GPL violations have repositories emptied, but not project page/issue queues
- Trademark violations are mostly left up to the project maintainer to deal with (I only remember 1 of these happening and it was in ~2008)
- Spyware issues get a critical issue in the module queues that can result in losing access to the project if the maintainer doesn't remove the offending code, but the code/project stays around

IMO the reasons that Larry gave are more legal reasons than ethical in the sense that the original poster meant.

It is obvious that we have to remove/rename/do whatever with modules that infringe on somebody else's rights.

Ref. "Comment request for the "Banning unethical modules" discussion"
https://drupal.org/node/2129151
(request for @kenorb to comment here, posted in that module's issue queue)

probably the module page is used only to have quality links from drupal to deathbycaptcha site

How about we start with setting up a policy on how/why we would ban such modules.

They can always post them on Github. Drupal.org means that the community is taking responsibility for maintaining them to some degree.

First, I think #10 makes a great point, Drupal.org needs to have a policy in place.

The policy should not talk about banning people or projects, but draw the line regarding what type of material will be hosted on Drupal.org. I.e. a violation can be repaired by removing the unacceptable material from the project repo or from other content.

There seem to be consensus about that the following should not be hosted:

• GPL violations.
• Trademark violations (of someone else's trademark).
• Spyware. (e.g. "phoning home" to some 3rd party service without informing the user).
• Spam (content whose sole purpose is to promote a product or service, without disclosure).

I find the extra bullet point suggested by fizk problematic:

• Are there to promote a bad practice (breaking captcha's).

I think the term "bad practice" is far too vague too be used as grounds for policy. This can be illustrated by the example suggested: Death By Captcha, I don't see this module as a bad practice. I hate spam, and some of the language used to promote the project ("Don’t let CAPTCHAs get in the way of your marketing goals!") is mildly offensive. But I also happen to think that the type of CAPTCHA this module apparently break is useless these days. So the module serves an educational purpose. I can point clients to this module and tell them why they need to use a better strategy to prevent spam than the "distorted letter" CAPTCHA.

Unless someone can come up with a much better definition of what makes a "practice" unacceptable, I am not in favour of adding this point to the list.

However, I am in favour of adding the following two items to the list:

• Hate speech.
• Illegal content.

Hate speech (re #8) have a clear enough definition, so that it will be possible to know where to draw the line if we ever have to exercise this policy. However, I understand and respect that some people think that making "hate speech" unacceptable interferes with first amendment rights (i.e. freedom of speech). If the majority don't want to include "hate speech" in the list of unacceptable content, I'm fine with that.

Another point that I think need to be added to the list is "Illegal content". As a webhost Drupal.org can be held legally responsible for what is stored on its infrastructure. As Drupal.org will be required by law to remove illegal content, it should be stated up-front that this is not the place to host copyright violations, etc.

After a policy has been decided, I think it should be placed in a document commonly known as "Acceptable Use Policy". I may have overlooked something, but I was unable to find neither a "Acceptable Use Policy" nor a "Privacy Policy" anywhere on Drupal.org. I think every professionally managed need to have these two documents in place (they are usually linked in the site's footer). I find it weird that such a site such as Drupal.org, which should try to appear as professional as possible, does not have them. (There is even a project: Site Disclaimer for managing these, but IMHO, a Basic Page with some suitable text will do.)

As for deciding on the content of these two policy documents, I still haven't figured out how the decision making processes works on this site (except that they seem to take a very long time and that very little gets decided, even after prolonged discussions), so I leave it to whoever knows more about the process than I do to figure that out.

fizk, thanks for the feedback.

First, you didn't comment on my note that we shouldn't ban modules or people, we should have a list of "unacceptable content" as part of the site's "Acceptable Use Policy", and allow violations of this policy to be repaired if possible (flat out spammers - a pox on them - excepted).

I hope this means you agree with this point. If so, it may be an idea to change the topic from "How we ban modules" to "Do we need an Acceptable Use Policy"?

For the record: I am opposed to any sort of policy where anything (except spammers) are "banned". But I believe this site needs an acceptable use policy written down, and that this policy document needs to contain a list of things that are not acceptable.

Second, you want the list of unacceptable content to include the item:

• Software that breaks CAPTCHAs.

Or perhaps something in the same spirit, with a wider scope (see #17 for some examples), such as:

• Software that facilitates abuse (e.g. spamming, password cracking and other recognized forms of abuse).

If so, I respectfully disagree. As I've already written, software that breaks CAPTCHAs (and other abusive software) serves an educational purpose. Abusive software exists. As good site builders, we need to familiarize ourselves with it. I would rather download such a project from Drupal.org, where there are some policing in place regarding real malware (such as spyware, trojans and fly-bys), than having to download it from Warez'r'Us.com.

I don't think breaking CAPTCHAs is unethical. Breaking CAPTCHAs in order to circumvent a site's AUP is unethical: But I think it is a mistake, securitywise, to confuse the capabilities of a piece of software with unethical uses of those capabilities.

I also want to add that in the world of software security the line between tool for abuse and a tool for analysis is very blurred. Sometimes, it apparently comes down to the choice of acronym. Programmer Dan Farmer received praise for a vulnerability scanner named "COPS" (Computer Oracle and Password System), but when he created a very similar scanner for network vulnerabilities and named it "SATAN" (Security Administrator Tool for Analyzing Networks), the US Justice department went bananas and threatened Farmer's employer with charges. Farmer was fired. Then Farmer created yet another vulnerability scanner named "SAINT" (System Administrator’s Integrated Network Tool), and nobody raised an eyebrow.

I'm not sure what the difference is between "banning a module" and saying the module is unacceptable. Can you please explain the difference?

I have never suggested that that we say a module is unacceptable. I want to say that certain content is unacceptable, and that when unacceptable content is identified, it should not be banned, but repaired (if possible).

For instance, let's say a module is found to contain copyrighted non-GPL code. This is an obvious policy violation. I do not want to "ban" that module, or say that this module as a whole is "unacceptable". Instead, I want the module to be temporary suspended, and give the maintainer the opportunity to repair the problem by finding a way to remove the non-GPL code from the repo (as outlined in the guidelines for 3rd party code). When the problem is repaired, the suspension is lifted.

By the way, the "Drupal Git Repository Usage policy" may be considered an Acceptable Use Policy.

It is in the shape of an AUP, but it says up-front that it only covers the git repo. And some of it, such as git privileges, is only meaningful in the context of that repo. It is also not an easy document to find. IMHO, an AUP should be linked from every page.

I would rather have a general AUP with a general acceptable use policy for all of Drupal.org (including subdomains such as www.drupal.org, groups.drupal.org, git.drupal.org, etc.). Then the subdomains could link to the general AUP and just add specific policies only relevant to the sub-domain just below that link, if required.

According to Drupal Git Repository Usage policy, we already ban/terminate both users and content that violate its terms.

That is what the document says, yes. However, that is not what we do. What we do is described pretty accurately by greggles in #31. Having a policy that diverges from practice is in itself a problem, so this may need looking into as well.

As for the rest, we just have to agree to disagree. My position is this: I don't want to see a policy implemented that may result in software that can be used my admins to test their site for vulnerabilities being "banned" or declared unacceptable on Drupal.org. (Also: I don't see any merit in speculating about the motivation of the owner of Death By Captcha (however, just for the record, I believe simoneb in #34 is close to target) as this thread is discussion about policy, not about a particular module or a particular individual.)

Somewhat interesting to see this old thread resurrected. I don't see anything new here.

Bad-behavior modules can be created, and do exist, that much is true.
The spirit of the known policy is clearly about 'intent' and need not concern itself with your distinction between acceptable content and acceptable use. Lawyers may disagree with that, but I think that doing so would be deliberately ignorant. It's an interesting semantic discussion to have, in a different sphere

Hosting, support and endorsement on drupal.org is an earned privilege, not a right, and the eligibility criteria and process (and terms of use) should make that clear.

I, as someone who hosts and supports *beneficial* modules on d.o for many years do care about the "bad neighborhood" stigma, and still sell to my clients that a d.o-endorsed module is more stable and trustworthy than a random one-off custom job. I do not want to see that endorsement diluted by someone being able to point at a similarly-hosted module and say "yeah but this is clearly malicious, so d.o is just an unmoderated list and your endorsement means shit". That's not true, as I and dozens of others spend hundreds of hours filtering un-useful stuff out of our d.o pile of "contributions".

It's not impossible for there to be an unrestricted badlands zone #307211: Drupal Module 'Badlands' for modules like this - as that issue concluded, we now have working sandboxes which are available - without any implied endorsement - and that's an OK place for it to rest.

If someone want's to put potentially harmful code up as a module - it can be external on their own github, or it can 'require bad_judgement' . But having a small number of moderators on d.o agreeing that "what this module does should not be done ^tm" should be enough to reject it from d.o hosting.
It would be nice to keep the pee out of the swimming pool and just not have bad (or things that are clearly designed to be bad) modules in the public pool.
Go ahead and make them available elsewhere. We won't chase you down. Discuss and link to them from here, it's an educational talk to have. But don't make d.o responsible for hosting deliberately malicious code.

I personally use tools like netstat/wireshark, siege etc, portscanners, addblockers, fake foreign proxies, network sniffers and packet analyzers on a weekly basis, not to mention tor and torrents. Any of which could be variously characterized as 'hacker tools' or 'security toolset' depending who is talking. I have no problem accepting that this code and these tools reside in a grey zone that I get from third parties and is not often openly endorsed by the major tech supplier.
d.o is mature enough to acknowledge that it provides tools that can be reworked enough to be misused, but is paternal enough to let you go and find such tools on your own. It's not necessary to provide script-kiddie howtos.

dman wrote:

Somewhat interesting to see this old thread resurrected. I don't see anything new here.

What is obviously new is that mgifford in #35 changed the status from "Postponed" to "Active", and at the same time changed the subject from:

Banning unethical modules

to:

Define How We Ban Modules

and added:

How about we start with setting up a policy on how/why we would ban such modules.

I tried to respond to this by saying, essentially:

1. IMHO, the change of title was taking this in the wrong direction. We should not, as a policy, "ban modules". We should have a policy in place to say what content is unacceptable, and demand that unacceptable content is repaired.
2. Assuming that "such modules" refers to "Software that breaks CAPTCHAs", it is not a given that such modules should be sanctioned. IMHO, having a policy against such modules will do more harm than good.

I think there should be an easy to find Acceptable Use Policy for Drupal.org (at not only a hard to find one for for the git repo). However, I am not sure if this thread is the right place to discuss such a policy, since it seems stuck in a basic disagreement about 1) whether "banning" is the most appropriate course to sanction whatever it is that is found to be against policy, and 2) whether "Software that breaks CAPTCHAs" by definition is "bad", "unethical" or whatever criteria the OP and mgifford think is appropriate for "banning" such modules.

While it can be argued that the above just repeats the discussion from a year ago, I felt the steps in the wrong direction (IMHO) taken when setting this active needed to be addressed.

There is now a proposed ToS out: https://www.drupal.org/news/introducing-drupalorg-tos-and-privacy-policy

It contains a list of things that are not acceptable, so it is also an AUP, and it seems to have a catch-all clause where anything "otherwise objectionable" may be considered a policy violation:

The content you publish will not contain any material which is defamatory, obscene, indecent, abusive, offensive, harassing, violent, hateful, inflammatory or otherwise objectionable.

@gisle - with that ToS (GoogleDoc) can we close this issue?

@mgifford, closing is OK with me.

Ok, we can re-open this if needed then.