Requests for comment/Disable local uploads on smaller wikis

The following request for comments is closed. Was done already, see phab:T73403. --Rschen7754 01:55, 24 January 2016 (UTC)[reply]


The policy draft resulting from this discussion is at Local uploads policy.

Pre-proposal edit

Per Wikimedia Foundation Resolution: Licensing policy, quoted policy is approved by the Wikimedia Foundation Board of Trustees to apply to all Wikimedia projects. It may not be circumvented, eroded, or ignored by local policies.

General Discussion edit

Edit point 1 edit

Smaller wiki: Wikis that do not have the community size large enough to self-govern. This definition can be expanded.
Commons-only upload guide: Commons:Turning off local uploads

Smaller wikis are typically a graveyard of copyrighted content - often orphaned copyrighted content. These wikis disregard the above WMF resolution. This may be because the local community may lack anyone with enough experience to handle copyright. Stewards and global admins are unable to maintain hundreds of wikis that do not wish to self-govern.

Also some wikis are even used as a free webhost. Furthermore there are wikis that have content to supplement cyber attacks where defacement attacks post files.

Therefore I propose file uploads to all of the smaller wikis be disabled until they can demonstrate they are willing to and are capable of self-govern. Until then commons should be used. This would also allow the local communities to experience commons procedures and know-how on copyrights so that it can be adopted locally.

-- とある白い猫 chi? 09:12, 7 May 2012 (UTC)[reply]

If this is a problem, and I am not saying it is or isn't as I have no involvement in this area, it seems sensible enough, particularly when we already try to encourage the use of commons over local uploads. What would happen to locally uploaded files that were uploaded previously tho? Also, this probably needs some kind of centralnotice+global spambot etc to get input from everything if this is to be implemented. Snowolf How can I help? 09:31, 7 May 2012 (UTC)[reply]
Existing files are a problem and needs to be dealt with. A good number are copyrighted and even free ones are typically not properly marked. I am not saying that existing files are problem-free but the main concern behind this post is to prevent the matter from getting worse. Deployment of a language edition of a project comes in two phases currently. First it needs to mature in the incubator, and then it is migrated to its subdomain. With this proposal a third phase would be the enabling of local file uploads if the local wiki requests it. Perhaps stewards would be given the ability to "enable/disable" file uploads for the entire wiki. -- とある白い猫 chi? 10:30, 7 May 2012 (UTC)[reply]
Can you give examples of projects which problematic? John Vandenberg (talk) 09:43, 8 May 2012 (UTC)[reply]
Is there a list of projects which have an Exemption Doctrine Policy (EDP)? e.g. Some wikinews allow fair use, but only three have a fair use policy linked to the English policy. I dont see a fair use policy for wikinews:fa:پرونده:Afghan-sheea.jpg or wikinews:de:Datei:Veroeffentilchung der Staatsanwaltschaft in Griechenland Amtliches Werk - Foto Polizei GR.jpg. John Vandenberg (talk) 09:58, 8 May 2012 (UTC)[reply]
Yes, Non-free content. Nemo 10:53, 8 May 2012 (UTC)[reply]
I can give many examples but I really do not want to "single" any wiki out. The assessments should be based on a case-by-case basis. Questions I would ask are:
  1. Does the wiki have a sizable community that can and is willing to process such content/How stable is this if a few users decide to retire/How many files does the wiki have per active administrator?
  2. Does the wiki's users have a good understanding in copyright/Are there active experienced users that handle copyrighted content?
  3. Does the wiki have a process that deal with new uploads? On en.wikipedia for example new uploads are checked if they have a valid license and/or a source (if needed)
  4. Does the wiki have a process that deal with non-free content? On en.wikipedia for example fair-use content not used in articles are promptly marked by bots. Likewise each use of non-free content on articles requires a rationale notice.
  5. Does the wiki have a process that deal with copyrighted content/Is the wiki a graveyard of (orphaned) copyrighted files?
Anybody can translate an en.wikipedia policy but that alone is insufficient to consider a "wiki" ready to self-govern on file uploads.
-- とある白い猫 chi? 14:12, 8 May 2012 (UTC)[reply]
I don't see how translating a policy can be enough. The EDP will usually have to follow the "local law" most users of the wiki are subject to, include things which aren't included in the anglo-centric en.wiki EDP, explain why that stuff is needed on the wiki etc. Practically speaking, very few wikis made one, which proves the point. Checking existing EDPs, if they make sense and they're respected, would be a later step; there's so much to do now that this is not needed for the first huge batch of cleanup. If you had to ask those questions, not even it.wiki would be able to keep local upload, as it's always had at most 2-3 users active in the area, sometimes 1, sometimes 0; I'd personally like it.wiki to close local upload but such criteria won't work. Nemo 14:22, 8 May 2012 (UTC)[reply]
EDP must enforce Flordia & US Federal Law first, then additional restrictions for local use can be considered. I am more worried about some of the wikis with fewer than 10K articles rather than it.wikipedia. Also "local law" can be controversial for languages such as Spanish, Portuguese, French and etc. where the language is spoken in different countries. -- とある白い猫 chi? 14:53, 8 May 2012 (UTC)[reply]
  • I think it's very easy to implement (technically and conceptually): all wikis have local upload disabled, unless they have an EDP in place, which proves the need for local upload (non free-files) and the presence of the needed infrastracture (templates, copyright geeks etc.). Local upload is very hard to manage and very, very few wikis do it properly (the licensing policy is not respected at all); on the other hand, Commons serves all wikis very well providing a very nice and easy to use infrastructure without setups hassles. The Upload Wizard is a good incentive to use Commons and the local upload links should point to it. Nemo 10:53, 8 May 2012 (UTC)[reply]
  • As a representative of a smaller wiki I think this is a terrible idea. en.wikibooks has a very serious need for things like screen shots of non free software in books explaining the use of the software. In response to Nemo's comment, I find the upload wizard by far over simplified when it comes to copyright issues, and it seems to be getting worse as years go on. It used to be fairly easy to indicate in the wizard concepts like "my work is a derived work of a work available under license XXX. This is the original author, and appropriate attribution (a link, etc)." My last upload to commons was exactly this type, but the over simplified interface no longer gave an easy way to express this, but it used to be as simple as a pull down menu. But now I am off topic. We have no way to verify someones knowledge/understanding of copyright laws or really keep tabs on how many such users are active on any given wiki. So any decisions made on such criteria are just building houses on sand. Overall I think this would damage several smaller communities. Thenub314 (talk) 16:10, 8 May 2012 (UTC)[reply]
  • I support this proposal. On many (probably: most) small wikis, there is no control at all whether uploaded files are license-conform. On Incubator, we have already disabled local uploading for some years now and ask people to upload on Commons; also, in requests for new languages the test-contributors are nowadays asked whether local updates should be allowed or not. – For the start, we could consider to disable uploading on every global sysop wiki which does not have any local files (except the logo, maybe); that would not impact many people and prevent upload "vandalism". --MF-W 16:33, 8 May 2012 (UTC)[reply]
  • On "my" wiki we have local upload and no EDP. We are even more strict in our interpretation of CR than Commons. (All uploads and texts have to follow the law of Sweden or Finland beside the US law.) My experience is that the bureaucracy on Commons (it takes weeks to do a speedy-delete) and the technical problems (confusing uploadwizards), sometimes makes it necessary to have an alternative to Commons, at least temporary until the problems on Commons are solved. The community of Commons have very little understanding of what is in scope on our type of project. Some deletes has been made since it is not considered in scope of Wikipedia. Even if our community is small, we have a system of templates, and a bot running daily to detect unlicensed contributions. Do I support this proposal? - No, not until we have made Commons a better place! -- Lavallen 16:59, 8 May 2012 (UTC)[reply]
  • Complete support for this proposal per above. Disabling local uploading on global sysop wikis without an active admin community would work very well for preventing copyright violations, and it wouldn't be hard for those projects to enable local uploading if they are ever in a position to manage it well. Ajraddatz (Talk) 17:00, 8 May 2012 (UTC)[reply]
  • May I ask why file-copyviolation is considered worse than text-copyviolations? The latter is much more frequent than the first! -- Lavallen 17:08, 8 May 2012 (UTC)[reply]
    The latter is also much harder to outright prevent than the first. We have the opportunity to significantly reduce image copyvios, so let's do it. Ajraddatz (Talk) 17:19, 8 May 2012 (UTC)[reply]
    • (Edit conflict.) What is your source for that statement? I'm not saying that it isn't true, but I've never seen any figures. Personally, I mainly see image copyright violation, but that's because I'm mainly editing pages related to the file namespace. --Stefan2 (talk) 17:49, 8 May 2012 (UTC)[reply]
    Was that Q to me or to 'Ajraddatz'? - When checking contributions from newbies on Wikipedia, I often find text which has been copy-pasted from websites. In many of these cases, the copyviolation is unintensional, since it sometimes is the same author to the website as in the article, but that is hard to prove. This is almost always solved when the text is wikified, or removed since it doesn't fit an article. Copyvios in files are frequently uploaded (and kept) on Commons, but they are rare in articles. -- Lavallen 06:46, 13 May 2012 (UTC)[reply]
    I was merely asking about a source for your statistics. You wrote that text copyright violations are more frequent than image copyright violations, but I haven't seen any evidence of that. I frequently check recent image uploads to English Wikipedia and I often find lots of copyvios (in particular from new users), so it not surprising that people checking articles find lots of text copyvios from similar users. Still, I've not seen any statistics of what's more common (text violations or image violations). Probably irrelevant, though. --Stefan2 (talk) 12:16, 13 May 2012 (UTC)[reply]
  • I'd support this (disclosure: I'm a Commons admin). Basically, Commons is there as Wikimedia's central media repository. Almost by definition, a "small wiki" is one too small to have run into the areas Commons doesn't cover (Fair Use), or to be effectively able to manage differences in licensing policy compared to Commons (eg differences in interpretation of "public domain"). So turning this off by default for such wikis makes absolute sense: the burden of proof should be on small communities to show that (i) they need local uploads and (ii) they can effectively manage them, such that the benefits outweigh the costs. Even some very large wikis manage to do without local uploads, so it isn't necessary for small wikis to do so in general. Specific instances may arise where small wikis do need local uploads (does Wikibooks, mentioned above, count as small?) - so let them make a case that they need it turned on. Rd232 (talk) 17:32, 8 May 2012 (UTC)[reply]
  • Comment: (1) Restricting uploads to Commons is I think a non-starter. Commons is already woefully behind in keeping up with deletion requests (see six month backlog). (2) The criteria here that a project needs to demonstrate ability to self govern; en.wikipedia fails this requirement as is. There are enforcement attempts, but actual compliance is absent. Violations of the local EDP are rampant and essentially ignored. Bots supporting EDP operations are broken or otherwise inoperative. Editors who attempt to uphold the policy are relentlessly hounded (not surprising) and not supported by those in charge of self governance (not surprising either, but creates an environment where the resolution above can not be upheld). The non-free image count on en.wikipedia is now 442k, and rising at a rate of over 100 images per day over the last year, percentage wise at a rate faster than article creation. En.wikipedia is no longer capable of stemming the tide, and as a whole they frankly do not care anymore. Long experienced editors are routinely violating aspects of the EDP, without anyone raising even the slightest alarm. Examples:
    • An editor of a year's experience and 7000 edits [1] adds 25 non-free logos to a table listing companies [2], violating local EDP policy #8 and #3, and guideline at w:WP:NFTABLE.
    • An editor with 3500 edits spread out over nearly seven years [3] adds a non-free image to a template [4], violating local EDP policy #9
    • Local EDP #10c violations, requiring a rationale for each use of a non-free item number roughly 10k.
  • En.wikipedia simply doesn't care about the EDP policy anymore. So, pass this resolution if you must, but understand that en.wikipedia wouldn't pass this metric and should not be upheld as a scion of how it should be done. Neither is shifting the burden of monitoring uploads to Commons going to be effective. --Hammersoft (talk) 17:44, 8 May 2012 (UTC)[reply]
    • En.wikipedia is hardly a small wiki. En.wikipedia DOES enforce how non-free images are used. It meets all the criteria above. -- とある白い猫 chi? 17:53, 8 May 2012 (UTC)[reply]
      • Some people attempt to enforce how non-free images are used, but there are too few of those of us who do, so the backlog of violations is constantly increasing. --Stefan2 (talk) 18:08, 8 May 2012 (UTC)[reply]
        • Even so, smaller wikis do not even have a backlog and the issue will permanently remain a problem on them under status quo. A backlog by definition eventually will be addressed. -- とある白い猫 chi? 18:18, 8 May 2012 (UTC)[reply]
          • If nobody ever addresses a backlog, it remains a backlog. If the amount of work being applied to reduce a backlog is smaller than the 'work' that is increasing the backlog, the backlog will never be cleared. This is the case at en.wikipedia. --Hammersoft (talk) 19:28, 8 May 2012 (UTC)[reply]
            • This proposal was not intended to address the issues of the largest wiki in existence. Instead it is intended to cover "smaller wikis". You are welcome to start a separate RFC if you like but this really is not the right median. -- とある白い猫 chi? 19:50, 8 May 2012 (UTC)[reply]
              • My point was that the standards being established here would not be passed by en.wikipedia, and upholding it as a scion of how it should be done would be fraught with problems. I am not experienced with other language editions. However, if en.wikipedia is not capable of handling the problem outlined by this proposal, I doubt any project can. That point, plus the reality that Commons can't accept the burden being proposed here, as they are already heavily backlogged. --Hammersoft (talk) 20:34, 8 May 2012 (UTC)[reply]
                • No en.wikipedia would qualify as it even fulfills each and every one of the 5 questions I posted above. This proposal would not be a burden to commons. These small wikis get few uploads each which combines to hundreds of different backlogs. Just reviewing if each wiki has a new upload or not is a demanding task which involves over 100 tabs. Once the image is identified the user needs adminship of some sort to delete the files. There are very few global admins and stewards to handle the massive backlog on hundreds of wikis. Migrating the problem to one location would help resolve it. -- とある白い猫 chi? 21:15, 8 May 2012 (UTC)[reply]
  • (Edit conflict.) I largely support this proposal. I understand that the idea isn't to remove local uploads from large projects (such as the Italian Wikipedia), but to remove it from very small projects where no one seems to care about copyrights at all. While I assume that all projects with local uploads violate wmf:Resolution:Licensing policy (e.g., fair use images on French Wikipedia tend to lack a fair use rationale while fair use on English Wikipedia sometimes isn't "minimal"), the purpose seems to prevent more serious violations. There have been numerous discussions on the English Village pump on Commons lately about projects ignoring copyrights, and it would be very good to solve this. For example, upon visiting a small project, I remember seeing a welcoming template on my talk page containing an image with neither source nor licence. I looked a bit more and saw that the same image also appeared further up on the page in the MediaWiki:Sitenotice section of the page. Since only admins can edit that page, I got the impression that copyright violations were supported by admins on that project.
If projects are forced to resign local uploads, we would need to define some criteria for determining when to disable uploads. Apart from uploads covered by an EDP, there are additional cases where images may be kept locally while being ineligible for Commons. For example, English Wikipedia has templates such as en:Template:PD-US-1923-abroad, en:Template:FoP-USonly and en:Template:PD-ineligible-USonly which suggest that an image is free in the United States but not in the source country. Such images would be "free" in the Wikipedia way of thinking but aren't free enough for Commons. Requiring an EDP in order to enable local uploads might not be sufficient. On the other hand, I would like to see some reasonable image use policy and see that policy enforced in practice. --Stefan2 (talk) 17:49, 8 May 2012 (UTC)[reply]
  • I am strongly opposed to this proposal. It appears yet another case of Commons expanding its scope while simultaneously reducing its usefulness to the projects it was intended to support. As the commons community has a history of acting without an understanding of the goals and missions of the projects its actions affect, it should confine its judgments and influences to its own wiki.. - Amgine/meta wikt wnews blog wmf-blog goog news 20:48, 8 May 2012 (UTC)[reply]
    Every wiki with a community would be free not to use Commons also under this proposal. --MF-W 20:51, 8 May 2012 (UTC)[reply]
    But only if Commons agrees they qualify as a community. - Amgine/meta wikt wnews blog wmf-blog goog news 20:54, 8 May 2012 (UTC)[reply]
    Commons will not decide. This does not expand commons' scope one bit as project scope of all Wikimedia wiki's and more are within the scope of Commons already. This decision would be discussed through meta discussions. Just like "requests for new languages" a similar process like "requests for local uploads". Stewards would play a role whom the community has elected to handle the very missions of projects. Bottom line is it is impossible to enforce the WMF resolution with the current setup. -- とある白い猫 chi? 21:12, 8 May 2012 (UTC)[reply]
    To be honest "Requests for local uploads" seem overdone. Just do it like the opt-out from global sysops. --MF-W 21:23, 8 May 2012 (UTC)[reply]
    I mean for new languages. They would start with uploads being disabled initially. No wikis uploads would be disabled overnight. Wikis would be asked to take the required measures. If they fail to respond or comply as required, only then local upload would be disabled. It is very important to establish the minimum standard required that constitutes as sufficient to allow the local wiki to self-govern local uploads. -- とある白い猫 chi? 21:30, 8 May 2012 (UTC)[reply]
    No in both cases: it should (at worst) be default opt-out.
    Here is the reason for this particular case: If a community *was* active, and is currently not active, this does not mean they will not be active in the future. But this proposal would pre-emptively remove their (current) ability to upload locally, no matter how hard-won and well-supported that privilege was earned. A large hurdle for the community's mission may be re-instated, a second time they will have to needlessly argue for what may (in some project's scope) be a really obvious functionality. Example: very few of the Wikinews projects have upload privileges, yet they are the least affected by copyright.
    It seems to me that if this were not a power grab/scope creep by commons community members, it would not be solely proposed by commons members nor argued in support solely by commons members. - Amgine/meta wikt wnews blog wmf-blog goog news 21:38, 8 May 2012 (UTC)[reply]
    This proposal aims at wikis like omwiki, tiwiktionary, kiwiki, iawiktionary where it's ATM simply very hard and unnecessary work to build up the whole "upload infrastructure" with info pages, license info, files for deletion etc. And therefore local uploads there should be discouraged there, as nobody is there to check copyrights etc. Once there would be a group of users who wish to have local uploads and/or an Exemption Doctrine Policy, they could request that and get that (after having voted locally of course). On a side note, I support this proposal and have 69 edits on Commons. --MF-W 22:58, 8 May 2012 (UTC)[reply]
    Regardless of which wikis this proposal may be targeting, it will affect all WMF wikis. I agree the "upload infrastructure" is an overwhelming hurdle for most small communities; especially those for whom commons is not a supportive tool. This policy will do nothing to help them, but rather only alienate the members of those small communities who will rightly feel targeted and harrassed - second class wikimedians. - Amgine/meta wikt wnews blog wmf-blog goog news 23:48, 8 May 2012 (UTC)[reply]
    The alternative is let these wikis be copyrighted file graveyards. Copyright should be taken seriously by everyone. In my view, the wikis in question would have still been in the incubator had incubator exist so far back ago. Should incubator projects feel like they are third class wikis, languages? There are reasons why "incubator" came to exist. -- とある白い猫 chi? 11:19, 9 May 2012 (UTC)[reply]
    Yes, copyright should be taken seriously by everyone, as should other rights. In the United States the right to a free press has been recognized by the constitution, courts, and law as greater than the copyright. Full stop.
    Should incubator projects feel like they are third class wikis, languages? Yes, of course they should, because we have defined them as such. Stating the unutterably obvious as a rhetorical question does not alter the state in the slightest. - Amgine/meta wikt wnews blog wmf-blog goog news 15:21, 9 May 2012 (UTC)[reply]
    Free press? How is that relevant? The US constitution offers no protection to Wikimedia Foundation against Intellectual Property lawsuits.
    I disagree. I believe incubator has a purpose. I do not think anyone feels "lowly" of other projects just because they have not matured out of the incubator project yet.
    -- とある白い猫 chi? 15:56, 9 May 2012 (UTC)[reply]
    Wikimedia Foundation Resolution: Licensing policy is approved by the Wikimedia Foundation Board of Trustees to apply to all Wikimedia projects. It may not be circumvented, eroded, or ignored by local policies. Any wiki making an effort to deliberately disregard the WMFR:LP even after warnings risk to have their local uploads revoked with all problematic files be deleted. We cannot have local wikis opt-out of this if they deliberately want to disregard WMFR:LP. -- とある白い猫 chi? 23:07, 8 May 2012 (UTC)[reply]
    As you may be aware, I was involved in the creation and adoption of the en.Wikinews FU policy which was approved by the Board in 2005, some years prior to the EDP, which allowed uploads for the first time on the Wikinews project. I am somewhat conversant with the issues involved as the effort required six months and a legal brief. I am also aware that in your opinion some wikis may make a deliberate effort to disregard the WMFR:LP, but it is possibly slanderous, defaming, and of course rude to state they are doing so. You of course are not being abrasive, I just thought I should point out the difference between your Point Of View and factual statements. - Amgine/meta wikt wnews blog wmf-blog goog news 23:34, 8 May 2012 (UTC)[reply]
    I haven't accused you of anything personally. I am more concerned with bla.wikipedia projects with something like 10 or fewer (as low as 0) active users which are a graveyard of copyrighted content. There are wikis that that are reluctant or even outright hostile towards people asking them to sort out their local copyright mess. We have also seen wikis were the local community say they will deal with the issue but they never do. -- とある白い猫 chi? 10:35, 9 May 2012 (UTC)[reply]
    Your statement, in my opinion, is filled with POVioring. Allow me to do express some of how you sound to me:
    • something like 10 or fewer (as low as 0) = "this is too small to be able to police itself, and will never be able to do so." (it is also too small to do great damaage, isn't it?)
    • which are a graveyard of copyrighted content = "have more than 0 copyrighted files which I feel do not meet any fair use defense, and will not be addressed in a timely fashion as defined by me."
    • There are wikis that that are reluctant or even outright hostile towards people = "I am in a position to objectively judge the motivations and goals of entire communities who speak languages I do not and/or have differing ethos and mores from my own by their interpersonal communications with främling, and my judgment should be widely accepted (and communicated.)"
    • asking them to sort out = "when I tell them how to run their community".
    • their local copyright mess. = "Have more than 0 copyrighted files which I feel do not meet any fair use defense, and will not be addressed in a timely fashion as defined by me."
    • We have also seen = "I speak as the GodBoss from a position of omniscience and the third person."
    • wikis were[sic] the local community say they will deal with the issue but they never do. = "wikis which do not act homogenously to implement what I feel are the correct processes on my timeline which I have imposed on them."
    - Amgine/meta wikt wnews blog wmf-blog goog news 15:21, 9 May 2012 (UTC)[reply]
    Your misinterpretation of my remarks is distressing. I will not reply to any such posts beyond this one in the future. -- とある白い猫 chi? 15:56, 9 May 2012 (UTC)[reply]
  • I support this in principle but I don't want to impose it harshly right away. Currently upload is enabled by default, and disabled on all wikinewses and 19 other wikis. I propose to disable it by default, after putting a global notice saying like "Local uploads will be disabled by default. If your community wants to keep it enabled, request it [here]." So any wiki which still wants uploading enabled can say so easily. After that, we have a clear view on which wikis have uploads enabled and we can see how to deal with those. SPQRobin (talk) 23:56, 8 May 2012 (UTC)[reply]
Would this be an acceptable draft proposal:
  • Put a global notice saying something like "Local uploads will be disabled by default. If your community wants to keep it enabled, request it [here]."
  • Disable uploads on wikis that do not reply to the global notice or volunteer to get uploads disabled.
  • Deal with the wikis that requested to keep uploads but have not addressed the issue of copyrighted files.
We may need an exception list so as not to generate unwanted traffic. Commons itself would be exempt from this proposal for example.
-- とある白い猫 chi? 11:58, 9 May 2012 (UTC)[reply]
Please don't make any exceptions for specific wikis. In that case, small wikis would complain about bullying from above. Either require all projects (except possibly Commons) to confirm that they want to continue to have local uploads or scrap the proposal. --Stefan2 (talk) 12:18, 9 May 2012 (UTC)[reply]
Fair point. I just am rather worried about the logistics. -- とある白い猫 chi? 12:22, 9 May 2012 (UTC)[reply]
  • I think the proposal seems problematic. Is the problem ("small wikis typically ...") real or only perceived? Turning off local upload for small projects using it would probably alienate the users, especially if done without a discussion in the language of the project. If in fact most media violating WMF policy is uploaded on big projects, then the action would, in addition, indeed be unfair.
I would like to see some analysis about whether the problem is real and whether it concerns many or only a few projects, before any decision is made - in fact the discussion is premature without the analysis. Turning on uploads for new projects only on request and discussing closing local upload for projects where it seems problematic might be reasonable as a safeguard, but making projects change there way of working need justification.
The small project where I am active does have a handful of administrators and the activity is small enough that I personally can check every edit when not on vacation or similar. I cannot see how the upload function could be abused. On the other hand we might not have resources for the bureaucracy probably needed for turning on local uploads (if a simple request would not be enough). Making a request would be harder for projects with few English speakers.
--LPfi (talk) 10:31, 9 May 2012 (UTC)[reply]
What would be hostile is if I list the wikis. You can go to any of the smaller wikis and look at their uploaded files. You will see many (even orphaned) files that do not come with a license of which a good deal are movie posters, cd covers, movie screenshots, publicity photos and other obviously copyrighted content. Users can still upload to commons and also get their upload capability re-enabled if they are willing to handle copyright. Mind you the community may have 0 users so in that case no one is alienated. With 0 w:sv:Special:Oanvända filer (orphan files), 0 w:sv:Special:Okategoriserade filer (uncategorized files) and 94 sysops your wiki (sv.wikipedia) has nothing to worry about. -- とある白い猫 chi? 10:35, 9 May 2012 (UTC)[reply]
And with 0 files and no enabled upload page, this proposal wouldn't affect the Swedish Wikipedia in any way. Local uploads have been disabled for ages: everything has to go to Commons. --Stefan2 (talk) 12:15, 9 May 2012 (UTC)[reply]
The only Swedish projects with any kind of problem in this is wikibooks. I am not aware of any copyvios there, but there is almost no record of what licence the files are under. -- Lavallen 08:36, 10 May 2012 (UTC)[reply]
By their nature, I do not expect wikibooks projects to be all that problematic. sv.wikibooks seems to have 333 files that may perhaps be uploaded to commons. Playing cards seem to be marked with GFDL, I am not sure if that is correct as these are either fully copyrighted or PD. I have seen this pattern of cards IRL before. -- とある白い猫 chi? 09:27, 10 May 2012 (UTC)[reply]
That is the small project I mentioned (the Swedish Wikipedia certainly qualifies as a big project: 11th wp, close to 500k articles). The images are mostly old. They seem not to be too problematic copyrightwise, but would be deleted at Commons (bad licence and source information, e.g. the cards may be from some GPL game). We discussed the matter recently and decided new images should go to Commons only, unless there is a special reason, but kept the possibility to upload locally as it is unproblematic and might be needed in the future. I can imagine there are many projects like sv:wikisource: small but well maintained projects that use local uploads. --LPfi (talk) 09:46, 10 May 2012 (UTC)[reply]
A local wiki can indeed make such a decision. If the local/small wiki is responsible enough to self-govern on copyright they do not have anything to worry. My comment in regards to sv.wikibooks file content is that they can be transwikied to commons which would be nice but this isn't something required. Playing cards may be an issue though I am not sure. Either way at a glance I do not see any speedy delete-able content on sv.wikibooks. On the problematic wikis I can find 50 copyvios under 10 minutes without paying too much attention. That is what I would be more worried about. -- とある白い猫 chi? 11:59, 10 May 2012 (UTC)[reply]
What I see as a problem is the technical and cultural problems at Commons. That project has forgotten to "Keep it simple", and they forget that there are other projects than en/de/fr/ru.wikipedia. -- Lavallen 12:08, 10 May 2012 (UTC)[reply]
Those would not lead to lawsuits though. -- とある白い猫 chi? 12:13, 10 May 2012 (UTC)[reply]

Edit point 2 edit

I would have to oppose this proposal as it stands. Commons works well for files that I have created myself. However I live in fear that even these files will be deleted when some zealot notices that the date in my digital camera is not always set correctly. For files that others have asked me to upload it doesn't work at all. I now politely decline such requests.
I have tried to work out how the system is supposed to work, and failed. I have even considered falsely claiming that photos taken, for example, by my cousin at my request were actually taken by me, but it doesn't seem worth the hassle. I now ask her to hand me the camera, and if I'm not there to do that, I don't use the photo.
It's a shame.
English Wikipedia is even worse, but that's another story.
The solution to the abuse of WikiMedia resources is not to close down the facilities that these smaller wikis use and value, thereby possibly extinguishing some of them completely. The solution is to provide viable alternatives, and then, and only then, to close these loopholes, once the reasonable use of them has ceased. Andrewa (talk) 19:54, 9 May 2012 (UTC)[reply]
I have never heard of a deletion nomination based on meta data alone. Could you link to this? -- とある白い猫 chi? 20:59, 9 May 2012 (UTC)[reply]
Straw man. The problem is that there is (probably justified) fear about how the precautionary principle of Commons will work in the future, when "some zealot notices" [whatever].
(I am sure there have been cases where perfectly legal images have been deleted because they have been republished elsewhere without mentioning the licence or Commons as the source. If the image is watchlisted by Commons regulars the deletion might be stopped, but otherwise it might slip by.)
--LPfi (talk) 10:01, 10 May 2012 (UTC)[reply]
Local communities will either have to deal with commons or sort out their copyright issues locally. A lot of people complain about how commons take copyright "way too seriously" when this is what we want local wikis to do locally as well. Nobody is claiming local communities are malicious, they simply may not have anyone experienced with copyright. Also there are a lot of countries where IP laws aren't exactly enforced which only leads to such communities lacking interest in copyright enforcement. This is why I feel these local communities can gain a lot by experiencing commons for a while. -- とある白い猫 chi? 12:10, 10 May 2012 (UTC)[reply]
This is a real problem. Commons is one of very few Internet sites taking copyright seriously and few people have any understanding of copyright issues. But I feel very bad about closing down a feature for small projects, regardless of whether it is a problem on that wiki, while letting big projects keep the feature, again regardless of whether it is used properly. People need to be educated, regardless of whether they upload to small wikis or to Commons. --LPfi (talk) 10:36, 14 May 2012 (UTC)[reply]
"People need to be educated, regardless of whether they upload to small wikis or to Commons." - Yes; but a big part of the issue is that education is more likely on Commons than on a small wiki. If a small wiki is organised enough to be clear about copyright issues (having correct templates, and using them correctly), that's fine. But that's more likely if users of small wikis are forced to engage with Commons and learn the ropes there, contribute to translation of Commons materials into their small-wiki language, and then take that knowledge and those materials back to the small wiki and try to set up a good system there. Rd232 (talk) 22:41, 15 May 2012 (UTC)[reply]

What needs to be decided edit

As of now we have 4 proposals - and proposals 1, 2 and 4 have an awful lot of overlap. A proliferation of similar proposals is a good way to end up doing nothing... The basic problem is really the decision criteria, and that's what we need to focus on in this RFC. Other details should be left to implementation (by a Meta WikiProject?). What we need to decide is

  1. Whether to make the default off for new projects
  2. Whether to make the default off for existing projects, requiring each project that will retain local uploads (whether sysop-only or all users) to be listed as a specific exception.
  3. Criteria for allowing projects to retain sysop-only or all-user local uploads. Some options:
    • allow any project to choose sysop-only or all-user local uploads
    • set quantitative standards that projects need to meet
    • set qualitative standards that projects need to meet (judged by who, where?)

Other issues like timescale and order of events should be left for implementation. We should also not over-focus on the "big bang" transition to default off. We need to also consider how projects can request local uploads in future - and how projects with local uploads can be reviewed to have the facility removed for lack of sufficient supervision. Rd232 (talk) 18:01, 13 May 2012 (UTC)[reply]

I think it is unfair not to lay out phases of implementation to the peoples attention on something that may fundamentally affect the wikis future operation if left open-ended. It would only make people very concerned and uncomfortable of the implementation phases. Fine details of implementation (such as deadlines) can be left for later but the general overview should be present. We hopefully will have a toolserver tool that will assist with the task of how bad the situation is with some wikis - that said some wikis such as Medawiki wiki has already made efforts to cleanup poorly licensed content even though it is a backstage project. -- とある白い猫 chi? 23:52, 13 May 2012 (UTC)[reply]

Implementation edit

I really think we should try and leave the boring bits of implementation out of this RFC, and only mention points of contention here. To that end, I've made a draft Local uploads policy and draft implementation plan at Local uploads policy/transition. I've tried to make it fairly general, apart from including my view that any project should be able to request sysop-only upload without qualification. Rd232 (talk) 15:07, 14 May 2012 (UTC)[reply]

Further down this page, とある白い猫 raises a good point about implementation costs to developers, and has raised Bugzilla:36833 to request stewards be able to make these configuration changes. (Currently, configuration changes relating to who has the right to upload on a project can only be done by developers.) Rd232 (talk) 21:48, 14 May 2012 (UTC)[reply]

That said, even if the configuration changes are done by developers (because the bug hasn't been fixed by the time implementation of the transition is required), it does involve editing just one file (the Wikimedia settings file, to set $wgEnableUploads and/or set the [upload] permission as required by each project, eg limiting to sysops; MediaWiki default settings are to assign [upload] permission to all registered users). So as long as the transition process is well-organised, all the necessary changes can probably be done in one go by one developer, which should not be so burdensome that we need to worry about it. Rd232 (talk) 21:57, 14 May 2012 (UTC)[reply]
Config files are delicate and should be modified with great care. Also developer time is precious. We should do our best to use dev time as little as possible. This is why a default action may not be a good strategy. Default should be inaction unless some condition. -- とある白い猫 chi? 22:31, 14 May 2012 (UTC)[reply]
Yes, we know that developer time is precious; that's why I looked into it and concluded that if we're well-organised (so that all the changes can be made in one go), it's not that much time - maybe an hour or two. It's certainly several orders of magnitude less developer time than would be required to fulfil your bug... Rd232 (talk) 22:55, 14 May 2012 (UTC)[reply]

Are we willing to set minimum standards to enable local uploads or not? edit

I'm getting some sense in the comments made so far that people are reluctant to face the fact that it's pretty pointless to make the default "local uploads off" if it's trivially easy for any project to override that default. If that's all we do, then we're just making a lot of work for ourselves, and making a lot of projects jump through a hoop, in order to barely move from the current position. Only if we're willing to set minimum standards for compliance with the Licensing Policy (see Local_uploads_policy#Background), and accept that some projects may fail those standards (at least theoretically, and at least temporarily) is there much point to any of this. Minimum standards will force some projects to improve, and others to ensure that they really are already meeting them; and exclude projects which won't or can't. Otherwise, without minimum standards, then all we're doing is turning off local uploads for projects that aren't active enough to organise a request to keep them. Whether that's worth doing is debatable - a project not active enough to do that is probably not doing much anyway, including not doing much uploading. Rd232 (talk) 23:11, 14 May 2012 (UTC)[reply]

I don't think so; the standard should simply be "is there an active sysop?" since, y'know, if no-one's there to delete potential violations, then no-one's there to take care of business. Seb az86556 (talk) 00:06, 15 May 2012 (UTC)[reply]
An active sysop is a minimum standard! And I agree that having an active sysop - maybe two - should be at least part of the standard. For simplicity's sake, it could even be the entire standard - especially if we allow for some discussion about what "active" means, and preferably require "active" to be defined partly in relation to managing copyright reasonably effectively. (An active sysop who doesn't much care about or understand copyright and doesn't have much community support or infrastructure isn't much use, in relation to this problem.) Rd232 (talk) 06:52, 15 May 2012 (UTC)[reply]
Well, then let's celebrate, seems like that's something we can agree on. "Standards" sounded like 3 forms to be filled out in 8 versions with a pink and green duplicate to be filed at 5 different locations, and then... nyeah... Seb az86556 (talk) 06:57, 15 May 2012 (UTC)[reply]
Ha, well... What I personally have in mind is something like (i) an active sysop, where "active" is defined as Special:ActiveUsers is (action within the last 30 days) (ii) a reasonably well-developed infrastructure for labelling files (templates and categories etc) (iii) no unreasonably large deletion/review backlogs or unreasonably large proportion of errors in copyright labelling. (ii) and (iii) have to be judged subjectively - it's not really practical to define objective criteria for them. That would be a standard for "all user" local uploads, and if the project can't meet those, they can have sysop-only uploads. Rd232 (talk) 11:40, 15 May 2012 (UTC)[reply]
To be honest a wiki without at least two active sysops shouldn't even be complaining since that means the wiki cannot deal with files in a reliable manner. I say 2 sysops as one could be considered backup should the other become inactive. I am not happy talking quantitatively about criteria since it really depends on the number of uploads the wiki receives. Hence for a larger wiki 2 sysops would be greatly inadequate. -- とある白い猫 chi? 15:29, 15 May 2012 (UTC)[reply]

A closer look edit

Out of curiosity, I started taking stock; while I'm at it, I'll mark problematic files for deletion; if anyone is bored enough to pitch in, I start from the bottom of List of Wikipedias working my way up... Seb az86556 (talk) 04:21, 17 May 2012 (UTC)[reply]

That's definitely very helpful, thanks. Stats.wikimedia.org doesn't show admins (it has contributors and active users) but there is Administrators of Wikimedia projects (data are not current, but it gives a good overview). Rd232 (talk) 07:01, 17 May 2012 (UTC)[reply]

Proposals edit

Proposal 1 edit

I know that discussion usually leads to little result, so I'll make a specific proposal of what I mentioned above:

  • Currently upload is enabled by default, and disabled on all wikinewses and some 19 other wikis.
  • I propose to put a global notice for logged in users on all WMF projects (except commons and enwiki/dewiki/ruwiki/itwiki) saying like "Local uploads will be disabled by default. If your community wants to keep it enabled, request it [here]." So any wiki which still wants uploading enabled can say so easily, without having to meet any requirements.
    • Exceptions: Commons because.. duh, and enwiki/dewiki/ruwiki/itwiki because they have by far the most files (+100,000) and I don't see any chance they would disable uploads. If easily possible, the notice would also not be displayed on wikis that already disabled it (wikinewses and some more).
  • We disable uploads by default, except for enwiki and all wikis that requested upload to be still enabled (and I suppose private wikis too).

This will certainly not completely deal with the issue, but it would be a big step forward without much controversy I hope.

Yes/no? SPQRobin (talk) 21:21, 11 May 2012 (UTC)[reply]

Discussion for Proposal 1 edit

  • Yes! Support. Reasons are already stated above. To note that any community can of course also later "get back" the possibility to make local uploads. --MF-W 21:47, 11 May 2012 (UTC)[reply]
  • Query: Why default opt-in? It sounds like you do not trust the local community to make the 'right' decision, but you trust the much larger community to do so on their behalf. Perhaps instead of edicts and prescriptions, communities which have a range of copyvios (digression: are there any communities which have this described situation? it has been asked several times already for evidence that this is a real and not imagined problem) should be encouraged to acknowledge there is an issue and offered the opportunity to ask their uploads be turned off? - Amgine/meta wikt wnews blog wmf-blog goog news 04:54, 12 May 2012 (UTC)[reply]
  • Support Support as first step; but projects with an EDP should be assumed to have interest in keeping local upload (although review might be needed), to reduce paperwork. Nemo 07:21, 12 May 2012 (UTC)[reply]
  • Comment Comment I have seen wikis that translated EDP (generally an outdated en.wikipedia fair-use policy) but do not really understand it or enforce it, those can however be dealt with separately. That said, I Support Support this proposal since giving exception to wikis with pre-existing EDP would reduce the overall logistics. As mentioned/implied, we should also give an exception to wikis that already agreed to disable local uploads since it is redundant to ask them to confirm the existing practice. -- とある白い猫 chi? 14:29, 12 May 2012 (UTC)[reply]
  • Comment Comment: As a member of a relatively small wiki that took the trouble to expressly opt-out and have uploads disabled, I believe the feature should be disabled by default and only enabled on an opt-in basis.

    That said, if a community has adopted an EDP (not just copied/translated without discussion but adopted as policy) then that should be taken as expressly opting in. Therefore, I think this should not be done as a site-notice initially. It should be a notice on their "Village Pump" or equivalent forum asking them to affirm and/or document the policy. The logistical overhead of politely enquiring whether the community has opted in is a necessary cost of treating them with respect. A site notice would be an appropriate last resort and final warning in case there is no response. ~ Ningauble (talk) 16:13, 12 May 2012 (UTC)[reply]

  • Oppose sippenhaft; punish only offenders (and all offenders), do not execute the innocent. Seb az86556 (talk) 21:42, 12 May 2012 (UTC)[reply]
  • Support Support see Nemo. Alexpl (talk) 10:11, 13 May 2012 (UTC)[reply]
  • Oppose Oppose - see my comments above at #Are_we_willing_to_set_minimum_standards_to_enable_local_uploads_or_not.3F. If it's trivially easy for projects to keep local uploads, then we're not really changing the default, and we may as well not bother. Rd232 (talk) 23:15, 14 May 2012 (UTC)[reply]
    Indeed we are changing the default, as projects (except the obvious cases, as can be read above) will need to do something in order to keep local uploads enabled. --MF-W 10:42, 15 May 2012 (UTC)[reply]
    Indeed, as I said in the section I linked to, then all we're doing is making work to stand still. Rd232 (talk) 11:31, 15 May 2012 (UTC)[reply]
    If only wikis who opt-in (without further requirements) keep local uploads enabled, I except a lot of small and/or inactive wikis to not opt-in, so imho that will be not a stand-still with a relatively easy and uncontroversial proposal. Besides, we will have a clear view which wikis opted-in, i.e. where one can still upload locally. But, if there is consensus on a minimum standard without controversy, I'd be happy, I just fear that everyone would have a different view on what the minimum requirement should be. SPQRobin (talk) 11:13, 16 May 2012 (UTC)[reply]
  • Oppose Oppose - Image upload is necessary in German Wikipedia because this way we can host corporate logos that can not be transferred to Commons. This is rather important for article work.--Aschmidt (talk) 14:39, 15 May 2012 (UTC)[reply]
    Have you even read the proposal? It is suggested to keep upload enabled in large wikis, and those which have an Exemption Doctrine Policy about uploading. --MF-W 14:43, 15 May 2012 (UTC) (and those who request it, too; I should probably add) --MF-W 15:36, 15 May 2012 (UTC)[reply]
  • Support Support - For Fair use image (like logos, album cover, etc.). The fair use image on Commons will be deleted under CSD. But for GFDL image, upload it to Commons. Mbak Dede (talk) 10:41, 16 May 2012 (UTC)[reply]
  • Oppose Oppose Chaddy (talk) 01:21, 19 May 2012 (UTC)[reply]
  • Oppose Oppose, nobody has ever complained about the files of bar:, nobody apart from the project's users has ever cared - most likely because there has never been a reason. w:Throw out the baby with the bath water? I say no. → «« Man77 »» [de]·[bar] 12:11, 21 May 2012 (UTC)[reply]
  • Oppose Oppose, per Seb az86556 --Gschupfta Ferdl (talk) 17:53, 21 May 2012 (UTC)[reply]
  • Oppose Oppose. This proposal is a de facto discrimination between enwiki (and a few others) and the rest of the planet. Either come up with a proposal that is equal to all projects or scrap this RfC. The sole idea of disabling uploads after more than a decade of having them active is a sure recipe for discouraging people from participating in these projects.--Strainu (talk) 22:13, 20 July 2012 (UTC)[reply]
    • If there is nobody who look after the uploaded images and the upload possibility is misused; then the upload should be restricted at least with a special userright for trusted users. I have collected some experience at the English Wikibooks and was somehow shocked that there isn't any real gnomish user active except one or two admins trying to get the spammers and socks out. Many images were clear copyvios (e.g. flickr uploads with NC or ND part) and other uploads not that clear; or fair use images which needed cleanup, and so on. Since my start at enwb 2 months ago, enwb 'lost' ~1k images through transferring it to commons or deleting as copyvio! Enwp, dewp and other big projects have really many gnomish users who checking old images, clearing backlogs, develop bots for such tasks, etc. I also got involved at the German Wikinews and was confused that images were uploaded without licenses, logos which don't meet the TOO and thus should be moved to Commons. mabdul 11:39, 21 July 2012 (UTC)[reply]
I understand that there are some project with problems. But I think AGF should also apply to the people of those projects. The stewards should help them clean up their pictures, elaborate an EDP if necessary and only if none of this has worked, disable uploads as the last resort.--Strainu (talk) 16:52, 21 July 2012 (UTC)[reply]

Proposal 2 edit

  1. Agree a date for when the default for local uploads will be switched to Off. I suggest 1 January is realistic, considering how long it will take to complete this RFC and make a decision to do something, and how much time we want to give projects to discuss the issue locally (re requesting local uploads be enabled for them).
  2. Exempt "large" projects from the switch-off - just add them to the exception list. This would be projects that clearly want to retain local uploads, are large enough to manage local uploads effectively, and should be allowed to do so without requiring them to discuss it. A definition of "large" needs to be developed, but any project with a valid (community-endorsed) EDP should qualify, for example (though some large projects choose not to have one, so that can't be a criterion).
  3. Projects with at least X active admins (1? 3? 5? 10?) can choose to enable sysop-only uploads on request, without qualification.
  4. Projects with an active community can have a discussion on their project about whether to enable/retain local uploads. If this is agreed, the request can be made on Meta. The project must make a case that it has infrastructure and governance in place to enforce copyright reasonably well (not perfectly, since no project does that...), and a large enough and active enough community to handle local uploads.
  5. Global notice sent to all projects, except
    • those who have local uploads off already
    • Projects exempt per 2.

Rd232 (talk) 21:13, 12 May 2012 (UTC)[reply]

Discussion for Proposal 2 edit

  • Oppose sippenhaft; punish only offenders (and all offenders), do not execute the innocent. Seb az86556 (talk) 21:42, 12 May 2012 (UTC)[reply]
    • EPIC Godwin's Law FAIL: Since "small wikis" are not a collective, your hyperbole of "Sippenhaft" does not apply (even if they were being punished, which they're not). Managing local uploads effectively takes a certain amount of infrastructure and work, and projects need to show that they can do it. It's exactly the same principle as not making every user a sysop: they need to show that they can handle the tools before being given access to them. Rd232 (talk) 21:56, 12 May 2012 (UTC)[reply]
      • The assumption is that all small wikis are the same and that they all deserve the same treatment; therefore, sippenhaft. Absolutely accurate comparison. The top of this page doesn't say "Disable local uploads where violations are found". That — would be reasonable. Seb az86556 (talk) 22:08, 12 May 2012 (UTC)[reply]
        • No - read the article. Sippenhaft is not "collective punishment" (which would be inaccurate also, since small wikis are not a collective), it is specifically a form of collective punishment based on blood relations. If you're going to be hyperbolic, at least understand your own hyperbole. Rd232 (talk) 17:44, 13 May 2012 (UTC)[reply]
        • Oh, and the assumption is not that "all small wikis are the same" - it is not to turn off local uploads for small wikis, end of story. It is to turn off local uploads by default, and to enable it for wikis that want it and can show that they can handle it. Rd232 (talk) 17:46, 13 May 2012 (UTC)[reply]
  • I agree with your general idea but I am not a fan of static numbers. I have seen wikis with few articles whom are not a copyright infringement graveyard likewise I have seen wikis with tens of thousands of pages whom do not take copyright seriously. I think we should perhaps draft something else. I will give it a shot. -- とある白い猫 chi? 22:05, 12 May 2012 (UTC)[reply]
  • Neutral Point "2" is likely to make small projects angry. Would support if point 2 is scrapped. --Stefan2 (talk) 22:58, 12 May 2012 (UTC)[reply]
    • Why it would make them angry? Basically, we're looking at several categories of projects. A: obviously too small or otherwise unable to manage local uploads effectively; B: may be able to manage them, but need to make a case; C: obviously able to manage them, and asking these projects to make a request to keep local uploads is a waste of time. Rd232 (talk) 17:39, 13 May 2012 (UTC)[reply]
      • And who is "obviously able to anage them"? Those you assume to be automatically exempt are the biggest offenders... Seb az86556 (talk) 22:01, 13 May 2012 (UTC)[reply]
        • The case for A is quite clear. If there is no user community or administrators, then there is nobody managing copyrights. Those engaging should not start with uploading non-free images. B could also be OK, but the way they have to "make a case" is critical. And with C: is it enough to have know-how and man-power, or should there also be a commitment to make it work? --LPfi (talk) 10:55, 14 May 2012 (UTC)[reply]
  • Oppose Oppose – Upload should remain free as is.--Aschmidt (talk) 14:40, 15 May 2012 (UTC)[reply]
  • Oppose Oppose Chaddy (talk) 01:24, 19 May 2012 (UTC)[reply]
  • Oppose Oppose, per Seb az86556 --Gschupfta Ferdl (talk) 17:54, 21 May 2012 (UTC)[reply]
  • Oppose Oppose per my argument at proposal 1.--Strainu (talk) 22:14, 20 July 2012 (UTC)[reply]
  • Support Support with little amendments: I prefer proposal 1 with the amendments above (which would make me neutral), but this is just a slight variation to proposal 1, or rather a corollary. Sysops are often the worst offenders (the users who upload most copyvios), but I guess this can be checked in a later step. --Nemo 10:50, 18 August 2012 (UTC)[reply]
  • Weak support. Generally an good idea. Regarding rule no. 2 - "Exempt "large" projects from the switch-off", I am going to mention that not just large wikis have an EDP and since I am an admin on an small wiki that remark slighly throws me off.--Snaevar (talk) 09:13, 8 September 2012 (UTC)[reply]

Proposal 3 edit

Cleanup before punishment, no Sippenhaft

The reason for this proposal is the laziness of Global sysops. They need to do their job, go through the projects and delete all images that do not have any note or template on them; before that happens, this whole deal is simple injustice. It is immoral to punish the innocent for the crimes of others. So please go ahead and do your job; start deleting, it won't take that long. One person can easily clean up an entire project in one day; if every GS pitches in, the problem will be solved by the end of the year. No punishment for the innocent needed. Seb az86556 (talk) 21:48, 12 May 2012 (UTC)[reply]

Discussion for Proposal 3 edit

  • Comment Comment Why is it the global sysops fault? A global sysop is not a wiki-babysitter. If local wikis cannot self govern, that is entirely their fault. No one is being "punished" here. You make it sound like lacking local uploads is a punishment. It is merely a means to simplify the overwhelming task of global sysops and stewards whom need to make sure ~600+ wikis do not have copyrighted uploads. That is 600 tabs just to review a single log. -- とある白い猫 chi? 21:59, 12 May 2012 (UTC)[reply]
  • Oppose Oppose No-one is being punished. And if you've got a running tap causing a blocked bath to overflow, the solution is not to indefinitely bail the water out into the sink: it's to turn off the tap. Rd232 (talk) 22:00, 12 May 2012 (UTC)[reply]
    • Yes, if there are bathtubs overflowing, turn it off. But don't turn off the water for the entire apartment complex or house. You turn off the water only where there's actually an overflow. Seb az86556 (talk) 22:10, 12 May 2012 (UTC)[reply]
  • There is entirely no punishment happening here. Who is punished if uploads are turned off on wikis which do not oppose this step? --MF-W 22:10, 12 May 2012 (UTC)[reply]
    • And how would they oppose it? If all it took was simply one user showing up and saying "don't do it for xx.wiki", then yeah, that'd be fair. But that's not the way it's gonna be, speaking from experience... Seb az86556 (talk) 22:14, 12 May 2012 (UTC)[reply]
      • In proposal 1, there is >>"Local uploads will be disabled by default. If your community wants to keep it enabled, request it [here]." So any wiki which still wants uploading enabled can say so easily, without having to meet any requirements.<< In my understanding, this indeed means that one user coming by on meta would be sufficient. However, it might be good if said user announced that on the wiki itself beforehand, so that those disagreeing with him (if existing) can discuss it first. --MF-W 22:34, 12 May 2012 (UTC)[reply]
        • Can I take your word that your understanding is correct? If indeed it is correct, I'll immediately stop throwing a fit. Where is that list? Add nv.wiki, and I'll shut up. As one of two active sysops, I've been working quite a bit to keep it free from criminal activity (that's what copyvios are). So, again, where's the list? Seb az86556 (talk) 01:02, 13 May 2012 (UTC)[reply]
          • I think my understanding is the way SPQRobin intended it. The list does not yet exist, as it's only proposed. --MF-W 01:22, 13 May 2012 (UTC)[reply]
          • AFAIK copyright violation of the type we're talking about will almost always be a civil matter (an issue between the copyright infringer and the copyright holder), not a criminal one (an issue between the copyright infringer and the state). Just for some perspective... BTW, if you wanted to help the discussion, you could make a case for why nv.wp should be listed on Local uploads policy/Local uploads projects. (For me, having at least two active sysops is good; but details on templates and maintenance processes would be helpful, plus anything else that might be relevant.) Rd232 (talk) 23:23, 14 May 2012 (UTC)[reply]
            • The case has been made yesterday; we had a review, we were found in good shape. Seb az86556 (talk) 00:02, 15 May 2012 (UTC)[reply]
              • OK - where? I was hoping it could serve as an example. Rd232 (talk) 06:54, 15 May 2012 (UTC)[reply]
                • wikipedia:nv: is a pretty good example. I went through most of the files and discovered a few unlicensed files but aside from that most copyrighted content was properly marked with a "fair-use" template rather than fake "freely licensed" templates you see on other wikis. Local community although small is keeping the wiki in shape and not turned into a copyrighted file graveyard. The wiki is of course not without problems (which wiki is without problems?) but those problems can be better dealt with if pointed out to the local community whom are more than willing to address the problems rather than to global sysop/steward involvement. This is what we want smaller communities to do. -- とある白い猫 chi? 16:17, 15 May 2012 (UTC)[reply]
I been working on cleaning up the images on smaller wikis, but it honestly has been a one man task (me) and sometimes it is either replacing images with Commons ones or finding things that are orphaned and deleting them on the spot. It has gotten better at some places, but to say the syops are not doing anything is not correct. While it is just me at this point, I could use some help if there is a serious goal to clean up the wikis of problematic images. User:Zscout370 (Return Fire) 23:54, 16 May 2012 (UTC)[reply]
Yeah, that was my entire point: "just me" is one, and that is not plural. A concerted effort where everyone pitches in could clean up the mess, maybe not entirely, but substantially — something that will still have to be done, no matter how the future will be handled. It's not like turning off uploads now will make all the problematic images disappear. Seb az86556 (talk) 04:04, 17 May 2012 (UTC)[reply]
It's not like turning off uploads now will make all the problematic images disappear. - that's certainly true. But I suspect we'd get slightly more interest in cleaning up something that isn't a continuous, Sisyphean task. Rd232 (talk) 06:44, 17 May 2012 (UTC)[reply]
There are times where I clean out a wiki of images that some do come back, but most of the times it stays where I left it (even after a long period of time). If they are orphans, they go immediately. If not, then the tricky thing is what to replace them with. User:Zscout370 (Return Fire) 07:26, 17 May 2012 (UTC)[reply]
It's not or task to look for replacements; if there are violations, they just need to be nuked. Seb az86556 (talk) 08:21, 17 May 2012 (UTC)[reply]
It is certainly nice to look for possible replacements but if the files are not licensed they can be deleted on the spot. I have seen articles which is a shrine (gallery) of copyrighted files for a local artist and/or political/religious leader. The amount of time global sysops/stewards should be directly proportional to how much the local community wants to enforce copyright. -- とある白い猫 chi? 14:39, 17 May 2012 (UTC)[reply]
Right but the way I do things, especially with smaller wikis, is I find a replacement (or see if it is shadowing a Commons image) before I press the delete key. I just feel the mass deletion of everything and not replacing (or leaving a lot of red links) is not going to do anything except piss off a lot of people. I just think we need to be systematic about it all, as others have suggested. Also, I believe each wiki should have the option to kill uploads or not. But saying only one or two people can upload on certain wikis will not work, since most of the time, we are dealing with projects that have little to no oversight with local admins. User:Zscout370 (Return Fire) 23:31, 17 May 2012 (UTC)[reply]

Proposal 4 edit

Based on the above discussion I have formulated my own proposal. Three outcomes per wiki is proposed

  1. Wiki retains uploads just like how it is right now
  2. Only a usergroup or some user groups (Sysops, Autopatrolled, etc) can upload on that wiki
  3. Nobody can upload on that wiki

Exceptions will be given. These wikis will not be notified.

  1. Wikimedia Commons.
  2. Wikis that have already disabled uploads.
  3. Wikis that allow local uploads that already have structured procedures to deal with copyright and EDP (if applicable) violations.

The procedure I propose is:

Phase 1
  1. Wikis will be notified through sitenotice and asked if they want to keep uploads.
  2. Wikis that respond will go to "Phase 2" status.
  3. Wikis that do not respond will go to "Phase 3" status by the deadline of Phase 1.
Phase 2
  1. Wikis will get their uploads adjusted (keep as is, user group(s) only, disable) as they wish.
  2. Wikis that choose to retain uploads will be asked to clean up the copyrighted content. Wikis must satisfy the following conditions
    1. All files must have an accompanying license.
    2. Copyrighted content must not be falsely tagged with a free license.
    3. An Exemption Doctrine Policy (EDP) must be established if the wiki wants to allow the upload of copyrighted non-free content.
  3. Wikis that chose NOT to retain uploads must still clear their existing files from copyrighted non-free content. They may choose to move the freely licensed content to Commons.
  4. Wikis that chose not to clean-up their copyrighted content by the deadline of Phase 2 will go to "Phase 3"
Phase 3
  1. Wiki will have their upload disabled
    • Wikis can request their uploads enabled again later if they can demonstrate they have matured enough to self govern.
  2. Wikis will undergo a clean-up by global sysops and stewards. Following files will be deleted:
    1. Any file without a license.
    2. Any orphaned non-free content.
    3. Files with dubious copyright claims

I am intentionally avoiding arbitrary numbers such as "sysop count", "article count", "file count", etc since these numbers while relevant are not the only factor to consider. I also avoided deadlines as I am unsure what time periods would be fair.

-- とある白い猫 chi? 22:37, 12 May 2012 (UTC)[reply]

Discussion for Proposal 4 edit

I went ahead and reviewed nv.wikipedia. nv.wikipedia can be considered a wiki example of how small wikis can self-govern. One issue I see is that there are three active users of which only one is a sysop (you). Should you become inactive even temporarily, the wiki would not be able to self-govern. I would recommend redundancy in sysop access.
Particularly for smaller wikis en.wikipedia EDP is atrociously difficult to translate. I know this as I have helped translate it before. I'd personally prefer local wikis translate actual articles instead. Linking (or copying) to en.wikipedia EDP could be a good start but this should be done with at least a short note explaining the point of the EDP briefly. This should also be easy to find (both for visitors and for wikimedians). Redirects from English names could be considered. Linking (or copying) to en.wikipedia alone however is inadequate and the real issue is the implementation. If a wiki is randomly licensing Starbucks logo as PD/GFDL/CC-By or is using it without a license at all, I have a problem. nv.wikipedia for instance properly licensed the file w:nv:Eʼelyaaígíí:200px-Starbucks Coffee Logo.png following the required EDP steps. Therefore this wiki has a working EDP process and is NOT part of the overall problem with smaller wikis. For a small wiki, nv.wikipedia is impressive with its enforcement of copyright to be honest.
All that said, I think nv.wikipedia can better utilize commons but it isn't like utilizing commons is required.
-- とある白い猫 chi? 23:46, 13 May 2012 (UTC)[reply]
just to tell you, you didn't check: Stephen is also a sysop, and he reacted to one of your requests faster than I did; we are in constant communication, also via email; he knows when I go on vacation and vice versa. As for translating legal texts, it's not needed: laws are always in English, even Navajo Nation laws. Seb az86556 (talk) 00:04, 14 May 2012 (UTC)[reply]
Sorry I didn't notice he was a sysop. I suppose that concern of mine was misguided. Legal texts can be translated over time should the local wiki deem it necessary. -- とある白い猫 chi? 00:14, 14 May 2012 (UTC)[reply]
The EDP should also follow the laws which most users have to respect (like Italy's laws for Italian Wikipedia) and the templates and categories required for its application should exist. This is "an EDP". Then perhaps we could also require the EDP to be compliant with the board's resolution, but I guess this might be too much. --Nemo 10:46, 18 August 2012 (UTC)[reply]
I also think that it is ok to say to wikis that if they do not clean up they will loose the right to upload files. It gives the local admins a very good argument to take unpopular steps. And ofcourse for "us" to stop uploads on wikis that do not have a good process to cleanup.
If local wikis does not clean up the files we need to allow some non-local admins to clean up. But if that should be needed we can find out how to do that later. --MGA73 (talk) 20:03, 9 August 2012 (UTC)[reply]
  • Support. This proposal allows to start a discussion and follows a slow, not intrusive process to solve the issue. It takes in account several objections mentionned in previous discussions (like a realistic exemption criteria) --Dereckson (talk) 21:53, 9 August 2012 (UTC)[reply]
  • Support Support per Dereckson. The RFC is well conceived, and in the 20 minutes I spent reading, とある白い猫 had answers to all of the legitimate concerns that were raised. He's aptly summarized the results, in this proposal. kudos. Quiddity (talk) 05:48, 18 August 2012 (UTC)[reply]
  • Support Support Good. I have two pointers though. Firstly, it would be nice if the sidebar link to upload files would link to commons on those projects where local upload gets disabled through this process. Secondly, the deadline of phase one should be at least two weeks.--Snaevar (talk) 09:13, 8 September 2012 (UTC)[reply]

Proposal 5 edit

default off, sysop-only on request

As explained in the draft Local uploads policy and draft implementation plan at Local uploads policy/transition, I think any project should be able to request sysop-only uploads without qualification. Going beyond this, if a project wants wider access it should make a request at Meta, and make a case that it can manage local uploads reasonably well (not perfectly, since no project does). Rd232 (talk) 15:11, 14 May 2012 (UTC)[reply]

  • Hmm, yet another proposal? I think we are repeating ourselves here, with slight variations of proposals. About this proposal: It is already possible for any project to request the upload right being restricted to sysops. I think actually requiring proof / "case" from wikis that they can manage local uploads goes to far for the start, I prefer the suggestion of proposal 1 or 4 here ("Wikis will be asked if they want to keep uploads. [...] Wikis can request their uploads enabled again later if they can demonstrate they have matured enough to self govern."). --MF-W 15:40, 14 May 2012 (UTC)[reply]
    • "It is already possible for any project to request the upload right being restricted to sysops." - correction, it is currently possible for projects to restrict rights. That doesn't at all mean that if local uploads default to off, they'll have the right to broaden them in any particular way: we need to specify that, and I'm doing so. In addition, you say other proposals specify "Wikis can request their uploads enabled again later if they can demonstrate they have matured enough to self govern" - so we already have the issue of qualification; we need to address that head on. Rd232 (talk) 15:56, 14 May 2012 (UTC)[reply]
      • It involves dev involvement. It is a lot of work for devs to disable upload or make it a sysop only function on all wikis. I would like to bother devs as little as possible. That said the draft policy may be a step in the right direction however I think this RfC should still be continued. -- とある白い猫 chi? 18:54, 14 May 2012 (UTC)[reply]
  • Oppose Oppose – Uploads must remain free as is.--Aschmidt (talk) 14:41, 15 May 2012 (UTC)[reply]
  • Support Support Though I'm certain that not all sysops are aware of copyright. Perhaps we should introduce File_uploader rights? -- Bojan  Talk  06:45, 16 May 2012 (UTC)[reply]
The possibility to upload is already today controlled by a few user-rights, that you can put in almost any kind of group. These groups is best fitted to the need of each project. To install a new usergroup on every project, even those who have no upload at all, is not a healthy behavior. -- Lavallen 13:16, 18 May 2012 (UTC)[reply]
There are two projects that I know of that have an "uploaders" group, and the "upload" user right can be attached to any group (see commons:Commons:Turning_off_local_uploads#Projects_that_have_restricted_local_uploads). However, I'm not quite sure why you're making this point - no-one has (so far...) suggested creating a new user group on every project to do with uploads. Rd232 (talk) 23:26, 18 May 2012 (UTC)[reply]
  • Oppose Oppose as being a subset of Proposal 1 proposal 2. Please don't create proposals that basically say the same thing just to leave the impression that you address the issues raised be people commenting here.--Strainu (talk) 22:20, 20 July 2012 (UTC)[reply]

Proposal 6 edit

Double-check

Not sure, whether this was discussed before, so please apologize my ignorance. It's just one of the many points discussed above: Why not install a double-check-flag for uploads?
Every autoconfirmed user still can upload files, but these files have to wait for confirmation/correction by a sysop, before they are published.
IMO this is easier to handle than the restriction to sysop-uploads. --Murma174 (talk) 07:00, 21 May 2012 (UTC)[reply]

well, what if there is no sysop? Seb az86556 (talk) 09:29, 21 May 2012 (UTC)[reply]
No project should leave the incubator without sysop, is my strong opinion. And in case there's no sysop anymore, the active users cannot publish files, until they elect one. --Murma174 (talk) 10:22, 21 May 2012 (UTC)[reply]
A sort of en:Flagged revisions for uploads? Not sure the software currently allows that, but that could be addressed. However, it's already been said that what's needed is a wider infrastructure, and not just review by a sysop - sysops may not have the necessary knowledge or commitment, and without a system in place, it's all a bit difficult. This could be an inbetween step between sysop-only uploads and all-user uploads; but I think if this step is acceptable, all-user uploads should be as well. Rd232 (talk) 10:43, 21 May 2012 (UTC)[reply]
  • Oppose Oppose This creates unnecessary bureaucracy and is in effect no different from sysop-only. Seb az86556 (talk) 10:46, 21 May 2012 (UTC)[reply]
    In daily practice I (as a sysop on frrwiki) check all the new files and add/correct the license tags, if necessary. For me(!) it was much easier, if these new files were flagged and put into a maintenance category in the style of the speedy deletion category. (Maybe we could install such a feature locally, must think about it.) --Murma174 (talk) 11:10, 21 May 2012 (UTC)[reply]

Proposal 7 edit

Create a new user right "Global uploader", which can be given out by stewards. Disable uploads on all wikis which have no local sysops for users which do not have the global uploader right. --Claritas (talk) 20:35, 29 June 2012 (UTC)[reply]

  • Although I support the general shut don of the uploads, for what do we need that right? Which kind of images has to be uploaded by somebody on multiple wikis which aren't suitable for commons? mabdul 14:38, 30 June 2012 (UTC)[reply]
  • Eh, no. Basicly, you are asking for an new right that allows people to upload non-free images to all wikis, even those who don´t have an EDP policy. I am not going to jump to conclusions here, but to me that is an possible violation of the foundations Licensing policy.--Snaevar (talk) 09:13, 8 September 2012 (UTC)[reply]
  • I oppose this proposal, as per above reasons. If the images are free-use, use Wikimedia Commons.  Hazard-SJ  ✈  04:20, 9 September 2012 (UTC)[reply]

Conclusions edit

The conclusions derived from this requests for comment are: there is a consensus to implement #Proposal 4, and there is no consensus on implementing any of the other proposals, namely Proposals 1, 2, 3, 5, 6 or Proposal 7. We would still need to hammer out some of the finer details of the proposal before the linked page "Local uploads policy" can become actual policy, for that purpose the associated talkpage may be a better place for discussion since this RFC has died out. Some suggestions on what needs to be discussed: a suggestion to rename that page to "File usage policy for small wikis" since it contains information about more than mere uploads (such as copyright considerations and EDP), and to figure out an appropriate deadline for phases one and two. TeleComNasSprVen (talk) 06:25, 7 February 2014 (UTC)[reply]

When to close... edit

Either support or oppose, it seems all works above are done by Nemo bis, so any reason to keep? lol 2 years. --Liuxinyu970226 (talk) 14:18, 15 November 2014 (UTC)[reply]