Allow the Upload Wizard to automatically convert MP4 to WebM

We at Wiki Med have built the ability to automatically convert MP4 to WebM during upload via the Upload Wizard.

Is this something the Commons community is willing to accept? Ie has the position changed since the 2014 RfC? --Doc James (talk · contribs · email) 09:05, 29 March 2026 (UTC)

Gadget to hide NSFW images

LLM use in discussion

Restrict category creation to registered users

Why is it that unregistered users are allowed create category pages without restriction? File uploads are limited to registered users and yet category creation remains fully open, despite being a high-impact action that serves as the foundation of Commons' organizational structure. Categories are the primary way to organize and find files on Commons and are much harder to patrol at scale when created anonymously. The current system we have relies entirely on subsequent patrolling and maintenance by editors rather than prevention. But from what I am seeing on my end, that cleanup is not actually occurring. The categories simply remain. Regardless of how much they clutter the system and actively make it harder for readers to find meaningful media. The sheer scale of category creations makes maintenance extremely difficult to impossible. And unlimited IP/temporary account creations are not serving the project to that end. There was a similar proposal in 2024: Commons:Village_pump/Proposals/Archive/2024/06#Prevent_IP_addresses_from_creating_categories, to which Jmabel reponded:

I'd first want to see evidence that, in general, IPs are bad at creating categories, not that one person bad at creating categories happened to be editing without logging in.

Well, firstly, I disagree with the premise that this can be simply quantified in the form of some illusive, concise summary proving what IPs "generally" do. Even if individual edits vary widely, as I'm sure they would even for file uploads if unregistered users were permitted to do so, the underlying issue is still the maintenance burden and editor accountability. Secondly, I disagree because there is one user who has singlehandedly splintered the festival topic area on Commons into literally thousands of excessively narrow categorization layers that make navigating media harder not easier. And they purposely do this while logged out, which they have admitted is a deliberate act of deception in order to gratify their personal project of creating so many subcategories, which they say is caused by their autism and OCD. And they have not stopped to this day, despite repeatedly suggesting they had committed to doing so. 3x blocked on Wikipedia and miraculously not blocked on Commons despite a truly endless backlog of tendentious, soft disruption and sockpuppetry.

For context, read:

• Commons:Administrators' noticeboard/User problems/Archive 124#Timmy96
• Commons:Requests for checkuser/Case/Timmy96
• User talk:Οἶδα#From Timmy96

As I wrote to them on my talk page:

Not every event should be divided into categories for every moment of that event. This level of subdivision is excessive and unhelpful. Most images depict the same group of people together at the event, so splitting them into these extremely narrow categories clutters categorization rather than improving it. It makes finding relevant images harder, not easier. Commons categories are designed to help users navigate a collection of media files efficiently without fragmenting the content unnecessarily. Not every event or group of people needs its own sub-subcategory, especially when the visual content overlaps heavily. These overly specific categories are really just serving what has clearly been your personal categorization project here rather than the broader Commons userbase. Wikimedia Commons is not a personal archive. Categories should reflect meaningful groupings. Not any one editor's detailed breakdown of every event moment or participant. They should be kept simple, consistent, and easy to understand. Please reconsider this approach and focus on categories that genuinely help users find images without excessive fragmentation. Because I am honestly having a problem with these categories you created. Look at all of the [People at event] categories you created like Category:People at the 2025 Cannes Film Festival. All of the files in the parent Category:2025 Cannes Film Festival are already people at the event. The entire category consists of attendees, which makes this level of categorization useless and then results in this incomplete and even at times circular levels of categorization. When you have countless categories and subcategories for "events", "premiere", "photocall", "press conference", "panel" etc etc etc then other high-level strands like "People at" you then require a level of intersection that just contains all the same files. You are making users click through many layers to find images that are often very similar or even identical in content. This is outrageous and needs to stop. I completely understand the mindset that led you to make these, but it has not helped navigation. For example, I see no reason why a file like Dakota Fanning, Kristen Stewart 16.jpg needs any more categorization than Category:The Runaways screening at South by Southwest 2010 and Category:Dakota Fanning in 2010 and Category:Kristen Stewart in 2010. And often times, the screenings and other sub-"events" categories you have created contain so few files that there's really no reason to even create them in the first place. Commons is not intended to mirror the structure of a festival schedule, press packet, or red carpet lineup. Overcategorizing by every appearance, panel, or moment at an event turns Commons into an overly literal recreation of event programming rather than an easily navigable collection of media files grouped by the clearest visual attributes and most useful contextual non-visual attributes. These deeply nested categories serve you rather than Commons users, and create a significant maintenance burden for other editors. Cleaning up, merging, or navigating these structures takes time and effort that could be better spent improving actual file data, descriptions, or correcting errors. It would be more effective to limit event-related subcategories to clearly distinct and well-populated groupings, like a major press event or photocall if there are enough files to justify it. At this point, many of these categories probably need to be reviewed, merged, or deleted. If you're serious about improving Commons, then we need to start by going back through these all of these over-nested categories, all of which you deliberately created only through IP hopping sockpuppets, and seeing which ones actually serve a purpose and which can be rolled back.

to which they responded

"I stand by what I did."

and

"You're right. It actually does serve me."

I agree a single case isn't "evidence" on its own, but this ability is granted universally to all unregistered users, not just one individual. And I'm not proposing restriction based on a single case. We should be doing so based on the inherent difference between registered accounts and unregistered ones. The latter makes it harder to evaluate patterns of behavior in category creation at scale and only adds to the workload that is frankly not even being done. And if file uploads are limited to registered users due to abuse and maintenance concerns, then what exactly is the rationale for treating category creation differently when categories can also be spammed, misused and require ongoing cleanup from a system that is honestly slow as molasses? There is only so much attention that can be paid to the millions of corners of this website. So how exactly does unrestricted category creation serve the users attempting navigate the massive media library here or the editors working hard to maintain it for said users? Οἶδα (talk) 23:11, 16 June 2026 (UTC)

We should not ban temp accounts from creating categories. We should just ban them entirely. We do not have the capacity to patrol their edits and need the capacity for more important tasks. GPSLeo (talk) 04:47, 17 June 2026 (UTC)

@Οἶδα: it's late here, and I'm tired, and that was long, so maybe I misread, but at a quick read you seem to be saying that temporary accounts should be banned from creating categories because a user who is not a temporary account (or, perhaps, several such users) is (/are) overly splitting categories by date. (FWIW, I agree that overly splitting by date is bad.) If that is what you are saying, then the logic escapes me. What does this have do do with whether TAs can create categories? - Jmabel ! talk 07:14, 17 June 2026 (UTC)

No, I am not suggesting that restricting category creation to registered users will completely fix the instance I outlined above and stop registered users from excessively splitting. Nor did I say that it should be the basis for restricting unregistered users. It is simply an extreme example of a user whose unregistered category creations number in the thousands and have become impossible deal with let alone track down. You are free to skip over that example. Because I believe the rest of what I wrote made it clear that I am not saying what you've condensed my post down to. As I said, we should be doing so based on the inherent difference between registered accounts and unregistered ones. The latter makes it harder to evaluate patterns of behavior in category creation at scale and only adds to the workload that is frankly not even being done. How does this help the project here?

There is great inconsistency that exists throughout the category system, as categories are rapidly created by anyone and everyone, at any name they choose, with little done to maintain them, and to an unfathomable degree if we're being honest. It feels insulting as someone involved in improving categorization on Commons to be routinely confronted with a scale of unhelpful categories that I am unable to remedy. Especially from the onslaught of users who are simply duplicating encylopedic categorizations from corresponding categories on English Wikipedia. Any amount of progress I could make feels as if it is easily offset by all of the categories being created all the time. The category system here is like a wild west that is endlessly large and not exactly attended-to, to say the least. So I'll ask again: how exactly does unrestricted category creation serve the users attempting navigate the massive media library here or the editors working hard to maintain it for said users? Do we honestly believe that we have the capacity to patrol all of these creations, let alone actually merge/delete/rename the ones that require it? When Commons:Categories for discussion is so backlogged to the point of outright uselessness? It is a black hole where things go to sit for literally years. So is there an articulable reason for why file uploads are limited to registered users and yet category creation remains completely unrestricted? Οἶδα (talk) 08:18, 17 June 2026 (UTC)

1. i think everything is unrestricted except file uploads are restricted.
2. "I disagree with the premise that this can be simply quantified..." ofc it can be quantified. someone could show the monthly stats how many categories were created by ip/temp accounts, and how much percentage of them were deleted. even better would be, do the same for registered users and compare the two.
3. https://commons.wikimedia.org/w/index.php?title=Special:Contributions&end=&namespace=all&newOnly=1&start=&tagfilter=&target=85.115.0.0%2F16&offset=&limit=500 indeed, many of these intersection cats (crossing a person and an event, when the number in each is tiny) are useless. all these files should just be put under 2 separate cats for the person and the event.
4. from my experience, i've not seen such massive bad categories from ip/temp, but rather quite often from certain registered users. it might be just the area i work with. maybe your area has more problems from ip/temp. some stats will show us if it's really a problem for all ip/temp.

RoyZuo (talk) 10:38, 17 June 2026 (UTC)

someone could show the monthly stats how many categories were created by ip/temp accounts, and how much percentage of them were deleted

I feel like this implies a level of attention and swfit handling that is simply not happening in the world of categories on Wikimedia. Because so much of the unhelpful categorization added here is not obvious spam but rather overfragmentation that requires deeper consideration of the available media and comprehensively collecting together for upmerging. Unless I am sorely mistaken, and I don't believe I am, I don't see that meaningfully being taken on. As I said above, that cleanup is not actually occurring. The categories simply remain. They are not being deleted as you say. So that cannot be accurately measured in that way.

indeed, many of these intersection cats (crossing a person and an event, when the number in each is tiny) are useless

And that is all from before the Checkuser/AN discussion. They have not remotely stopped. I have no way of tracing all of these categories Timmy96 creates because they are spread across the entire project and only discoverable upon clicking through deeply nested categories. I can only come across one by chance and notice the temp account history. Such as ~2026-34854-38 (talk · contribs) and ~2026-26281-63 (talk · contribs). And so I just give up.

But again, I'm not saying it will stop registered users from excessively splitting categories. But unregistered accounts having the ability absolutely makes it harder to evaluate patterns of behavior in category creation at scale and only adds to the workload that is not even being done. So I'll ask again: how exactly does unrestricted category creation serve the users attempting navigate the massive media library here or the editors working hard to maintain it for said users? Do we honestly believe that we have the capacity to patrol all of these creations, let alone actually merge/delete/rename the ones that require it? If the answer is no, then why are we actively making it even harder for ourselves to improve the project here? If only "massive bad categories" that are obvious spam from IP/temps rises to the level of considering adding a restriction upon category creation on Commons then I may as well be done. If that is where the bar is set, then perhaps I should accept that this issue is simply not one that Commons is interested in addressing. Because obvious spam is easily detectable. Unhelpful, excessive categories that actively worsen navigation between the collection of media here are far far far more insidious and damaging to overall navigation here. And much harder to deal with. Οἶδα (talk) 19:10, 17 June 2026 (UTC)

I think you also have to realize that your proposal will also block good constructive category creations from temp accounts. So that is why it is important to do a research/analysis on the percentage of "good" and "bad" category creations from temp accounts. This allows us to decide whether your proposal is worth it to "sacrifice" the good category creations.

For example, let's say 70% category creations are good and 30% are bad, then I would say your proposal can be considered. But, if 99% of them are good, and only 1% are bad, then your proposal might not be worth it. Thanks. Tvpuppy (talk) 22:35, 18 June 2026 (UTC)

Then I think you also have to realize that restricting file uploads already blocks "good constructive" creations from temp accounts. That is not reason in itself to not apply a restriction. And I'm suggesting that the metric being proposed to "research/[analyze]" this is ultimately flawed and impossible to actually account for "good" and "bad" in such a way. Most cats are not obviously "bad" to the point of swift deletion. They are structurally redundant, duplicative, or excessive. That is not something you can easily classify in a simple percentage metric, yet all of it causes an incredible amount of clutter on Commons. A large number of individually "valid" but excessive or redundant categories still actively harm the project when they fragment topics beyond what the community is realistically able to maintain and remedy. Meaning they simply remain. And even if we assume a high proportion of constructive edits from IP/temp accounts, that doesn't change the core issue being the impossible maintenance workload needed to correct that navigation hindrance and our inability to actually identify problem category creations when they are spread across the entire project and across a horde of disparate IPs/temps. So it's less about "Are unregistered users worse than registered users?" but rather "Is the unrestricted creation of categories something we are actually able to patrol and correct at scale under current maintenance conditions?" Because, as of right now, the obvious answer appears to be no, regardless of who is creating them. But as I said: unregistered accounts having the ability absolutely makes it harder to evaluate patterns of behavior in category creation at scale and only adds to the workload that is not even being done. Does anyone actually disagree with that? No? So then why are we actively making it even harder for ourselves to improve the project here when it's already completely swamped...

I do not believe the "sacrifice" could ever be that big when category creation is so impactful and registration is so easy. Is it so much to ask that category creation, which remains the primary way to find and organize files on Commons and is therefore arguably as consequential as the file creation (which is restricted), be attributable in a way that actually supports meaningful oversight and cleanup across the project? Οἶδα (talk) 05:54, 20 June 2026 (UTC)

Wait, could it be that the restriction of file uploads to registered users is not solely because of disruption, but also because of issues with attribution? It's way less ideal to credit an image to a random string of numbers, and makes it harder or even impossible to reach out and negotiate or clarify licensing terms when people are anonymous. This is technically true for text, but you can always rewrite text to rid of copyright issues. Can't do the same with media that easily. HyperAnd [talk] 08:56, 20 June 2026 (UTC)

my personal habits now: dont care whether a category is redundant, or has a weird title.

because, com:cfd is nearly broken. the direct consequence of wiki's "consensus building" is a time sink. cfd cannot effectively deal with any sorts of problems or disagreement. and it wastes a lot of time. so i avoid sending categories to discussion or deletion.

more importantly, i have pretty good tools that let me browse and find files about any topic, so i dont give a shit about problematic categories.

take a look at Help:Gadget-DeepcatSearch, for which i have plans to greatly expand its functions.

utilising mw:Help:CirrusSearch, particularly deepcategory, incategory, insource, nearcoord, filetype, filesize, filewidth... when i want to look at any topic (be it a location, a person, an event), i go to its category page, and from there i do a search instead of expanding and clicking the subcats. RoyZuo (talk) 15:18, 20 June 2026 (UTC)

Category PAGE creation ? or category creation ? Because a category is just a specific link on a page and exists eternally. They do not require having contents and do not require having a page. Deleting a category is just the process of emptying it and deleting the page associated with it, but the category technically keeps existing and you can immediately add something to it again. In that sense, you cannot disallow creation of categories similar to how you cannot forbid people to insert any other type of redlink. —TheDJ (talk • contribs) 12:16, 17 June 2026 (UTC)

with regards to the concerns by TheDJ: Category page creation could be restricted. But I see little sense in doing so for IP users: the most prolific category-splitters are in my experience long-time autoconfirmed users. Sometimes, I notice category splits into basically atomized categories, which I consider a bad idea, since I like lumping as long as there are no patterns that require a split-off. But that does not mean that my view on the matter is necessarily correct in all cases. If IP (or new) users have a good idea about creating a category, why not allow them? We already have the latent practice that experienced users may just abolish and redirect/delete "bad" categories that were created by IPs, without the need of an CfD. If that practice is not allowed by the rules, the rules should be changed to codify the practice.

... Redlink creation needs to remain. Either, the redlinked categories do make sense, and patrollers/confirmed editors can then go on and create the page. Or, the redlinked categories are already existing under a different name, then it can be considered to create a category-redirect. Or, the redlinked categories make no sense, but even then they can be replaced with the correct category. We need to allow assigning redlinked categories, to everyone.

... The idea of banning temp accounts altogether appears to be a bit too radical in my opinion - Commons should remain open. --Enyavar (talk) 13:55, 17 June 2026 (UTC)

The primary function of Commons is uploading files, and that has always (AFAIK) required registration. I don't think it's particularly radical to propose that other secondary functions of the site require registration as well.

Creating redlinks to categories isn't something which we have the ability to technically restrict without preventing users from editing at all (which I don't think is on the table); by "category creation", what I think TheDJ implicitly means is indeed category page creation. Omphalographer (talk) 19:07, 17 June 2026 (UTC)

Category PAGE creation ? or category creation ?

Category PAGE creation. Adding a category to a file is not the same as creation of that category Οἶδα (talk) 18:22, 17 June 2026 (UTC)

A weary  Support. The current state of affairs is that, from a procedural perspective, it is dramatically easier for users to create category structures (e.g. creating category pages and populating those categories) than for other users to abolish those categories. We've seen repeated waves of bad category creations by IPs / temporary accounts in certain topic areas involving fictional characters and children's film and TV series (e.g. . While these changes certainly could be made using a registered account, the use of multiple temporary accounts makes it much more difficult to identify which categories were affected and revert the changes. One typical example from a few years ago was Commons:Categories for discussion/2024/05/Category:Films by character. Omphalographer (talk) 20:01, 17 June 2026 (UTC)

Proposed AI deletion criteria.

In order to codify some commonly cited deletion reasons for AI content (with a view to potential AI specific CSD / DR reasons.) I propose the following criteria, to be used against AI generated media. :-

1. Synthetic depiction of a living person (COM:AIIP);
2. Synthetic substitute for an obtainable photograph.
3. Mass-produced generic synthetic output with no human selection.
4. Misleading synthetic representation
5. Unverifiable historical reconstruction
6. Redundant synthetic replacement
7. Hallucinated details
8. Promotional AI generation

Thoughts? ShakespeareFan00 (talk) 19:02, 18 June 2026 (UTC)

 Support making these some kind of formal guideline. In particular “Mass-produced generic synthetic output with no human selection” could be a speedy deletion rationale. Dronebogus (talk) 19:07, 18 June 2026 (UTC)

There's a big RfC coming next week. (the 24th to be exact)
We may need additional policy (not guidelines) after that, but having various overlapping proposals in parallel is not a good idea imho. Discussing this to work out some details is fine, but this thread should be moved to COM:VP imho. This is not actionable, and changing core policy is not typically done like this. - Alexis Jazz ^{ping plz} 19:51, 18 June 2026 (UTC)

Agree that deletion rationales should be based on policy, not the other way around;  Oppose this specific request. -Consigned (talk) 09:14, 19 June 2026 (UTC)

If there's a pending RFC, then it would be prudent to 'hold. ShakespeareFan00 (talk) 19:53, 18 June 2026 (UTC)

Generally agreed. A few other specific classes of AI images I've frequently nominated for deletion are:

• AI-generated imitation (or "retouched") historical photographs or artwork
• Imitation or unofficial emblems
• Images with grey checkerboard backgrounds, often with weird glitches - this is a common result when users ask AI chatbots to "remove the background" of an image
• AI-generated infographics - these are problematic because they're often full of text that is practically impossible to correct
• AI-generated maps, charts, or graphs - which are usually malformed and/or based on no source data)

Omphalographer (talk) 23:22, 18 June 2026 (UTC)

•  Support per Dronebogus. --Bedivere (talk) 02:10, 19 June 2026 (UTC)

I would add that all newly uploaded and unused AI generated files are out of scope. GPSLeo (talk) 04:40, 19 June 2026 (UTC)

Maybe you would do so. But that simplistic blanket is not a policy that seems to have gained any ground with most of us. Andy Dingley (talk) 10:54, 28 June 2026 (UTC)

•  Oppose. It's fine to mention all of these somewhere is problems with AI, but we should have (presumably narrow) specific criteria for what AI-generated images are allowed, not a potentially gameable laundry list of bases on which they are disallowed. - Jmabel ! talk 04:42, 19 June 2026 (UTC)

 Support the idea. We can (and should perhaps) have criteria for both inclusion and exclusion. Sinigh (talk) 08:11, 19 June 2026 (UTC)

•  Comment: I don't think this proposal is ripe for a !vote. As I suggested in a recent RFC, Commons is many things to many people, and what may be misleading in one context is at least plausibly useful in another. There are the seeds of good ideas here, but some of them probably need to exist in the framework of Wikipedias (with strong editorial policies), rather than Commons itself. Rather than a policy or guideline that ought to be general, what about expressing this as a value judgment in essay form, using some concrete examples to argue how these characteristics are inherently incompatible with featured content or specific kinds of reuse? TheFeds 00:26, 25 June 2026 (UTC)

  I agree. The proposal seems much too casual for what it's trying to do (new deletion criteria, new speedy deletion criteria). It could evolve into a nice essay, and could be basis for further explorations on future policies, though. And yes, examples would help. whym (talk) 07:24, 28 June 2026 (UTC)

• I don't know what these mean. It's a long list of criteria (maybe good ones) with each one expressed in fewer words than we have criteria! That's not a good way to write policy; it makes interpretation hugely dependent on interpretation of each word, in a weak context.

We should also keep these deletion criteria consistent with existing general policy. Do we have a policy to delete misleading content anyway? (we've gone both ways on DRs). Famously we have no WP:NOR policy here, we also prioritise the rights of Wikipedias to define INUSE. So Commons has never been strong on deleting things for being 'misleading', we have no specific policy for that, at most we've fallen back onto SCOPE and whether it was still educational to mislead. This has often turned into personalised arguments over particular pet topics: for instance flags are regularly deleted for being 'fictional', even when they relate to a notable work of fiction. (And yet technically inaccurate flags survive, even when we have correct versions). In contrast, engineering diagrams can be hellishly wrong and still survive a DR, because the audience doesn't appreciate the complex error.

"Unverifiable historical reconstruction" we had some DRs recently (I !voted delete) on recreations of historical miracles in central European history. Commons:Deletion requests/File:Batalla de l'Aínsa.png, Commons:Deletion requests/File:Lacuerco.jpg Should these Keeps be overturned?

On the whole, I'm against any new policies about extending existing practices to cover AI . If we do so (clearly we must), they should be as limited as possible. Our existing policies already cover most of the issues with AI (Read Larry Lessig's 'Law of the Horse'). Why do we need a new policy about 'misleading' in AI? Don't we already cover that with our policies for misleading photographs and misleading pencil sketches? The problem here is being misleading, not the tool used to achieve that. Our existing expression (possibly improved and clarified) should still be enough. AI makes this stuff easier, makes it more common, makes it obviously more of a problem for us to deal with; but it doesn't change the basis of the underlying policy.

I think this is a useful effort that we need, so thanks to ShakespeareFan for it. But they need to be written with greater clarity in terms of just what we mean. Also we should try and eliminate them where possible, in favour of falling back onto existing policies for the same issue on non-AI content. Andy Dingley (talk) 10:54, 28 June 2026 (UTC)

We always had this problem. With AI tools we now have much more of such content and small projects seem to fail moderating their content. GPSLeo (talk) 12:02, 28 June 2026 (UTC)

•  Support seems a reasonable list. -- Infrogmation of New Orleans (talk) 21:20, 29 June 2026 (UTC)

Commons:Bots/Requests/BorkedBot - Automated image labeling

It would be good to have more eyes on this proposal. The tl;dr is "what if we used AI to add provisional content descriptors to images while waiting for humans to catch up".

I expect it to be somewhat controversial, but I think there is value in it if agreement can be reached. BrokenSegue 14:47, 23 June 2026 (UTC)

FAQ

open https://commons.wikimedia.org/wiki/Special:Random/File and https://commons.wikimedia.org in a private window (to see what it's like without login)

FAQ/Help is not linked anywhere.

i think this is not helpful at all for users who are not familiar with our website.

also, when users are logged out, the left sidebar, which contains the link "help center", is by default hidden. it's not obvious that some info about the website is there. the about link at the footer is also not obvious since its font size is small and it's one of many links in a long row of text after two paragraphs of text.

imagine you are a person who is unhappy about an image currently being used on wmf projects. you think you have a better pic, so you want to find out how to upload it. with the current website design (both the main page and any file page, which are the pages people most likely see), i find it difficult to get help.

these should be improved. RoyZuo (talk) 10:19, 25 June 2026 (UTC)

No longer allow some CC 1.0 or problematic licenses for new licensing

7 years ago, we disallowed GFDL only for new uploads; should we ban some problematic Creative Commons licenses?

This proposal is intended to ban

• Template:Cc-by-1.0
• Template:Cc-by-1.0-fi
• Template:Cc-by-1.0-il
• Template:Cc-by-1.0-nl
• Template:Cc-by-sa-1.0
• Template:Cc-by-sa-1.0-fi
• Template:Cc-by-sa-1.0-il
• Template:Cc-by-sa-1.0-nl
• Template:Cc-sa-1.0
• Template:Cc-sa-1.0-fi
• Template:Cc-sa-1.0-nl
• Template:Cc-sa-2.0-jp
• Template:Cc-pd

Thanks. JaydenChao (talk) 07:23, 29 June 2026 (UTC)

 Support That these should be deprecated or discouraged. ―Justin (koavf)❤T☮C☺M☯ 13:27, 29 June 2026 (UTC)

 Question What is the actual problem with these licenses that is considered sufficiently serious that we should reject otherwise acceptable works solely because they are released under them? I understand why GFDL was deprecated for new uploads, as it creates practical and legal complexities. However, licenses such as CC BY-SA 1.0 seem relatively harmless in comparison. We already do not encourage their use through our upload tools, so what practical issue would be solved by outright refusing new uploads (not just new "own works") under these licenses? Is there a concrete legal or operational problem that these older CC licenses create, or is this primarily about encouraging the use of newer license versions? --Jonatan Svensson Glad (talk) 13:48, 29 June 2026 (UTC)

Unfortunately, some of the wording in earlier CC licenses creates loopholes and vagaries that can result in some bad outcomes. See Commons:Copyleft trolling and in particular, Commons:Copyleft_trolling#Forced_watermarking for a very specific example. ―Justin (koavf)❤T☮C☺M☯ 13:55, 29 June 2026 (UTC)

There's also a problematic clause in all versions of the CC 1.0 and 2.x licenses: "You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement." Depending on how one interprets this clause, it could be understood to prohibit uses of CC 1.0/2.x media which would otherwise be permitted, e.g. displaying them on a password-protected web site or distributing them in an encrypted archive (both "technological measures which control access"). This clause was removed in CC 3.0. Omphalographer (talk) 22:46, 1 July 2026 (UTC)

•  Support to discourage the use of CC-1.0 for all new contributors uploads but we should only have an exception for works that were licensed CC-1.0 at a time then CC-2.0 didn’t exist or not yet in mainstream use. As a free-use repository, can we ban a free-use license? Bidgee (talk) 16:14, 29 June 2026 (UTC)

 Strong oppose First of all you have given absolutely no reasons at all in this proposal. CC-SA without BY is important to provide a sharealike license without attribution which is more free and CC-SA and other licenses without BY was retired not because of any actual problems with them but because of "Inadequate demand". There are more than 4,500 files in Category:CC-SA-1.0 and there was no solution suggested to provide for that situation.

If you want an actual problem with the 1.0 CC licenses it is that they contain a warranty from the licensor that they own all rights which can be dangerous and it doesn't have "later version" clause. However there was a discussion 5 years ago and there was no consensus to deprecate it and more importantly {{Cc-sa-2.0-jp}} is the solution to this problem as it is 2.0 version license that fix the above 2 problems and probably should be compatible with CC-BY-SA 3.0 and 4.0. No one has given a single problem with {{Cc-sa-2.0-jp}} and there is absolutely no reason not to accept it. If it was to be deprecated it should be only if a new share alike license without attribution was created. 999REAL 💬 ⬆ 16:30, 29 June 2026 (UTC)

Why is the Japanese licence (which CC withdrew over twenty years ago) any better? Andy Dingley (talk) 17:40, 29 June 2026 (UTC)

1.0 CC licenses contains a warranty from the licensor that they own all rights which can be dangerous and they don't have "later version" clause. {{Cc-sa-2.0-jp}} is a 2.0 version license and fixes these 2 problems in the text of the license. Again, it was retired not because of any actual problems but because of "Inadequate demand" 999REAL 💬 ⬆ 18:02, 29 June 2026 (UTC)

But why the Japanese version? Is this just because the Japanese set preserved a CC-sa into 2.0, when others retired it after 1.0? It was dumped and never added to CC 2.0, but for some arcane reason beyond my knowledge, the Japanese team were slow to action this, so they had preserved its existence.

If you compare the deeds though, they're identical between 1.0/en and 2.0/jp

• https://creativecommons.org/licenses/sa/1.0/deed.en
• https://creativecommons.org/licenses/sa/2.0/jp/deed.en

We can take these as a reasonable statement of intent by CC as to the meaning of these two licences.

There are differences between the legal code statements of the two licences. These are the full definition of their licence.

• https://creativecommons.org/licenses/sa/1.0/legalcode.en
• https://creativecommons.org/licenses/sa/2.0/jp/legalcode.ja

Most obviously, they are not simply translations. In particular, 2.0/jp shall be interpreted in accordance with Japanese law. I don't have a translation of the Japanese legal code, but if there's some specific aspect of it that you see as relevant, perhaps you can point us to it? Andy Dingley (talk) 19:10, 29 June 2026 (UTC)

• Do we have any CC 1.0 licences? Do we have new ones arriving? Of these 'new' ones, how many are new to us, but their licences are old enough to be reasonable legacies from the CC 1.0 era? Without being able to answer even this much, I can't see any case to be talking about banning anything. Andy Dingley (talk) 17:39, 29 June 2026 (UTC)
•  Oppose for multiple reasons – I've yet to see past threads raising an issue about (mis)use of the v1.0 licenses themselves similar to GFDL. Also, there was no consensus to deprecate the 2.0 JP at the moment, and I don't see that happening soon. Also, I've yet to see evidence of such licenses becoming frequent tools for copyleft trolls to use. Furthermore, even when proven, the banning of GFDL has left wary copyright holders with no other alternatives except CC 1.0 versions. Let's not favor this at this time. —George Ho (talk) 19:11, 29 June 2026 (UTC)

CC 1.0 licenses for new works (not new uploads) could be disallowed, there's no good reason to license new works with a 1.0 license.
The question is: is anyone actually using these in 2026? GFDL was being abused as a kind of BY-NC/ND backdoor. (not everyone who used it did so in bad faith, for example, some small wikis had failed to update their default license setting decades ago) Who uses CC 1.0 today? - Alexis Jazz ^{ping plz} 20:18, 29 June 2026 (UTC)

How often the v1.0 licenses have been used or popular they've been especially recently should not be a major or the sole reason to favor or oppose the proposal. They're still used somewhat or somehow, but other than potential misuse by copyleft trolls, deprecating the licenses for being seldom used anymore would be, IMO, prejudicial. George Ho (talk) 20:45, 29 June 2026 (UTC)

• weak oppose. I dont think the problems are severe enough to outright ban. They should certainly be discouraged though. Bawolff (talk) 02:07, 30 June 2026 (UTC)

 Comment if we just do something about {{CC-BY}}, {{CC-by}}, {{CC-BY-sa}} and {{CC-by-SA}} (why are they different from {{CC-BY-SA}} and {{Cc-by}}?) that'll probably solve most of the problem. When searching for recent files, that's what I mostly stumble upon. - Alexis Jazz ^{ping plz} 08:36, 30 June 2026 (UTC)

 Support, see Commons:Deletion requests/Template:Cc-sa-layout.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:22, 30 June 2026 (UTC)

•  Strong oppose We should not reject otherwise freely licensed works merely because the chosen free license is older or less than ideal, absent a clear and significant legal or operational problem that outweighs our mission of accepting freely licensed content. --Jonatan Svensson Glad (talk) 10:57, 30 June 2026 (UTC)

  Per Jonatan --PantheraLeo1359531 😺 (talk) 16:27, 1 July 2026 (UTC)

•  Oppose. The licences are sufficiently cromulent. Even the SA ones. Banning them serves to reject a class of free works belonging to or representative of the culture of innocent people, based on the antisocial choices of a few people, and the aversion to conflict of a few others. (There are some detailed issues with CC PD that bear discussion separately, but I'd oppose until that plays out.) Fine to gently discourage the use of these without fearmongering or badgering. TheFeds 10:12, 14 July 2026 (UTC)

 Oppose in strongest possible terms. Being overly restrictive is not helpful. PARAKANYAA (talk) 07:48, 18 July 2026 (UTC)

Require people uploading their own photos taken with digital cameras to include the file with its original exif data.

I've been seeing instances where people steal copyrighted photos and upload them as their own work. An example of this is File:Darline Graham 2026.jpg which was taken by Sean Rayford then stolen and uploaded by William Bartlett who did not take this photo.

I propose requiring people who upload their own photos taken with digital cameras to upload the photo with its original exif data. News organizations usually remove this data from photos on their websites. So if the photo doesn't have that, it should be a red flag. Please let me know what you think about this. Minermatt122514 (talk) 00:39, 14 July 2026 (UTC)

@Minermatt122514: Enforcing the presence of EXIF may cause privacy issues. Furthermore, most if not all license reviewers are already sensitised about EXIF, the lack thereof or inconsistencies within. I don't think that we need a policy about this. Regards, Grand-Duc (talk) 01:15, 14 July 2026 (UTC)

We can allow people to remove or replace location data or serial numbers. But we should not allow wiping of the entire metadata. GPSLeo (talk) 04:10, 14 July 2026 (UTC)

I think some editing software tends to remove at least some EXIF data without asking or informing the editor. A professional might notice it or be aware of it, but I don't think that we can expect hobby photographers to even know what EXIF data is. Nakonana (talk) 08:58, 14 July 2026 (UTC)

1. If someone really wants to commit fraud, you can completely fake EXIF data.
2. There are editing tools, especially but not exclusively on phones, that strip all meaningful EXIF data. Some strip EXIF entirely, others leave nothing but an indication of what tool was used for the editing, etc.
3. Not every image is initially created with digital photography.

Jmabel ! talk 05:58, 14 July 2026 (UTC)

 Oppose as unworkable, also useless. Andy Dingley (talk) 09:10, 14 July 2026 (UTC)

 Oppose unworkable, unrealistic. This suggestion has the problem of boiling down the world to 2 situations, 2 possibilities as if there actually are just 2. Thats a recipe for disaster. —TheDJ (talk • contribs) 09:33, 14 July 2026 (UTC)

 Oppose per Grand-Duc and the opposes above.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:50, 14 July 2026 (UTC)

New criteria for speedy deletion: Newly uploaded and unused raster images identical to existing vector images

I could have sworn I proposed this before, but I don't remember the outcome and I can't find the discussion.

We get with some regularity people uploading raster (.png, .jpg, etc.) logos which we already have vector (.svg) versions of on Commons (and these vectors are often already in use on various projects). I believe deleting these is in the spirit of CSD F8 (Exact or scaled-down duplicate), but not the letter of that criteria. Therefore, I propose one of two options

Option 1 - Modify CSD F8

Addition below, in red:

F8. Exact or scaled-down duplicate
The file is an exact or scaled-down duplicate of an older existing file. The generally accepted rule is to delete the newer duplicate, but that may not always be the case, such as when comparing between a user uploaded file, and a bot uploaded file. For very large files, however, it may be acceptable to have a scaled-down duplicate for accessibility reasons. This criteria also includes newly uploaded raster images that are an exact duplicate of an older existing vector file.

Option 2 - New CSD

F12. Raster image duplicating older vector image
The file is a newly uploaded, unused exact duplicate in a raster format of an older existing file in a vector format. Because vector images can be scaled to any size, the raster image can be any size, as long as it's identical in design to the vector image.

Discussion

•  Support Either as proposer. The Squirrel Conspiracy (talk) 07:15, 15 July 2026 (UTC)
•  Support F8. --Krd 07:18, 15 July 2026 (UTC)
•  Support F8 but would say, "This criteria also includes newly uploaded raster images that duplicate an older existing vector file." to avoid "exact duplicate" disputes. Glrx (talk) 15:35, 15 July 2026 (UTC)
•  Support F8. ―Justin (koavf)❤T☮C☺M☯ 16:51, 15 July 2026 (UTC)
•  Oppose Raster and vector files are totally different. We should therefore keep both of them. This of course only applies if both versions have sufficient quality and not to any logo that was uploaded as compressed jpg. GPSLeo (talk) 18:06, 15 July 2026 (UTC)
  • But MediaWiki software generates PNGs of various sizes for every SVG. Why are other raster graphics useful in addition to these? ―Justin (koavf)❤T☮C☺M☯ 18:21, 15 July 2026 (UTC)

    A PNG generated out of and SVG is still not the same as an original PNG where you have guaranteed control over every single pixel. GPSLeo (talk) 19:10, 15 July 2026 (UTC)

•  Comment there seems to be an assumption here that (1) the subject is appropriately represented with a vector file and (2) that the SVG is "good", e.g. not an inefficient, thinly disguised raster file wrapped in an SVG. - Jmabel ! talk 20:35, 15 July 2026 (UTC)

• I don't think either of those change anything.

This is presumably (needs to be stated more clearly?) that this is a static bitmap matching the bitmaps our renderer generates. In which case, it doesn't matter if the subject is 'appropriate' for vectors, it's just going to be equally inappropriate in both files, and it's this duplication that we're looking for.

If the SVG is a wrapped bitmap, then you could raise a DR on the SVG itself. But a speedy would still be valid for the static bitmap because, again, it's a technical duplicate of the bitmap version. Andy Dingley (talk) 21:44, 15 July 2026 (UTC)

I didn't want to get overly wordy in the CSD text, but IMO if the SVG is insufficient quality for use, it should be DRed, at which point there wouldn't be a vector "duplicate". The Squirrel Conspiracy (talk) 21:49, 15 July 2026 (UTC)

• And meanwhile you've already speedied the otherwise OK raster version? - Jmabel ! talk 23:34, 15 July 2026 (UTC)

  If the two images are sufficiently different (e.g., earlier poor quality SVG versus later good quality PNG), then the speedy predicate is not met because the images are not duplicates. The PNG should not be deleted.

  A poor quality SVG need not be DR'd but rather marked as a fake SVG, bad SVG, or a poor vectorization that needs to be improved. If SVG is an appropriate format for the image, then do not DR it. If a better SVG already exists, then just mark the poor SVG as superseded by the better SVG. Glrx (talk) 05:14, 16 July 2026 (UTC)

•  Support adding this to F8, with the simpler wording:

  The file is an exact or scaled-down duplicate of an older existing file, or a raster version of an older existing vector image. The generally accepted rule […etc, etc…]

  It has been my experience that F8 deletions of this form were already generally accepted. Omphalographer (talk) 22:05, 15 July 2026 (UTC)
•  Support F8, I'd flagged these as F8 in the past until one was rejected. --Belbury (talk) 16:29, 16 July 2026 (UTC)
•  Support F8, as long as the vector image really is a vector image, and not a raster image embedded in an SVG. --Carnildo (talk) 20:58, 16 July 2026 (UTC)
•  Comment: Is it a duplicate in the sense of sameness, or in the sense of order of derivation? Is it older in terms of creation or upload? (Imagine a sports team logo, for which there exists somewhere a BMP raster from 1999 and a GIF raster from 2009, and on Commons a Commons-user-created SVG from 2019, which means there is also a PNG output of our conversion. Let's further say that the BMP, the GIF and the PNG are each uploaded today as new files, stating their original dates in the description. Which rasters are eligible for speedy deletion, and why?) TheFeds 23:18, 16 July 2026 (UTC)

  @TheFeds: The GIF raster could be deleted as a duplicate. The PNG output would not be saved as a file here. The BMP could be saved for provenance of the SVG file, unless that file has off-wiki provenance. Of course, all would need to be in-scope and free enough for us or below TOO.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:07, 17 July 2026 (UTC)

  It was sort of a trick question to highlight quirks of the proposed rule. If duplicate means sameness, there's no stated mechanism to choose between the BMP, GIF and PNG uploads. (I grant that choosing the oldest raster could be reasonable, but I could certainly imagine arguments about why the implementation details of BMP vs. GIF vs. PNG in the context of a specific file might matter—transparency being the obvious one. And if the retained raster is intended to document the source of the vector, then you'd have to know either which raster file was actually vectorized, or that the vectorizer would have generated the same output with each of the 3 as input—which feels impractical.) If "older existing vector file" refers to upload order, then the result would change if the rasters had been uploaded first (clearly not deletable by the text of the proposed rule). Ultimately I think CSD F8 needs to be simplified to core criteria that are purposeful and minimally ambiguous, rather than tacking clauses on to it. TheFeds 13:04, 17 July 2026 (UTC)