This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Proposals/Archive/2025/04.
One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
An editor has requested comment from other editors for this discussion.
If you have an opinion regarding this issue, feel free to comment below.
Should any default options be added or removed from the menu in the Upload Wizard's step in which a user is asked to choose which license option applies to a work not under copyright? Sdkbtalk20:19, 19 December 2024 (UTC)[reply]
Support. Many organizations on Wikipedia that have simple logos do not have them uploaded to Commons and used in the article. Currently, the only way to upload such images is to choose the "enter a different license in wikitext format" option and enter "{{PD-textlogo}}" manually. Very few beginner (or even intermediate) editors will be able to navigate this process successfully, and even for experienced editors it is cumbersome. PD-textlogo is one of the most common license tags used on Commons uploads — there are more than 200,000 files that use it. As such, it ought to appear in the list. This would make it easier to upload simple logo images, benefiting Commons and the projects that use it. Sdkbtalk20:19, 19 December 2024 (UTC)[reply]
Addressing two potential concerns. First, Sannita wrote, the team is worried about making available too many options and confusing uploaders. I agree with the overall principle that we should not add so many options that users are overwhelmed, but I don't think we're at that point yet. Also, if we're concerned about only presenting the minimum number of relevant options, we could use metadata to help customize which ones are presented to a user for a given file (e.g. a .svg file is much more likely to be a logo than a .jpg file with metadata indicating it is a recently taken photograph).
Second, there is always the risk that users upload more complex logos above the TOO. We can link to commons:TOO to provide help/explanation, and if we find that too many users are doing this for moderators to handle, we could introduce a confirmation dialogue or other further safeguards. But we should not use the difficulty of the process to try to curb undesirable uploads any more than we should block newcomers from editing just because of the risk they'll vandalize — our filters need to be targeted enough that they don't block legitimate uploads just as much as bad ones. Sdkbtalk20:19, 19 December 2024 (UTC)[reply]
"we could use metadata" I'd be very careful with that. The way people use media changes all the time, so making decisions about how the software behaves on something like that, I don't know... Like, if it is extracting metadata, or check on is this audio, video, or image, that's one thing, but to say 'jpg is likely not a logo and svg and png might be logos' and then steer the user into a direction based on something so likely to not be true. —TheDJ (talk • contribs) 10:52, 6 January 2025 (UTC)[reply]
Oppose. Determining whether a logo is sufficiently simple for PD-textlogo is nontrivial, and the license is already frequently misapplied. Making it available as a first-class option would likely make that much worse. Omphalographer (talk) 02:57, 20 December 2024 (UTC)[reply]
Support Assuming there's some kind of review involved. Otherwise Oppose, but I don't see why it wouldn't be possible to implement a review tag or something. --Adamant1 (talk) 19:10, 20 December 2024 (UTC)[reply]
How about we just disable uploads entirely to eliminate the backlogs once and for all?[Sarcasm] The entire point of Commons is to create a repository of media, and that project necessarily will entail some level of work. Reflexively opposing due to that work without even attempting (at least in your posted rationale) to weigh that cost against the added value of the potential contributions is about as stark an illustration of the anti-newcomer bias at Commons as I can conceive. Sdkbtalk21:36, 3 January 2025 (UTC)[reply]
Oppose. I think the template is often misapplied, so I do not want to encourage its use. There are many odd cases. Paper textures do not matter. Shading does not matter. An image with just a few polygons can be copyrighted. Glrx (talk) 19:47, 6 January 2025 (UTC)[reply]
Support adding this to the upload wizard, basically per Skdb (including the first two sentences of their response to Krd). Indifferent to whether there should be a review process: on one hand, it'd be another backlog that will basically grow without bound, on the other, it could be nice for the reviewed ones. —Mdaniels5757 (talk • contribs) 23:57, 6 January 2025 (UTC)[reply]
Support New users which upload logos de facto always use wrong tags such as CC-BY-4.0-own work. Go to bot-created lists such as User:Josve05a/Logos or cats like Category:Unidentified logos, almost all logos uploaded by new users have such invalid licencing - all of which has to be reviewed & fixed at some point. People will upload logos that are too complex/nonfree etc regardless of this option, but adding the option might increase the change that they familarize themselfes with the requirements for uploading logos and apply the correct tag. ~TheImaCow (talk) 21:12, 22 February 2025 (UTC)[reply]
Question Why {{PD-textlogo}} instead of for example {{PD-ineligible}}? I can understand the reason that keeping it simple is prefered and in that case PD-ineligible could be more usable. I do not think adding a review is a good idea. Or well a review is a good idea but realisticly it will never be reviewed. We had {{PD-review}} but it was dropped. --MGA73 (talk) 10:10, 6 March 2025 (UTC)[reply]
The idea is definitely to keep things simple. There are so many possible reasons something could be PD that we can't list them all; the ability to add a custom tag in the last line will always be a significant bucket. But we do want to provide the specific PD tags for common use cases, and as argued above logos falling under PD-textlogo is one of those. PD-ineligible, by contrast, is a much more generic tag, and is generally not a good idea to use when there is a more specific tag available. I think adding it to the default options list could be risky, since people might use it for "I want to upload this but I don't know if it's actually PD or how so I'll just use PD-ineligible" situations. Sdkbtalk16:59, 6 March 2025 (UTC)[reply]
I understand keeping it simple, but the copyright tags I use most are absent, instead "copyright NASA" and "US federal government" (the rest of the world?) seems questionable, as it must be the result of careful evaluation and not simply localism. So for the same principle at least the most common upload copyright tags should be present. -- ZandDev (talk) 19:36, 15 March 2025 (UTC)[reply]
Support for autopatrolled users only, Weak support for autoconfirmed users, Oppose for non-autoconfirmed users - enough experience is needed. Xeverything11 (talk) 07:06, 28 May 2025 (UTC)[reply]
Conditional support only on the following conditions, similar to Xeverything11's conditions:
Only autopatrolled (or at least autoconfirmed) users can choose this option;
All files tagged through this manner must automatically be categorized under a maintenance category for review.
Review must be done by sysops or license reviewers.
Non-experienced or new users are not allowed to tag as such, in addition to more efficient filtering to discourage them from uploading logos etc..
I had recently the need to contact our Commons oversighters. I knew from my home wiki, DE-WP, that an option to contact the German oversighting team through Wikimail, using de:User:Oversight-Email, is offered. I was a bit disappointed by that Commons is a notable exception of projects where such an easy-access way is not implemented (it may be the largest project where this is not given, according to the description on de:Benutzer:TenWhile6/OSRequester). Could a Wikimail way of oversight contact be enacted, parallel to the existing way of the mailing list? Regards, Grand-Duc (talk) 12:08, 14 February 2025 (UTC)[reply]
Support Major issue with commons oversight. That and adding a T&S role account for wikimail. I think they attached the emergency account, but I'm unsure. All the Best -- ChuckTalk17:55, 14 February 2025 (UTC)[reply]
"Soon" and "Before the end of 2025" is somewhat contradictory! Worst case, that's more than 9 months in the future. Can somebody knowledgeable please inform me and whoever is interested on the amount of work needed to setup such a "contact user account"? The lesser the effort, the sooner it should come, even if it is only for a limited amount of use time. It's kinda the same reasoning as a military who refurbishes a warship, only to put it into reserve status a few months later (like it was done on the carrier USS Franklin (CV-13) or several other US Navy ships after V-J day). The use case is clearly shown, the potential replacement functionality has no clear ETA given yet, so waiting for it is non sensible. Regards, Grand-Duc (talk) 19:01, 14 February 2025 (UTC)[reply]
The problem with an account for this is the question who has access to the account. It would need to be all oversighters that they are able to check each other but everyone who is able to access the account would also be able to change to password and exclude everyone else. Additionally the account should definitely use 2FA what makes it hard to be accessible for all oversighters. The worst scenario would be that someone with access to the account changes the email address unnoticed to fish reports. We could decide on one oversighter who owns this account but in the case of problems (loss of rights and not handing over the account or lost contact/dead) we would need to figure out a solution to regain access through the WMF MediaWiki operations team. Because of the potential serious trouble I think we can keep it as we did for more than one decade or one more year until we have a much better solution. GPSLeo (talk) 19:45, 14 February 2025 (UTC)[reply]
"Potential serious trouble"? Do you hint to that people who sign a confidentiality agreement and identify themselves in front of the site operator would regularly go postal and make nasty trouble, breaching privacy for whatever reason? What's the base for the whole adminship, checkusership and trust in licensing, then? Pinging user:Ra'ike and user:Raymond, the first as OS on DE-WP and the second as local OS: do you have any insight on how the German contact user is set up and if a similar thing is also suitable here and now? Regards, Grand-Duc (talk) 21:14, 14 February 2025 (UTC)[reply]
They don't need account access, they just need the email access, someone from the WMF can have the password. this account only needs to forward all emails sent to it from commons to the oversighter's mailing list. En-wiki can do it for 4 different role accounts, we can do 1. All the Best -- ChuckTalk22:44, 14 February 2025 (UTC)[reply]
It is not possible to have different mail addresses for wikimail and password reset. Therefore the only thing that could be handled by the WMF could be the second factor. But then setting up the account and logging in would be very complicated. GPSLeo (talk) 05:39, 15 February 2025 (UTC)[reply]
@Grand-Duc Some thought from me as Commons OS. Not discussed with the OS colleagues. First I do not see a big advantage of such a Wikimail: One click to open the Wikimail form and one click on the current e-mail-address to open the mail program. Anyway. Technically it is easy: Creation of the OS user account on Commons with the current mailing list email-adress in the preference. All mail will be forwarded to our mailinglist (not moderated!) and can be handled as usually. One caveat: we do not have a safe place to storing the password. Any of us can have it, of course, but when oversighters change, there is no guarantee that the password will be passed on.
The IRS does not currently support oversight requests, if you select the option for "doxxing" it tells you to report it on a public page like it does everything other than threats of harm. The future plans for the tool are unclear, and I have no further information at this point. AntiCompositeNumber (talk) 03:25, 28 February 2025 (UTC)[reply]
Why should the account be blocked to prevent abuse? If an oversighter would want to abuse the account they could just unblock the account. GPSLeo (talk) 16:31, 18 March 2025 (UTC)[reply]
To be fair, emails to legal-reports[@]wikimedia take months to get a response, if I get a response, which is only half the time. Commons is relatively quick and much more reliable. JayCubby (talk) 18:56, 12 May 2025 (UTC)[reply]
for example, File:Jordan protest in front of police2.PNG claims to be made by VOA, but because the youtube video is gone it's impossible to verify. nonetheless, the claim appears trustworthy, so it doesnt seem appropriate to either pass or fail it. a sensible thing to do would be to simply remove the Template:LicenseReview.
But, simply removing it will not prevent certain users slapping the template on it again.
As such, add an outcome, termed "indeterminable" or "review impossible", to signify that users have tried to review the file but could not succeed because source is gone, but there is no significant doubt about the authenticity of the claim, so the file is tolerated. RoyZuo (talk) 10:40, 25 February 2025 (UTC)[reply]
Support only if there is some sufficient method to reduce cases of this being set mistakenly. People should not set it if a youtube video is down and they can't check it anymore. They should only set it if they also checked the Wayback Machine properly to see whether it has it archived. Prototyperspective (talk) 14:41, 5 March 2025 (UTC)[reply]
This applies to anything that cannot be passed, but for which users do not have significant doubt about the copyright claim for now. RoyZuo (talk) 12:51, 24 March 2025 (UTC)[reply]
@Yann: I don't see why presumed U.S. government images would be any different from anything else that we can no longer verify. If it looks like the uploader was generally doing what they should, and there is no serious reason to doubt that, we should keep it.
Question, though: I thought as of about a year ago we stopped doing any systematic review of PD images such as U.S. government images. Do I misunderstand what was going on here and here? - Jmabel ! talk01:24, 31 March 2025 (UTC)[reply]
Comment: No you are correct Jmabel I did not know of this development. But since I had time, I decided to check for non-flickr US Government Department sourced images...and succeeded in finding quite a few still fortunately. With Trump II now in power, I wonder if the USAID flickr site will exist soon as he has fired so many US Government Department employees now. VOA's website may soon be gone too sadly. The NIST and NZERT flickr accounts closed a few years ago. Best, --Leoboudv (talk) 00:10, 1 April 2025 (UTC)[reply]
Question I wonder if it should be a simple "indeterminable" or if there should be a field where reviewer could explain why the file could be kept even if it could not be reviewed. I imagine that if reveiwer think the file should be deleted then the review would be failed instead. --MGA73 (talk) 11:08, 4 March 2025 (UTC)[reply]
it's not "kept". it's merely tolerated. anyone could send it to DR if they have a significant doubt of the claimed licence. RoyZuo (talk) 12:55, 5 March 2025 (UTC)[reply]
Any of the following would be "significant doubt":
can be found by reverse image search, and some results might suggest the image has been published elsewhere by different claimants of copyright predating commons upload.
uploader has rampant copyvio history.
the claimed source doesnt seem to exist.
unlikely claim (e.g. claims to be ccbysa from disney but disney most probably doesnt publish ccbysa; photo of north korean soldier in north korean tank but claims to be us-army photo and pd; claimed source website has weird domain that's more typical of content farm / spam...)
I agree that it may be easier to explay why something looks fishy than why not. So I guess your plan is that reviewer just add an "indeterminable" and then the template would add a suitable text. I can live with that. Next question is what such a text should be. Perhaps something like "A reviewer have reviewed this file but it was not possible to confirm the license because the file is not available on the provided source. However, reviewer did not find significant doubt about the validity of the license claim. If you disagree you may start a deletion request and explain why you think there is significant doubt as of why the license claim is valid."? --MGA73 (talk) 09:14, 7 March 2025 (UTC)[reply]
For example #c-Grand-Duc-20250228132500-Add_an_outcome_of_LicenseReview is commendable, but still that's just circumstantial evidence because the exact image or the video was not found at the VOA website. So if I were to decide, instead of "passing" it, I would let it be "indeterminable", with reason=Grand-Duc's analysis. (Because there's a mini concern: VOA sometimes reuses other news agencies' works, sometimes even mixing external and their own together in one article.) RoyZuo (talk) 10:11, 7 March 2025 (UTC)[reply]
There are estimated 153.8 k files uploaded to other wikis than Commons. Many of those are dual licensed or uploaded before the cut-off date so they are eligible to move to Commons provided there are not other reasons not to do so (COM:DW and lack of COM:FOP for example). But around 2.1 k files are GFDL only and uploaded after the cut-off date. It means they can't be transferred to Commons. It makes it harder for other wikis to use them because they have to be uploaded to every single wiki that would like to use them. It also means that wikis that do not allow local upload can't use the files.
If we change the cut-off date it will help us centralize the files allready uploaded on a wiki and make it easy to use them on all other wikis. It will not give users the option to bypass the restrictions on GFDL on Commons by uploading new files licensed GFDL only to a wiki and then move them to Commons because the suggested cut-off date are two months prior to this proposal.
Background and rationale (change GFDL cut-off date)
Commons decided to ban (or restrict) files licensed GFDL-only with a few exceptions per 15 October 2018 after this accepted proposal to phase out GFDL for most media. The reason for the ban is that GFDL is not a good license. By banning files licensed GFDL-only, users who want to upload files to Commons are forced to choose a better license.
In August 2021, I suggested changing the cut-off date on Commons to 1 August 2021 after English Wikipedia decided to restrict GFDL-only files too. However, there was not enough support for the proposal at that time.
I think there were two reasons for the lack of support for the proposal:
It was not clear how many files it would affect.
As long as it is possible to upload new files licensed GFDL-only at some wiki projects, there is a risk that someone will use that as a backdoor to get the files to Commons if Commons changes the cut-off date again and again.
Since 2021 I have been working on files across all wikis:
I have checked and made sure that categories and templates related to GFDL are now linked via Wikidata on all wikis. That will help us get a more correct number of files.
I have been working on w:en:Wikipedia:GFDL standardization and the GFDL update and moved thousands of files to Commons and have been nominating invalid licensed files for deletion. That have reduced the number of files outside Commons and have given me an idea how many new files are licensed GFDL.
I have been checking wikis to see if they have files uploaded and if GFDL is listed in MediaWiki:Licenses. If GFDL was listed as GFDL-only and wiki was still open for uploads I have often suggested to remove GFDL and several wikis have now removed GFDL. See this list. That should reduce the number of new files licensed GFDL-only. It also gives me an idea how many wikis agree to remove GFDL.
I have made a list of all files licensed GFDL and counted/estimated how many are not eligible for Commons because of the cut-off date. See table below:
Family
Files
Date issues
Wikibooks
2,002
6
Wikinews
40
0
Wikiquote
5
0
Wikisource
180
0
Wikiversity
30,633
0
Wikivoyage
133
0
Wikipedia
117,207
1,946
Wiktionary
103
0
Special wikis
635
0
Grand total
151,938
1,952
Some of the files licensed GFDL can't be moved to Commons because of FOP issues, and many are copyright violations. I have tried to exclude those in the count of files with date issues above. But I have to use Google Translate on many wikis. Also some files may be uploaded to more than one wiki but they should only be moved to Commons once. So the numbers are not 100 % accurate.
Based on the above, it is my conclusion that the number of new files licensed GFDL-only is limited. Since GFDL has been removed from a number of MediaWiki:Licenses or are now only there as a dual-license, the number of new uploads with GFDL-only should be very limited in the future.
It was suggested to make an RfC on meta to establish a global restriction for GFDL. However, I do not think that it will be approved. First because some wikis seem to be more open to accepting GFDL for example Wikibooks communities, Wikiversity communities, and some (often smaller) Wikipedias. Second because even when it is reported on meta that some wikis have thousands of unlicensed or invalid non-free files, there seems to be an opinion that it is not something meta or other communities should interfere with because each community are independent.
I have some lists like m:User:MGA73/GFDL files and User:MGA73/GFDL-list if anyone would like more details. If anyone would like to help check and move files and perhaps contact the wikis that still have GFDL files uploaded and/or have GFDL listed on MediaWiki:Licenses it is ofcourse most welcome.
List of wikis with files and GFDL-only in MediaWiki:Licenses (change GFDL cut-off date)
Update:m:User:MGA73/GFDL_files/Licenses#Wikis_with_GFDL_or_variants_and_files this list shows the wikis that have GFDL in MediaWiki:Licenses and have files uploaded. I think those are the wikis that are in risk of still uploading GFDL-only files. I have listed if GFDL is there as GFDL-only or as a dual license. Circa 60 wikis have GFDL-only but many of those send user to Commons if they click "Upload file" and some of them said it was a waste of time to remove GFDL when local uploads don't happen. Everyone is welcome to help check and update and contact the wikis to ask them to remove GFDL. — Preceding unsigned comment added by MGA73 (talk • contribs) 14:45, 5 March 2025 (UTC)[reply]
Update 2: Copied the wikis here with info about the number of files licensed GFDL and those with date issues
Note on ro.wikipedia: listed under Alte licențe libere (other free licenses), with a warning that it is more intended for documents. There is no explicit statement that the licenses in this section are acceptable, but given that the section includes things like Imagine asupra căreia s-a renunțat la drepturile de autor (images were the copyright-holder has given up their rights), it would appear so. - Jmabel ! talk16:01, 20 October 2024 (UTC)[reply]
The situation is not necessarily a lot clearer for ro.wiktionary and ro.wikisource, both of which say simply Licențe libere - Licența GNU pentru o documentație liberă ("Free licenses - GNU license for free (libre) documentation.") There is nothing explicit there about whether the license is acceptable for images or not. - Jmabel ! talk16:07, 20 October 2024 (UTC)[reply]
The list shows that the wikis that have the most number of files licensed GFDL no longer mention GFDL at MediaWiki:Licenses or they now only mention it as a dual-license.
Feel free to check the wikis and if you can persuade them to remove GFDL or change it to a dual-license it would be great. Please strike out or remove wikis if you it works. --MGA73 (talk) 20:12, 9 March 2025 (UTC)[reply]
Update 3: The list User:MGA73/GFDL-list show wikis with GFDL-files and if there are any with date is-sues. Date issues are files uploaded after 15 October 2018.
Someone commented on what has been done to make users stop using GFDL and relicense files already uploaded. So I have made a list of wikis and users with 5 or more GFDL-files with date issues.
Wiki
Category
Files Total
Files GFDL
Date Issue
Remarks. (Blocked users are ignored. Users with no edits for years are ignored. Month/year for latest edit added for non-active users.)
Many have FOP-issues or lack proof of permission (COM:VRTS)
uk:User:Polonskiy 7 FOP-issues. Asked user to relicense. (latest GFDL upload 2019, latest edit December 2023)
Total
82,943
1,957 1,930
List is updated April 27 2025.
The list shows that there are 14 wikis (all Wikipedias) and 42 users with 5 or more files with date issues.
4 users have more than 100 uploads. One is blocked and the 3 other have not uploaded GFDL files since 2021.
You can also see there are almost no uploads in 2024 and 2025. I have checked and new up-loads are mostly reuploads of existing files (crops, edits etc.) or copying files from other wikis because there are COM:FOP-issues. Some are also likely to have a wrong license so they should be fixed or deleted.
So I think GFDL uploads are not really a problem anymore. I see no indications that any users try to get around the ban on Commons by uploading the files to another wiki somewhere.
If someone would like to see the files you can click the links above named "xx:User:MGA73/GFDL". Everyone are of course welcome to check files and talk to users.
Update 4: Based on earlier lists I made a list of the files sorted per year. It shows that the GFDL files are mostly uploaded in 2019.
Year
2018
2019
2020
2021
2022
2023
2024
2025
Total
Files with date issues
122
1,212
329
261
18
9
2
2
1,955
I have excluded files from mk.wiki because they need a permission via COM:VRTS and files from lij.wiki because they have a wrong license. It is not possible to get an exact number without checking all files manually. Sometimes there is no good source and author so it is unclear if the license is valid. --MGA73 (talk) 17:29, 9 April 2025 (UTC)[reply]
As proposer of this suggestion I Support the change of cut-off date. I hope many users will join this vote/discussion and comments and questions are ofcourse welcome. MGA73 (talk) 19:29, 4 March 2025 (UTC)[reply]
Oppose. This feels like it's just kicking the can down the road. So long as GFDL-only uploads are still allowed on some wikis, we'll inevitably end up with more of these files; extending the cutoff for migration without fully addressing the problem at the source just establishes a norm that the cutoff doesn't actually mean anything. I might be willing to support a proposal which was limited to wikis which have committed to no longer accepting new GFDL uploads. Omphalographer (talk) 22:59, 4 March 2025 (UTC)[reply]
There are like 800 wikis and if you want all of them to ban GFDL it is impossible. The top five wikis no longer mention GFDL on MediaWiki:Licenses. --MGA73 (talk) 06:57, 5 March 2025 (UTC)[reply]
I added a link above that should hopefully make it easier to see which wikis still have GFDL on the list of licenses. --MGA73 (talk) 06:40, 6 March 2025 (UTC)[reply]
@ Omphalographer Hello, I have now also added #List of wikis with GFDL date issues where you can see more about the users that have uploaded files licensed GFDL. I think it shows that GFDL is not really in use anymore.
I would really appriciate it if you could tell me what more should be done before you would support the proposal. --MGA73 (talk) 12:11, 20 March 2025 (UTC)[reply]
Oppose The decision to stop allowing that license was done to protect our end users. That makes me loath to undermine it. The sister projects have had years to sort this out and have chosen not to ("If you choose not to decide, you still have made a choice" -Rush). That said, I don't know what outreach has been done to either the projects still allowing it or the uploaders still using it, so I don't know if additional outreach would be effective at getting at existing files dual licensed. The Squirrel Conspiracy (talk) 23:51, 4 March 2025 (UTC)[reply]
I do not think that GFDL pose a danger to our end users it is only a difficult license to use on non-electronic products. As I wote English Wikipedia and other (main) wikis have removed GFDL-only as an option. But there are more than 800 wikis and some of them does not even care about copyright. As it is now English Wikipedia have banned GFDL but around 480 files are stuck there because the ban was not made untill August 2021. --MGA73 (talk) 06:57, 5 March 2025 (UTC)[reply]
Some of the wikis I have been talking to had no idea GFDL was bad. So it is not always because they do not want to remove GFDL. --MGA73 (talk) 06:40, 6 March 2025 (UTC)[reply]
@ The Squirrel Conspiracy Hello. You mentioned the outreach to the projects still allowing and the uploaders still using it. So here is a summary:
There are 868 wikis and I have in most cases ignored those have no files (388 wikis) even if GFDL in theory could be uploaded there. I have generally also ignored wikis with only a few files and without GFDL on the list of licenses (MediaWiki:Licenses). If wikis and users only use GFDL as a dual license I have normally only said something to that if they used an old version of Creative Commons instead of 4.0.
For wikis with GFDL-only I have suggested that they removed GFDL from the list. Until recently I ignored wikis that had no uploads for years but based on the comments, I have also started suggesting them to remove GFDL.
If I noticed active users that still uploaded GFDL-only I have suggested that they relicensed the files and uploaded with a CC in the future. In many cases they agreed.
I can only think of one wiki where some users insisted on GFDL and that was English Wikipedia. There I suggested to ban GFDL and that suggestion was met in 2021.
Then there are a few wikis where users sadly just uploaded Internet files and licensed them GFDL. There admins have a cleaning up to do. For example in hr:Kategorija:Slike GFDL-ja. But according to petscan the latest upload there is from 2021. I have not asked users to relicense because its a waste to relicense copyvios.
Right now I can only think of one wiki where users still upload GFDL-only: lij:Categorîa:File GFDL. It is spoken Wikipedia articles so the license should be CC-BY-SA-4.0. I told them and hope for a response.
@ The Squirrel Conspiracy Hello, I have now also added #List of wikis with GFDL date issues where you can see more about the users that have uploaded files licensed GFDL. The biggest uploaders no longer use GFDL. In most cases GFDL is only used when reuploading old files and in some cases by a mistake.
As I wrote above I would really appriciate it if you could tell me what more should be done before you would support the proposal. --MGA73 (talk) 12:11, 20 March 2025 (UTC)[reply]
Weak oppose I agree with The Squirrel Conspiracy that our sister projects have made a decision and some have decided by inaction to do nothing. I would support increasing outreach (if that would be effective) to get these existing files dual licensed but the community had decided after many years to finally stop accepting GFDL-only uploads and I would rather not backslide on that. Abzeronow (talk) 00:20, 5 March 2025 (UTC)[reply]
Sadly many of the files are uploaded by users no longer active (some are dead). So it is not possible to get all files relicensed. --MGA73 (talk) 06:57, 5 March 2025 (UTC)[reply]
I'd be open to finding a way for GFDL-only files by deceased users that have this date issue to be uploaded to Commons, but if there isn't a way for a very limited exception to current policy, I can live with these files just not being on Commons. Abzeronow (talk) 23:26, 6 March 2025 (UTC)[reply]
I would hate to see a very complicated rule and for us to ask for proof that a wikimedian is actually dead. Personally I think that allowing 2k files to be moved is a limited exception compared to the 115m files hosted on Commons :-) Also many wikis did not discuss it for example because 1) they had no idea Commos was going to ban GFDL, 2) they had no clue why or what it would mean, or 3) someone never bothered to start a discussion because the wanted to focus on something else. For example I have just spend a year trying to get Wikinewses to update the license from 2.5 to 4.0. It have taken a lot of time and some angry comments. I was even blocked at one wiki. And if you look at the proposals here on this page many of them get very few comments so it is not a surprise if many users do not think it is worth the efford to suggest something. --MGA73 (talk) 09:05, 7 March 2025 (UTC)[reply]
@ Abzeronow Hello, I have added two lists: 1) #List of wikis with files and GFDL-only in MediaWiki:Licenses (change GFDL cut-off date) a list of wikis that still have GFDL in MediaWiki:Licenses and 2) #List of wikis with GFDL date issues a list of the users that have uploaded files licensed GFDL (5 or more files). I think the two list show us that the number of new files licensed GFDL have more or less stopped. I can't take credit for it all but in 2021 and 2024 I wrote to many wikis. Others have done the same. To me it seems that in most cases GFDL is only used when reuploading old files and in some cases by a mistake. I see no indication that any user is trying to get passed the ban on Commons by uploading to other wikis.
I would really appriciate it if you suggest any actions I could do before you would support the proposal. If possible :-) --MGA73 (talk) 12:33, 20 March 2025 (UTC)[reply]
Oppose. Reasons are given why the previous extension was turned down, but I do not see reasons why the new extension should be made. Yes, there are thousands of files that are GFDL-only files on other wikis, but Commons does not want that license used here. Commons does not allow other licenses such as -NC or -ND. This request is really about revisiting and overturning a previous decision. We did not want those files before, and I do not see an argument about why we would want them now. For an example issue, users are being hurt by failing to follow the minimal requirements of CC-BY 2.0 licenses. I do not see why we should allow more onerous license requirements that are less likely to be followed. Glrx (talk) 01:29, 5 March 2025 (UTC)[reply]
I do not think you can compare with NC or ND because those licenses were never allowed and they are not allowed on other wikis either. GFDL was the main license for many years and Commons have millions of files with the license GFDL. If a file was uploaded to a wiki in September 2018 it can be moved to Commons but if it was uploaded to a wiki in November 2018 it can't be moved. So its not like Commons do not want GFDL-files to be here it that we do not want new files to be licensed GFDL. All free files belong on Commons and the existing cut-off date makes it impossible. When the proposal to ban GFDL-only on Commons was made similar proposals should have been made on all wikis to make sure all wikis knew about it and implemented a similar ban. Sadly that did not happen so now some free files can't be moved to Commons. --MGA73 (talk) 06:57, 5 March 2025 (UTC)[reply]
Some people want NC or ND files on Commons because they are free to use in some circumstances. The community chooses not to accept those licenses, and the community can choose to start or stop using other licenses. Your statement, "All free files belong on Commons and the existing cut-off date makes it impossible," indicates that your actual position is Commons should always allow GFDL-only licenses — not just those grandfathered by the 2018 cutoff date or your proposed 2024 date. In a few years there will be more GFDL-only contributions, and a like-minded person would want to reset the date again. I'm OK with the 2018 cutoff date excluding thousands of free files because Commons no longer likes the license. I'm also OK with Commons sunsetting CC-BY 2.0 and CC-BY 3.0 licensed contributions because those licenses have issues that cannot easily be fixed. Glrx (talk) 18:57, 5 March 2025 (UTC)[reply]
NC and ND is not allowed per wmf:Resolution:Licensing_policy so it does not matter if someone want them or not. It is simply not possible for Commons to allow NC or ND. I do not know where you get the idea that I think that Commons should allow GFDL-only licens. I have been spending hundreds of hours trying to get wikis to stop allowing GFDL-only. If you check this you can see that it was my suggestion to ban GFDL from being uploaded to English Wikipedia. I also spend hundreds of hours trying to persuade users to relicense their uploads. Actually I do not think you can find anyone who spend more time on wikis trying to eliminate GFDL than me. As I wrote it should be a one-time change now that most wikis have stopped using GFDL-only. As an example of a wiki that did not want to remove GFDL I can mention cs.wikipedia. They only have one file uploaded: The Wikipedia logo and it was uploaded in 2016. They simply think its not relevant to change anything per this. Should we let wikis like that be the reason that we do not want to move files to Commons because they could in theory upload a new file tomorrow? I know I wrote that all free files belong on Commons and I might want to modify that a bit to all usable free files should be on Commons. There are junk out there that should just be deleted. As you can see above the files that are relevant in this proposal are almost all uploaded to Wikipedias and the main part of the good files are from English Wikipedia. When I made the first suggestion in 2021 it was mainly to make it possible to move the files from English Wikipedia to Commons but as I wrote above someone prefered that it should include all Wikis. Sadly it is not possible because some wikis don't really care about it because either they do not see a problem with GFDL or they have no users uploading files there and do not want to waste time on what to them is a non-existing problem. --MGA73 (talk) 20:07, 5 March 2025 (UTC)[reply]
Leaning toward support, but looking back at m:User:MGA73/GFDL files/Licenses, I'm a little concerned that my remarks on Romanian are the only remarks that anyone seems to have made that followed up and tried to identify any nuances there. Is it possible that almost no one bothered reviewing this? - Jmabel ! talk16:55, 7 March 2025 (UTC)[reply]
@Jmabel: (I moved your comment to the discussion section - hope you do not mind). The comment have been "hidden" in my user space so I do not think anyone noticed your comment. Except me. I have read it and I do not think it is easy to understand because I have to use a translator. But as I understand it the meaning of the text is that GFDL is a free license but it should only be used for documents (similar to what apply on Commons). As for the rest of the wikis that mention GFDL and have files uploaded I checked in m:User:MGA73/GFDL_files/Licenses#Wikis_with_GFDL_or_variants_and_files if it is GFDL-only or dual license and on many of the wikis I suggested that they remove GFDL-only. I have not added my suggestion on that page. But it would be great if someone who speak the language would check too and help remove GFDL. --MGA73 (talk) 20:54, 7 March 2025 (UTC)[reply]
Support Although I'm on the weak side since changing the licenses for files that are obtained from other sites seems questionable. Someone could argue it's a form of licensing laundering. That said, I doubt it's that big of a deal. So whatever. Hopefully there's at least efforts to depreciate the license on other wikis. Otherwise it's just kicking the can down the road per another comment. --Adamant1 (talk) 01:38, 11 March 2025 (UTC)[reply]
Thank you! The only change of license is the license migration of files uploaded before August 2009 and if someone upload a random internet file and claim it to be licensed GFDL. Hopefully someone will notice if internet files are licensed incorrectly so they are not moved to Commons. I have checked 868 wikis and 388 of those have no files so no work is needed for those wikis. Closing for local uploads have without doubt prevented many problems and many files licensed GFDL (thanks to User:Nemo_bis and other that helped close for local upload of files on smaller wikis). A number of other wikis have files but does not allow new uploads or uploads are only allowed for admins. I and many others have since 2009 worked to get GFDL removed and now 347 wikis have files but not mention GFDL as an option during upload (MediaWiki:Licenses). 133 wikis (with files) mention GFDL during upload but most only as dual-license. So only 50 wikis mention GFDL-only as an option per the table above. But as you can see some of those have no actual uploads and others write "not recommended" or mention that it is only for documents. I am trying to get GFDL removed from the last few wikis that still have uploads. Another good news is that even if some wikis mention GFDL in 2025 then almost none of them had any actual uploads of GFDL-only since 2018. If anyone speak the language of the wikis above they are very welcome to help depreciate GFDL. --MGA73 (talk) 07:54, 11 March 2025 (UTC)[reply]
Comment I'm not sure how feasible it is, but could we have a different date per wiki if it's a transfer? Keep the current date for any direct uploads to Commons, but use the date each wiki banned GFDL-only for transfers from that wiki -- and if they have not, keep the current Commons date until they do? I think we still accept files that are naturally GFDL-only from other non-Wikimedia sites, but that should be very rare (outside of documentation). Carl Lindberg (talk) 12:58, 24 March 2025 (UTC)[reply]
If we make such a rule it will not be easy to find any files that violate the ban. But since there are almost no new uploads of GFDL-only I doubt it will be a big problem. It may ofcourse be hard to explain to users that they can only move some files and not other files. I have one question: Should a ban be written in a license policy like Commons:Licensing#GNU_Free_Documentation_License or en:Wikipedia:Image_use_policy#GNU_Free_Documentation_License or is it enough that the license have been removed from MediaWiki:Licenses? Latest status: The estimated number of files is 2,000 and almost 500 of those are from English Wikipedia where there is a ban. Around 600 files are from Hungarian Wikipedia and 400 from Azerbaijani Wikipedia but many are probably incorrectly licensed so the actual number of files to move to Commons is likely lower. The remaining 500 are from a number of wikis. --MGA73 (talk) 16:04, 24 March 2025 (UTC)[reply]
Should a ban be written explicit like on Commons:Licensing#GNU_Free_Documentation_License or is it enough that the license have been removed from MediaWiki:Licenses (the page that generates the dropdown with licenses users can chose during upload)?
Should it be on ALL ~860+ wikis or is it okay if wikis where uploads are impossible or where no uploads have been made for years are excluded for example?
Are there any wikis you would think is okay to include or any wikis you would like to exclude?
I have tried to add and update lists above that I thought you might find relevant. Please let me know if you need any other info. --MGA73 (talk) 06:08, 7 April 2025 (UTC)[reply]
I admire the effort you have put into this issue, but the question for Commons is much simpler. Commons is a separate project, and the decision has been to not accept post-2018 GFDL licenses. What other projects accept is up to those projects; Commons does not control them, and they do not control Commons. Commons no longer accepts post-2018 GFDL-only content. What is in a dropdown box, years since last upload, or which wiki are irrelevant. Glrx (talk) 03:24, 8 April 2025 (UTC)[reply]
Thank you. I agree that Commons decide what to do and sometimes we change our mind :-) The purpose of Commons is to host free files and an important part of that is to host files for all WMF-wikis. The reason I raised the question about a ban on other projects is that someone suggested that our choice should depend on what other wikis do. --MGA73 (talk) 05:07, 8 April 2025 (UTC)[reply]
Oppose - IMO, all GFDL-only licensed files should be deleted from Commons. GFDL-only is not a free license for media in any practical sense. Nosferattus (talk) 17:20, 4 May 2025 (UTC)[reply]
If Commons implement that the result will probably be that the files are copied to the wikis where the files are used and many wikis will stop uploading to Commons. But I agree GFDL is not a very good license. I just think it would make sense to put all the free files to Commons instead of having some of them locally. --MGA73 (talk) 19:20, 6 May 2025 (UTC)[reply]
Oppose - GFDL-only is no longer allowed to be uploaded on Commons because it isn't a good license and isn't easy for re-users. Local Wikis are the right place for content that is useful to local wikis, meets their standards (even if the standards are not exactly intentional), but doesn't meet the Commons standards. While one element of Commons' purpose is to be the central location of media across Wikimedia projects, another element is hosting only freely-usable media, and based on the decision made years ago, GFDL-only is not easily or effectively freely-usable. The inconsistency in that Commons has some old GFDL-only content is an annoyance (I suspect it was a necessary compromise to get the GFDL rule change implemented years ago), but I don't see a pressing problem with it; if we did intend to make changes in this area I would lean in the other direction, as Nosferattus suggests, to delete the GFDL-only files on Commons (which as MGA73 said above would probably involve copying to local wikis if in use). Consigned (talk) 07:22, 15 May 2025 (UTC)[reply]
@Consigned Thank you for your comment. I think it is time to close this as "not done" :-) I have kept it open because I have been using the suggestion as an argument for local wikis to remove the option to upload GFDL-files.
I would like to add one comment about reuse. It is a problem to reuse GFDL-files in printet works (books, papers, magazines etc.) but in electronic media it is not a problem. In 2008-09 when this was discussed and implemented printet works was more widespread and Internet was not as widely used as it is today. So as a counter argument to delete all GFDL-only files you could argue that the original reason to ban GFDL is no longer valid. So personally I would not support a proposal to delete files licensed GFDL (or older versions of Creative Commons as someone else suggested).
Also I have been cleaning up on wikis and I like to be able to move all free files to Commons so that only non-free files are stored locally. The problem of local uploads is that many wikis have a history of not checking up on copyright so when users like me comes and start to check then hundreds of thousands of files have to be deleted. Files that could easily have been saved if someone had told the uploader right after upload "Hey remember to add a valid license!". And many of those files would have been usable on other wikis too if they had been saved in time. Commons have almost 119 million files so I would be willing to allow perhaps 2 thousand files to be transferred here so the local wikis could be cleaned up and the files could be used on other wikis too. I think that will be harder to trust wikis to move files to Commons if we start to delete old files because we no longer want specific licenses on Commons. --MGA73 (talk) 09:46, 15 May 2025 (UTC)[reply]
All too rarely are files from Commons attributed to their creator in accordance with their license. I've noted that instructions for attribution have been discussed multiple times before, and that "Use this file" provides an adequate text string for attribution.
Support: per above. Also, CC licenses are being recognized by copyright authorities globally, such as in Russia where free licenses were recognized in 2014 (coinciding with liberalizing uses of architecture there). A few years before, according to Britannica, there was a ruling in 2008 by a Federal Appeals court in which free licenses "are enforceable under copyright law because they 'set conditions on the use of copyrighted work.' In the event that the conditions are violated, the license disappears, resulting in copyright infringement as opposed to the lesser violation of breach of contract." JWilz12345(Talk|Contributions)13:57, 7 April 2025 (UTC)[reply]
Support I support this in principle but it only works if we entirely ban custom licenses and author templates they are not conform with Commons:Machine-readable data. On the exact wording: It also needs to include a link to the file page. GPSLeo (talk) 17:04, 7 April 2025 (UTC)[reply]
Has anyone done a formal review of what users put in custom license templates? If not, someone should. I suspect there are some common use cases - like requests to be attributed under a specific name, or contact information for commercial licensing - which can be addressed in a standard fashion, rather than having everyone do their own thing. Omphalographer (talk) 07:26, 8 April 2025 (UTC)[reply]
Am I seeing right that the only difference is the word "attribution" in red? That is not remotely sufficient. "Failure to provide this attribution can incur legal penalties to the reuser, including heavy fines" needs to be added. Ikan Kekek (talk) 18:18, 7 April 2025 (UTC)[reply]
"Fines" seems the wrong term. "Fines" are paid to a government, not to the plaintiff in a civil suit. - Jmabel ! talk
The other (and more important) difference would be to place this prominently on the file page, rather than have it be something you have to click to see. - Jmabel ! talk20:10, 7 April 2025 (UTC)[reply]
And to be fully clear, I Support any notice that serves to make it more obvious to reusers what their responsibilities are and what consequences could befall them if they fail to credit their source properly. Ikan Kekek (talk) 21:26, 8 April 2025 (UTC)[reply]
If you open a file in the Media Viewer there is already a generated attribution text as plain text and HTML but it is hidden behind a download button. In the implementation the text should definitely not be in red but aligned with the general style. GPSLeo (talk) 20:36, 7 April 2025 (UTC)[reply]
Yeah, no red. I was just getting annoyed with several news outlets that only had "Wikimedia Commons" under CC BY photos, so I went a little crazy in my suggestion. Positively unhinged.
As for the wording, don't y'all think we should go for something more concise and direct? For example, "If you use this file, you must attribute the author / you must include this information:" Doesn't have to be that, but you see what I mean.
Whatever we decide on, we don't want informaton about attribution, fees etc. to appear when no attribution is needed. "Use this file" always provides a credit line, even when the file is PD. Sinigh (talk) 22:05, 7 April 2025 (UTC)[reply]
Support. A step in the right direction. I would be careful about including things like "Failure to provide this attribution can incur legal and/or financial penalties to the reuser". Licences and use-cases are complex, so it is not a good idea to provide legal advice.--Commander Keane (talk) 09:34, 8 April 2025 (UTC)[reply]
Oppose this seems to be a reaction to this complete communication disaster. I am not against correct attribution and will change to support this if we're not effectively scrapping the CL-TR-Guideline as a result: This approach here is going to add scary warning templates TO ALL FILES regardless of the problematic licenses. Images contributed under a CC4 license do not invite costly legal battles and should not be scary. And even most images contributed under CC1-CC3 license do not cause the respective uploaders to involve enforcement agencies... also no reason to scare people about fines & fees. My point is that: Images from those uploaders who do employ enforcement agencies to directly send large invoices to re-users, still require additional attention, and the easy-to-overlook warning label proposed above is of no help for those cases. --Enyavar (talk) 12:31, 8 April 2025 (UTC)[reply]
Comment My suggestion was by no means a reaction to that or any other currently ongoing discussion. I have not participated in or even read it. I also advised against adding any legalese. My suggestion only attempts to address a frequent issue (unattributed works that require attribution when used), by adding clear instructions immediately below files, since they unfortunately seem to need it. Sinigh (talk) 13:44, 8 April 2025 (UTC)[reply]
Comment The main problem, of course, is that not even professionals seem to have a clue on using free non-PD images. We need to make it obvious that you need to check what the licence requires from you. If we can tell the actual requirements in a good way that covers everything that isn't an obvious corner case, then good.
The second problem, however, is that requirements can be complicated. I haven't figured out any watertight advice, other than to let a lawyer check the actual licence. Is the attribution line actually constructed so that it takes into account any place where requirements may be stated? How can we extract an attribution line from user templates? What if an attribution line is specified, but placed in the description field (by a non-author uploader)?
The proposal is just an attribution, I don't think there is a need to over think it. It may reduce copyright infringement cases, but it can never prevent them all and that is the best we can do. As you say, only a lawyer can interpret the licence and give thorough advice and it is up to reusers to find the correct attribution (and meet all of the other conditions). Of course, Commons can strive to extract the correct attribution - we should do that anyway. The attribution line makes it somewhat more obvious to reusers that the file has licence conditions, hopefully they will see the creativecommons.org link and actually make their way to the deed. Commander Keane (talk) 12:46, 10 April 2025 (UTC)[reply]
Just thinking about it, it is essential to call it "Credit:" rather than "Attribution:" to avoid confusion with the term in the licence summary. Commander Keane (talk) 12:55, 10 April 2025 (UTC)[reply]
Agree. I also agree that this shouldn't be made more complicated than it needs to be. The Stockphoto gadget always provides a credit line, with the addition of "Attribution not legally required" when applicable (which I didn't notice before). This new feature could work the same way. What works there should work here. Sinigh (talk) 13:45, 10 April 2025 (UTC)[reply]
Comment I would support having the design team to redesign the file page to provide users with clear attribution instructions. The current UI is not user-friendly for those who just want to download a picture, leaving them confused about how to give attribution. Some people just attribute to "Wikimedia Commons" or "Wikipedia". --0x0a (talk) 10:31, 14 April 2025 (UTC)[reply]
I work since 3 days to improve chi2 graphes without using Javascript because commoms refuses upload of SVG containing JavaScript.
I have found a solution based on CSS and input tag of xhtml but commons refuses to upload this SVG because it contains "http://www.w3.org/1999/xhtml" namespace !!!
In FAQ I found some explanations indicating that this namespace is not accepted in SVG without saying WHY !
First of all, xhtml is accepted in SVG, it is only refuse by Commons Wikipedia not by SVG.
Can this restriction for xhtml in SVG be removed to allow great improvements in graphes design ?
No, and it's for essentially the same reason - the XHTML namespace includes elements and attributes like <script> or onclick="…" which can be used to execute scripting content. While I'm sure you have good intentions, scripting content (even in SVGs) presents a risk to users; we can't allow it to be included in files. Omphalographer (talk) 23:05, 9 April 2025 (UTC)[reply]
Just for information, my SVG file doesn't contain <script> or any other events using script. My SVG contains only <div> and <input> html tags !
I understand your explanation but I don't understand the second NO that indicate that it is impossible for Wikipedia to improve this situation.
It's just a matter of willpower !
Wikipedia can certainly check if uploaded file contains script code or prohibited html tags and accept all files that are conform to check process ! Schlebe (talk) 08:19, 17 April 2025 (UTC)[reply]
@Schlebe This also wouldn't work after thumbnailing. Right now there isn't a whole lot of interest in allowing interactive SVGs (Personally I think it would be cool, but it does open up a lot of things that need to be thought through.). If this is for Wikipedia, I was recently doing some experiments at w:User:Bawolff/Graph_demo which might be of an interest to you. Bawolff (talk) 09:59, 11 May 2025 (UTC)[reply]
"Removing templates from image pages" abuse filter: enable tagging or warning
In the description of "Removing templates from image pages" abuse filter, a note says "Removing warn until false positives go down. A lot of issues with category related templates. The tag "blanking" also seems inappropriate. A throttle may not be good for this filter since people working with categorization tend to do a lot of similar edits at a relatively fast rate.". As can be seen in the list of abuse filters, that's currently true: if the filter is triggered, it has no consequences at all. According to that filter's description page, "Of the last 377,416 actions, this filter has matched 52 (0.01%)". I think this number is small enough to tag or warn when the filter is triggered, so all cases can be reviewed and undone when neccesary. Some template removals can have a serious impact (for example, removing or replacing a license or license review template, by a vandal IP user). MGeog2022 (talk) 11:35, 18 April 2025 (UTC)[reply]
What I have seen in the last month is that warnings do not really help. Therefore I would suggest to make this a blocking filter for IP users and the warning for not autoconfirmed users. GPSLeo (talk) 10:34, 20 April 2025 (UTC)[reply]
Support As a regular at com:FILTERT, warnings won't work, the action should be disallow for all non auto confirmed users. Noting here that the filter (like all commons filters) will need to be rewritten for temporary accounts. All the Best -- ChuckTalk19:25, 20 April 2025 (UTC)[reply]
Sorry, I was mistaking autoconfirmed users for autopatrolled users. Not all autoconfirmed users can be automatically trusted, but the abuse prevention doesn't need to be disallow, if the template removal edits are marked in a way that they can all be patrolled later. MGeog2022 (talk) 14:58, 26 April 2025 (UTC)[reply]
Not all autoconfirmed users can be automatically trusted. Well, maybe more than I think. Perhaps it's highly unusual that a vandal becomes autoconfirmed before detected. Many people here know it much better than I do, for sure. MGeog2022 (talk) 15:01, 26 April 2025 (UTC)[reply]
Self uploaded files are the main case of this as people remove deletion templates from their uploads without addressing the problem. GPSLeo (talk) 15:50, 26 April 2025 (UTC)[reply]
1 or 2 more weeks of margin can still be given, but I think that, if no one has any objection, this change should be implemented (by someone who can do it), taking into account what @Alachuckthebuck and @GPSLeo have said, to prevent the proposal from being archived due to inactivity. MGeog2022 (talk) 18:45, 6 May 2025 (UTC)[reply]
@GPSLeo, thanks. Then, when the original filter is modified to block it also for non-autoconfirmed users (I suppose this is the intention), this can be marked as solved. MGeog2022 (talk) 14:29, 18 May 2025 (UTC)[reply]
@GPSLeo, are there any plans to also change the original filter, for non-autoconfirmed users, or will it be enough with the new filter for IP users only? For example, maybe all edits by non-autoconfirmed users with bad behavior are usually reverted, so it's not so important. In any case, I reply here so the proposal doesn't get automatically archived until it's clear that it has been fully solved. MGeog2022 (talk) 13:25, 4 June 2025 (UTC)[reply]
I am not sure. I think half of the edits currently hit by the non blocking filter are fine. But I created a new tag to see patrol these edits. GPSLeo (talk) 13:50, 4 June 2025 (UTC)[reply]
@GPSLeo, OK, in fact, my initial proposal was about tagging or warning only. If you think that this is fully addressed now, you can mark it as solved. Thanks for your work in it. MGeog2022 (talk) 20:04, 4 June 2025 (UTC)[reply]
There are many galleries with flags. Many of them are absolutely usable even if currently incomplete like Flags of municipalities of Angola or similar. But there are other galleries with a scope that would result in tens or thousand files being added to the gallery like Gallery of Flags in 3:2 or Flags of country subdivisions. And there are galleries they could be useful but are currently used as political battleground and sandbox by IP users like Sovereign-state flags or with totally unclear definition Flags of stateless nations. Some of these pages where once clearly defined like Flag map of the world (original page) but at some point got expanded without prior discussion and no clear concept again primarily by IP users.
We need some way to deal with this. I think we should definitely delete the overly broad or unclear scoped galleries and restore the useful galleries to a version where they had a clear scope. Then we should protect them from IP edits. GPSLeo (talk) 10:52, 27 April 2025 (UTC)[reply]
Support. Gallery pages about flags should be used for specific collections of the flags of closely related entities, e.g. flags of nations, flags of states or provinces within a country, etc. Collections of unrelated flags like "flags in 3:2" are handled adequately by categories; rollups like "flags of country subdivisions" are too broad. Additionally, I'd note that we have a whole mess of year-by-year flag galleries which are completely unmaintainable and which, in most cases, barely change from year to year. I'd propose that we get rid of most of those as well - collections of historical flags at specific, stable points in time could be useful, but we certainly don't need one for every single year. Omphalographer (talk) 21:15, 28 April 2025 (UTC)[reply]
I could definitely see some value in a gallery of national flags for a period (certainly longer than a year), but part of what would make it valuable would be precisely to note the changes in that period, whether it is Canada moving away from incorporating the Union Jack in its flag, the U.S. adding stars as it added states, the many changes of flags during the decolonization of Latin America or Africa, or the adding and dropping of Communist symbols from flags. - Jmabel ! talk03:18, 29 April 2025 (UTC)[reply]
Couldn't you just do that with a regular gallery for flags of a country without it being based on a time period ("by year" or otherwise) though? Like what's the point in having a gallery specifically for flags over time when the same thing can be done with a regular one? --Adamant1 (talk) 03:39, 29 April 2025 (UTC)[reply]
You could for any one country, but it wouldn't show patterns like the wave of decolonization or the fall of Communism in Eastern Eruope. There is definitely value in a visual representation of such things, and Commons galleries are a good tool for showing it. - Jmabel ! talk17:44, 29 April 2025 (UTC)[reply]
A timeline of changes to flags in a region could also be a great idea for a gallery. But what I meant there were collections along the lines of "flags of Europe in 1815" (i.e. post-Congress of Vienna), where there's a substantial difference from modern flags, not only in the designs of the flags but also in the nations represented. Omphalographer (talk) 18:37, 29 April 2025 (UTC)[reply]
Comment There are three separate problems being discussed here: 1) Galleries where the majority of images that should be in that gallery are non-free, and therefore won't be on Commons for the foreseeable future. 2) Galleries that don't seem to serve a clear purpose or provide a benefit separate from a category covering the same content. 3) Galleries as a venue for ethnic/geopolitical edit warring and vandalism. I'm not sure if the 'a gallery for every year, most of which are substantially similar' concern is an issue or not (apart from issue 3). In my opinion, we should be getting rid of galleries where issue 1 or 2 are the issue. For issue 3, that's a behavioral issue that should be addressed through the page protection and blocking policies. The Squirrel Conspiracy (talk) 21:54, 29 April 2025 (UTC)[reply]
CommentAnd there are galleries they could be useful but are currently used as political battleground and sandbox by IP users. The solution for this is page protection, not deletion. It would set a very bad precedent if a page is deleted because of political edit wars, propension to vandalism, or the like. Lots of very useful gallery pages could potentially be lost if things are managed in such a way. MGeog2022 (talk) 18:49, 13 May 2025 (UTC)[reply]
Support I think IP editing should be disabled. I agree that there are some useful contributions, but in most cases, they result in vandalism. They might be useful for Wikipedia, but definitely not for Wikimedia Commons. Incalltalk18:04, 19 May 2025 (UTC)[reply]
The Angola gallery is absolutely fine as it has a clear scope. The subdivision is also fine as there is a clear definition to only include first level subdivisions what is a reasonable size. But someone already started to also add historical countries with their subdivision. This is something that needs to be removed to prevent to gallery from also becoming an unusable unclear collection of files. GPSLeo (talk) 18:51, 7 June 2025 (UTC)[reply]
Hello, regarding the 'Media of the day' section on the main page, to maintain consistent quality, I suggest that all media featured there—such as the image of the day—should be sourced from the featured media list. While there may be a limited number (278) of medias (especially if we aim to display one per day), this approach could encourage more users to contribute high-quality content and to suggest it to be featured media. Regards. Riad Salih (talk) 15:30, 11 May 2025 (UTC)[reply]
Disagree, there's far too few of these files. Instead, more people can readily contribute to the featured media pages such as adding or replacing files there. Prototyperspective (talk) 15:43, 11 May 2025 (UTC)[reply]
Exactly, that's the issue. There are too few featured media, even though many existing files have the potential to qualify. Just like featured articles and featured images, featured media should showcase the highest quality content. That would be the most logical and consistent approach in my opinion. Riad Salih (talk) 15:51, 11 May 2025 (UTC)[reply]
It won't change, no need to drag other parts of the site down with it. Improve it independently albeit it's somewhat a time-sink with not much tangible benefit. Instead of using featured media for media, people also can use MOTD via the category. Except for a few exceptions which are partly in a subcat, motd files also are highest quality content. It's not feasible and again, if some part of the site is suboptimal or not active enough, there is no need to have it drastically affect other functionalities. Prototyperspective (talk) 15:55, 11 May 2025 (UTC)[reply]
Oppose; as Prototyperspective said, there simply isn't enough featured media to make this feasible. But it is worth discussing whether MotD is even sustainable. As it stands, it seems like the majority of the media displayed on the front page is videos imported from YouTube; this doesn't feel like a good demonstration of what Commons has to offer. Omphalographer (talk) 19:30, 11 May 2025 (UTC)[reply]
It doesn't matter that much where the file was originally uploaded. It doesn't even interest most users nor is it any problem. Lots of videos are also from elsewhere such as from studies or uploaded by users but YouTube is the most widely-used easiest way people upload their videos so it's likely that's where many of the better-quality files are from. I don't know why it feels that way for you but what matters is the file itself, not where it was first uploaded and given the low view-counts and low activity and low feedback on Commons and lack of search indexing of videos on Commons in Google & DuckDuckGo's Videos tab, it's more than understandable that people upload to YT first/only. Prototyperspective (talk) 21:11, 11 May 2025 (UTC)[reply]
Also, until recent improvements in Video2Commons, it was a lot easier even for our own users to upload to YouTube or Vimeo and from there to Commons, rather than directly from their own machine to Commons. - Jmabel ! talk22:31, 12 May 2025 (UTC)[reply]
When a file is marked for new file upload, it should be automatically unmarked after the person uploads, either by a bot that deletes old upload templates, or by the system itself once a certain amount of time passes. This is so that not every single autoconfirmed person can upload their own file.
Anohthterwikipedian (talk) 07:43, 13 May 2025 (UTC)[reply]
In August 2024 we had a clear consensus that we need to restrict cross-wiki uploads using the the mw:Upload dialog. That decision was announced on meta multiple times (most recent) and also tracked on phabricator phab:T370598. But nothing happened to make this technically working in a good way. Therefore I propose that we demand a technical implementation to restrict uploads using the Upload dialog. Upload using this feature should only be possible to users who are (auto)confirmed ether on Commons on the Wiki where they are using the Upload dialog or even more restricted. If there is no solution until August we change our already existing AbuseFilter to block all uploads using the Upload dialog by users how are not (auto)confirmed on Commons. This would mean that users see the upload feature when editing but the message that they do not have sufficient rights is only shown after the upload process. GPSLeo (talk) 11:09, 15 May 2025 (UTC)[reply]
Support as long as we can provide clear messages explaining what is going on when people are refused this possibility. - Jmabel ! talk17:50, 15 May 2025 (UTC)[reply]
Support unfortunately, the interface used to upload through the visual editor is inadequate to handle/screen uploads -- information about licensing/ownership isn't sufficient, and it will upload even if the user never actually saves their edits (with no communication to the user that this is the case). Hopefully there will be improvements, but in the meantime it's too much of a risk to continue allowing this. — Rhododendritestalk | 23:17, 25 May 2025 (UTC)[reply]
Support as it currently is, as everyone has already mentioned, it's a hazard waiting to cause confusion again. I'd actually disable it even for people who are autoconfirmed on only the non-Commons wiki, as it doesn't take much to become autoconfirmed and you still may have no idea what Commomns is. The Tduk (talk) 02:36, 26 May 2025 (UTC)[reply]
And I noticed that warning messages are not possible. When the warning message is shown there is no save button visible. GPSLeo (talk) 21:08, 28 May 2025 (UTC)[reply]
This is the filter in production (I made it blocking uploads by the account TestLeo) that works. The thing that does not work is showing a message in warning mode of the filter that allows uploading after confirming the warning. The warning mode shows the same way as the blocking mode with the proceed button greyed out after closing the message through the dismiss button. GPSLeo (talk) 09:10, 30 May 2025 (UTC)[reply]
Thanks, I think I understand it now. I wonder if it's a bug to be filed and resolved in the AbuseFilter side, if not in the upload dialog. whym (talk) 09:48, 1 June 2025 (UTC)[reply]
The problem is in the Upload dialog and if someone touches this tool to make warning abuse filters working they could just implement the hiding of the tool for users with insufficient rights. GPSLeo (talk) 16:09, 1 June 2025 (UTC)[reply]
The idea with the warning was to notify users that this tool will be limited soon. But it would not be that informative anyways as most users who see the message are autoconfirmed until the blocking for not autoconfirmed users is in force. GPSLeo (talk) 17:51, 1 June 2025 (UTC)[reply]
Ah, now I understand. And I agree that the warning is not necessary, because the blocking will only affect newbies, and they are often editing for the first time when they also try to upload an image. Do you know if it's possible to translate the filter notice to other languages or is it only going to be in English? kyykaarme (talk) 17:06, 2 June 2025 (UTC)[reply]
I think a better wording for the "headline" would be "You do not have sufficient rights on Commons to perform cross-wiki uploads." Clearer about what rights are in question, and about what exactly they cannot do. - Jmabel ! talk23:27, 28 May 2025 (UTC)[reply]
Nonetheless, I think I made the task broader than intended, didn't I? From what I read, the upload dialog and FileEx/Imp are different tools, and there's yet to support restricting other tools that aren't the upload dialog, especially at the Meta RFC discussion. I'm thinking about creating a child subtask (to that existing parent task). George Ho (talk) 00:12, 2 June 2025 (UTC)[reply]
It seems that the assumption behind the proposal is that cross-wiki uploads by new users are worse than average. How do we know that is true? I compared uploads by new users with cross-wiki-upload tag and all uploads by new users in the same date range. I found no evidence that CWU is worse in terms of the ratio of deleted uploads. One example: 15110 uploads and 5193 deleted (34.4% deleted) regardless of tags vs 3455 uploads and 968 deleted (28.0% deleted) for the cross-wiki-upload tag, both between January 11 ("20250111") and January 30 ("20250130"). This is only a quickly done database query. I'd be happy to correct any mistake I might have made (or you can fork it and run a modified query, if you want). --whym (talk) 06:11, 8 June 2025 (UTC)[reply]
The statistic would need to be cleaned from out of scope deletions they are much less problematic than copyright violations. All files uploaded through the cross-wiki upload are in use and therefore in scope unless they are removed from the article. But that is complicated to evaluate. GPSLeo (talk) 08:11, 8 June 2025 (UTC)[reply]
In my opinion the issue is not whether they're worse than the average: the issue is that they're problematic and that's why something needs to be done. The WMF's own study showed that newbies trust that because they're able to upload an image with a couple of clicks it must be fine, because otherwise Wikipedia wouldn't let them do it. Then they get slapped with a deletion notice and told they're infringing on someone's copyright. If newcomers upload deletion-worthy images with the UW as well, then that can be addressed by modifying the Wizard. With the cross-wiki tool the newbies don't even have a chance of finding out what they're doing wrong before they've already done it. kyykaarme (talk) 09:01, 8 June 2025 (UTC)[reply]
Abstract categories like "Culture of X", "Nature of X", "Politics of X" and "Society of X" are now widespread (where X is a country, region, or a city). But the problem is that such categories often get messy without following a consistent definition across a given topic. So, my proposal is to define the categories as follows:
Nature of X – non-human aspects of X, like environment, landforms, organisms etc.
Society of X – human aspects of X.
Culture of X – topics of X related to arts, beliefs, cuisine, customs, festivals, philosophy, religion, science, technology, traditions etc.
Politics of X – topics of X related to government, elections, royalty etc.
Nature of X – non-human aspects of X, like environment, landforms, organisms etc. — where to put human-made parks or similar aspects of landscape architecture in this case? Where to put photos of flowereds that are maintained by a city's administration? Where to put agriculturally used fields? Also, where to put human-made water canals? Or what about rivers that got altered by humans (e.g. Category:Straightening of the Rhine)? Nakonana (talk) 09:17, 17 May 2025 (UTC)[reply]
I would move most what is currently in Nature of categories to the also existing Geography of categories. I think Nature of should only contain close up photos of individual plants or animals but then also if they are cultivated. GPSLeo (talk) 09:50, 17 May 2025 (UTC)[reply]
I oppose hiding "culture" under "society". Not intuitive for the average end user.
I'd put royal families under "society", but probably not under "politics", as a rule (though of course ruling monarchs do belong under "politics". I think it is ridiculous, for example, to have things like the current irrelevant Bonapartist and Bourbon claimants to the French throne under "politics"; similarly, some highly collateral relation of the British royal family.
@Jmabel: Yeah, I confused royalty with monarchy, and the latter is a form of government. Regarding "culture" under "society", although I see how unintuitive it might be to put "culture" under "society", I know that separating the two is not always a good idea for the follwoing reasons:
Culture refers to shared aspects of the society of a given region.
Having two categories separately can confuse people. Especially categories like "ethnic groups" and "religion" would be put under both "culture" and "society" if they are categorized separately.
A better compromise would be to have a unique sortkey for subcats like "culture", "economy", "people", and "politics" under "society", so that they don't appear "hidden". Plus, a navbar can be used to access the important categories, albeit being "hidden" by larger categories. Sbb1413 (he) (talk • contribs • uploads) 04:48, 18 May 2025 (UTC)[reply]
Please remember, this is more about helping people find things than about ontology; the latter is more of a Wikidata concern. If people won't think to look for "culture" under "society", then it does not matter how ontologically correct it is. And there is nothing wrong with having a fair number of categories be under both, it's not like it has a significant cost. - Jmabel ! talk19:43, 18 May 2025 (UTC)[reply]
@Jmabel, GPSLeo, and Omphalographer: Considering the navigational aspect of categories, I have now made an alternative proposal to have the following categories as top-level ones:
Architecture of X – buildings, structures and the art associated with them.
Culture of X – topics of X related to arts, beliefs, cuisine, customs, festivals, philosophy, religion, science, technology, traditions etc.
Economy of X – economic aspects of X.
Geography of X – landforms, maps, subdivisions etc.
History of X – events, monuments etc.
Nature of X – environment, organisms etc.
Objects of X – buildings, structures and other objects.
People of X – individual humans.
Politics of X – government, elections, politicians etc.
Science in X – science, technology, engineering etc.
Society of X – certain aspects of X that involve human interactions, excluding culture, economy, politics etc.
Views of X – panoramas, skylines, aerial photos etc.
I'm not certain it makes sense to try to apply a single category hierarchy to all location categories - trying to enforce one appears to have been one of the factors that led to the New South Wales mess I mentioned above. If the only media we have of a region is photos of grain silos (for example), it's better to have "grain silos in some place" as a direct subcategory rather than building out a whole hollow hierarchy of "objects in some place", "buildings in some place", "storage buildings in some place", etc.
With regard to specifics:
"Objects of X" seems overly broad and generic. Given how common photos of buildings are, a dedicated category for that might be more generally applicable.
"People", "Politics", "Culture", and "Society" seem like they'd overlap a lot. Is there some better way to draw dividing lines between these topics?
I agree with Omphalographer that we want to impose too much uniformity on smaller places where the materials we have may be quite narrow, but something like the above would work well for countries, provinces, and substantial human settlements. Anything we have here should be a loose guideline: "this is normal, but if there are good reasons to go a different way, feel free."
I think it is probably OK that some sub-categories would come under more than one top-level heading. For example, transport probably belongs under both "economy" and "geography", "organizations" under both economy and society.
I don't love "objects" as a top-level heading, though I understand why you want it for completeness.
Conversely, given the nature of the content we have and what people are likely to be looking for, "architecture" should almost certainly be top-level (with "buildings" directly under that).
Where are you proposing to put aerial photographs? panoramics? videos? other categories that are about the type of content?
"Architecture" - or perhaps "structures"? Either way that's a good point; there's plenty of things which humans build which aren't precisely "buildings" - bridges, dams, towers, and so on. For general images of an area not focusing on any particular subject, like panoramas and aerial photos, how about "Views of X"? Omphalographer (talk) 20:48, 22 May 2025 (UTC)[reply]
What Jmabel and I are getting at here is that photos of buildings or other structures are likely to make up a substantial portion of the photos of a place, so having the appropriate categories easy to find is important. "The arts" is not a place where users are likely to look for pictures of buildings, no matter how much art is (or isn't) involved in their design - regardless of whether this is technically accurate, it's not intuitive. Omphalographer (talk) 03:33, 23 May 2025 (UTC)[reply]
@Omphalographer: That's why I have put "objects" as a top-level category, which can be used to put any artificial stuff. "Structures" (or "architectural structures", as the "structures" category is due to be renamed) can directly come under "objects". To be honest, even "structures" can be a top-level category separate from "objects:. Sbb1413 (he) (talk • contribs • uploads) 03:55, 23 May 2025 (UTC)[reply]
I'd be OK with "structures" though I think you will find that at the moment the vast majority of such categories have "architecture" or "buildings" at top level, which suggests a certain measure of de facto consensus. What is important to me is that building, people, and subordinate named places be very easy to find. I think that is what the largest number of people are likely to be looking for in the category tree.
I do remain skeptical, though, of any effort to impose uniformity. The people working in a given area of Commons are likely to be very invested in what they've already done, and I'm not sure that in this case the value of uniformity outweighs the value of people feeling ownership over their work. - Jmabel ! talk04:14, 23 May 2025 (UTC)[reply]
I know that vast majority still uses "architecture" or "buildings" rather than "structures" or "objects". But I still think that at least "structures" can be a top-level category along with "objects", with "architecture" covering the art aspects of different structures (for example Category:Greek Revival buildings). Sbb1413 (he) (talk • contribs • uploads) 04:23, 23 May 2025 (UTC)[reply]
Currently, "structure" is handled like a sub-category of "architecture" instead of the other way around as you suggest. See for example, Category:Architecture by color by country or Category:Architecture of Afghanistan. (It just so happens that I had recently asked a question about this myself: Commons:Village pump#Difference between "architecture" and "structure"?. And tbh, I'm still not quite clear on what's supposed to be the difference and which one of them should be the parent and which the child category. However, I think that limiting "architecture" to artistic stuff might be problematic, because "art" is too subjective. For some people, a generic square building is "art" - especially if it was designed by a renowned architect. So where would we draw the line? And would our definition of "architecture" still be the same as the common definition of architecture? To me, bridges, dams, towers etc. are all elements of "architecture", and there are likely also architects involved in building those "structures", so why would they not be categorized under "architecture"?)
Well, considering that "construction" also comes under "architecture", I think the better thing would be to consider "architecture" as the top-level category instead, as "art" (or "the arts") categories should be restricted to artists and artworks. Sbb1413 (he) (talk • contribs • uploads) 04:34, 23 May 2025 (UTC)[reply]
Standardizing "location categories" is overall not a bad proposal, however I think that "Maps" should not be hidden under "Geography". Yes, it seems evidently logical to place maps as "geographical", and many categories are already organized that way (while many others, aren't), but for easier navigation I would suggest making "Maps of X" a top-level category directly under "X".
Many maps (election maps, transport maps, political maps, history maps) don't place much focus on geography; and especially if "X" doesn't already have a geography subcategory, I'm not in favor to introduce an otherwise empty "geography" node that "maps" have to be located under.
Similarly, "Symbols of X" (typically flags, crests, pins, coats of arms...) are often hidden under "Society" or "Culture". These too could be lifted to the top level, in my opinion.
Sbb, I suspect you already did some navigating on categories around the world, right? Just to put some random examples out, there is Guarulhos (with many top-level categories already in Portuguese and of local events, which seems to happen often in Brazilian categories and I'm not a big fan, but I can manage); Akita (I typically find Japanese locations well-structured, but according to a systems slightly different than yours) and Category:Lomé (many, many African nations have rather empty location categories still, imposing a uniform structure onto less than 50 media files would seem a bit over the top). Should we allow to have regional differences in the structure? --Enyavar (talk) 15:40, 23 May 2025 (UTC)[reply]
Sbb, I suspect you already did some navigating on categories around the world, right? Just to put some random examples out, there is Guarulhos (with many top-level categories already in Portuguese and of local events, which seems to happen often in Brazilian categories and I'm not a big fan, but I can manage); Akita (I typically find Japanese locations well-structured, but according to a systems slightly different than yours) and Category:Lomé (many, many African nations have rather empty location categories still, imposing a uniform structure onto less than 50 media files would seem a bit over the top). Should we allow to have regional differences in the structure?
Yes, I have looked into these categories. However, I don't think we should allow regional differences in the structure, as the Universality Principle says, "The categorization structure should be as systematical and unified as possible [...] Analogic categorization branches should have an analogic structure." However, I do allow simplifying the inner hierarchies while maintaining the top-level categories.
Yes, "maps" and "symbols" should also be top-level categories, as hiding them under "geography" and "society" (respectively) used to confuse even me. But I did not object this as I believed in ontology too much. Now I understand that the categories are there for navigation. Anyway, as we are discussing the top-level categories for country/region/city categories, should we extend this idea to the topics themselves, like Category:Maps being directly put under Category:Topics rather than Category:Cartography? Sbb1413 (he) (talk • contribs • uploads) 15:53, 23 May 2025 (UTC)[reply]
I won't argue here into which supercategory "Maps" should belong. But I would think that this far at the top of tree, more value should be placed upon ontology. Navigational purposes only come into play once you have concrete locations that are mapped?
As a whole, I am not sure how a consensus among even a dozen Commons editors can proscribe policy for every location category of the world. We could lead by example (showing how well it works in example cases) instead of dictating rules. Where would you like to apply your proposed structure first? All the best, --Enyavar (talk) 17:05, 26 May 2025 (UTC)[reply]
I think what Sbb1413 meant was that, within a location-based category like Category:Portugal, a category for maps of that location like Category:Maps of Portugal should be a direct child ("top-level category") of Category:Portugal rather than being buried under some non-obvious sub-subcategory like "Portugal → Science of Portugal → Geography of Portugal → Maps of Portugal". (This is not a real example.) How the real top-level category Category:Maps is handled is less of an issue. Omphalographer (talk) 17:51, 26 May 2025 (UTC)[reply]
@Sbb1413 with regards to "Architecture of X", it tends to overlap a subcategory of "Culture of X" (which is "Art of X"). Architecture, in some countries like France, is an art, so we expect some overlapping here. A complication is we do have buildings that are not really architectures but mere {{PD-structure}}-type objects, yet "Buildings in X" (e.g. Category:Buildings in Pulilan, Category:Buildings in Vladivostok) are typically subcategorized under "Architecture of X".
In something of a quirk of the English language, a football stadium with an outdoor pitch is not usually referred to as a "building". (belated addition 2025-06-01)
In German there is a clear definition for Gebäude (building) building (Q41176) and Bauwerk (architectural structure) architectural structure (Q811979). I think the English term building includes some that would be a Bauwerk and not a Gebäude in German. The German Bauwerk also covers thins where I am not sure if they are covered by the typical definition of architectural structure. GPSLeo (talk) 16:21, 1 June 2025 (UTC)[reply]
There has been objections to put people categories under animal categories for various reasons. On the other hand, the main reason given to support putting people categories under animal categories is that humans are animals. So, to better facilitate on how things are categorized, I have proposed to have separate categories for humans and people. Here, the human categories will cover certain aspects of humans as animals (like human activities, human fossils, etc.), while the people categories will focus on the individuals in more social aspects (like people of certain gender, occupation, state/territory/region, religion, ethnicity, etc. and also people in art like paintings and sculptures). Here's the list format of my proposal for the topic X:
Any ideas about this? Or I can go ahead to implement it, although I will use Homo sapiens instead of "humans" when referring to humans as animals, as using "humans" can be confusing to end users. Sbb1413 (he) (talk • contribs • uploads) 06:56, 27 May 2025 (UTC)[reply]
I would appreciate if you hold off. I don't see any reason to think that this being ignored here means people think it's a good idea. I'm not necessarily saying it is a bad idea, but it's presumably a large change, and should have some sort of consensus behind it. - Jmabel ! talk19:16, 1 June 2025 (UTC)[reply]
There are just under 2,500 fake SVGs - which Commons defines as files that use the .svg (vector file) extension but are entirely composed of raster (non-vector) data.
If I have some time, I'd like to go through them and either reupload them under raster image formats or nominate them for deletion. Once we get the number down though, I think it makes sense to convert {{FakeSVG}} to a timed deletion notice (a "fix this or it will be deleted 7 days after being tagged" template like {{Dw no source since}}). I can't think of any good reason to host raster graphics under a vector format. The Squirrel Conspiracy (talk) 00:31, 3 June 2025 (UTC)[reply]
Oppose. Fake SVG files are legitimate images; they will have a modest bloat because the underlying JPEG or PNG file goes through another level of encoding. A few years back some Commons users debated ripping out the underlying bitmap image, uploading it, and then deleting the original SVG. That seems an enormous waste of effort. The files work right now, so they can be left alone. If they are used, then great. If they are not used, then leave them around and do not spend any effort on them. Many of the bitmap-only files could be (or should be) improved to use the SVG vector format, so you get into this strange cycle of uploading the embedded PNG file but then immediately tagging that PNG with {{Convert to SVG}}. The proper course is to consider {{FakeSVG}} as an invitation to improve that SVG file by uploading better versions rather than a slightly misused format that should be eliminated. See Category:Fake_SVG#Replacing_fakes_by_real_SVGGlrx (talk) 01:34, 3 June 2025 (UTC)[reply]
SupportThe files that are in use should be removed from other projects and replaced with better versions first. Otherwise, I'd probably support it. I'm actually kind of surprised there isn't already efforts being made to phase the files out. I'm willing to support this when, or if, that happens though. --Adamant1 (talk) 07:23, 3 June 2025 (UTC)[reply]
As the given arguments prevail, I'm repeating the proposal:
Commons:Username policy since Special:Diff/355439634 says: "Use of the names of organizations is allowed on Commons only if you verify your account, proving that you are or represent the respective organization."
It has never been Common sense since then that account verification is mandatory at Commons. There are currently only 550 transclusions of Template:Verified account.
Compared to Wikipedias, either company accounts are discouraged completely, or account verification is done to lay open concflicts of interest, or to grant company accounts some leeway when uptating employee numbers or similar without proof. Nothing of all that applies to Commons, account verification doesn't make any sense here, not least as it doesn't and cannot replace file permissions. The Volunteer Response Team doesn't have procedures for account verification at Commons, nor any capacity to handle them.
At Commons:Volunteer Response Team/Noticeboard once in every while there are discussion about such verification, sometimes requested by third party users, sometimes requested by the affected users themselves, but in nearly all cases for no practical reason, but just because the policy says so.
To adjust the username policy to common practice and common sense, I suggest to replace:
Use of the names of organizations is allowed on Commons only if you verify your account, proving that you are or represent the respective organization.
to:
Use of the names of organizations is allowed on Commons. Account verification, proving that you are or represent the respective organization, shall happen only in controversial cases.
Support I agree with the stated proposal to remove the current text. I care so much about this issue that I wrote manifestos for reform at en:Wikipedia:Identity verification and Commons:Role account. My further opinions are beyond the scope of this stated proposal, and I could accept this proposal as is, but I do not like perpetuating the current system of identity verification even though this proposal would reduce it. As an alternative or supplement to this proposal, I would like to reform the identity verification process to be public with what users post on-wiki rather than private in VRT email, especially for corporate identity verification. If the process were more public and automated, then organizations could verify their own identities at will instead of getting a haphazard private review, and the wiki community could better review their identity evidence. This proposal is not about identity verification in general, but only about corporate identity verification. I think it would be too disruptive to quickly reform all of our processes, but starting only with corporate identity verification is a great start. Perhaps we could have a recommended user page template for corporations, and if they want to verify identity, then they fill it out and post to their userpage. Bluerasberry (talk)15:09, 4 June 2025 (UTC)[reply]
If There are currently only 550 transclusions of Template:Verified account then where is the problem? If companies and other orgs don't want to have to verify which doesn't all that much effort, then they could just use a name that isn't their company name.
Could you or Krd, please respond to the concern and reason for why this policy exists, namely the potential problem of impersonation and otherwise misleading people (for example making them think badly about the org)?
I saw the policy grounded in the wish to alleviate any fears about mischievous impersonifications, as it is actually already worded "[...]proving that you are or represent the respective organization." This is IMHO sensible and should be kept, I do not see the verification as proxy for copyright statements or the like. Regards, Grand-Duc (talk) 15:12, 4 June 2025 (UTC)[reply]
How could such mischievous impersonifications look like at Commons? Is there any know case? Who can handle this in the future, if VRT cannot? Krd15:35, 4 June 2025 (UTC)[reply]
Before I could construct a hypothetical case, Jmabel said something below (-> "doing some borderline shitposting") that is likely in the same vein as my thinking. I do not know about an actual case, and as VRT handles the "Benutzernamensverifizierungen" in DE-WP, I do not see any technical hurdle to do the same for Commons (may it be a manpower issue?). Correct me please if I'm wrong. Regards, Grand-Duc (talk) 22:51, 4 June 2025 (UTC)[reply]
As I already mentioned in my initial post, the fact that other projects do it is a moot argument. Perhaps it makes sense for them, perhaps not, but Commons is not Wikipedia. If one user misbehaves, they will be blocked, and then perhaps renamed, but that doesn't mean all user have to verify because one could or could not do wrong. Krd04:11, 5 June 2025 (UTC)[reply]
Re "The Volunteer Response Team doesn't have procedures for account verification at Commons, nor any capacity to handle them": We do occasionally do account verifications (see {{Verified account}}) so that prolific uploaders who also upload their work elsewhere do not have to repeatedly send permissions to VRT. To me, whether verification is required does not depend on whether the account represents an organization or a person - it depends on whether the account represents some person/entity that is famous or has an alternate online presence (such as social media or personal website) that would make it theoretically possible for someone to impersonate them by downloading their images from their website and uploading them to Commons. -- King of ♥ ♦ ♣ ♠17:00, 4 June 2025 (UTC)[reply]
I'm trying to understand how this fits in with other policies. (1) If an account is verified as belonging to an organization, and that account uploads content for which that organization clearly holds copyright, am I correct that we can skip the VRT process for those uploads? Because that is the main context in which I have seen accounts with organizational names used. (2) If we do not require that accounts with names of organizations be verified, am I correct that we will still have to have a process by which an organization can say, "That account does not represent us" and have it renamed or blocked? For example, someone could wreak quite a bit of havoc opening an account as, say, User:General Motors or User:UNESCO and doing some borderline shitposting. - Jmabel ! talk18:30, 4 June 2025 (UTC)[reply]
Per all VRT experience, account verification cannot replace any file permisison at all. That a file is uploaded by User:General Motors doesn't at all mean the GM company is copyright holder of the files they upload. For the exact scenario VRT does have a permission procedure, i.e. Category:Custom license tags with ticket permission. Krd04:06, 5 June 2025 (UTC)[reply]
If they upload content with a free license on their website we normally trust them that they have the permission to do so. If they do not upload it to their website but directly on Commons we require additional proof beyond who operates the account? This does not make sense. Independent of this I think account verification should not be done on every Wiki but centralised on meta. GPSLeo (talk) 05:12, 5 June 2025 (UTC)[reply]
Yes, the VRT offers them additional support to make them aware that they mistaken and are not copyright holder, which is the case in the majority of such cases per my VRT experience. Creating the impression that an upload by a verified account is more trustworthy than an unverified account, puts additional risk on the re-user. You can of course say that it's not our business to care. That's a valid argument, but I'd disagree. We can achieve a better result and at the same time have less work, without user verifications. Krd07:28, 5 June 2025 (UTC)[reply]
Support admittedly this isn't something I have much experience on. Nor do I necessarily understand how it fits with other policies per Jmabel's comment. That said, Krd has enough experience on here to know what their doing and there isn't any obvious issues with the proposal from what I can tell. So it makes sense. Except for the parts that don't, but whatever. I trust Krd knows what their proposing even if I don't completely understand it myself. --Adamant1 (talk) 07:20, 6 June 2025 (UTC)[reply]
Support I have never requested verification differently as in the proposed phrasing. As a VRT agent however, I did process requests from institutions that requested verification because the username policy says so.
In general, it makes uploads done by accounts with for instance the names of GLAM orgs and (well known) artists more trustworthy, and those users don't have to request VRT permission for every image, or every batch of images, anymore since the account is already verified through VRT. The verification that the account actually is who they say they are, helps them to re-use images they own the copyrights to, and that for instance they might have used on their websites or in communications before. This brings down the work load in image patrolling, in deletion requests, in restoring deleted images, and in VRT.
However it does not mean they are knowledgeable on the topic of copyrights, and does not mean that, for instance, if any GLAM org would upload an image of a work by Karel Appel, there is no need to request a validation for this specific image. Commons users need to be aware that the verification tag is for the account, and they can still raise concerns about the individual image copyrights as they see them. Ciell (talk) 07:40, 8 June 2025 (UTC)[reply]
Proposal: Tighten upload process and related policy.
Given that uploaders are expected to know and understand the status of works they upload, I am asking for opinions about tightening the upload and related policy, for post June 2025 uploads.
Namely :
Unless a (revocable) trusted uploader status is held by a User, any upload from the which has date later between 1930 and 2005 (Essentialy the pre Commons era), is automatically flagged for license review, and is indicated as such, the relevant template being added during the upload process. Bot users, GLAM and bulk uploaders would be able to apply for "trusted" status.
Commons should keep a list of Users granted 'trusted' status.
Uploads utilising specfic 'exemption' licenses such as {{PD-USgov}} should include a rationale as to why the exemption applies. In respect of 'non-renewal' of US works, this rationale should ideally include original registration numbers in the Catalog of Copyright Entries or Copyright Record Books,(Commons trust it's users to have undertaken a reasonable effort to identify the status of a work.)
Uploads from Internet Archive, Hathi and Google should not use bare links, but the appropriate templates, with bare links being converted by an appropriate bot. As part of the use of these templates, the additional reviewed template should be added either by trusted uploaders, or during the license review. On new uploads, identifiable bare links, are bot migrated to the templated forms.
Works upload without a license, are 'auto-flagged; for deletion during the upload process, or by a bot subsquently.
Unchallanged speedy/copyvio deletions, are deleted on 'expiry' of the time period in the relevant template (admin bot enforced.) Striking this as comments below say this already happens.
Uncontested "Deletion requests" (Those that get no replies) are after the expiration of the consultation period, automated closes, with the files being removed, but with "Unedeletion information" being given when the request is auto closed.
Abolish "no consensus to delete" outcomes. A file is either 'Delete' or 'Keep' with a decision reached.
On uploads of books or publications, if multiple volumes, printings or editions exist, then it's the date of most recent applicable edition used to determine the license, if there is no information about earlier ones. (This would mean that if a 'Revised' edition of a work by the same authors exists, It is the revised edition that is used to determine if the status is acceptable on Commons, even if the earlier edition would otherwise be permitted. This is to ensure text integrity.)
Didn't understand all the points you propose but Oppose for now point Abolish "no consensus" outcomes. A file is either 'Delete' or 'Keep' with a decision reached. – if there is no consensus either way then it's not good to claim or call it otherwise; moreover I don't know what you even mean by that since files are already either kept or deleted. Also #5 Works upload… is already done. Prototyperspective (talk) 10:39, 6 June 2025 (UTC)[reply]
A firm decision has to be reached about retaining (Keep) or removal (Delete) with a clear rationale as to either outcome. "No conesnsus to delete" cannot be used as a reason for closing the DR, which typically favours a file being retained. If a file/media is retained a compelling rationale for doing so should be stated on closure (which could include a 'Withdrawal(Kept) if the nominator found new information for example. Most DR's I've been involed with end in a clear outcome.
Commons needs to have a 'can we realisticaly prove it's 'status' (and usability)' culture, rather than a 'retain because we couldn't work out what was wrong' culture. Quite a lot of the contributors I've dealt with have the former rather than latter stance though, and such a shift, would to my viewpoint, further the sort of academic approaches Wikimedia projects aim for. ShakespeareFan00 (talk) 12:30, 6 June 2025 (UTC)[reply]
"No consensus for deletion" is a necessary rationale for DR closures that concern COM:SCOPE rather than questions concerning copyright. Not all DRs are about copyright issues and therefore consensus might matter. Some cases of De Minimis might also fall under "no consensus" (while others might fall under COM:PCP). Nakonana (talk) 13:11, 6 June 2025 (UTC)[reply]
1. There's already the user group "autopatrolled" for that, I think?
7. Oppose Such DRs shouldn't be auto-closed / automatically deleted, because a lack of replies doesn't necessarily mean that there's no opposition to the DR. It could just mean that the DR in question did not attract anyone's attention and that nobody has looked at it (yet). It still requires at least one human user to assess the validity of the DR rationale. A bot cannot make such an assessment based on such a non-indicative criteria as "no replies". "No replies" doesn't say anything about copyright, SCOPE, etc. Nakonana (talk) 13:21, 6 June 2025 (UTC)[reply]
Not a specific tag for license review, but autopatrolled means that the upload doesn't show up in "recent uploads" (or at least that's how it was explained to me here). Nakonana (talk) 17:11, 6 June 2025 (UTC)[reply]
Oppose Although purely procedurally. The upload/deletion process clearly needs to be tightened and there's some good ideas here about how to do that. I don't think it's a good idea to combine 9 different ideas into the some proposal. Each one needs it's own separate discussion and consensus. Otherwise it's just risks this turning into a potshot of random support and oppose votes without a clear outcome and no way to deal with it. --Adamant1 (talk) 13:56, 6 June 2025 (UTC)[reply]
@Adamant1: Another idea not listed here, is going to be controversial, and that is that the Upload process should look for specific authors, titles or publishers, and warn during the Upload process. PG has a set of Renewals for post 1964 "Books" (Commons also has a complete run of the CCE to 1978!), and if those sets of data were in Wikidata, it would not only be useful Biblographic data to have, it's potentially a means of having a more friendly Wikimedia way of doing pre upload screening, warning uploaders, rather than "Never uploaded anything by Disney!" filters more aggressive rights holder want to mandate on hosting sites. Of course getting that Data in Wikidata would be a Mars-shot project of itself. :( ShakespeareFan00 (talk) 15:55, 6 June 2025 (UTC)[reply]
That's an interesting idea. I thought about something similar awhile back where the uploader could put the creators name in and it would check the copyright status of their works on Wikidata. Since that information exists for a lot of people, if not individual works yet. Although it would take them putting in the name to begin but it's better then nothing. Maybe a lot of this stuff can be semi-automated once AI gets better. Who knows. Something needs to be done about the amount of COPYVIO that gets uploaded on here though. --Adamant1 (talk) 16:01, 6 June 2025 (UTC)[reply]
Commons:Principle of least astonishment (motivated by this discussion) discusses how the principle of least astonishment applies to Commons, followed by a closer analysis of a tricky case, the nude and partially nude "Geekography" photographs by Exey Panteleev, and proposes a specific way of handling the latter, which has been the subject of multiple DRs and other lengthy discussions, so far with no generally satisfactory conclusion.
Currently Commons:Principle of least astonishment has status only as an essay; I would like to see it adopted as a guideline (possibly with some minor rewordings) so that we can agree that the proposed way of handling Panteleev's photos is something we can enforce as consensus. The short version: in general, these are in scope, but they should not be categorized under the technical topics that they reference, because people looking up technical topics would reasonably expect these categories not to contain NSFW content. - Jmabel ! talk17:57, 6 June 2025 (UTC)[reply]
Support Strongly. Something like this is badly needed. People shouldn't be forced to view nude photographs on here when they aren't looking for them. --Adamant1 (talk) 18:02, 6 June 2025 (UTC)[reply]
Question How is this intended to work with structured data? Are these files also banned from having the categories where they were removed to be added as structured data? GPSLeo (talk) 18:40, 6 June 2025 (UTC)[reply]
@GPSLeo: I don't have a strong opinion on that, but I can see it could become important as search leans more heavily on SDC. Would it be OK with you if we confine this proposal to the general "least astonishment" principle and its application to categorizing these, and then separately take up the SDC aspects? - Jmabel ! talk21:32, 6 June 2025 (UTC)[reply]
For search this proposal does not solve the problem anyway as the search also uses the file name and description. For the search the only solution would be filters they can be applied during search. This is also the reason why I am sceptical with this proposal as it only covers the category system that is the least important for people looking for photos. GPSLeo (talk) 04:56, 7 June 2025 (UTC)[reply]
Realistically both need to be dealt with. Even if categories aren't the main way people look for images. Like it's OK to show people porn when they aren't looking for it just because less of them will see it going through the category system then they will searching for an image. --Adamant1 (talk) 05:22, 7 June 2025 (UTC)[reply]
If we would have a gadget that allows hiding for all photos with depicts statement vulva or penis this hiding of these files could work on category pages and in the search. If we had such a gadget we do not need to care about the categorisation as everyone could just enable the filter. GPSLeo (talk) 05:44, 7 June 2025 (UTC)[reply]
We do not need a special tag. Simply looking for depicts (P180)human penis (Q8124), human vulva (Q116196473) and maybe some other statements should we sufficient. It only needs a tool that allows hiding photos with such statements on every page. But of course creating such a gadget is not that simple if it should not result in very poor loading times. The request for such gadget is already eight year old phab:T198550. GPSLeo (talk) 17:23, 7 June 2025 (UTC)[reply]
Anecdotally, I've found that P180 statements that mention anatomy with sexual connotations often get reverted without comment. Jerimee (talk) 21:25, 7 June 2025 (UTC)[reply]
They are often added as simple spam or to photos where these body parts are barely visible. I also would not add a NSFW tag to these photos. GPSLeo (talk) 04:39, 8 June 2025 (UTC)[reply]
@Jeff G.: Probably people who do that are just tagging for later use with AI algorithms or something. I see the same thing with categories a lot and that's at least my guess. I can't image anyone who uses this site to begin with really about it outside of that though. --Adamant1 (talk) 05:03, 8 June 2025 (UTC)[reply]
Question: are there any ways you foresee this guideline being applied which go beyond nudity? One potential example which comes to mind would be images of visibly dead animals (e.g. carcasses at butchers, roadkill, etc). Omphalographer (talk) 00:17, 7 June 2025 (UTC)[reply]
I was going to ask if this approach was going to be applied to 'ideologicial' subjects, like materials from certain political groups that are trigger material for some people? ShakespeareFan00 (talk) 12:15, 7 June 2025 (UTC)[reply]
Both of that makes little sense to me. What would make sense to me is not showing media depicting dead or dying people in unexpected places and/or enable users to have them blurred. Prototyperspective (talk) 12:19, 7 June 2025 (UTC)[reply]
The sort of situation I have in mind is "if I open up the category for skunks (or whatever), I should expect to see pictures of them alive, not flattened on the pavement". Which isn't to say that we shouldn't have those photos at all, but rather that they should be categorized separately, even if the resulting category is small. It feels like another case of the same underlying principle of "don't show the user potentially distressing things in places where they didn't expect to see that". Omphalographer (talk) 21:37, 7 June 2025 (UTC)[reply]
Not sure what you mean precisely by "ideological subjects". If you mean things like political flags, those are typically going to be expected in the categories they're in. Omphalographer (talk) 17:00, 7 June 2025 (UTC)[reply]
Leaning oppose on this. It seems like a guideline based entirely on an unusual case. Why isn't a simple finding of consensus not to categorize the Geekography images according to their "geek" topics sufficient to deal with that? What other cases would this be applied to. The lack of other examples is what worries me, as it opens the door to a wide range of arguments over what is or is not "astonishing". There is also the issue raised above that it does nothing for the main way people find images (by search). This seems to me like yet another case where finishing the job of implementing SDC would help. Some sort of major aspect/minor aspect distinction of the ability to default search to excluding images with some NSFW/nudity/violence/whatnot flag(s) -- things our category system simply doesn't do. — Rhododendritestalk | 20:44, 7 June 2025 (UTC)[reply]
I beg to differ. The first 25% or so is a guideline, and this is certainly not the only case the guideline applies to, but this case shows well how complex it can be to apply the guideline it in practice. Doubtless there will be other cases eventually worth adding. - Jmabel ! talk00:31, 8 June 2025 (UTC)[reply]
Yes, but the reason the Geekography stuff is a special case is that if these were not nudes, there are probably circumstances where they would be good illustrations for some of these topics, and unlike other places where such issues have arisen, our usual solution to that (make a subcategory) doesn't work well here. - Jmabel ! talk03:55, 9 June 2025 (UTC)[reply]
if these were not nudes I see no reason for why that would be so and disagree. Writing a few words or painting a small logo on nonnude bodies wouldn't be useful illustrations either and for other subjects, such photos aren't useful. Prototyperspective (talk) 12:02, 9 June 2025 (UTC)[reply]
I think the key part / disagreement is about you describing them as [good] illustrations [for some of these topics]. What I said is that they don't really illustrate the subjects (and especially not well). The file you linked to is in that cat via only "Things named after Wikipedia". Btw, Category:Named-after categories would be one of the category-types one should be able to easily filter away with a click when looking at a cat with the deepcategory view since those are only in some way related but not really about the subject / useful in that viewmode. Prototyperspective (talk) 09:34, 10 June 2025 (UTC)[reply]
Question is this proposal only intended to stop soliciting images of nude people in categories, or is there another motive? I am not concerned with the effects of stopping nude images, and I support this proposal if that is its only application. I am concerned that the whole idea is introduced with something that has nothing to do with nudes: "We try to keep a similar structure for category names with similar purposes. E.g. if we have a category Category:1968 in the United Kingdom we should have Category:1968 in England, not Category:England in 1968." Hmmm. So if this principle is consequently applied, then a lot of categories need to be reconsidered, including the above example, actually. We DO have Category:England in the 1960s but not Category:1960s in England; and the same on the century-level Category:England in the 20th century, not Category:20th century in England. By now, I have become familiar with this contradiction in the naming-principle, but for the first years, I always had trouble finding the correct category name. So yes, this has regularly astonished me. I am not opposed that this establishes a standard either way, and preferably location first, since the <year in location> is the odd one out in the whole categorization scheme. --Enyavar (talk) 18:20, 8 June 2025 (UTC)[reply]
It is weird that we ended up with a different convention for decades and years for places, but at least each is applied more-or-less consistently across locations. Could our category naming be more consistent? Absolutely, and every so often we end up with some pretty big projects to apply consistency to some area. This particular one (decades vs. years for places) is probably a lost cause, because at this point it would involve renaming hundreds of thousands of categories. Should have been caught 15-20 years ago, but wasn't. - Jmabel ! talk03:52, 9 June 2025 (UTC)[reply]
Briefly, I don't think it's a lost cause but also not that it's important. In general, it would be best if decade-first cats redirected to the cats with naming schemes of decades last or vice versa so ideally doing something with some scripts/bots would be best; also I doubt it's hundreds of thousands of cats but since they should all be in some meta-category like categories by decade, it shouldn't be too hard to build a script to address this so it's standardized and the other naming scheme cat title is created as a redirect. Prototyperspective (talk) 12:00, 9 June 2025 (UTC)[reply]
What to do with mass uploaded PDF/DJVU which are not in use or verified?
Back in 2020 Fae and others uploaded a substantial proportion of the IA's collections. There was a reasonable good faith assumption at the time that these would be integrated into Commons and ultimately Wikisource, and that at some point the files would be checked for compatibility with Commons and Wikimedia objectives.
This didn't happen, and subsequently, it has been found that due to the metadata provided, and asepcts of the upload process used, widespread license errors, a number in copyright works (both PDF, dju and image media), and faulty metadata has resulted.
So what is the sensible response to this, given that asking Commons license reviewers to check every single upload is a farcical task,
as is requesting a wipe of all unused files?
I'm against in favour of a massive 'nuke' delete, given that I have found compatible items, which HAVE subsequently been useful to Wikisource, without needing to re-upload them from IA directly. However, something has to be done, to avoid the 'problem' files becoming a time-bomb of potential issues. Would a more nuanced removal of post 1930 file be a possible solution? (I.E WE adopt the Hathi-Trust policy approach, of only considering pre 1930 media 'safe', and only allow media after this date on a case by case review by appropriate experts.)
ShakespeareFan00 (talk) 13:41, 8 June 2025 (UTC)[reply]
A lot of the work of getting rid of these, without throwing out the baby with the bathwater, does not need to be done by people who are officially license reviewers. In particular, anyone can mark clearly problematic files for deletion. - Jmabel ! talk03:57, 9 June 2025 (UTC)[reply]
Specic howlers, include clearly post 1930 works in error marked as PD-USGov, which they clearly are not.
@Jmabel: Are you able to help provide some hints or filters? I favour the removal of anything post 1930 on the grounds that date can be looked for relatively easily without getting into soecfic nuances, (or need to check external catalogs.).. ShakespeareFan00 (talk) 10:14, 9 June 2025 (UTC)[reply]
I've stopped short of calling for a CCI on Fae, given that all thier uploads were made in good faith, based on the infromation (and tools they had.) . But if it's going to take a CCI to solve issues that have persisted since the left, I think it should be. Is there a process for iniating one? Files tagged in error as PD-USGov is the largest problem. (An aside is the quality of the scans in places, but that's not something Commons generally worries about) ShakespeareFan00 (talk) 10:14, 9 June 2025 (UTC)[reply]
Some key areas I've noted:
Seed catalogs - Pre 1930 are PD-US and the license can be updated. I did some recatting this moring to diffuse the relevant categoru.
USPTO Library items, which are not US Gov works , but where tagged as such because they were tagged as FEDLINK collection items in the metadata. Some where PD-US, but not all.
Post 1978 Naval Postgraduate Student thesis. These are not PD-US-Gov works, despite some on Commons arguing that the writers of some of them are serving military, in some instances. Many deleted items of this type were not and have not been authored by Federal entities ( Typically these are civilian, state or Foreign military.) Pre 1978 items have been considered no-notice(when none was found), but the collection includes items from various other institutions, and requires review.
Clearly post 1930 journals, tagged in PD as error, because IA had followed a library practice of recording serials date as the date of the first issue of the serial, as opposed to the cover date of the publication, in metadata, which was used in error during the upload process.
Flickr 'Commons' images tagged as PD by default, although examining the source publication proved the publciation and images were not.
and others...
Fae uploaded at least 500,000 IA items I think, and it's far far easier to make a bold decision and conclude the process to check these pre or post upload failed, or never happened, then it is to expect Commons users and viewers to do audits themselves that they would have reasonably expected a responsible library or archive to have undertaken beforehand. A broad post 1930 cutoff cull deletion would quickly resolve the issue, without the extended period of non-action from Commons Processes. ShakespeareFan00 (talk) 10:33, 9 June 2025 (UTC)[reply]
Not to say I think there should be a mass deletion of everything uploaded by Fae but they imported a ton of stuff from GLAMs that have questionable origins, licenses, Etc Etc. And a good percentage of the files have never been organized or checked to make sure they are PD. Like photographs that have no evidence of prior publication but they aren't being deleted because of coming from a library or wherever. Deleting everything post 1930 would obviously be an option but then there's a lot of post 1930 stuff that's still PD in the USA and it wouldn't deal with pre-1930 works that haven't been published before either. Individual DRs for a million files to make its done right obviously wouldn't scale. But then again, I'm probably against a mass culling. So I don't know. It doesn't seem like there's a good solution here. --Adamant1 (talk) 15:49, 9 June 2025 (UTC)[reply]
All books which are in the public domain are also in scope. So I oppose deleting any of them. I have quite a number of reservations about Fae's uploads (notably poor categorization), but I don't see any reason to delete them. Yann (talk) 16:48, 9 June 2025 (UTC)[reply]
Books have to have some plausible educational value. If I took a random assortment of non-educational freely-licensed photos off of Flickr and made them into a book, they wouldn't ipso facto become educational or in scope. That said, to your main point, I would certainly prefer if we didn't delete Fae's uploads en masse, but I can understand why someone would want to, as copyright violations need to be taken seriously and Fae evidently just noped out of the project years ago and will not be around to fix the mess personally. —Justin (koavf)❤T☮C☺M☯16:57, 9 June 2025 (UTC)[reply]
I have noticed there is a lack of commonly used public domain options in the visual uploader.
I have seen logos liscensed wrong
I propose this addition. {{pd-textlogo Cyberwolf (talk) 15:48, 10 June 2025 (UTC)[reply]
This is intentional as there would be to many incorrect licensed uploads. If we could get a special mode only available for users with autopatrol rights such a mode could include tags like {{Pd-textlogo}}. GPSLeo (talk) 17:13, 10 June 2025 (UTC)[reply]
Support. Many organizations on Wikipedia that have simple logos do not have them uploaded to Commons and used in the article. Currently, the only way to upload such images is to choose the "enter a different license in wikitext format" option and enter "{{PD-textlogo}}" manually. Very few beginner (or even intermediate) editors will be able to navigate this process successfully, and even for experienced editors it is cumbersome. PD-textlogo is one of the most common license tags used on Commons uploads — there are more than 200,000 files that use it. As such, it ought to appear in the list. This would make it easier to upload simple logo images, benefiting Commons and the projects that use it. Sdkb talk 20:19, 19 December 2024 (UTC)
Oppose. Determining whether a logo is sufficiently simple for PD-textlogo is nontrivial, and the license is already frequently misapplied. Making it available as a first-class option would likely make that much worse. Omphalographer (talk) 02:57, 20 December 2024 (UTC)
Comment only if this will result in it being uploaded but tagged for review. - Jmabel ! talk 07:14, 20 December 2024 (UTC)
Question Why {{PD-textlogo}} instead of for example {{PD-ineligible}}? I can understand the reason that keeping it simple is prefered and in that case PD-ineligible could be more usable. I do not think adding a review is a good idea. Or well a review is a good idea but realisticly it will never be reviewed. We had {{PD-review}} but it was dropped. --MGA73 (talk) 10:10, 6 March 2025 (UTC)
Weak support for autoconfirmed users, 
Weak oppose I agree with The Squirrel Conspiracy that our sister projects have made a decision and some have decided by inaction to do nothing. I would support increasing outreach (if that would be effective) to get these existing files dual licensed but the community had decided after many years to finally stop accepting GFDL-only uploads and I would rather not backslide on that. Abzeronow (talk) 00:20, 5 March 2025 (UTC)
Agree. I also agree that this shouldn't be made more complicated than it needs to be. The Stockphoto gadget always provides a credit line, with the addition of "Attribution not legally required" when applicable (which I didn't notice before). This new feature could work the same way. What works there should work here. Sinigh (talk) 13:45, 10 April 2025 (UTC)
In something of a quirk of the English language, a football stadium with an outdoor pitch is not usually referred to as a "building". (belated addition 2025-06-01)
.jpg?lang=de){kind=link}
