Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Community portal
introduction
Help deskVillage pump
copyrightproposalstechnical
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcuts: COM:VP/P· COM:VPP

Welcome to the Village pump proposals section

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.

Please note
  • 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.
  • Have you read the FAQ?

 
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Page protection[edit]

Images that are sexual content are on Commons so that why we need to put some measurement to secure it we all know we are in 21st century and research is not limited so people young than the age of 18 will have access to these. We should but many opinion on ground to solve this problem. Some people can see this has a advantage to criticize Commons and discourage other from using it. We need to act fast let put idea on table. Tbiw (talk) 02:36, 13 May 2020 (UTC)

Discussion[edit]

  • What does this have to do with site security? —Justin (koavf)TCM 03:03, 13 May 2020 (UTC)
    • Title changed now it okay! Tbiw (talk) 22:03, 25 May 2020 (UTC)
  • Note: OP is retired. Brianjd (talk) 12:03, 10 June 2020 (UTC)
    • OP has come out of retirement to vote {{S}} on their own “proposal”.
  • Background reading: {{NSFW}}, w:Internet Watch Foundation and Wikipedia. This barely scratches the surface. Having read up on previous filtering attempts, is anyone brave enough to put up an actual proposal? Brianjd (talk) 12:03, 10 June 2020 (UTC)
  • I see that the OP has decided to start a vote, despite us lacking an actual proposal. Just saying that we need “some measure[]” is not good enough. Brianjd (talk) 06:45, 21 June 2020 (UTC)
    • Brianjd is right not cool to start a vote this a the issues i lack unable to access and re-organize a decision. All yours dude. Tbiw (talk) 11:47, 21 June 2020 (UTC)
      • And the OP has suddenly removed the voting section. Brianjd (talk) 11:53, 21 June 2020 (UTC)

Proposal: avoid excessive use of gender in diffusing categories[edit]

Proposal:

Subcategories based on gender should be permitted for a profession if and only if one of the following applies:
  1. physical appearance is important to that profession (e.g. acting, modeling)
  2. gender is highly relevant to that profession for some other reason (e.g. vocalists; athletes in most competitive sports).

Besides professions, this should apply also to categories about affiliation with an institution or organization (e.g. members of the faculty of a particular college or university; alumni of a particular college or university; people associated with a particular newspaper or magazine) or receiving a particular award (e.g. Nobel laureates).

To be clear: categories about gender as such are fine (we certainly want to keep Category:Men by name and Category:Women by name); the issue is about intersecting and diffusing categories. And, as with any other category about people, categories about gender may be difffused by nationality and even subregional classification (e.g. U.S. states) is fine: e.g. there is no problem with Category:Women of the United Kingdom or Category:Men of Washington (state) .

Jmabel ! talk 01:12, 15 May 2020 (UTC)

Votes (gender categories)[edit]

  • Symbol keep vote.svg Agree - I also find categories like that annoying. --Jarekt (talk) 01:34, 15 May 2020 (UTC)
  • Symbol support vote.svg Support per my comments at the previous thread. -- King of ♥ 02:11, 15 May 2020 (UTC)
  • Symbol support vote.svg Support Yes, yes, yes. There's no reason to have this type of intersection category. Pi.1415926535 (talk) 02:52, 15 May 2020 (UTC)
  • Symbol support vote.svg Support (obviously, as proposer) - Jmabel ! talk 04:14, 15 May 2020 (UTC)
  • Symbol support vote.svg Support TommyG (talk) 06:46, 15 May 2020 (UTC)
  • Support unless there is a good reason to categorise by gender, we shouldn't be doing. ~~ Alex Noble - talk 06:54, 15 May 2020 (UTC)
  • Symbol support vote.svg Support see previous discussion -- B2Belgium (talk) 08:22, 15 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose a general guideline. Such decisions should be taken on a case-by-case basis.
Take Category:Female writers for example.
Does gender matter for writing as a profession? Maybe not. However, commons dont only serve commons but all wikis. Many wikis distinguish writers by gender: Category:Women writers (Q7944338). Their users might find it odd that the corresponding cat does not exist on commons. Deleting these cats might create unnecessary hurdles for both the categorising effort and finding media for use.--Roy17 (talk) 13:54, 15 May 2020 (UTC)
@Roy17: Do you have a different, perhaps looser, guideline to propose, or do you think that because of that example there should be no rule at all on this? - Jmabel ! talk 14:33, 15 May 2020 (UTC)
Writer is a very general topic and it encapsulates the problem of this proposal. lawyers, politicians, physicians, photographers... are some other common professions that come to mind. this proposal is gonna get rid of all of their subcats. then ppl are gonna ask, why some jobs are listed in Category:Women_by_occupation (or the men cat) while these most common ones are not?--Roy17 (talk) 14:45, 15 May 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose Without refining the categories to some extent you have a general pool that is too broad to be of any use. Your proposal to refine them by nationality is not based upon historical reality. 1) Nationality is a fairly recent development in the scheme of history. Prior to the development of national borders, people identified with their community and ethnic culture; 2) Women, did not have nationality in their own right in the majority of countries in the world until the 20th century (in France 1927, the US 1922-1940, in Canada 1940, in Britain (and most of their colonies) until 1948, etc.) In many instances, they became stateless if they divorced a foreign spouse, i.e. Maymie de Mena or even if their nationality was settled were still required to take on the residency of their spouse in various US states, see Patsy Mink, into the 1960s. In some countries women still do not have their own nationality; 3) Nationality has often changed by the whim of war or treaties, redrawing boundaries on a map with no relationship to the culture to which people identify. Communities, even movements, fought long hard battles to be recognized legally for their identifying ethnicity, gender, beliefs to be validated and protected by law by numerous "nations". Simply categorizing people by national boundaries diminishes the complexities of their existence and removes the context of their history; it also can reclassify people into a category to which they never identified except on paper. It impacts readers/searchers as well, by making it far more difficult to find the subjects they might be interested in reading about or adding a photograph to, as it has broadened the grouping so that it has become irrelevant. This and the one below are both IMO bad ideas. SusunW (talk) 17:31, 15 May 2020 (UTC)
  • Symbol support vote.svg Support While IMHO Commons usually should support category-equivalents for wikipedia articles (and "wikidata content items"), with regard to categories I do not think is strictly necessary to provide the equivalent here. If somewhere "a" wikipedia does an inconvenient categorization, Commons should not be required to replicate the same schema here. IMO occupation+nationality (meaning 'citizenship') should be generally avoided too (except maybe for sportspeople and the like) (using a broader notion of "significant country/region/place wrt that occupation wrt that person" instead), but that's not being discussed here. Commons categories are not intended to provide reading stuff. Women by occupation and Men by occupation categories might be deleted if they are a problem, hanging "female actors" and "male actors" only from "Actors" instead. Strakhov (talk) 18:31, 15 May 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose I don't understand why of this proposal. Just think on gender difference in sport. Susun explained very well why. --Camelia (talk) 19:41, 15 May 2020 (UTC)
    The proposal does cover and make an exemption for such cases. -- King of ♥ 20:18, 15 May 2020 (UTC)
Is not only about sport. In Italian Wikipedia we struggle for the categories splitted by gender from a while, as they, apart from a few exceptions, are not allowed. And every time we organize our events based on female professions, our mostly used "base" for articles to write / translate are the Commons categories (as Wikidata queries are not yet "accessible" for a lot of users). So, no, apart from the identity and women's recognition and equality reasons expressed by others, there is also a practical issue. For us would be a big problem. --Camelia (talk) 21:41, 16 May 2020 (UTC)
Wikidata & Listeriabot do a great job creating lists. IMHO keeping gendered categories in Commons in order to have articles to write in it.wikipedia... doesn't make much sense. Wikidata works much better for that. And it's pretty easy creating those lists. Strakhov (talk) 03:05, 17 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose and — Strong oppose because a "hell no, are you out of your mind?" option isn't available. A broad general guideline is problematic for any number of reasons, and the one proposed above is absolutely horrible. Nationality per SusunW is a problem for all the reasons she lists, and "relevant in the profession" is nothing but ghettoization (pigeonholing people in only certain occupations opens another can of worms over whether "gender is highly relevant" in a category). This needs to be done on a case by case basis. Montanabw (talk) 19:47, 15 May 2020 (UTC)
    "Highly relevant to that profession" - as a subjective criterion, that means deciding on a case by case basis. What alternate criteria do you propose for guiding the "case by case" decision on whether to diffuse by gender? -- King of ♥ 20:18, 15 May 2020 (UTC)
    ”Case by case basis” is the default for all wiki discussions so doesn’t need special rules. The problem is your suggested limitations, which in practice become policy and getting exceptions is more drama-inducing than just leaving it well enough alone: I mean, are you serious that the criteria for diffusion should be “physical appearance is important to that profession (e.g. acting, modeling)“ and “gender is highly relevant to that profession” —two most unbelievably sexist criteria imaginable? You have got to be kidding! Montanabw (talk) 00:46, 16 May 2020 (UTC)
    Given that you've said "case by case basis", that implies that you do not believe that all professions should be diffused by gender. Can you give some examples of such professions, and why you would not diffuse them by gender? -- King of ♥ 04:10, 16 May 2020 (UTC)
    @Montanabw: You can try {{subst:User:Tuvalkin/Template:No way!}}… -- Tuválkin 01:00, 16 May 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose as per the many reasons given above. As someone who uses the Wikipedia categories regularly when creating off wiki discussions about women in various roles in life it would seriously limit my ability to work. When it is no longer necessary to talk about women's involvement in an area of life because equality has become so ingrained that it is a meaningless topic, then, and only then, should this topic be discussed again.Antiqueight (talk) 20:29, 15 May 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose per the solid reasons already mentioned. --Rosiestep (talk) 23:10, 15 May 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose I've been working on List of African-American women in medicine and it's already hard enough finding good photos for article like these. I can't imagine how much worse it would be if I had to sort through all of the images of doctors/nurses/midwives/PAs just to find what I need for these kinds of articles. There's no stigma is separating categories by gender, race or any other valid criteria. Leave things as they are. As a librarian, I would like to mention that even cataloging conventions for libraries have categories for gender, race, etc. It's professional and necessary. Megalibrarygirl (talk) 00:17, 16 May 2020 (UTC)
  • I Symbol oppose vote.svg oppose, too. E.g.: When I created Category:Female tram drivers, and pretty much every time I add one more file to it, I wonder how useful / empowering / clarifying it is, versus how objectifying / segregating / exotifying it may also be felt. My goal was/is to illustrate a detail aspect of reality, as with any other category, but also to very clearly exemplify how women not only could, but actually can — do a “man’s job”. I am glad to add my vote to that of a few fellow female editors above. -- Tuválkin 00:41, 16 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose I had read the previous discussion, and I'd say this proposal has good intentions (especially the LGBT part). However, I agree with the opposers above. Such problem can't be solved by a very broad proposal. It should be dealt with in a case-by-case basis via CfD. If only CfDs are more active and closed more often... --pandakekok9 01:54, 16 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose for the reasons already given above, as they've stated things better than I ever could. I especially echo Antiqueight statement on equality. Huntster (t @ c) 07:11, 16 May 2020 (UTC)
  • Symbol support vote.svg Support soft Symbol oppose vote.svg Oppose These diffusing categories are messy and generally unnecessary, this move is needed. Having taken a beat, I think this move could be made for some categorisations, but as a swift and unilateral move like this it might be too clumsy and cause too much unintended consequences that would swamp any perceived benefits. Smirkybec (talk) 10:14, 18 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose, strongly. This isn't about branding people, rather about search instruments. The proposal will remove a search instrument which, I am sure, is important to the reusers of content. People who come here for "stock photos" are looking for red brick buildings, yellow brick roads, and women operating pneumatic hammers. That's normal, especially given today's emphasis on "equal representation" of sexes in the media. Why discourage these specific searches by hiding Rosie the Riveter among many men? Retired electrician (talk) 10:54, 18 May 2020 (UTC)
    I guess the thing is, it is useful to have separate categories for men and women at work. What is not useful IMO is classifying portraits of people, who happen to be of an occupation but not actually depicting them engaging in that occupation, separately by male and female. -- King of ♥ 17:14, 18 May 2020 (UTC)
    @King of Hearts: That's precisely the kind of reasoning that I oppose. Reusers of free content don't seek "any" portraits, they have specific demands, they have already "painted the portrait" of what they need. They look for, say, bearded men wearing high hats or curvy blondes wearing ... where was I... never mind. The point is, sex - being probably the most important facet of human appearance, - is a valid and needed search criteria. Unconditionally, regardless of "depicting them engaging" or not. Retired electrician (talk) 11:37, 22 May 2020 (UTC)
  • Symbol support vote.svg Support - Dividing most people-related categories by male, female, non-binary, etc. is pointless and arbitrary. We don't do this for race or age or hair color, so why do we do it for gender? Kaldari (talk) 04:00, 21 May 2020 (UTC)

Comments[edit]

As proposer, I would be open to extending this to race and ethnicity as well as gender, but I think that case is less clearcut, and I'd like to see first if we have consensus about gender, leaving race and ethnicity to a separate discussion. Conversely, I think it is fine to diffuse categories by nationality and even subregional classification (e.g. U.S. states), as long as we understand that the same person may qualify for inclusion in more than one nationality, etc.

Motivation:

  • Categories keep being split and diffused by gender where gender has nothing to do with the matter. Diffusion by gender is not like diffusion by nationality, where we might usefully break up a big category into dozens of smaller categories: for gender, at least one of the resulting categories will always be at least half as large as the parent category. What possible purpose does it serve to split bass players, or non-fiction writers from the United States, or jazz composers by gender? How is this any more valuable than splitting categories by, say, height or hair-color?
  • Diffusing by gender often has the effect of "ghettoizing" the women in a mostly male profession.
  • What on earth are we then supposed to do with transgender or non-binary people in this respect?

How to put this in practice if adopted:

If adopted this would ultimately result in merging quite a few pairs of existing categories. We would not be able to do this all at once. However, I believe the direction to head would be clear:
  1. Stop creating additional categories that violate this policy.
  2. Categories where there is reasonable doubt as to whether diffusion by gender is appropriate will each merit a CFD discussion.
  3. For categories that clearly violate this policy, or for those where a CFD discussion results in a decision that this diffusion is inappropriate, the category can be turned into a {{Cat redirect}} to the appropriate ungendered parent category, and the usual bots that operate on that template will recategorize any files and subcategories appropriately. (Obviously, if anyone wants to move subcategories and files by hand, they would be welcome to do so; I'm just pointing out that in general no one will have to do that.)

(Thanks to the several people who commented at Commons:Village pump#Overuse of gender in categories, especially User:King of Hearts whose wording in that discussion I have drawn on heavily.)

Jmabel ! talk 01:12, 15 May 2020 (UTC)

Comment: I thought it was long settled that where categories listing gender exist, they are either to be fully diffused (no "generic" category and both a men and a women's category instead) or fully non-diffused AND if subcats are needed, then there are BOTH men's and women's subcats. I strongly oppose "ghettoizing" anyone by race, gender, nationality, ethnicity, and so on; i.e. there should not be a "general" category and then just a "female" category. However, there is probably a discussion to be had about how to categorize people who are non-binary in fully diffusing categories. I also think it is often not necessary to sex-segregate small categories ("Category:Professional underwater basket weavers of 1970", for instance). Overall, the creation of gendered categories should be handled on a case by case basis. Montanabw (talk) 19:54, 15 May 2020 (UTC)

Is it safe to assume this proposal is rejected and can be closed now?

IMO this proposal fails simply because it's based on the assumption that for example female drivers is created by dividing drivers into male and female, but actually it could also be women divided by jobs of which driver is one.--Roy17 (talk) 01:26, 27 May 2020 (UTC)

  • @Roy17: I find your wording to be very confusing. A clearer wording would be: This proposal fails because it assumes that, for example, “female drivers” is a subset of “drivers” defined by gender, when it might actually be a subset of “female people” defined by occupation.
I am only here to comment on the wording. Whether this is an accurate summary of the discussion, I will leave to others. Brianjd (talk) 11:19, 10 June 2020 (UTC)
  • Pictogram voting comment.svg Comment I think that we can all agree that any "excessive" use should be avoided. The problem is to define what is excessive and what is not. If we have a category named "Women" and a category named "Writers" we could discuss if we need "Women writers" because it is possible to create that by intersecting the other two categories. But the same apply for any other categories. As long as we do not make so many categories that we will only have very few files in each category I think it is okay (I hate categories with only 1 or 2 files).
I see a bigger problem in the gender categories itself because some day someone will start arguing that gender is not relevant and question how do we define genders etc. --MGA73 (talk) 22:12, 20 June 2020 (UTC)

Ban certain custom licenses[edit]

As we've seen at Commons:Deletion requests/Template:Resolution restricted-by-sa and Commons:Village pump/Archive/2020/05#Images licenced under GFDL-1.2 and CC-BY-NC-(SA/ND), there are many problems with custom licenses, the two main ones being: 1) legal uncertainty due to not being backed by a formal legal document; and 2) incompatibility with other free licenses. I would like to call upon the community to help draft an addendum to COM:L to ban certain types of custom licenses after some date in the future, similar to Commons:Licensing#GNU Free Documentation License.

In my opinion, the ban should at the very least include {{Resolution restricted-by-sa}}, but should not be so broad as to ban {{PD-self}} (even if {{Cc-zero}} is preferred). Some potential points of contention are:

  1. What is the definition of "custom license"? The most obvious definition would be "a license whose text exists only on a wiki", but there is a loophole: uploaders who want to use a custom license could just put it on their personal website.
  2. Should we ban only ShareAlike custom licenses, or something broader? ShareAlike is particularly odious because it only works in practice if there is a large enough ecosystem of works under the same license to remix with, and that obviously doesn't exist for custom licenses.
  3. If we want to ban more than ShareAlike custom licenses, where do we draw the line? Again, we probably don't want to ban {{PD-self}}.
  4. Currently, the way we deal with custom licenses made by third parties (think big organizations/governments) is with a community review on COM:VPC to see if the license is acceptable. Assuming we want to continue accepting third-party custom licenses, how do we distinguish between those who are allowed to create custom licenses and those who aren't?

Note: There is nothing to !vote on yet. Once we come up with a formal proposal, we can proceed with a !vote. King of ♥ 00:27, 24 May 2020 (UTC)

  • Perhaps develop a whitelist of acceptable base licenses already present on the site? It doesn't have to be exhaustive to the point of spelling out individual country variants of Creative Commons, of course (i.e all those at Category:CC license tags), but it would allow us to control on a more basic level what is and isn't permitted in terms of what goes in to custom templates. Huntster (t @ c) 04:53, 24 May 2020 (UTC)
    I think a whitelist might be too restrictive and add too much bureaucracy. We would have to maintain the whitelist and have a community-wide discussion every time we wanted to add a new license. I don't want to change the current approach, where anyone can create a tag for a (published) license they believe in good faith to comply with COM:L and someone else can raise it for discussion or nominate it for deletion if they disagree. -- King of ♥ 05:17, 24 May 2020 (UTC)
  • Pictogram voting comment.svg Comment 1) Copyright is too much of a minefield for us to leave things like license tags up to single individuals. 2) We should focus on streamlining our content for re-users by standardizing our media's meta data as much as possible rather than catering to a bunch of individuals' egos. If you're asking me: Ban all custom license tags made up by individual users for their own stuff. Especially the ones that are just a variation of the regular CC-tags with custom colors etc. Custom licenses by third party organizations are a different matter, of course. --El Grafo (talk) 10:09, 24 May 2020 (UTC)
    I like the idea, but it can be hard to define. Where do you draw the line between: 1) a Commoner who has no other accounts; 2) a Commoner who also has a personal website; 3) someone who has a personal website but isn't really a member of the Commons community; 4) someone who operates a website that others can contribute to, but still contains mostly their own works; 5) someone who operates a popular website that lots of people contribute to? I assume we want to allow the last scenario. Case in point, after Unsplash stopped using CC-0, we stopped accepting photos from them not because it was a custom license per se, but because the terms of the license were unacceptable (i.e. the prohibition against "compil[ing] photos from Unsplash to replicate a similar or competing service"). If Unsplash switched to an acceptable custom license, then I'm sure we'd still be accepting photos from them. -- King of ♥ 17:09, 24 May 2020 (UTC)
    @King of Hearts: If it's "someone" (i.e. an individual) rather than some kind of organization, that should be a yellow flag. Definitely exclude 1) and 2), have an obligatory structured community review for everything else. I'm very much with Colin on this one. We really need to tighten up our rules and procedures if we want to be taken seriously – reliability is not what Commons is knonw for, unfortunately. --El Grafo (talk) 10:45, 3 June 2020 (UTC)
  • Pictogram voting comment.svg Comment What about a type of procedure where every new license template has to become aproved by a couple of license reviewers and/or admins. --GPSLeo (talk) 20:47, 24 May 2020 (UTC)
  • Pictogram voting comment.svg Comment I think that what @GPSLeo: suggest is a good idea. It is simple and can go fast. For example if we say 5 admins support and no disputes.
I do not know if we need a formal approval for licenses that is just some intro and an official license. For example: {{Cc-zero-Scot Nelson}}.
What about licenses like "User:xxx/Some-license"? They are easy for the uploader to make. But they are also easy for the user to change. That could be a risk.
The question is also how we find files that uses an "illegal" license. --MGA73 (talk) 09:43, 25 May 2020 (UTC)
  • I don't like the suggestion that a new licence type should be approved by anything less than full community scrutiny. Why on earth do we have to "go fast"? Too easy to game, and well known that some Wiki chapters (e.g. Austria) were/are dominated by GFDL-1.2 supporters who were not in the slightest interested in contributing outside of Wikipedia. The same was for Saffron Blaze with their {{Resolution restricted-by-sa}}. I don't think we should allow novel licences that are defined only on wiki. I also agree that a "share-alike" licence only works if it has cross-licence compatibility with other licences or is itself a hugely popular licence choice, and has been developed by an organisation with access to professional legal advice. I think we could come up with policy on "share-alike" that says firstly that any such licence needs community approval before acceptance, and secondly a short-list of characteristics such a licence has.
As for custom "licence" templates, I think they must always include an official template, so that the official licence cannot be tampered with. I see the use in them providing additional information about the copyright owner or how to contact them, etc, but as always, we should review them to ensure nobody tries to sneak extra restrictions into them. -- Colin (talk) 10:22, 25 May 2020 (UTC)
  • The problem I'm having is that some users identify (what they think is) a problem with a commonly used free licence (for example CC-BY-SA) and then write their own licence. These users typically don't have a legal team checking the licence, so the custom licence risks having much bigger errors than the licence that the user was trying to fix. In some cases, the licence could be seen as a lottery ticket where it is impossible to know how a court would rule if the right holder sues for copyvio. However, I can't think of a clear definition of such licences. Requiring licences to be approved by the community before their use on Commons sounds like a good idea.
Somewhat related to this are the big boilerplate templates which some users put on file information pages, such as User:Ralf Roletschek/Autor4. This template could be seen as a disclaimer. Many GNU and CC licences require you to include certain types of disclaimers with all copies of the work. For example, according to CC-BY-SA 3.0: You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. We rejected GFDL because the requirement to include a copy of the licence with every copy of a file is too restrictive, and then it's bad if people can circumvent this by providing a huge disclaimer of warranties which all reusers have to include a copy of. It is my understanding that a disclaimer has to be quoted verbatim (keep intact). In other words, it can't be translated, and if the licensor provides the disclaimer in multiple languages (in this case English and German), you may have to provide a copy of all language versions of the text. I think that we need to restrict the use of disclaimers. --Stefan2 (talk) 11:23, 25 May 2020 (UTC)
  • I think some of my concerns with custom licences have been voiced by others above. I have no problems with very very basic licences such as {{PD-self}}, {{Copyrighted free use}} and {{Attribution}}. But the ShareAlike ones are the ones I have huge problems with as some of them are contrary maybe not to the letter of policy, but definitely to the spirit of this project. And the flaws in the language of these tags are also problematic, as Stefan2 mentions above. I would in favour of a ban on custom ShareAlike tags / licences, and ones that are clearly more restrictive than CC-BY-SA-4.0. I would also be in favour of community involvement and approval for any custom licences--custom CC tags, namely the OTRS created tags that are a CC licence summary + OTRS permission should be exempted. --Ìch heiss Nat ùn ìch redd e wenig Elsässisch!Talk to me in EN, FR, PL, GSW-FR(ALS). 19:27, 25 May 2020 (UTC)
  • I agree with User:El Grafo about banning all custom licenses in the future, where custom license is defined as some license written by individual user or group of users for their works. Customized clarification of existing license, like CC license + OTRS template or CC license + attribution text is OK, but elaborate custom templates with additional explanations or translations are not. No additional restrictions on top of base license, for example CC-by for noncommercial works and contact me for commercial permission (Thar is not allowed already but I am not sure if it is spelled out anywhere). I would go as far as having different set of available licenses for "own works" (uploaded directly to commons or indirectly through flickr or some other website). I would vote for phasing out {{PD-self}} in favor of {{CC-zero}}; {{Attribution}} in favor of CC-BY licenses, and no {{Copyrighted free use}} for own works. So for Own works first published after some data we would have a whitelist of few dozen licenses. Transfer of older files from wikipedia or flickr would be OK under the old rules. --Jarekt (talk) 02:35, 26 May 2020 (UTC)
  • I generally do not like the idea of outright banning free licenses. Our project scope and mandate is to allow files which are free by the definition at freedomdefined.org . That does include custom licenses. It is very common for sites out there (say government sites) to have a rights statement that is effectively a free license -- I feel this will be used as an excuse to delete such works. I do agree that any custom license tag should go through a community review before being allowed, and I do agree that Commons users coming up with their own licenses is also often problematic, so there should be some sort of review process for them. But an outright ban I think is contrary to the project scope, which is deeper than just policy. The GFDL was on the edge I thought, as those are technically free but people were using the terms against the spirit of free licenses. Banning anything further I disagree with; it feels like we are now going down the slippery slope to only allowing CC licenses for administrative sake, rather than serving the user base. However, there should be a way to point to a community discussion on a license, and to mark any license tag (perhaps using the 10 person criteria mentioned below), with possible deletion pending the outcome. Maybe even just a special type of DR with an additional notice being posted to Village Pump/Copyright. Carl Lindberg (talk) 14:31, 9 June 2020 (UTC)

Draft[edit]

Here's my first attempt to codify it:

Custom licenses are licenses created by Wikimedia users for their own works. Because they have not undergone strict scrutiny and legal review, they present a risk to reusers and hence are considered deprecated. No work may be uploaded to Wikimedia Commons on or after 1 July 2020 under a license whose text exists only on a wiki or other user-editable site, unless the license is used on works by at least 10 unique authors as of 30 June 2020. (The purpose of the latter provision is to grandfather in long-standing license templates such as {{PD-self}}, which continue to be permitted despite the existence of more favored licenses such as {{Cc-zero}}.)

Thoughts? -- King of ♥ 16:59, 7 June 2020 (UTC)

Maybe add something like "exceptions can be made with community consensus" to prevent later discussions on changes for adding of more templates like the PD-self example? --GPSLeo (talk) 22:52, 7 June 2020 (UTC)
Another gray area is credit tags vs actual licenses. A note stating that they are only licensing the uploaded resolution, i.e. they do not intend to license expression at a higher resolution if the photo is found elsewhere, is fine -- that is not a license, but rather simply identifying the expression being licensed. A *request* to be contacted etc. is also fine. It's when the wording gets into restrictions on what the user can do, that it can be a problem. Such credit-type tags can also start out fine, then be edited into the more dubious areas, as well. Carl Lindberg (talk) 14:38, 9 June 2020 (UTC)
I disagree that such a resolution-restriction note is not a problem. If using a licence like CC the licence applies to "the work of copyright" and it is up to legal experts to determine if another copy of the file at a different resolution is "the same work". CC forbids users from adding further restrictions to their licences. CC is not a file-based licence, and CC and WMF have already clarified this. -- Colin (talk) 10:09, 10 June 2020 (UTC)

Draft 2[edit]

I took into account GPSLeo's suggestion, and added custom restrictions to the mix per Clindberg and Commons:Village pump/Copyright#Licences restricted to a certain resolution, but higher resolution uploaded. I also tweaked the wiki part because not all wikis are user-editable, and such licenses are permitted (e.g. wmf:Wikimedia 3D file patent license).

Custom licenses are licenses created by Wikimedia users for their own works. Because they have not undergone strict scrutiny and legal review, they present a risk to reusers and hence are considered deprecated. No work may be uploaded to Wikimedia Commons on or after 1 July 2020 solely under a license whose text exists only on Wikimedia Commons or other user-editable site, unless the license is used on works by at least 10 unique authors as of 30 June 2020. (The purpose of the latter provision is to grandfather in long-standing license templates such as {{PD-self}}, which continue to be permitted despite the existence of more favored licenses such as {{Cc-zero}}.) Furthermore, uploaders may not impose additional mandatory terms or restrictions upon otherwise permissible licenses, unless the license explicitly allows such terms to be imposed (such as specifying the manner of attribution for a CC-BY license). Exceptions to allow or disallow specific licenses can be made with community consensus.

@Mattbuck, Ww2censor, , Jarekt: Pinging users at the other discussion. -- King of ♥ 18:22, 9 June 2020 (UTC)

  • This sounds good. I wonder if we could also allow removal of any custom license "clarifications" even if it not contradicting the license. I find them confusing as each should be studied to verify that they do not contradict the license. Also should we do anything about double licensing like {{FAL}} (which few people understand) and CC-BY-NC (which is easier to understand). I would like to no longer see any double-licenses with CC-BY-NC or CC-BY-ND. --Jarekt (talk) 18:57, 9 June 2020 (UTC)
    I think both those points are tangential to the discussion here, which is to ban a certain type of license from qualifying a file as appropriately licensed; your points are both cosmetic details which affect only the file description page, not the copyright status of the file. If those "clarifications" are non-material, then other users can remove them without permission of the copyright holder. Likewise, if we don't even want to display non-permitted licenses at all, then we can just edit them out, leaving only the permitted one (by the way I am not in favor of this). But neither of those affects the conditions under which we accept a file as appropriately licensed. -- King of ♥ 19:03, 9 June 2020 (UTC)
  • I'm not that keen on either draft. What's a "user-editable site"? I can create a website for $10 and publish a licence definition. Have we established if custom non-SA licences are a problem we need to solve? Which ones would we not permit now? I think the case is strong for banning ShareAlike licences that are not legally compatible with existing major SA licences (CC compatibility) or have not themselves already achieved a high degree of acceptance worldwide. A licence that says "You can reuse this but only if your JPG is no larger than an unspecified JPG on a website that is user-editable by anyone at any time" is not "free". Can we have a draft that just bans novel ShareAlike licences without community review.
We don't need to ban extra terms on licences: they are already banned by the licences. I think "Exceptions to allow or disallow specific licenses can be made with community consensus." is not necessary or useful or accurate. For example, we are not permitted, as a community, to just decide to accept NC licences or to start accepting Fair Use material. -- Colin (talk) 10:24, 10 June 2020 (UTC)
  • The premise seems reasonable to me. Some clarification may be in order, but generally a good idea. -mattbuck (Talk) 11:25, 10 June 2020 (UTC)
  • The term “custom” bothers me somehow. Perhaps we should define a “custom” licence as any licence not covered by a licence template. That seems to correspond to the normal meaning of the word “custom”; it also seems to be the best way to address the first major problem listed at the very top of this section (legal uncertainty). Brianjd (talk) 11:37, 10 June 2020 (UTC)

Draft 3[edit]

Colin had some good points. Unfortunately, perhaps "custom" is just too hard to define. However, when share-alike restrictions are involved we can afford to be more aggressive. Even if a share-alike license is published by an official organization and used by a few people (e.g. {{DSL}}), it's still pretty useless for new works. Let me propose a less ambitious version (much of it adapted from the GFDL ban):

Copyleft, or share-alike, is a feature which requires persons who wish to make a modified version of a work to release their modifications under a compatible free license. However, copyleft provisions work effectively in practice only if there is a large ecosystem of compatibly licensed content with which a work can be remixed. However, a work with share-alike restrictions is free in practice only if there is a large ecosystem of compatibly licensed content with which it can be remixed. Therefore, a share-alike license is not permitted as the only acceptable license where all of the following are true:

  1. The content was licensed on or after 1 July 2020. The licensing date is considered, not the creation or upload date.
  2. The license is not compatible with any version of a Creative Commons license or any version of the Free Art License.
  3. The content is primarily a photograph, painting, drawing, audio or video.
  4. The content is not a derivative work of copyleft software.

I think the "community review" part (re Colin) doesn't need to be included, as any community review that blesses a copyleft license would simply allow point 2 to be amended. -- King of ♥ 01:47, 23 June 2020 (UTC)

  • I propose two slight tweaks to the wording:
    1. not permitted as the only acceptable license” seems to leave a loophole, where two licences, both of which meet the criteria above, are applied to a work, without any other licences being applied. The proposal should be reworded somehow to fix this.
    2. The word “acceptable” does not seem right. Note my use of the word “apply” in the previous item.
Regarding the proposal as a whole, I have a couple of comments:
  1. I hate copyleft, basically for the same reasons you cited in your proposal. So anything that restricts the use of copyleft licences is probably a good thing.
  2. Regarding the licensing date vs creation/upload date, I guess that makes sense for files already on Commons before 1 July 2020, but what about files licensed before 1 July 2020 and uploaded to Commons on or after 1 July 2020? I think those should be banned too, if they meet the other criteria.
Brianjd (talk) 04:59, 23 June 2020 (UTC)
I lifted the wording for both straight from Commons:Licensing#GNU Free Documentation License. I don't see a loophole, because both of them would be unacceptable licenses. The existing GFDL rule clearly implies that, for example, you can't dual-license your works under only GFDL + CC-BY-NC. (Getting on a philosophical tangent) I strongly support copyleft when applied to software, because with software there is a significant risk that a private company could make an improved proprietary version of free software that cannibalizes the original. Likewise, copyleft on Wikipedia text ensures that no one can fork it to make their own proprietary version. Unlike the previous two cases, media is by nature far less collaborative so it's not as necessary, but when CC has a 90%+ market share it doesn't really matter too much so I'm fairly neutral on CC-BY vs CC-BY-SA for images. -- King of ♥ 06:44, 23 June 2020 (UTC)
This sounds good to me, in general and I would be OK with small wording improvements if anybody finds better or clearer way of expressing the same concept. --Jarekt (talk) 03:36, 28 June 2020 (UTC)
I just noticed that the wording of the second sentence wasn't ideal (implying that the share-alike restriction isn't effective, when we really want to say is that the share-alike makes the work effectively non-free). I've made a slight tweak to that effect. As this is merely expository material there is no change to the meat of the proposal. -- King of ♥ 04:22, 28 June 2020 (UTC)
  • Thanks @King of Hearts: for the ping. I totally agree that we should avoid licenses that makes it hard to reuse files. But Commons is where all free files from wiki projects should be uploaded so I agree with Brianjd that the upload date should perhaps be changed to a license date. Otherwise we risk that files on xx.wikipedia can't be moved to Commons.
Speaking of wiki projects I think that we should make a general notice to all wikipedias about the change of licenses. Many wikipedias do not have users that know or care much about copyright. So a general notice with a suggestion that the wiki do not accept files with the bad licenses from now on and with a link to a page explaining the problem. I'm not sure every wiki knows that GFDL has been banned. Anyone here know how to make such a global letter?
If wikis should have a chance to comment and not just get a notice about it perhaps the date should be August instead. --MGA73 (talk) 08:19, 28 June 2020 (UTC)
Actually, "the upload date should perhaps be changed to a license date" - you are agreeing with my original wording, and disagreeing with Brianjd. Almost no one uses share-alike licenses apart from CC/FAL (and even FAL is a small minority), so I don't think the specific cutoff date / notification matters too much because in practice it only affects a few contributors who intentionally use a weird license like {{Resolution restricted-by-sa}} at the moment. Remember that there are even some people (a significant minority) who are arguing we should retroactively delete files already under that license. -- King of ♥ 16:32, 28 June 2020 (UTC)
Huh? Okay I may have read something wrong. So just to be a little more clear:
GFDL is an example of a bad license but starting a mass deletion af GFDL files would be too much I think. If anyone have used a valid license I think the situation is the same. That is why I think we should give wikis a chance to stop using whatever licenses they use. But I also think we should advice them to stop using any non-standard licenses.
But what I would agree to delete is files if the license was never really valid. The discussions started with {{Resolution restricted-by-sa}} that have terms that are unclear. I might vote keep on those files but if we have any licenses that are worse then I would probably vote delete to the files.
As for the suggested text it looks fine to me (I'm not a native English speaker). However if we want to limit the use and make it easier to check we could say the file should be uploaded to any wiki project before <some date>.
Question: File A is uploaded to Commons with a soon to be bad license. Then I use file A and make some changes and upload it as file B with the same bad license. Would that be acceptable or not with the suggested ban? --MGA73 (talk) 22:26, 28 June 2020 (UTC)
We wouldn't require wikis to stop uses any existing media under a soon to be bad license; any media available under such licenses before 1 July 2020 are grandfathered in, and it would not be a violation of this proposed policy to use existing images (i.e. add them to articles) after the cutoff date. All that changes is that you can no longer upload new photos under such licenses. In practice this is a very rare phenomenon, done only by people who have a political objection to our standard licenses, and they are probably aware of this conversation so it won't be a big surprise to them. People at other Wikimedia projects are not going to come across these licenses randomly; they are not mentioned at any of the common places to find licenses (COM:L, Special:Upload, Special:UploadWizard, etc.). If this proposal passes we can go down Category:License tags and tag any unacceptable ones to warn potential uploaders.
I prefer "license date" over "date uploaded to a Wikimedia project". There could be some 1990s files under a weird license that we'll probably want to accept.
For your question, good point. The GFDL ban didn't actually specify either, but I think common sense dictates that we accept such files. Incompatible share-alike works can only be relicensed under the same license, so to include modified versions of grandfathered bad share-alike files in the ban would have the effect of turning the SA provision into an ND provision, which is definitely a step in the wrong direction. -- King of ♥ 23:14, 28 June 2020 (UTC)
  • Though this is my first comment on this proposal, I have been following a bit on this discussion. This draft in general looks okay to me, and a lot better than the first two drafts which suffer from the problem of defining "custom". I would suggest simplifying the photograph, painting, drawing of the third criteria into "static image", then add "animation" to the said criteria to avoid any ambiguity. My suggestion would make it simpler to look at, while still being unambiguous. --pandakekok9 02:06, 29 June 2020 (UTC)
    The reason why we had that line for GFDL is that the GFDL is designed for text documents, and so we continue to accept it in such cases. Note that the GFDL actually falls under our proposed definition of "unusual share-alike license", so we don't want to ban any uses of GFDL which are not already covered by the GFDL ban. It's possible for a text document to consist of a static image. -- King of ♥ 02:46, 29 June 2020 (UTC)
    Yes, it's possible for a text document to consist of a static image, but it doesn't necessarily mean it's primarily a static image (i.e. a PDF file containing only one page where a majority of the content is a static image, or a PDF consisting only of slides, without or almost without any text). I think my suggestion actually closed a loophole (kinda), since "static image" includes screenshots. Someone who didn't like the GFDL-only ban could publish their GFDL photographs on another website, make a collage of it, and screenshot it. They would then upload the screenshot to Commons with the GFDL as the only license. If someone nominates their upload for deletion, they would just argue that their file is not a photograph, painting, or drawing, but a screenshot of a collage of GFDL photos. Of course they violated the spirit of the policy, but I think technically they would be correct. pandakekok9 02:41, 30 June 2020 (UTC)
    We don't need to account for every possible loophole. This is a policy issue, not a legal issue, so at DR the argument "goes against the spirit of COM:L" is very much valid. In your specific case, it's either just a collage (so they can't argue it's a screenshot even if that's how it was made), or it's a screenshot and does not fall within COM:SCOPE, and the action required to bring the image in scope (namely, cropping it) would cause it to fall under the ban. -- King of ♥ 02:55, 30 June 2020 (UTC)
  • Pictogram voting comment.svg Comment The problem with this proposal is that different people seem to be talking about slightly different things: The first group wants to make sure that we have a library of freely licenced media and want to ensure that the media that we have is distributed under a free licence; The second group want to make sure that we will not have a library of non-freely licence media and want to ensure that the media is not distributed under a non-free licence. The problem is that sometimes it is difficult to figure out the impact of the policy in regard to these two positions, especially since sometimes they actually oppose one another. I am considering adding an extra NC licence on all of my files in case there is a project out there that is already distributed under a NC licence and they cannot incorporate FAL into it. Of course, if somebody were to beging a new project, I would urge them to chose FAL or in the worst case CC-BY-SA / GFDL, but what if the project has already been ongoing. I am a copyright holder, and I can distribute my work under as many different licences as I want, and they are allowed to be contradictory, a reuser may chose which licence to use. Also I find it completely baffling why we have such anger towards Share-Alike licences here; some people want to take something without contributing, and we have supporting them, but people who want to contribute are made to jump through hoops. Let people contribute under whatever Free Licence they want, and make tools for reusers to find a work that fits with their project. ℺ Gone Postal ( ) 08:00, 2 July 2020 (UTC)
    @Gone Postal: We are not banning uncommon share-alike licenses entirely, or even non-commercial licenses for that matter. You can even put a license saying "You may use this image freely if you belong to the Church of Scientology" if you want. The point is that to be considered truly free, an image must be under at least one acceptable license. Everything else is just icing on the cake. -- King of ♥ 15:17, 2 July 2020 (UTC)
    And there is no such thing as "a library of non-freely licence media". All media by default is "all rights reserved", so even if uploaders don't put an NC or GFDL license on it, all CC media is already multi-licensed under the CC as well as "all rights reserved". -- King of ♥ 15:20, 2 July 2020 (UTC)
    Thanks for pointing out another problem with this discussion, there is a huge confusion about the legal status of works. "All rights reserved" is an old phrase that was used some time in the 20th century, when in some countries to protect one's copyright you had to put such a phrase on your work. It said nothing about the licence. Today there is no such thing (all rights are reserved as soon as you put your work in a tangible medium), but if there were, you would have to put "All rights reserved" in order to distribute your work under CC-BY or GFDL or whatever. Creative Commons attempt to make a play on words, sometimes using "Some rights reserved", but that is not a legal instrument either. In other words you cannot multi-licence as "all rights reserved", just as "I am a sovereign citizen" is not a driving licence. ℺ Gone Postal ( ) 13:17, 3 July 2020 (UTC)
    And I think that my comment is probably unclear. While two first drafts are just trying to find a problem to solve, the third one is disruptive. Not only is it bad, but the opposite of it would be better, something like No user should be allowed to pressure another contributor to change their preferred free licence. Any user who engages in such behaviour should be brough to administrator's attention for a ban.Gone Postal ( ) 13:26, 3 July 2020 (UTC)
    Just to clarify: Do you believe that {{Resolution restricted-by-sa}} (the license that started this whole discussion) should be banned going forward? Why or why not? -- King of ♥ 15:53, 3 July 2020 (UTC)

Rename COM:ANU[edit]

I propose to rename Commons:Administrators' noticeboard/User problems to Commons:Administrators' noticeboard/Problem users because the former is ambiguous: a) problems which normal users (but not admins) have because of the level of access; b) problems related to interaction of users.

User:King of Hearts tried to solve the issue with creating an edit notice (Template:Editnotices/Page/Commons:Administrators' noticeboard/User problems) but the problem seems to persist according to Special:Permalink/421492592#Sandbox got deleted (see the comment by User talk:Pandakekok9). 4nn1l2 (talk) 03:54, 25 May 2020 (UTC)

Yeah, the same here. Though I am near-native in speaking and reading English, when I look at "incidents" without enwiki lens, I don't expect it to be a venue to complain about other users. pandakekok9 04:12, 25 May 2020 (UTC)
  • Commons:Administrators' noticeboard/Incidents would probably result in the same problem. I prefer Commons:Administrators' noticeboard/User disputes. pandakekok9 04:11, 25 May 2020 (UTC)
  • I have always thought of this as a difference between w:WP:NPOV and COM:NPOV. Commons doesn't require a neutral point of view, so the title is based on a non-neutral POV (there's a problem with the user with whom you are in conflict). On the other hand, Wikipedia takes a more neutral stance and refers to it as an 'incident' instead. --Stefan2 (talk) 11:29, 25 May 2020 (UTC)
  • Not "problem users" please. Not everyone who gets reported there, is a problem user. --A.Savin 18:11, 25 May 2020 (UTC)
  • None of the alternates appear better than the current. User disputes would be wrong as issues like user naming or language issues are reported with no dispute, and as has been explained "problem users" implies bad users too. Though there's already a help desk, VP, VP/T, VP/C as well as more specific AN boards, so there no obvious need for extra boards either. -- (talk) 18:19, 25 May 2020 (UTC)
Er, isn't COM:AN/U supposed to be a place only for disputes with other users? From {{Administrators' noticeboard}}: Report disputes with users that require administrator assistance. Further steps are listed at resolve disputes. The reason why this proposal was made is because we are receiving threads that are out of the scope of COM:AN/U. User naming can be reported to COM:AN/B, per COM:IU: Usernames that are obviously inappropriate may be blocked on sight by any administrator and may be reported at Commons:Administrators' noticeboard/Blocks and protections. I'm not sure what you mean by "language issues" though. pandakekok9 02:27, 26 May 2020 (UTC)
No, the text reads "You can report vandalism, problematic users, or anything else that needs an administrator's intervention." So the noticeboard is a place you can go to with any account problems, potentially with no history of disputes. This can include questions about things like adding archiving to a retired user's template breaking talk page, or a user might ask things about their own account like whether their signature text is allowed, or to remove/amend some of their user groups outside of the right application pages which normally only add these groups. Language issues was meant to include confusion about what words in different languages mean and whether this is worth taking further, like whether a user doing mass renaming is doing something against policy or not; again this need not have a history of dispute. -- (talk) 10:08, 27 May 2020 (UTC)
It seems clear to me that the text quoted by @ applies to AN as a whole, while AN/U has a more limited scope. However:
  • It might not be so clear to someone for whom English is not their native language.
  • The notice is confusing overall, as covered by some of the comments below.
Brianjd (talk) 11:44, 10 June 2020 (UTC)
  • Symbol support vote.svg Support rename to Commons:Administrators' noticeboard/User disputes; the description for the board already uses that very same language. – BMacZero (🗩) 18:49, 26 May 2020 (UTC)
  • I think there is a bit more clarification needed at the admin noticeboards. I always do not know if I should use Commons:Administrators' noticeboard/Vandalism or Commons:Administrators' noticeboard/Blocks and protections, because nearly every page protection or user and IP block is due to vandalism. If it is not it is a topic for the Commons:Administrators' noticeboard/User problems. --GPSLeo (talk) 08:30, 27 May 2020 (UTC)
    Maybe a flowchart on a help page might work well, so users can more easily navigate to an appropriate board. Being confused about which is best is not a big issue, as new threads are often moved by others to a more appropriate noticeboard if need be, and frequently there are issues that could be on several different boards, including things that start at AN but end up at VP because they are of wider interest and not needing specific sysop action. -- (talk) 10:20, 27 May 2020 (UTC)
  • Pictogram voting comment.svg Comment Disputes with users? What other kind of dispute is there? Why don’t we just say “disputes”? Brianjd (talk) 11:48, 10 June 2020 (UTC)
Because there are "content disputes", which should be dealt with at the affected file/page's talk, and for those that need wider community discussion: COM:VP, COM:VPP, or COM:RFC. pandakekok9 10:52, 19 June 2020 (UTC)

Create a Commons equivalent of Project:Embassy (Q1197883)[edit]

Last year I suggested to close inactive, unattended versions of Village Pumps in other languages: Commons:Village_pump/Proposals/Archive/2019/06#Close_inactive_non-English_village_pumps. So many users vow to keep them, but still no actual measures were taken to improve answering requests for help.

Today I saw someone referring ppl to the Turkish VP. 🤣 Come on it's long deserted!

The better solution would be to notify a Turkish user to help, so the Embassy comes to mind. Surprisingly, there isn't one yet?! There's only a Commons:List_of_administrators_by_language?

Therefore, I suggest a list should be set up and users can sign up to volunteer for any languages. Maybe a bot can be devised to keep the list up to date by removing inactive (>1 year?) volunteers from time to time. (But some most common languages, such as English, might not need a list.) Then when ppl see foreign languages they cant help with, they can invite a user from the Embassy to attend to the newbies.--Roy17 (talk) 01:26, 27 May 2020 (UTC)

  • Symbol support vote.svg Support Good practical proposal. As a side note, Wikipedia finally got unblocked in Turkey a few months ago, so I expect a more natural flow of Turkish users on Commons too. User:E4024 may help ppl with regard to Turkish language. 4nn1l2 (talk) 02:45, 27 May 2020 (UTC)
  • Symbol support vote.svg Support · Good idea. -- CptViraj (📧) 04:00, 27 May 2020 (UTC)
  • Symbol support vote.svg Support Huh, I thought we already have some kind of embassy. We're a multilingual project after all. If this proposal passes, I would immediately volunteer in a "Tagalog Embassy". :) --pandakekok9 05:07, 27 May 2020 (UTC)
  • GA candidate.svg Weak support Though COM:LP states that Commons is multilingual, there is no doubt that English is the most frequently-used language on Commons. Meanwhile, language-specific Village Pumps are seriously inactive, so the main language of such discussion board should be limited to non-English language.廣九直通車 (talk) 06:13, 27 May 2020 (UTC)
    • Also if such discussion board is established, other equivalents (such as Commons:Café for Spanish) should probably then be deleted for simplicity and central archival?廣九直通車 (talk) 06:12, 27 May 2020 (UTC)

I would like to clarify that, my proposal is to maintain a list of active users who can help with each language, so that users can find one fluent speaker to answer questions on demand. The proposal is NOT to replace the various VPs, regardless of their activity. For example, the Turkish request was special:permalink/421939064#Telif_Hakki. If the proposed list had been set up, the first responder could have invited a user straightaway, rather than pled for help (which could only be picked up by a Turkish user by chance) and eventually sent the user to the unhelpful, deserted Turkish VP.--Roy17 (talk) 11:51, 27 May 2020 (UTC)

  • Thanks for clarification, if such discussion board is established, I will be happy to assist with Chinese responses.廣九直通車 (talk) 13:43, 28 May 2020 (UTC)
  • Symbol support vote.svg Support, such a list will be opt-in and the people will be willing to help, we're all volunteers here so it makes sense. Although it might be wise to have a number of volunteers look at the activity of the listed users so it won't contain inactive (or retired) users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:33, 27 May 2020 (UTC)
  • Symbol support vote.svg Support fully agree with Roy17. Face-smile.svg Lotje (talk) 14:02, 28 May 2020 (UTC)
  • Symbol support vote.svg Support Good idea. Lymantria (talk) 15:59, 30 May 2020 (UTC)
  • Symbol support vote.svg Support If I need help in some language I check Commons:List_of_administrators_by_language for familiar names, but by all means great many users who are not admins can volunteer to be a contact people in some language. There are two types of issues which are language specific: some non-English speaker needs help or guidance or English speaker needs help with translation to or from some language. Some people might be more comfortable in one role but not the other, for example I am not very good at translating technical terms to Polish, despite of being a native speaker, since all my technical interaction are in English. Perhaps a per language list of volunteers can specify what they are comfortable to help with. --Jarekt (talk) 18:25, 1 June 2020 (UTC)
  • Symbol strong support vote.svg Strong support, in fact, looking for an answer to a specific question, I went to Commons:井戸端 where Omotecho was so kind as to look into it very accurately :-) Lotje (talk) 09:59, 3 June 2020 (UTC)
  • Symbol support vote.svg Support Well, thank you Lotje, it was very lucky coincidence that I am keen on woodblock prints and the particular image had a jawiki article to put onto. Not quite frequenting ja/village pump myself, however, it is often advised to double-post inquiry to en/VP there, as posters did not find help pages translated into ja, when ja community is underpopulated esp with ppl comfortable to handle topics as Merge/split request. Regarding self-help, I guess we’d better start a translation drive on high demand topic for linguistic inclusiveness/diversity. If we think of monthly translation drive, six pages to go. I started with en-ja translation on Merge&split pages, and it’s up now. Who’s next putting c:Commons:History merging and splitting into your language? (: --Omotecho (talk) 10:02, 5 June 2020 (UTC)
  • Symbol support vote.svg Support // Eatcha (talk) 14:17, 5 June 2020 (UTC)
  • Symbol support vote.svg Support Christian Ferrer (talk) 18:11, 5 June 2020 (UTC)
  • Symbol support vote.svg Support --✝iѵɛɳ२२४०†ลℓк †๏ мэ 11:46, 10 June 2020 (UTC)

Proposal: Allow bureaucrats to remove administrator permission[edit]

Currently Commons bureaucrats can grant but cannot remove sysop permission. I believe Commons community is large enough and we have enough active bureaucrats to handle desysops locally. This will make desysop log store locally instead on Meta. Stewards can still act in case of emergencies if no local crat is online. Note that this proposal does not support crats removing sysop in cases other than uncontroversial procedure (inactivity removals, RfDA, in case of emergency). -- CptViraj (talk) 06:02, 30 May 2020 (UTC) Fixed per Pandakekok9. CptViraj (talk) 06:24, 30 May 2020 (UTC)

Discussion[edit]

  • Symbol support vote.svg Support as the proposer. -- CptViraj (talk) 06:02, 30 May 2020 (UTC)
  • Symbol support vote.svg Support Long overdue! 4nn1l2 (talk) 06:11, 30 May 2020 (UTC)
  • Symbol support vote.svg Support About time. And just for clarity, can a local crat still emergency desysop a rogue admin even without the inactivity or RfDA procedures? pandakekok9 06:14, 30 May 2020 (UTC)
    Yep, fixed. Thanks :) -- CptViraj (talk) 06:24, 30 May 2020 (UTC)
  • Symbol strong support vote.svg Strong support Revoking sysop permissions by bureaucrat here and not by a steward is faster (and I'm Symbol keep vote.svg agreed about it), but how about with revoking bureaucrat permissions by bureaucrat? Nieuwsgierige Gebruiker OverlegCA 06:46, 30 May 2020 (UTC)
    "Allowing bureaucrats to remove bureaucrat right" is prohibited by system administrators, see m:Limits to configuration changes. -- CptViraj (talk) 07:05, 30 May 2020 (UTC)
  • Symbol support vote.svg Support - Bureaucrats close such requests, and the removal of administrative rights by stewards usually needs a successful de-RfA closure by a bureaucrat. So, if they should first close the request (their closure is somehow "official"), why shouldn't they remove the right as well? Ahmadtalk 07:34, 30 May 2020 (UTC)
  • Symbol support vote.svg Support for 'procedural' rights removals. Emergency actions would need a more detailed proposal and agreed policy, especially if the removal decision is based on any non-public data of any kind. As a procedural corollary, though removing the 'crat group has a systems issue, by default if a 'crat removes another 'crats sysop rights, the desysoped 'crat is by existing policy automatically no longer a functioning 'crat, even if technically the flag is still there. -- (talk) 12:32, 30 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose If bureaucrats can't be trusted to return sysop rights after 24 hours, they shouldn't be able to do this. Also, the bureaucrat team has 7 members, but one or two are active in that role. So no, you won't get a "faster" response. 1989 (talk) 14:35, 30 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose With the level of infighting that Commons has had lately - this is a very bad idea to remove stewards from the picture. --Rschen7754 15:53, 30 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose Per Rschen7754. Lymantria (talk) 16:00, 30 May 2020 (UTC)
  • BA candidate.svg Weak oppose, per Limits to configuration changes, this will only be done if there is both multiple active bureaucrats, and a demonstrated need. Given the only real reason for bureaucrats being able to remove the bit is speed, and we only have 7 bureaucrats, I'm not sure we meet these criteria. ~~ Alex Noble/1-2/TRB 16:39, 30 May 2020 (UTC)
  • Symbol support vote.svg Support - Seems natural. I have high trust in our local bureaucrats and it strengthens the local community. --Schlurcher (talk) 07:54, 31 May 2020 (UTC)
Thanks. Please elaborate how this is relevant here? --Schlurcher (talk) 08:32, 31 May 2020 (UTC)
Though I wasn't here when Russavia was WMF banned in 2015, as far as I read the archives, he seem to had been a good bureaucrat. The only reason he resigned was because of the controversy of hiring Picasso to make a painting of Jimbo. He didn't abuse his tools nor made a bad judgement on a significant issue on Commons AFAIK. He did committed sockpuppetry though, but that's because he suddenly got banned by the WMF without warning. We still don't know what got him banned. I only had a few interactions with him via IRC, and that was only about helping with translating stuff to Tagalog. He seemed like a nice guy, too bad I wasn't able to know him much before he got banned.
But as Schlurcher said above, I don't see how Russavia is relevant in a proposal about granting crats the ability to remove admins. That was a 3 years or 2 years ago problem (the last I saw him sock was in 2017 or 2018 I think). If you think we shouldn't trust the bureaucrats just because of one former member who long resigned like 6 years ago, that ain't fair to other bureaucrats who had done their community role well for years. Russavia only served for like 2 years as a crat. The rest of the crat team served and still serves longer than that. pandakekok9 09:44, 31 May 2020 (UTC)
Bad cases make bad law. If any oppose votes here are because of what happened with one rogue account many years ago, where there never was any misuse of bureaucrat status or sysop tools, then that's very bizarre.
All current 'crats are demonstrably trustworthy, the only criticism is that there aren't many active 'crats. Hardly a reason to reject this proposal. -- (talk) 10:17, 31 May 2020 (UTC)
the only criticism is that there aren't many active 'crats. Hardly a reason to reject this proposal. Er, that's actually a reason why such change won't be implemented by the sysadmins, see m:Limits to configuration changes#Changes that are likely to be declined. We do want some more active crats, but I think we have enough to prevent any crat abuse. pandakekok9 10:23, 31 May 2020 (UTC)
  • Pictogram voting comment.svg Comment You'll sometimes say stewards are allowed to remove bureaucrat permission or maybe kick someone out... --Red-back spider (talk) 10:00, 31 May 2020 (UTC)
  • Symbol support vote.svg Support Granting and removing rights should ever be possible by the same users. If there are doubts that this could take to long we should look for some of the very active admins becoming promoted. --GPSLeo (talk) 10:01, 31 May 2020 (UTC)
  • Symbol support vote.svg Support Anyone who has the technical right to grant a sysop should have the same right to remove it following a clear consensus. Regards. T CellsTalk 19:02, 31 May 2020 (UTC)
  • Symbol support vote.svg Support, Wikimedia Commons is large enough to stand on its own feet. Bureaucrats are highly trusted users and while I don't always agree with some individual decisions of some permission holders, the removal of the sysop flag can only be done with the support of a sizable number of community members, so there is not much of a chance that this will be abused. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:59, 31 May 2020 (UTC)
  • Symbol support vote.svg Support Bureaucrats on Commons are trustworthy and they have adequate knowledge on doing this. --A1Cafel (talk) 09:13, 3 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose Per Rschen7754. Trijnsteltalk 20:15, 4 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose Per Rschen7754. -- Geagea (talk) 05:47, 10 June 2020 (UTC)
  • Symbol support vote.svg Support Of course. Regards, ZI Jony (Talk) 08:24, 14 June 2020 (UTC)
  • Symbol support vote.svg Support This is a common feature of what it means to be a bureaucrat and it also means that this project can be self-policing. —Justin (koavf)TCM 01:43, 21 June 2020 (UTC)

Turn MOTD into MOTW[edit]

Since Commons cannot churn out one featured video (FV) a day, I suggest to turn Media of the Day (MOTD) into Media of the Week (MOTW). The current problem is that some MOTDs are of low quality not becoming of the Main Page. Even we can't write English captions for all of our MOTDs. The solution is to focus on quality rather than quantity. Each week we can show high-quality featured videos with captions in English and hopefully many other languages.

See also Commons:Administrators'_noticeboard#nudity_on_front_page. 4nn1l2 (talk) 08:33, 1 June 2020 (UTC)

  • Symbol support vote.svg Support as the proposer. 4nn1l2 (talk) 08:33, 1 June 2020 (UTC)
  • Pictogram voting comment.svg Comment We actually have a lot of quality video or audio content here. — Racconish💬 09:36, 1 June 2020 (UTC)
  • Pictogram voting comment.svg Comment The main page gets around 125 thousand views in a day, in comparison en.wp's main page gets 5.5 million. It asks a lot of the small community to maintain and select the content on a daily basis and give it all a meaningful review or vote (thereby avoiding manipulation by disposable sock accounts), so moving MOTD to a weekly cycle makes a lot of sense. Thoughts from those active in maintaining the main page should carry significant weight in this consensus. -- (talk) 09:40, 1 June 2020 (UTC)
Amended to comment, based on Racconish's objection. -- (talk) 13:36, 1 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose strongly. motd need not be featured videos. there are certainly more than 365 high quality, free videos that are produced in the world or expire into pd each year.--Roy17 (talk) 09:53, 1 June 2020 (UTC)
    Commons may have enough content (I have my doubts), but certainly does not have the manpower to present them all in a neat way. Just in the previous month four MOTDs went to the Main Page without English captions. Although they had French captions, English captions can be read by many more people. See Template:Motd/2020-05. 4nn1l2 (talk) 10:11, 1 June 2020 (UTC)
    I had seen that but I was not sure what the consensus was and I was concerned to avoid antagonising the uploader. Have added English captions to his June MOTDs. — Racconish💬 10:38, 1 June 2020 (UTC)
  • Further comment. I am a little concerned about giving too much importance to technical considerations as opposed to historical, documentary or merely educational value. We do have a handful of contributors who do use the venue to show some of their own productions which might not always meet EV criteria, but I think we should be very careful in establishing formal criteria, if there is a consensus to go that way, in order to preserve the highlight on diversity. — Racconish💬 10:05, 1 June 2020 (UTC)
  • Symbol support vote.svg Support in principle. We theoretically have enough high-quality media to feature one a day, yes, but in practice we do not have enough volunteers to curate it on a daily basis. I agree with some reduction in frequency, but 7x might be a bit drastic. One every 2-3 days would be the sweet spot, but I'm not sure how to name such a thing. -- King of ♥ 15:37, 1 June 2020 (UTC)
    Alternative suggestion: We currently are promoting FPs at a rate of 2-3/day, so most of them will never have their time in the spotlight. Since "media" technically includes images, perhaps we can alternate between days with an FP in MOTD (i.e. running two FPs at once) and days with a video/sound/other in MOTD? -- King of ♥ 15:44, 1 June 2020 (UTC)
Another suggestion: let's take a real recent situation, {{Motd/2020-02}} + {{Motd/2020-03}} and look at it carefully. I see no void there, therefore no evidence the daily rythm is problematic. But I am sure we can evidentiate some problematic nominations or template issues (not in English, without wikilinks, etc.), and then try to avoid these problems by stating some guidelines for nominators. In an nutshell, I think what we might need are simple guidelines. — Racconish💬 17:05, 1 June 2020 (UTC)
  • Symbol neutral vote.svg Neutral I If we have enough volunteers to curate MOTD for each day, than by all means lets do it, but I am also fine with reducing the frequency or allowing FP to be included in MOTD. --Jarekt (talk) 18:05, 1 June 2020 (UTC)
I dont get any of the arguments here.
1. not enough FV
no, motd dont need to be FV. many videos or audio files are not selected for the little known FV—I never give a damn and I'm sure many ppl dont care either—but that doesnt mean they are low quality.
2. no english caption
captions need not be english. I dont care if it's french czech or polish. none of them are my native. very rarely would i see a caption in my native, and even if someone wrote it i wouldnt find it coz i use the english UI. Commons doesnt prefer any language. I dont care much about the captions either. it's motd not caption of the day. i can enjoy a video even if nobody summarises it. if i find it interesting but not understand the language i could find out more by looking at its source.
3. not enough volunteers
that's factually wrong. I know for a fact that there are always czech polish and Erzya users adding captions timely for the past one year. what you are complaining is that sometimes the english caption is not added in time, or that you dont like the video/audio file chosen.
Solution for your actual problem: Take it upon yourself. Add the caption yourself. Select videos you like yourself. Challenge the ones you dont like on VP yourself.
this proposal is gonna cut the number down from 365 to 52. that's ABSOLUTELY NO.--Roy17 (talk) 00:08, 2 June 2020 (UTC)
if you really have trouble finding nice vids, go to these cats. there are plenty and they will never run out.
  1. Category:Films in the public domain
  2. Category:Music videos
  3. Category:PD US Government especially Category:PD US Military and Category:PD VOA, which has not just english-language and american vids but vids in many languages covering all sorts of topics around the world.--Roy17 (talk) 00:33, 2 June 2020 (UTC)
365 motd a year is not too much but actually not enough. if the world is divided into subnational first-level units, there're several hundred (50 states of US, regions/provinces of france/germany/spain/china/india etc.). each region can only have motd less than once a year. if every 10 million ppl (roughly the population of sweden/belgium/cuba/jordan/UAE) were to have one motd, then the queue would be two years.--Roy17 (talk) 11:28, 2 June 2020 (UTC)
  • Pictogram voting comment.svg Comment A weaker proposal: How about making FP sets eligible for MOTD? They were featured as a set for a reason, because they work better together than individually. As such, they don't really belong in POTD: either you include everything and it's not really a "Picture (singular) of the day" or you have to choose one of them, diminishing the value of the set. A set is effectively an interactive slideshow, which is more appropriate for MOTD than POTD IMO. The word "media" has the nice property that it can be singular or plural. -- King of ♥ 20:42, 4 June 2020 (UTC)
  • Symbol neutral vote.svg Can't we have both? Media of the Day has 365 (three-hundred-and-sixty-five) different media files, reducing this to 52 (fifty-two) would greatly reduce the diversity of files presented, I know, that's the proposal, it's better to have a few quality files than a lot of lesser quality files, but higher amount of files can better showcase the great range of media files present on Wikimedia Commons. Perhaps the MOTW can be located on the top and we'll move the MOTD to the bottom, where those that check out the main page can still see a different MOTD every day, while the more excellent files would be located front and centre above. Those who are interested enough in Commonswiki to begin with will simply scroll down. Short low quality videos that showcase "science in action" or peculiar animals that currently make it to the main page tickle my interests, so I'm not a fan of removing them, while allowing fot the continued existence of the MOTD will let there be "more winners" thus more people that will look for "maybe not the greatest, but certainly the most interesting and educational" type of videos we have now. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:04, 5 June 2020 (UTC)
    I'm not in favor of having two audiovisual files on the main page when we only have one static picture. Like it or not, the vast majority of our content (featured or otherwise) is pictures, and putting up even more AV media on the main page (417 a year) isn't what we should be aiming for IMO. -- King of ♥ 13:10, 5 June 2020 (UTC)
  • I prefer MOTD over MOTW. --✝iѵɛɳ२२४०†ลℓк †๏ мэ 11:51, 10 June 2020 (UTC)
  • Symbol support vote.svg Support Changing MOTD to MOTW. The current daily release is clearly not working this month and even in the months prior not all of the english captions where filled. Some change is needed, keeping the status-quo is not an option.--Snaevar (talk) 15:23, 4 July 2020 (UTC)
  • Symbol support vote.svg Support And then limit to featured videos. --GPSLeo (talk) 16:06, 4 July 2020 (UTC)
  • Symbol support vote.svg Support I think the week time period will also allow for actual discussion on the media as well. I don't think we necessarily need a requirement to have featured media be a criteria at the moment but that can be considered later. -- Ricky81682 (talk) 19:39, 5 July 2020 (UTC)
    I think what we can do is always favor FV over other videos. So if FVs are getting promoted at a rate of faster than 1/week, then FV will become a de facto requirement. If the rate is less than that, then we can supplement FVs with suitable videos chosen by consensus (which the slower process will allow more time for). -- King of ♥ 05:19, 6 July 2020 (UTC)

Change commons search view from list to Grid view[edit]

Currently Wikimedia commons is displaying search result in list view type. This is not what other popular services are doing.

Check out Google images, Flickr, 500px and Shutterstock (all links search for "plants"). Now search for plants on commons.

In my opinion list type view is not well suited for commons but for search engines like Google/Bing or encyclopedia like Wikipedia. It's not easy to find the image that I am looking for on commons, lists can't display more files than grid view. If you want to compare images you are forced to use the galleries/categories, new users/unregistered are usually unaware of categories / galleries. And you know what, we don't have categories or galleries for every possible search. There's also a lot of text on search results (on commons) which is utterly useless, I'm not criticizing the developers (Sorry, if you think so.) this was implemented a long time ago.

Please use *{{s}} ~~~~ to support or *{{o}} ~~~~ to oppose. Please add reson for oppose or support.

Proposed by User:Eatcha

Votes to change search view type to grid view[edit]

  • Symbol support vote.svg Support Eatcha (talk) 14:16, 5 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose: Hell, no. It’s both ugly and stupid. -- Tuválkin 18:30, 5 June 2020 (UTC)
  • Symbol support vote.svg Support As long as all of the information that's currently available about the item is still available (I use most of it often, and these other services often seem obsessed with showing as little as possible) and the grid is uniform and not irregularly sized (another thing image services like to do that only makes sense if you're showing only the image). On my 1920x1200 monitor search only utilizes a fraction of the screen space, so it would be nice to take advantage of the rest. – BMacZero (🗩) 17:43, 8 June 2020 (UTC)
Symbol oppose vote.svg Oppose Going to have to change my vote because I just saw the likely implementation at Special:MediaSearch and, wouldn't you know it, it fails both of my caveats. – BMacZero (🗩) 17:51, 8 June 2020 (UTC)
Symbol oppose vote.svg Oppose but it's good to have as an option. I use that "useless" text much more often than looking for images, when you are searching for categorization reasons. Carl Lindberg (talk) 05:32, 10 June 2020 (UTC)
  • As long as it clicking on an image at the current implementation of grid view at Special:MediaSearch takes me to the file description page (which is annoying and not how image search on Google works), I oppose making grid view a default option for images, and I strongly oppose it as the default view for all namespaces in case that's what the proposal is about. I might consider supporting it as the default view for images if my concern is solved. Note that I don't oppose making this an option/opt-in. --pandakekok9 06:09, 10 June 2020 (UTC)
  • Symbol neutral vote.svg Neutral/GA candidate.svg Weak support as long as "power users" are given the option of switching to old-style-search through their preferences. If images took a little bit less time loading, I'd totally support it. Strakhov (talk) 22:12, 18 June 2020 (UTC)

Votes to enable grid view as an opt-in or as an optional feature[edit]

Discussion[edit]

  • In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. -- Eatcha (talk) 14:16, 5 June 2020 (UTC)
  • Pictogram voting info.svg Info There is currently a new search system in development using a grid view Special:MediaSearch. --GPSLeo (talk) 14:49, 5 June 2020 (UTC)
  • Pictogram voting comment.svg Comment, this should be optional, discoverability is an issue on Wikimedia Commons, but the current list search, while not perfect, is best for searching for categories, galleries, and templates, as well as various other types of pages, while Wikimedia Commons exists for its media, pages like "{{PD-USGov}}" should be easy to find. Personally I think that we should incorporate more "search features" into the website itself, such as a "view all" option for categories and an option to also add files from sub-categories to this, solutions like these would make searching easier. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:49, 7 June 2020 (UTC)
  • It appears that most users hate Special:MediaSearch beacuse it's not similar to Google's or beacuse we have files other than media(images,videos,sounds) and grid isn't ideal for searching pages/templates. I am adding a new proposal for enabling the prototype as opt-in feature. Thanks for your valuable inputs. -- Eatcha (talk) 08:24, 10 June 2020 (UTC)

Mass requests to GLAM to mirror PD content on Commons as well as on Internet Archive[edit]

The draft message below was one I was one I was considering that appropriate Wikimedia contributors forwarded to GLAM contacts they know, that have contributed public domain material to Internet Archive. The proposal was that this was sent by GLAM contact as a mass request to as many of them as possible ( assuming that they can be identified.)

My apologies in writing to you directly on this,

As you may be aware, certain publishers have decided to take a more "aggressive" stance towards the "Internet Archive". ( https://blog.archive.org/2020/06/01/four-commercial-publishers-filed-a-complaint-about-the-internet-archives-lending-of-digitized-books/ and https://arstechnica.com/tech-policy/2020/06/publishers-sue-internet-archive-over-massive-digital-lending-program/ ). This stance is "disappointing" given the extraordinary circumstances facing many libraries and archives at present, and would hope that you will also be making appropriate representations about this issue.

Whilst it is unlikely, a 'take-down' of the Internet Archive, however temporary would be potentially disruptive, to readers and user alike, that make use of the vast collections of public domain material that the Internet Archive provides access to. It would be useful to have a 'backup' in place.

It is therefore politely but strongly suggest, that in respect of material you have been or are able to confirm as being in the public domain (taking into due consideration copyright terms of other jurisdictions such as Canada and the United Kingdom), you actively consider uploading such public domain material "in parallel" (as well as to the Internet Archive) to other archives and sites that are working to make the public domain accessible to others. One such site being Wikimedia Commons (commons.wikimedia.org). Wikimedia Commons is recomended, because public domain material uploaded to it, can be made use of very quickly on many other Wikimedia sites like Wikipedia (en.wikipedia.org) and Wikisource (en.wikisource.org).

If you were also able to consider other potential projects in relation to Wikimedia sites (see https://outreach.wikimedia.org/wiki/GLAM), if you have not already done so it would be very highly desirable.

It would also be appreciated if you could share this message with colleagues in both your own institution and further afield so that they can also make a decision about uploading content "in parallel".

Let's keep the public domain and knowledge, free and accessible, with a fully supported context for future generations!

ShakespeareFan00 (talk) 15:49, 10 June 2020 (UTC)

  • @ShakespeareFan00: I have changed the heading to make it shorter and, in my opinion, clearer. I like your idea. Brianjd (talk) 07:30, 14 June 2020 (UTC)
  • I know that Commons has some projects to pull material from other sites, but I did a quick search and couldn’t find one for the Internet Archive. There should be one. Brianjd (talk) 07:33, 14 June 2020 (UTC)
    • Unfortunately the ability to import from other websites is largely limited to a handful of websites, mostly Panoramio (now defunct) and Flickr. It would actually be handy to have a tool that could theoretically import from any website and automatically checks websites for their copyright licenses and that certain websites could be "Whitelisted" (as a whitelist would be far more manageable than a a blacklist) and then put all the files up for (human) review. Wikimedia Commons should have been presenting itself as an alternative to the Internet Archive and Flickr Commons among many others years ago. Perhaps this crisis will bring more attention to Wikimedia Commons. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:26, 20 June 2020 (UTC)
    • Good news: It looks like other users are ahead of me (and Donald Trung has already supported that proposal). Brianjd (talk) 06:52, 21 June 2020 (UTC)

Deluge of logos on Commons[edit]

There is an insane amount of logos on Commons. A lot of them are unidentified and uncategorized, a whole bunch more are tagged as own work. A lot of them are not notable businesses and organizations that violate COM:NOT. Does anyone have any ideas how to address this problem? Would a new deletion criteria have some support? For example, a logo uploaded by a new user (under 50 edits), unidentified for longer than a year, and not used on pages is eligible for speedy deletion? Renata3 (talk) 00:28, 19 June 2020 (UTC)

They're mostly spam, as most are from accounts that upload nothing else and have no other edits. Random examples
  1. Rulicub (talk · contributions · Move log · block log · uploads · Abuse filter log
  2. Redikalur1 (talk · contributions · Move log · block log · uploads · Abuse filter log
  3. Nojesoj12 (talk · contributions · Move log · block log · uploads · Abuse filter log
It's unlikely any proposal for mass deletion or speedy deletion would pass, as many users love spam prefer keeping logos, as they might become useful.--BevinKacon (talk) 11:41, 20 June 2020 (UTC)
User:4nn1l2 care to comment? Those user uploads did not meet any speedy deletion criteria, that is unhelpful to discussion.--BevinKacon (talk) 17:14, 21 June 2020 (UTC)
Deleted based on COM:CSD#G10. If you think I was wrong, please go ask for their undeletion at COM:UDR. 4nn1l2 (talk) 17:32, 21 June 2020 (UTC)
  • Sounds like a job for COM:CSD#G10. My guess is, if that criterion does not apply, then it is not a clear-cut case and therefore a new deletion criterion is not appropriate. Brianjd (talk) 11:49, 20 June 2020 (UTC)
  • Although an F10 style criteria for logos of obviously non notable firms would be useful, I can't think of a feasible way of making it specific enough for CSD - a speedy deletion criterion should be specific enough that any reasonable user would agree whether a file meets it. ~~ Alex Noble/1-2/TRB 21:16, 20 June 2020 (UTC)
  • No, this is not a matter for speedy deletion. Scope matters are dealt with DRs. -- Tuválkin 23:42, 20 June 2020 (UTC)
  • Instead of deletion we need to specify what information is required to make them useful. Things that are labelled own work, but are not the work of the uploader are another kind of problem. We probably cannot tell in a speedy way if a firm is notable or not. So there should not be a speedy delete criterion for that. Graeme Bartlett (talk) 13:40, 6 July 2020 (UTC)

Document display[edit]

Propose to make two display improvements for documents. Make the default Commons image display document page user selectable, not just the first page. In the same way as is possible for thumbnails, add a "page" parameter for images in galleries and larger image transclusions so that users are not forced to split out useful document pages as separate files.

A consensus here would make it easier to request a WMF development analysis, in particular as addition to gallery tag syntax and file transclusions syntax would be a global addition.

Case studies:

Case 1
Default.
Case 1
Cover page that should be preferred for the image page.

Addendum: Striking part of this proposal. It turns out that an apparently hardly used feature of transclusions and galleries is the page parameter. Just none of us knew about it or how to use it correctly, probably because mw:Help:Gallery tag does not mention it (which Help:Galleries points to) and the briefly mentioned transclusion option is rather buried at en:Wikipedia:Extended_image_syntax#Page. A task to add a default page to image pages is the scope of this proposal.

FYI an example usage for a gallery looks like:

<gallery>
File:Farm and garden seeds - (catalog) (IA CAT31288354).pdf|page=3|Case 1
</gallery>

-- (talk) 11:20, 25 June 2020 (UTC)


Votes (document display)[edit]

  • Symbol support vote.svg Support as proposer. -- (talk) 10:38, 19 June 2020 (UTC)
  • Symbol support vote.svg Support Wikisource Index pages , have this is an option , and having it on Commons would also be useful. ShakespeareFan00 (talk) 16:56, 20 June 2020 (UTC)
  • Symbol support vote.svg Support Seems like a useful option. Wasn't aware you couldn't use a page parameter on gallery entries, actually. Carl Lindberg (talk) 17:46, 20 June 2020 (UTC)
  • Symbol support vote.svg Support Christian Ferrer (talk) 18:12, 20 June 2020 (UTC)
  • Symbol support vote.svg Support, oftentimes the cover of the book may only include the title or a bland design (this is especially true for older works), while the first page or index page may be much more recognisable. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:17, 20 June 2020 (UTC)
  • Symbol support vote.svg Support Helpful idea. Not sure what the engineering is to do this but seems sensible. —Justin (koavf)TCM 03:00, 21 June 2020 (UTC)
  • Symbol support vote.svg Support --Dick Bos (talk) 18:44, 26 June 2020 (UTC)
  • Symbol support vote.svg Support --Tibet Nation (talk) 01:13, 27 June 2020 (UTC)
  • Pictogram voting info.svg Info This seems non-controversial with 100% support, so after a week have now created Phab:T256565 to request the option. As there has been no technical analysis, if folks have suggestions on how best to go about it, please add them on Phabricator. Perhaps someone else would like to mark this proposal as archived? -- (talk) 10:51, 28 June 2020 (UTC)
  • Symbol neutral vote.svg Neutral I think we all agree that a title page is the best page to display in case of multipage PDF/DjVu documents. Wikimedia software already supports "gallery tag syntax and file transclusions syntax" where one can select specific page of multipage document. Our templates and Wikipedia pages were using them for years. title page number (P4714) used as qualifier on Wikidata or as property on SDC allows storage of the title page number, so various templates can use them. However one think we are missing is a way to automatically determine title page number and mass add title page number (P4714) to large number of PDF files. Alternative approach would be to create a tool to simplify addition of P4714 SDC property. However those tasks do not sounds like a tasks for WMF. I would support any efforts to develop such tools. --Jarekt (talk) 18:27, 6 July 2020 (UTC)
It would be actively damaging and clumbsy for Commons to rely on Wikidata accuracy and availability to be able to display our own media files. Commons needs to be robust enough to work even when links to Wikidata are failing. Functionally and technically, having the title page defined as part of the Commons image display page is the most obvious and robust way of doing it. -- (talk) 18:47, 6 July 2020 (UTC)
Currently title page number (P4714) is mostly used on Wikidata, as a qualifier, but I agree that such data should be stored on Commons as properties of a given file. That is why I think we should be adding title page number (P4714) as SDC property. Any tool that tries to determine title page (arithmetically or by crowd sourcing) number should store it right here on commons. --Jarekt (talk) 19:09, 6 July 2020 (UTC)
This would hide the option in wikitext searches, so again a bad way of doing it. Hiding more and more media file information in "sdc" tags that nobody understands (same as 'captions') and readers can't find is unhelpful. -- (talk) 19:20, 6 July 2020 (UTC)

Mass "Evacuation" copy of Public domain resources from Internet Archive to Commons.[edit]

This is almost certainly going to be controversial but:

It is proposed in light of the litigation threats IA is facing, that there is an automated effort, to "evacuate" copies of as many public domain 'books' from Internet Archive to Commons,as possible. User:Fæ already has some scripts that are doing this for a small number of collections already identified.

Initially, subject to appropriate metadata checks being feasible, what would be needed is a bot or script that essentially goes through a list of every single "book" scan on Internet Archive, and if its a work from between 1780 and 1870 (because that's the latest date something can be reasonably considered for {{PD-old-assumed}}), in English, (ideally a work published in the US), and under a commons compatible license, the bot grabs it and 'reliably' "mirrors" a suitable hi-res PDF to Wikimedia Commons, with the full IA style metadata, being placed in a suitable {{Book}} template on the file description page. If a suitable file already exists on Commons, (SHA1's could be checked) then that file is skipped. (Although a metadata only import could be considered, as well.)

Is it feasible, to do this for over 100,000 items? I don't think Commons Batch Uploading has ever attempted anything that big...

ShakespeareFan00 (talk) 16:55, 20 June 2020 (UTC)

FYI Portable Antiquities Scheme 559,631 photographs, Geography uploads were larger. 100,000 files can take me about a week or two, but if there are custom fixes and interventions, you can count on it being several weeks, especially as this is summer and everyone wants time in the sun. -- (talk) 17:16, 20 June 2020 (UTC)
Thanks. However I prposed this here rather than directly on the talk page for your effort, because I felt it needed a clear consensus from the whole community.ShakespeareFan00 (talk) 17:54, 20 June 2020 (UTC)
To be fair, I'm not actually sure how many 'public domain' books exist at IA, or if Commons has the capacity for all of them.. ShakespeareFan00 (talk) 17:56, 20 June 2020 (UTC)

Perhaps some background could be helpful. According to this NYT article from 1 June 2020, Penguin Random House, HarperCollins, Hachette and Wiley sue the Internet Archive for making books available for lending which are still protected by copyright. This electronic lending was originally quite restricted (just one copy per book at a time) but these restrictions were lifted recently due to the Corona crisis. The Internet Archive has already stopped this. However, the problem is, that this lawsuit threatens the existence of the Internet Archive. In theory, there could be up to $ 150,000 statutory damages per each of the 1.4 million titles per this analysis and this article at vice.com. --AFBorchert (talk) 18:19, 20 June 2020 (UTC)

Regarding the proposal: Disk space is not an issue at Commons. The precious resource is our time we have to fix things after the initial upload. Hence, it is of greatest importance that we focus on books where we can be sure that they are in the public domain. The description, categorization etc. should be good enough. This means that we would need a slow start with trial uploads to see if there are problems which should be fixed before we upload the whole amount. --AFBorchert (talk) 18:34, 20 June 2020 (UTC)

  • Symbol support vote.svg Support I support importing books to Commons as long as we are sure that most of them are in scope and there are no copyright issues. The suggested approach above gives me no reason to worry. So it's a go from me.
I'm also willing to risk a few copyvios if time is an issue. We can either mark those with risk as "Review" or we can simply delete them all and go through a review and undelete them if they are okay (or when they are okay). --MGA73 (talk) 18:45, 20 June 2020 (UTC)
  • Some uploads are already being made at Category:Books from the Library of Congress. I'm finding a few post 1870 works in the uploads being made. Nothing that looks problematic on the items reviewed so far, but there is only so much a single contributor can do. One issue I've found already is the use of 1800 as a placeholder date. The expertise of other commons contributors in reviewing things like dates against the scans and other sources ( Commons now has a set of the Catalog of Copyright Entries (Category:Catalogs of Copyright Entries BTW ) would be appreciated. ShakespeareFan00 (talk) 19:29, 20 June 2020 (UTC)
  • Symbol strong support vote.svg Strong support, I've imported many individual books from the Internet Archive in the past and have always hoped that this community would one day mass-import Internet Archive books, if Wikimedia Commons would want to be taken seriously as "a public domain library" such an import is a must, and more importantly it would also preserve this knowledge online in case it might be lost forever. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:15, 20 June 2020 (UTC)
  • Symbol support vote.svg Support for sure. —Justin (koavf)TCM 03:01, 21 June 2020 (UTC)
  • Symbol strong support vote.svg Strong support Scope be damned, we need to import everything we can from IA while we still can. (We can sort out any scope issues later. Also, it sounds like Commons is the only organisation willing and able to take on a task like this, so even if a file is out of scope, perhaps we should assist in preserving it for those who are interested in it.) One question: why a cutoff of 1870? {{PD-old-assumed}} says it can be used for anything up to 120 years ago, which would currently be 1900. Brianjd (talk) 06:59, 21 June 2020 (UTC)
1870 to take into account potentially longer terms outside the US, 2020-140 (2 lifetimes) + 10 years margin = 1870. I will also note that 1870 is when Copyright functions were centralized in the US, and thus after that date the Library of Congress is more likely to hold 'deposit copies'.
The 1780 lower cutoff was because prior to that it was felt more difficult for volunteer effort to verify certain information, earlier works, typically being in libraries special collections, with varying access requirements to protect works that old.
If there is a view that there's sufficient expertise on commons to robustly upload, evaluate and review items that are dated before 1780 or after 1870 (taking into account the issue of placeholder dates, differing copyright terms outside the US.) then I would agree Commons could potentially rescue EVERY public domain book on IA that's compatible with Commons licensing. ShakespeareFan00 (talk) 07:19, 21 June 2020 (UTC)
  • @ShakespeareFan00: I still don’t have a good understanding of PD templates here. I don’t see why the IA should be treated differently to any other source, so should we update {{PD-old-assumed}} to use a number greater than 120? Brianjd (talk) 07:56, 21 June 2020 (UTC)
Changing {{PD-old-assumed}} would be a different proposal. I set 1870 as a cutoff, but if there's consensus to 'push' the dates a little, I can't argue with consensus. ShakespeareFan00 (talk) 08:10, 21 June 2020 (UTC)
My sense of this is that Library of Congress book scans are pretty darn reliable, and anything up to 1899 is going to be 95%+ unchallengeable as PD. The current run today will cover 1801-1835 (8,000 books) and I'm inclined to push to go as far as 1899 as the maximum date.
Unfortunately there's no consistent filter for source publication country on archive.org. Though technically it would be possible to pick out publisher names and location (like "Chicago") in practice this would take up so much volunteer time, it's probably just better to get on with it and if necessary do a little triage on the debatable <5% cases which might result from imports dated 1870-1899. -- (talk) 12:04, 21 June 2020 (UTC)
@Brianjd: Nice sentiment, but I don't think WMF or the Commons community would tolerate holding a 'hidden' archive of material whose status or 'scope' could not be definitively determined. ShakespeareFan00 (talk) 07:38, 21 June 2020 (UTC)
I think the Commons community and the WMF already tolerate a "hidden archive", most of which are copyvios. If they don't, the WMF would have been permanently deleting every file that had been DMCA'd after the Commons community says the office action is okay. So I don't see why a "hidden archive" of IA files whose copyright status or scopeness could not be determined would be any different now. pandakekok9 09:36, 21 June 2020 (UTC)
@ShakespeareFan00, Pandakekok9: I agree that we can have (and already have) a "hidden archive". As I said above we can copy files to Commons and delete them and undelete if/when the copyright expired. So if we have a reason to think most of them are in scope it is just a matter of doing a mass import. We should only "speedy delete" those we think are problematic. --MGA73 (talk) 09:45, 21 June 2020 (UTC)
In addition, having a "hidden archive" could very useful for files whose copyright is expected to expire at a certain year. For example, a painting was deleted in 2014 because it's still not free in Mexico, whose copyright lasts life of the author + 100 years. And the painting's copyright will expire in 2021. Once we are on that year now, we could just check every file at Category:Undelete in 2021 and quickly bring it back to life (including the history of the file's description), with no need to reupload it again. Imagine if we can't undelete an old movie whose filesize is 5 GB. To reupload such size again would be a huge pain! (At least for me and everyone who is in a 2 Mbps connection) pandakekok9 09:56, 21 June 2020 (UTC)
This proposal should SOLELY be about 'books' which are clearly 'public domain', and that was why an upper cutoff in terms of dates was applied.
Copyvios on Commons (or other WMF projects), should NOT be tolerated. The whole reason IA is in trouble is because publishers ARE exercising copyrights they understand they are entitled to. Thusly WMF projects and Commons should absolutely avoid making themselves a potential next target, by refusing to upload works still in copyright from the outset.(And no this isn't a "Chilling Effect" but basic common sense.) Has anyone contacted WMF-legal yet for an official position?
For the above reasons, I cannot and never could support a "hidden archive" of copyvios, however well intentioned some people might think it would be.
WMF (and by extension individual projects) in my view SHOULD be perma-wiping files subject to legitimate DMCA takedowns, to send a very clear message that it doesn't support copyright infringement either. (I would hope there are measures in Special:UploadWizard and related pages to prevent accidental re-upload of previously "office" ed files.)
My apologies if I sound slightly strong-viewed on this, but I hold strong views.

ShakespeareFan00 (talk) 10:17, 21 June 2020 (UTC)

Another consideration, that may need to be considered, is if someone from GLAM, needs to actually let IA know they might suddenly have a lot more traffic of a focused nature. ShakespeareFan00 (talk) 07:47, 21 June 2020 (UTC)
  • Those IA files should obviously be imported here, because that's a commons thing to do, seeing Special:NewFiles without the patroller's filter. So I won't bother with using a support template. I agree with Brianjd that we should import everything from 1780 to 1870 ASAP and ignore COM:SCOPE for now. --pandakekok9 09:46, 21 June 2020 (UTC)
  • IA should be contacted directly to expedite the process, and an import of such a size should be under a dedicated bot account only.--BevinKacon (talk) 17:33, 21 June 2020 (UTC)
Yep! We just need a volunteer :-) --MGA73 (talk) 19:32, 21 June 2020 (UTC)
  • The Internet Archive contains about 1.5M texts published before 1870, hundreds of thousands of public domain or freely licensed images and thousands of public domain movies. They're a very small part of the data the Internet Archive holds, so even if we downloaded it all in one day it would barely register on their graphs. We're not able to host the uncompressed master files, so any mirroring at Wikimedia Commons must not be considered a preservation effort. Mirroring can however help increase access (for instance for users whose download speed from the Internet Archive is too low). For the books, we'd have to decide whether to import DjVu or PDF files when both are available. The download and upload must be performed from a server in the USA, preferably on the West Coast, because transoceanic download from the Internet Archive tends to be slow. Nemo 17:42, 22 June 2020 (UTC)
The reason we are uploading PDF is this 2016 statement.
With respect to "download and upload", we are using upload by url.
-- (talk) 17:58, 22 June 2020 (UTC)
  • @Nemo bis, : I believe Fæ is referring to the feature where files are imported directly to the Commons server, without going through the user’s own computer or Internet connection. Commons servers are based in the US, which is why we have to obey US laws as well as relevant local laws. I vaguely remember something about them being in Florida, but beyond that I don’t have any relevant information. Brianjd (talk) 05:05, 23 June 2020 (UTC)
  1. How certain is the public domain status of the non book 'media'? (Commons has to be sure that media isn't just out of copyright in the US, but globally.)
  2. How reliable is IA metadata, The first batch of some recent efforts encountered the use of 1800 as a placeholder date?
  3. I can probably see why Commons can't host Massive ZIP files of Jpeg or TIFF scans. Are there pre 1870 texts on IA that are only in DJVU format?
  4. Is there a way for the IA side of things, to directly upload to Commons? Rather than relying on user and bot scripts on the Commons side?
  5. (Aside) Is there 'free' software on the IA site, which could be utilized on Commons, like the book viewer, or tools used to convert between individual scans (JP2, JPG, TIFF) and PDF, DJVU amongst other formats?
  6. Another collection on IA (not mentioned so far) that maybe of interest to Commons are the Librivox recordings. Not as much of a priority as Librivox has it's own site and archive IIRC.

ShakespeareFan00 (talk) 23:19, 22 June 2020 (UTC)

WRT formats, we have yet to spot a document in djvu that is not available as a pdf. Oddly there are some that have neither, possibly a transcoding error (example)? -- (talk) 15:20, 23 June 2020 (UTC)
Yes, usually if there's a DjVu there's also a PDF, while the opposite is not true. We generally upload DjVu if available. Most books on the Internet Archive were created when DjVu was still active. The example you link is indeed a case of failed derivation; there are also cases when derived files (OCR etc.) are intentionally not produced, to save resources. Nemo 13:35, 25 June 2020 (UTC)
(Technical note:) https://blog.archive.org/2012/04/26/downloading-in-bulk-using-wget/ in case anyone is still following this disscussion. ShakespeareFan00 (talk) 05:58, 24 June 2020 (UTC)
  • Pictogram-voting-question.svg Question Just to be sure. Are we talking about
    • a) A usual transfer where users transfers selected files from IA to Commons?
    • b) An import where someone go to IA server room and copy their data to a super-monster-huge-storage and then go to WMF server room and connect the super-monster-huge-storage to the servers?
If we are talking about a) then anyone who want to can just start copying whatever they want. If we are talking about b) then someone need to ask the WMF if they have storage ready and talk to IA if they are willing to give us/WMF a copy of their data. --MGA73 (talk) 08:38, 24 June 2020 (UTC)
a) To some extent is already happening on a mid-scale effort by but others are welcome to pitch in.
b) That was definitely not considered at this point, but if someone else was sufficiently crazy enough to lobby the WMF for it...
I also don't think the WMF has ever undertaken any major direct real-world transfers of large content donations from donors.
I would of course still exceptionally strongly object to WMF holding anything that was still "in-copyright" (such as post 1925 items) in a "hidden archive" though. Both WMF and Commons policy has distinctly stated many times it does not want 'non-free' content. ShakespeareFan00 (talk) 09:10, 24 June 2020 (UTC)
From experience of trying to send a USB disk with 100,000 high resolution images supplied very kindly by the Wellcome Library to WMF Ops with their prior enthusiastic agreement, having a disk lost, trying again, giving up after several weeks of trying to get this to work, then using a replacement disk plugged into a personal laptop and uploading using a not-very-reliable home broadband connection over a month instead... it may not be terribly practical to ask the WMF to take responsibility for cloning an image + data dump where volunteers can access it to publish on Commons. -- (talk) 09:27, 24 June 2020 (UTC)
And as for the "hidden archive" then we have one already. If we want to stop having it then we have to change policy so that once an admin deletes a file it is deleted, gone forever, can't be undeleted. That would be a big change for Commons.
I don't think we have any cases where we on purpose have moved a lot of copyrighted files to Commons to have them deleted. So I agree that if we want to copy copyrighted files in large scale we should make sure WMF won't complain.
But I think that most files before 1925 should be okay. So unless IA mark the files as copyrighted I do not see a big problem for us to import them. Do we have a stat somewhere so we can see how many files they have sorted by year? --MGA73 (talk) 09:39, 24 June 2020 (UTC)
  • @MGA73: unless IA mark the files as copyrighted As another user said somewhere recently, the IA is having its own problems with copyright right now (in fact, that’s the reason for this proposal), so we probably shouldn’t pay too much attention to their rulings on copyright. Brianjd (talk) 09:50, 24 June 2020 (UTC)
  • @Brianjd: No one is perfect. If IA say it is copyrighted they could of course be wrong. But I think we should make checks before we copy them and mark them as PD. --MGA73 (talk) 10:03, 24 June 2020 (UTC)
  • Additionaly, in the period 1870-1925, there are likely to be many many foreign works (including those from places like Mexico which has very long copyright terms. ), whose copyright terms are not Commons Compatible (given that Commons considers origin countries copyright rules as well as the US ones). There isn't a foolproof automatic way to fully confirm non US copyright status from the metadata IA provides at present, and hence why this proposal was originally limited to specifically pre 1870 items. If there was a way to get better metadata, or for Commons contributors to feed more reliable data back to IA (and IA contributors) as well, that should be encouraged. I would hope IA is also considering providing additional 'status' data, as part of it's response to the publishers concerns. Sorry if I sound like I have an "old-curator" mindset here...

ShakespeareFan00 (talk) 10:54, 24 June 2020 (UTC)

  • Commons has generally been rather conservative about what it considers to have expired copyrights, perhaps more so than even some publishers with fully salaried legal teams! The 'hidden archive' as such only exists because of the persistence and diligence of Commons contributors and admins exercise when removing copyright violations (perceived, potential and actual alike). Deliberately uploading of material that cannot or should not be upload under existing WMF/Commons policy is a different proposition, and I could not support the deliberate uploading of material contributors and admins would know wasn't "compatible". Perma-wiping existing "deleted" items would be a different, lengthy and difficult discussion, although one I think should be more actively considered.

ShakespeareFan00 (talk) 10:54, 24 June 2020 (UTC)

  • @: Ooops not good. But if we were are about to clone all the data that IA host then we are talking about a lot more than a USB. I'm not even sure the servers WMF have can store all the data from IA. --MGA73 (talk) 09:45, 24 June 2020 (UTC)
2,262,680 books before 1925 search.
So not too many really, considering 100,000/week is possible for one person using an ancient laptop and a home broadband connection. However we still are finding it highly unreliable to upload PDFs larger than around 200MB, even with many multiple attempts at upload. -- (talk) 09:47, 24 June 2020 (UTC)
P.s. every night while running jobs for User talk:Fæ/CCE volumes, my laptop has spontaneously powered off and lost the tasks, probably due to overheating. It's not really fixable, it's just very old kit. If more folks could endorse m:Hardware donation program/Fæ so an unused WMF laptop might be written off and sent over to get used for these Commons upload projects, it would help me out. Thanks -- (talk) 09:56, 24 June 2020 (UTC)
  • @: Thank you. Books are a good place to start. But I think IA also host fotos and videos so there may be much more than books to grab! --MGA73 (talk) 10:03, 24 June 2020 (UTC)
  • Symbol support vote.svg Support I will help with "review" work (with clear instructions), if needed. Books appear to be the priority, but is there any urgency with audio, video and photos? Can an adverse court ruling threaten the complete file contents of The Internet Archive by harming the non-profit corporation and/ or it's Board of Directors? What would be the estimated timeline for this legal process, including appeals? --Tibet Nation (talk) 01:31, 27 June 2020 (UTC)
  1. "Public domain" materials are the priority. 'Books' and 'primary' source documents (such as reports by US Federal Govt agencies) that can be shown to be license compatible with Commons are the focus of efforts, currently.
  2. Commons should not host copyvio, and thus please file detailed DR's if you find something that suggests a work might still be in copyright. (such as evidence in the work, or an entry in authoritative sources like the Catalog of Copyright Entries).
  3. In reviewing (Not an exhaustive list):
    • All meta-data should be checked against the physical scan. (There have been some anomalies, uncovered by doing this.)
    • All initial licenses should be checked against evidence in the scans, metadata and other available sources.
    • All work seemingly published after 1964 is to be assumed copyright, unless determined otherwise, (such as clearly being a work of US Federal Gov.)
    • All works that seem to be published 1925-1964, should be checked against the Catalog of Copyright Entries, for both an original copyright and a renewal. (Commons can't host works still in copyright in the US, unless it has explicit permissions and licenses).
    • Works published 1870-1925, of Non-US origin, not in English or without author life-times should be flagged for a more detailed review (Due to URAA interactions, and the extened copyright terms of some jurisdictions.) ShakespeareFan00 (talk) 10:09, 28 June 2020 (UTC)
    • Works (published in or after 1925) with a primary or substantial contribution by non US authors who died less then 70 years ago, should be flagged for a more detailed review. (Due to potential URAA interactions.)
  4. It's not clear what the full impact of an adverse court ruling could be, but the concern expressed by some is that the cost of paying damages would bankrupt IA, (effectively forcing it's shutdown.) The timescale of the ongoing legal process isn't clear yet.

ShakespeareFan00 (talk) 10:09, 28 June 2020 (UTC)

Accept files published by the copyright holder with a Public Domain Mark[edit]

Files published with a Public Domain Mark (PDM) alone are not currently accepted at Commons: an additional reason must be found for why the file is in the public domain. This proposal is to accept files that have been published by their copyright holder with a PDM, using a new template:

  • {{PD-PDMark}}: "The copyright holder of this work has published it with a Public Domain Mark. Although the Public Domain Mark is not itself a public domain release, when applied by the copyright holder in this way it implies that the work has been released into the public domain."

Alternative wordings were suggested by User:Brianjd and User:Clindberg, which I've combined as:

  • {{PD-PDMark}}: "A Public Domain Mark has been applied to this work by its copyright holder. Although the Public Domain Mark is not intended to be used on one's own works, when it is applied by a copyright holder in this way it implies that the work has been released into the public domain." --ghouston (talk) 10:33, 24 June 2020 (UTC)

The third version is simplified based on a wording by User:Brianjd:

Changed the template name, by popular demand:

Since the original RFC from 2015 at Commons:Requests for comment/Flickr and PD images, which resolved not to accept files released only with a PDM, there have been recurring discussions questioning that decision, such as:

The last discussion is still open. In these circumstances, it seems like time to reconsider the issue formally. --ghouston (talk) 02:43, 23 June 2020 (UTC)

Note: following a point raised below, this proposal wouldn't make PD Mark a new option when an uploader is putting their own works on Commons, including when they are copying their own works from another site. They should use one of the existing public domain dedications, preferably {{CC-zero}}, but there are others including {{PD-self}} which are accepted. --ghouston (talk) 00:00, 27 June 2020 (UTC)

  • If this proposal is accepted, I suggest a slight change the wording:
    The copyright holder of this work has published it withapplied a Public Domain Mark to this work. Although the Public Domain Mark is not itself a public domain release, when it is applied by the copyright holder, it implies that the work has been released into the public domain.
Brianjd (talk) 05:12, 23 June 2020 (UTC)
  • Symbol support vote.svg Support when the uploader is clearly the copyright holder. I would recommend everyone familiarize themselves with the existing conversation at Commons:Village pump/Copyright#Double standards for Public Domain Mark. I am not arguing that PDM is particularly rigorous. However, none of the Flickr licensing choices are. As you can see, the choices you have simply show up in a dropdown: All rights reserved, Public Domain Work, Public Domain Dedication (CC0), Attribution, Attribution-ShareAlike, etc. Unlike Wikimedia projects, there is no clickwrap agreement to ensure that the uploader has actually read and understands the license; they can just select an option and *poof* the file is licensed. None of the choices link to the official license you are using until after you've already selected it, raising the question of whether you can actually agree to a license that is only shown to you after you've chosen it. "Public Domain Dedication (CC0)" is the only license that even mentions the name of the license, and even there to most people CC0 is probably incomprehensible gibberish; most people cannot be expected to know the difference between the two PD options, so intent is what matters since the legal text is dubious anyways (again, how can you release a work under a license you've never read?). "Attribution" et al. do not even mention the fact that it is a CC license or the version of the license (until you've selected it); how do we know they didn't mean {{Attribution}}? There is also a slight nuance between the words "mark" and "work" (the latter being the actual wording used by the Flickr UI). If you choose "public domain mark", it has a little more connotation of just labeling something, but if you consciously choose "public domain work", the most reasonable interpretation is that you're making the statement "my work is a public domain work". In conclusion, so long as we continue to accept Flickr images at all, which are not rigorously licensed by any stretch of the imagination, we should not apply an artificially high standard to PDM. -- King of ♥ 06:22, 23 June 2020 (UTC)
  • It depends. The reason why the CC0 and {{PD-self}} (and related templates like {{PD-author}}) have a lax permissive fallback license is because some countries don't recognize "public domain" alone. In those countries, there must be an explicit permission to use the file for any purpose without any conditions from the copyright holder. If the external image is taken for example by a person who lives in the U.S., is taken in the U.S., hosted in the U.S., and the Commons uploader is from the U.S., then we could accept those PDM images. The same applies for those countries which recognize "public domain" alone as sufficient. All the conditions should be from countries that recognizes PD alone. If even one of them fails, we can't upload it. Files must be free in the U.S. and the source country to be uploaded and hosted here on Commons. pandakekok9 07:03, 23 June 2020 (UTC)
  • I don't think this is really tested much in court, at least outside the USA. I've never seen a copyright law that made any explicit provision for abandoning copyright, let alone explaining how it's supposed to be done. It would be an unusual sort of court case, where somebody would have to release something into the public domain and subsequently sue somebody for copyright violation, I guess. So I don't think it's possible to say that particular countries don't recognise public domain dedications. There are some that don't permit loss of certain "moral rights", but that also applies to licensing. --ghouston (talk) 07:47, 23 June 2020 (UTC)
  • It is indeed unusual for a copyright holder to sue someone for copyright violation even though they "released" it into the public domain, but I think it's totally possible. Otherwise, we don't really need such licenses like CC0 or Unlicense. A copyright troll who lives in a country that doesn't recognize PD dedications could mark their work as PDM, and bait others to use and copy it. After the bait succeeds, the copyright troll can sue them and profit from it. If we are going to accept all PDM works from any country, we should add a disclaimer noting that marking a work under PDM doesn't automatically mean it is released into the public domain in some countries, and warn the reuser that the work may still be non-free in other countries. pandakekok9 08:29, 23 June 2020 (UTC)
  • Anything is possible, but has it ever happened? Somebody trolling at that level could just as well upload their work to Flickr with a CC-BY licence and an alias. --ghouston (talk) 08:53, 23 June 2020 (UTC)
  • I would like to know which country would not allow it, really -- the economic right is always transferrable, and if you can sell the right I don't see how you can't abandon it. CC0 also tries to give up moral rights and other related rights, and those are indeed often not transferrable, and that is where a fallback license is definitely required (and even that may not always be operable). PDMark would just release the economic right and nothing else, so moral rights would still need to be followed (which we would normally do anyways). Moral rights are a non-copyright restriction though, so that is not a reason for deletion. Carl Lindberg (talk) 08:41, 23 June 2020 (UTC)
  • PDM doesn't say "public domain" though. If we go by the Flickr UI, it's "Public Domain Work" vs. "Public Domain Dedication (CC0)" - hardly a difference except for the CC0 name-drop which will be incomprehensible to a vast majority of uploaders. If we go by the legal text, it does not mention public domain at all and simply says "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission", so if one puts this on one's own work I think it should be sufficient. -- King of ♥ 14:07, 23 June 2020 (UTC)
Symbol support vote.svg Support when the uploader is clearly the copyright holder -- there is no way for that statement to be true unless the author has waived copyright. The intent to me is clear; CC-Zero is not particular well titled unfortunately, and most people know the term "public domain" and choose that instead as the title they recognize more. The wording of PDMark seems explicit -- copyright is irrevocably given up. To me it's certainly as good as PD-self or PD-author, etc. An explicit public domain declaration has been shown to give up all rights in the U.S. -- Carol Highsmith tried to sue Getty for selling her (declared PD) photos without giving credit, but since she had given up all rights she lost the case. The credit part would be required in other countries due to moral rights, but I really don't see how the economic right would work differently in other countries -- as far as I know there is no such precedent (whereas we do have a precedent the other way). It seems like it should qualify as the overt act mentioned at w:abandonment (legal)#Abandonment_of_copyright.
I would not allow automatic uploads from Flickr via the bots with the tag, and they should also require a human license review (maybe the bots could at least validate the PD-Mark tag without marking it OK), but I think they should be allowed when marked by the copyright owner -- seems like common sense to me, really. I might make the wording of a {{PD-PDMark}} (or maybe {{PDMark-author}} or {{PDMark-owner}}) tag more like "Although the Public Domain Mark is not intended to be used on one's own works, when it is applied by the copyright holder" (continuing with the rest of Brianjd's proposed wording), rather than saying it's not a release, because I think it does have that effect. Carl Lindberg (talk) 08:41, 23 June 2020 (UTC)
  • Symbol support vote.svg Support If I upload a file to Commons and add a license I'm requested to add a source and an author. If I do not then file risk deletion. When I upload to Flickr I'm not asked to provide source or author. We on Commons just assume that the uploader is the photographer.
So to me it makes no difference if I add CC or PDM. I'm not asked to tell WHY the file is CC or PDM. There is no active "I xx the copyright holder of this file hereby release the photo as CC" so I do not think it is a big problem if the author do not actively declare a "I xx the copyright holder of this file hereby release the photo as PD". --MGA73 (talk) 19:53, 23 June 2020 (UTC)
  • Symbol support vote.svg Support If the copyright holder publishes a file with a Public Domain Mark, the intention to release it as PD should be clear enough, even if it's not the formally right way to do it. Gestumblindi (talk) 22:53, 23 June 2020 (UTC)
  • Regarding the second draft:
    1. I like Clindberg’s contribution.
    2. I would like to change it back to the active voice: “The copyright holder of this work has …” This is consistent with {{Self}} and {{PD-self}}, at least, and emphasises the most important thing here: the copyright holder’s wishes.
    3. In the second sentence, by a copyright holder and in this way seem to mean the same thing; one of these should be deleted.
    4. I would like to move Although the Public Domain Mark is not intended to be used on one's own works to explanatory text (to be drafted later) (and reword the rest of the sentence accordingly).
So main text would say:
The copyright holder of this work has applied a Public Domain Mark. This implies that the work has been released into the public domain.
Brianjd (talk) 11:33, 24 June 2020 (UTC)
  • Yes, I think it's better to keep the wording simple on the template itself. It would be followed by: For details, see Commons:Public Domain Mark, were a lengthy essay can be written to discuss all the points raised during these discussions. --ghouston (talk) 00:22, 25 June 2020 (UTC)
  • Symbol support vote.svg Support, I've seen literally thousands of such images on qFlickr which were high quality images of museums and / or archaeological sites with this license, this weird double standard is a major disservice for Wikimedia Commons, it's essentially saying "We want free files, but not that free." Which is absurd. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:41, 24 June 2020 (UTC)
  • Random ping of some that have commented on old discussions @, Jarekt, Discasto, Josve05a, VIGNERON, Jameslwoodward, Natuur12, BU Rob13, Ruthven, Christian Ferrer:. If you do not want to comment that is fine. Just thought you should know. --MGA73 (talk) 08:24, 25 June 2020 (UTC)
  • Symbol support vote.svg Support Talked about this for too long, time to do it. In copyright law there's always space to recognize "reasonable" and in this case where an uploader has made a reasonable assessment that the copyright holder has released their own work then a templated warning is sufficient. -- (talk) 10:45, 25 June 2020 (UTC)
  • If this is accepted, we might want to go back and try to undelete PDM files (Is there any easy way of doing this, or should we start tagging DRs now?). Here’s one (where the uploaded didn’t take the news well): Commons:Deletion requests/File:YJ09OBT First Leeds 37722.jpg. Brianjd (talk) 13:09, 25 June 2020 (UTC)
  • Yes please. Nemo 13:35, 25 June 2020 (UTC)
  • Still not thrilled about this concept, but I like the third draft of the template. @Ghouston: You missed the closing quote, though. Brianjd (talk) 14:41, 25 June 2020 (UTC)
    • I like the text, but prefer PDMark-owner as the new template name, to distinguish it from "normal" uses of PDM -- otherwise people may think they can use it on *any* PDM-marked file on Flickr. Carl Lindberg (talk) 03:10, 26 June 2020 (UTC)
      • The name isn't great, but the convention seems to be that the public domain templates start with "PD-", see the contents of Category:Public domain due to copyright expiration for example. Maybe PD-PDMark-owner or PD-owner-PDMark. I'm not sure if we should also include the PDMark verison, currently 1.0. The existing template is {{Flickr-public domain mark}}. Also, COM:PDM redirects to a section of a page about Flickr: the section would need to be updated, and COM:PDM could redirect to a new Commons:Public Domain Mark page instead. --ghouston (talk) 04:25, 26 June 2020 (UTC)
      • {{Cc-zero}} doesn't bother with the PD- prefix, however, or with the version number. --ghouston (talk) 04:30, 26 June 2020 (UTC)
        • Since "PDMark" already starts with "PD", it seems a little redundant just so it has the dash. More like CC0, it is the name of a particular wording, rather than a generic-use PD tag. And I do want to distinguish between when copyright owners use it versus any other use, which should still require a more specific tag. Flickr-public_domain_mark is still generic, and should probably continue to be a redirect to a speedy deletion, though it should of course mention the new tag if this passes. And yes, COM:PDM would need updating, for sure, as well some other pages that older DRs point to (such as Commons:Requests for comment/Flickr and PD images). I'm not opposed to PD-PDMark-owner though -- just seems a bit redundant, but if folks feel the "PD-" prefix is important enough to preserve, then fine. Carl Lindberg (talk) 05:06, 26 June 2020 (UTC)
          • I also slightly prefer PDMark-owner. If Cc-zero didn't exist I'd probably want to preserve the "PD-", but since the naming convention is broken anyways I see no reason to insist on it here. -- King of ♥ 05:49, 26 June 2020 (UTC)
        • @Ghouston: I would also add a message that advises against its use by Commoners, pointing them to {{Cc-zero}} instead. -- King of ♥ 13:28, 26 June 2020 (UTC)
          • I don't mind putting a restriction on this proposal, that you can't upload your own files to Commons with a PDM alone, it applies only to uploading the works of others already published on other sites. Perhaps in some cases the author of the work will have a Commons account: I don't think that should prevent a transfer to Commons by others, since they may have just uploaded a few files to Commons years ago. --ghouston (talk) 14:12, 26 June 2020 (UTC)
            • Agreed. I think CC-Zero or PD-self should be used for first-time-being-published uploads to Commons, but should not prevent transfers to Commons. Carl Lindberg (talk) 16:00, 26 June 2020 (UTC)
  • Symbol support vote.svg Support My thoughts on the matter are exactly aligned with what Gestumblindi said above. The Squirrel Conspiracy (talk) 23:17, 26 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose the proposal to allow files to be on commons without an legally binding and explicit release under a free license (or to the public domain). In the U.S., marking one's own work with the public domain mark would probably be a valid waiver of one's rights. This is likely untrue in other countries, see FSF thoughts on informal releases. Marking one's own work with the Mark is more like an implicit license than an explicit license: it does not say "[I] irrevocably and unconditionally waive[], abandon[], and surrender[] all of [my] Copyright..." (CC0 1.0 legal code); rather, the PDM has no legal text at all, and says that the work was identified by someone as being in the public domain, and therefore reusers may use it accordingly. According to Creative Commons (who I would like to think know what they have written), "The PDM is not a legal instrument.... It should not be used to attempt to change a work’s current status under copyright law, or affect any person’s rights in a work.... PDM is not legally operative in any respect" (PDM FAQ). To see the difference, Compare "This work has been identified as being free of known restrictions under copyright law, including all related and neighboring rights." (PDM 1.0 summary) with "The person who associated a work with this deed has dedicated the work to the public domain by waiving all of his or her rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law." (CC0 1.0 summary), "To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights..." (CC0 1.0 legal code).
    All of that being said, if there is a consensus to allow works marked with the PDM onto Commons, I would like the template to use the name {{PDMark-owner}} with the following text: "The copyright holder of this work has applied a Public Domain Mark to it, which is thought to constitute an implicit waiver of their copyright in the United States. Other countries' courts may interpret the Public Domain Mark differently. This template should only be used on transfered files from other websites, and only on files where the Commons uploader is not the copyright owner. If the Commons uploader is the copyright owner, or this is not from another website, have the copyright owner explicitly release their work under a free license or dedicate their work to the public domain using the {{CC0}} dedication." --Mdaniels5757 (talk) 00:48, 27 June 2020 (UTC)
    • Keep in mind that the FSF guidance is about licenses, not an outright waiver of all rights, and is also about wording much less explicit than PDM. There is not much ambiguity in You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. It's similar to other PD statements that we do accept, and have always accepted ({{PD-self}} and {{PD-author}}). And while it was not intended to be a license, what Creative Commons intended does not legally matter, most likely -- more important is what the copyright owner intended. For one example, Creative Commons had their intended interpretation of what keeping the notice "intact" meant in a FAQ, but a court ruled that the actual license wording should be interpreted differently. I don't think it should be a general license here, but to me owners' intent is fairly clear when they use it on Flickr, and potential problems with such uploads are extremely theoretical at best, and fall well below COM:PCP. Carl Lindberg (talk) 01:52, 27 June 2020 (UTC)
  • Symbol support vote.svg Support I support this as an overdue acceptance of good faith efforts by flickr users/ photographers and Users here on the Commons to make their work more accessible to the world. I also support a process to identify and undelete all flickr uploads that were deleted, but now qualify for this new tag. I hope this process would be open for anyone to help get this job done. As for future flickr uploads of this potential new trove of available photos, can future uploads be made simple and/ or automated for the uploader using the Upload Wizard? Thanks to all in support. --Tibet Nation (talk) 01:01, 27 June 2020 (UTC)
    • Not sure about the upload wizard. We won't be accepting the PDM as a general license -- when used on old works created by others (the intended use, and the case for many files on Flickr) we still need a more specific, existing license tag to explain why it is public domain. Not sure we want to open up those images to being imported. Carl Lindberg (talk) 06:36, 1 July 2020 (UTC)
    • Definitely oppose adding this to the Upload Wizard. Part of the reason why we're in this predicament is because Flickr makes it too easy to select the PDM. Works should only be uploaded to Commons under the PDM by experienced users who know what they are doing. And yes, I plan to go through Category:Public Domain Mark 1.0-related deletion requests/deleted and overturn all the DRs where the only reason for deletion was that an image was under the PDM. -- King of ♥ 16:10, 3 July 2020 (UTC)
  • Symbol support vote.svg Support I reckon that's reasonable. The intention of the author of licensing in the public domain is clear in those cases. BTW: We've to check it it's OK for thoses countries where the public domain is borderline as a valid license (e.g. France) Ruthven (msg) 07:00, 27 June 2020 (UTC)
    Note that the official text says, "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission." So I think it ought to be OK even in those countries. -- King of ♥ 00:19, 28 June 2020 (UTC)
  • Symbol strong support vote.svg Strong support --Jarekt (talk) 02:53, 30 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose Looking at the Swedish copyright law, I see that the copyright holder has the right to transfer the copyright to someone else (Article 27). Transfer of copyright is sometimes known as 'granting permission', but the legal term is 'transfer'. However, I do not see any right to annul the copyright, and there are limitations in copyright transfer (for example when it comes to moral rights). A court would look at Article 43 where it says that the copyright expires 70 years after the death of the author and note that the work is copyrighted as the author is alive.
The next question is if the copyright tag counts as 'transfer of copyright' (permission). The problem here is that the legal text only states that the work isn't copyrighted, but it doesn't say that the author has granted any rights to use the work whatsoever. There could be issues if the author claims that he didn't know how copyright works and that he fixed the copyright tag after learning about this. For example, some new uploaders seem to think that anything publicly available is in the public domain. A person using the work could explain to the court that he was tricked by the author's fraudulent copyright tag and therefore believed that the work wasn't copyrighted. The court may or may not side with the person using the work regarding previous use of the work, but now that this person is aware that the copyright tag was wrong, he might not be able to use the work in the future. In other words, the unclear copyright statement might de facto make it into a revocable licence. However, Commons doesn't accept revocable licences. --Stefan2 (talk) 22:36, 30 June 2020 (UTC)
The thing is that we don't require an explicit statement of irrevocability in many other cases. Take {{PD-self}} for example, or the CC-BY 2.0 on Flickr, where the uploader has to do little more than select "Attribution" on a drop-down that doesn't even disclose what they are consenting to until they have already selected it (see my initial comment). PDM is being singled out for no good reason, I think. -- King of ♥ 22:41, 30 June 2020 (UTC)
I find it odd that a right can be completely sold or given away, but cannot be abandoned (i.e. given away to nobody). That seems strange to me -- is there any precedent for that being denied? To me, the right to transfer should imply the right to abandon/annul, though I could be wrong -- but I'm not aware of a counterexample. Moral rights, sure, those are not affected by the PDM at all (just the economic right), but that does not affect "free" status (moral rights are a non-copyright restriction). As for the legal text, it says You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. That sure seems like a grant of rights (though not necessary if those rights have in fact been abandoned). As for an author claiming ignorance, they can make the same claims with CC0 or CC-BY or any other license or statement. An abandonment is not revocable -- it doesn't need to explicitly say that. The BSD license doesn't use the word, yet it is not revocable either. Generally, you must make a license explicitly revocable if you want that attribute. Carl Lindberg (talk) 06:36, 1 July 2020 (UTC)
An example would have to consist of some European version of Carol M. Highsmith successfully suing an agency for selling her PD works without attribution - and for the court to rule that the agency has violated her copyright, not just her moral rights. I am not aware of any such case law. -- King of ♥ 20:26, 2 July 2020 (UTC)
  • Symbol support vote.svg Support The Flick user should know what they are doing. If they choose the license of PD-Mark, it is assumed that they release the photo to Public Domain. It is unnecessary to concern about the copyright status in US and their home country. BTW, it is a real shame that many good quality photos from Flickr can't be used just because of the PDM 1.0 restriction. However, some "Flickr-washing" account use PDM 1.0 as the license. If the PDM 1.0 restriction was lifted, there may be more Flickr-washing file. This required more patrol. --A1Cafel (talk) 02:41, 1 July 2020 (UTC)
    Correct, we wouldn't accept PDM unless we were fairly confident the uploader is the copyright holder. -- King of ♥ 02:47, 1 July 2020 (UTC)
  • Symbol support vote.svg Support It may not be the best way to make your work free, but it is a way. ℺ Gone Postal ( ) 07:11, 2 July 2020 (UTC)
  • Symbol support vote.svg Support. The license seems applicable to Wikimedia Commons, not withstanding possible issues outside US jurisdiction, but more or less similar restrictions seem to apply to the already accepted other licenses also. Eissink (talk) 15:30, 2 July 2020 (UTC).
  • Symbol support vote.svg Support --Matlin (talk) 21:34, 2 July 2020 (UTC)
  • Symbol support vote.svg Support Beyond My Ken (talk) 22:14, 2 July 2020 (UTC)
  • Symbol support vote.svg Support Editor-1 (talk) 03:12, 3 July 2020 (UTC)
  • Symbol support vote.svg Support If a flickr-user is chosing PD-mark as license he clearly want to give the image to PD. --Migebert (talk) 16:38, 3 July 2020 (UTC)
  • Symbol support vote.svg Support I agree with Gone Postal. Mitchellhobbs (talk) 17:52, 3 July 2020 (UTC)
  • Symbol support vote.svg Support but only if we are vigilant to restrict to cases where the uploader is the copyright holder and step up efforts against flickrwashing. Buidhe (talk) 06:33, 4 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose The PDM is not a waiver or a "fallback license" in the same way that CC0 is. It's only a labelling tool, and it is *not* supposed to be used by the copyright holder; the copyright holder should use the CC0. See the difference in this comparison chart between the CC0 & PDM made by Creative Commons. If the Flickr community doesn't know how to apply the CC licenses and tools, the way to fix it is not by creating more misunderstandings around the CC tools. PDM should only be applied to works that are in the worldwide public domain because the term of copyright has expired or is not applicable. Scann (talk) 13:11, 6 July 2020 (UTC)
    • That is what it was meant for yes, but if a copyright owner is using it on their own works, the intent seems fairly clear -- and an abandonment of copyright is the only way that would make sense. The wording may also qualify as a fallback license, as well. The intent of Creative Commons has no bearing on all that -- just the intent of the copyright owner. It's not recommended, for sure, but that's a different question than it still being legally valid. Carl Lindberg (talk) 13:33, 6 July 2020 (UTC)
        • CC's interpretation of the licenses and tools it's super relevant to the discussion. First, I seriously doubt that the PDM would be accepted as a waiver of rights in other countries; I think the US and some common law countries might accept it as a waiver of rights, but seriously doubt this for civil law countries. Second, CC can and has participated in the past in official interpretations of their license suite, because that's one of their main responsibilities as the stewardess of the licenses, in court cases such as Great Minds v. Fedex. So it does matter what they think, because when you are at a court case you'll surely want to call them in to offer their interpretation of their tool/license. Moreover, I don't see why you'd break a tool that someone else created just because you have an untrustworthy source of copyright statements such as Flickr. This is a Flickr problem, not a PDM problem. You're not fixing anything here with this statement, just breaking things that do work. Scann (talk) 18:08, 6 July 2020 (UTC)
          • They may be asked about their interpretation, but if someone licensing a work thought it meant something else, then a judge would have to decide if that was reasonable too. When it came to the clause about the copyright notice remaining "intact", CC (per one of their FAQs) only intended that to mean that the text should remain intact, not the placement (such as embedded in an image). When that came to a court case though, the judge ruled with a different interpretation, since in the end it was only the words actually in the legal license that mattered. So in that case, no, CC's intent did not matter either. In this case, the copyright owner is putting a statement of You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. on their work. I would be interested in knowing how that would not have an affect in civil law countries -- if you can sell or give away the economic right, why can't you give it away? In the end, if the copyright owner intended to place their works in the public domain -- and I really can't figure out what else they could have meant by putting that mark on their own works -- then that is what they likely did. I don't think Creative Commons gets to decide if that actually makes it PD or not. Part of the problem is the names -- people know what "public domain" means but they don't necessarily know what "Creative Commons Zero" means. And yes, maybe Flickr could do better, by making it clear that PDM is not intended for your own works, the way everything else in the licensing list is. Maybe PDM shouldn't even exist, since works PD in one country may not be PD in another, etc. But it does, and users on Flickr use it, and I really don't see the difference between the statement there and {{PD-self}}, or other similar "public domain" statements we use {{PD-author}} for. Carl Lindberg (talk) 02:06, 7 July 2020 (UTC)
      • "and it is *not* supposed to be used by the copyright holder" - We would not be having this conversation of copyright holders were as educated on the nuance of licensing as we are, but the reality on the ground is that lots of people are using PDM because they understand what "public domain" is but have no idea what "creative commons" is. Many of these Flickr accounts have been unused for years, as well, so even if we were somehow able to come with a concise and easy to understand way to word the request, and get it to all these accounts, it's likely that many of the files will remain unusable. The Squirrel Conspiracy (talk) 16:00, 6 July 2020 (UTC)
        • With that criteria, then you shouldn't use anything that is CC BY on Flickr because last time I checked when Flickr announced that they were going to commercialize some of their photos that were under a CC BY, there was a public outrage around this. So it's either you accept the copyright holders decisions as valid or you don't. This argument could also be used by a copyright holder to say "no no but my intent wasn't really to use a CC BY; I didn't want to let the work be used with commercial purposes". Scann (talk) 18:08, 6 July 2020 (UTC)
          • Exactly, exactly, that's precisely my argument. If we carry your logic to its logical conclusion, then we would ban all Flickr images. If we continue to accept Flickr images, then we have no reason to treat PDM differently. -- King of ♥ 22:10, 6 July 2020 (UTC)
  • Symbol support vote.svg Support Cards84664 (talk) 14:04, 6 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose per Scann and others: It's not a proper release. This feels like {{PD}} all over again. This fails the precautionary principle. This is like having a straw poll to decide that the world is flat: It doesn't matter how many people support it, it is still incorrect. Multichill (talk) 17:44, 6 July 2020 (UTC)
  • Mike nobody picks "public domain mark" as their license, what happens is that for years Flickr users were presented with "Public Domain" as one of their license options. That sound great in general but than Flickr links "Public Domain" to CC PDM page, causing all this confusion. From the Flickr user's point of view they just released their photographs to Public Domain, but we are refusing to accept them because Flickr links that phrase to a wrong page. Flickr is notoriously clueless about copyrights, why else would they be still using cc-by-2.0 instead of 4.0, but that should not interfere with users intentions to release images to PD. --Jarekt (talk) 19:31, 6 July 2020 (UTC)
    • @Jarekt: So we should assume that they actually meant to use CC-0? If we can't do that, then sadly they aren't actually public domain. Thanks. Mike Peel (talk) 19:43, 6 July 2020 (UTC)
      • Mike I do not think we should assume that they meant CC-0. CC-0 is a relatively new invention. I think we should assume that their intentions was the same as the intentions of generation of Commons users that used {{PD-self}}. For example me in 2009 when I created File:Commons Overcategorisation Rules 01.svg I added {{PD-self}} to release it to Public Domain, when on Flickr you do the same by picking "Public Domain" license. I agree that CC-zero is much better (legally clear) way of achieving the same, but just like I should not be relicensing my file from {{PD-self}} to (possibly?) more restrictive CC-Zero, we should not assume that Flickr users who chose to release their files as "Public Domain" really meant CC-Zero. {{PD-Author}} is the template generated over a decade ago for files released on external sites as PD. --Jarekt (talk) 20:01, 6 July 2020 (UTC)
  • @Mike Peel: If I, as a photographer, "waive all my rights etc." (CC-0), why could I not then "identify that work as being free etc." (PDM)? I don't think you can say I don't have that right. Of course I'm playing devil's advocate here also, but the ambiguity is in the license, which is the reason we have this discussion in the first place. Eissink (talk) 20:03, 6 July 2020 (UTC).
  • @Eissink: Then we can link to the original CC-0 declaration, which should be available. Thanks. Mike Peel (talk) 20:27, 6 July 2020 (UTC)
  • @Mike Peel: No, we can't, and no, it shouldn't. The author chose the PDM-license and is not obligated to provide a license for his or her considerations. Thank you, Eissink (talk) 20:32, 6 July 2020 (UTC).
    • @Eissink: There is no such thing as a "PDM-license". Thanks. Mike Peel (talk) 20:36, 6 July 2020 (UTC)
  • @Mike Peel: You automatically get those rights, and you also get the ability to abandon them (i.e. give them up, or waive them) if you want (or sell them, of course). That is almost certainly the effect of using such a notice on your own works. There was a court case where Carol Highsmith specified public domain status for many photos she donated to the Library of Congress, then Getty was selling them without attribution, and she lost her case over that -- they were in fact public domain at that point so Getty did not have to attribute them (in the U.S. anyways). You do need to have an overt, explicit act to make that happen, but placing this mark on your own works should do that. Carl Lindberg (talk) 21:22, 6 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose Note that the persons who use the PD mark are obviously not familiar with the use of licenses otherwise they would have chosen a relevant license. There is something a little bit immoral in taking advantage of these people's unquestionable lack of knowledge about the licenses and potential protections that go with it. Simply try to contact the Flick authors who have content potentially good, to ask that they chose a valid license. Christian Ferrer (talk) 18:20, 6 July 2020 (UTC)
  • Christian Ferrer, I do not think we should be protecting Flickr users from themselves as we with our superior legal knowledge would be taking advantage of them. Here on Commons we do not allow relicensing from less restrictive to more restrictive licenses and I do not think we should be asking others to do the same on our sites. Also some Flicker users choosing "Public Domain" know exactly what they are doing, for example see File:Jonathan roth 5182943.jpg by User:Slowking4 who has been on Commons since 2007. --Jarekt (talk) 20:12, 6 July 2020 (UTC)
  • Of all of the arguments here, I think yours is the strangest Christian Ferrer. Can you give me any possible explanation for why someone would tag their own work "public domain mark" other than that they intended to release it into the public domain? Most people outside of our bubble on this project have never heard of Creative Commons, but they have heard of "public domain", and seeing "public domain mark" and thinking it meant the same thing as "public domain" is the most reasonable possible interpretation. The Squirrel Conspiracy (talk) 21:07, 6 July 2020 (UTC)
After to have done hours and hours of maintenance work here, it is obvious to me that some people are completely foreign to the concept of copyright and to the concept of license, therefore at the question "God, why they do that?" 1/ I have no answer 2/ this question can be asked in many, many and many other situations without there being a possible answer either. Christian Ferrer (talk) 03:58, 7 July 2020 (UTC)
  • If your argument is "we shouldn't take advantage of Flickr users' ignorance": Note the options that are actually available on Flickr. For "Attribution", there isn't even a reference to Creative Commons at all. How is it OK for Flickr to foist upon them some random "Creative Commons license" that they never heard of, when all they chose was "Attribution"? If we accept that kind of lack of rigor as OK, then I don't see how PDM, which says "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission," is not acceptable. (The problem with contacting Flickr users to change the license is that many of them are inactive; we don't want to deny ourselves access to content that the author intended to release into the public domain, just because they can no longer be found.) -- King of ♥ 22:10, 6 July 2020 (UTC)

New language for Commons:Flickr files#Public Domain Mark[edit]

I've drafted up some new language for Commons:Flickr files#Public Domain Mark, below:

Current language:

The Public Domain Mark or PDM is a tool made by Creative Commons to mark works that are already known to be part of the public domain, but doesn't specify why they are. Sadly, quite a few photographers mistakenly mark their own photos with the PDM, and their intentions aren't always clear. Do they mean the photo is public, as opposed to private? Do they mean anyone can use it as long as they're not making money off of it or don't change it? (noncommercial/no derivatives) Or did they mean CC0? After multiple discussions[1], the consensus on Commons is to not accept PDM as a license. PDM is however frequently used on Flickr for actual public domain works:

Such works can be uploaded, but you must figure out first what license applies! If you need help, ask on the copyright village pump.

Proposed language:

The Public Domain Mark (PDM) is a tool made by Creative Commons to mark works that are already known to be part of the public domain, but it does not specify why those works are in the public domain. Some photographers mark their own photographs with the PDM, believing that they are releasing their work into the public domain. After multiple discussions,[1] the consensus on Commons is that Public Domain Mark is not a license, but that it is reasonable to conclude that when an author applies PDM to their own work, they are indicating intent to release their work into the public domain.

  • If an individual selects PDM for their own work, use {{PDMark-owner}}. Do not use PD-author or CC-0.

PDM is frequently used on Flickr for works which are ineligible for copyright or where the copyright has expired. For example:

Such works can be uploaded, but you must figure out first what license applies! If you need help, ask on the copyright village pump.

(this will be updated once the thread is archived)

If any changes need to be made, please suggest them below. Sincerely, The Squirrel Conspiracy (talk) 03:37, 1 July 2020 (UTC)

  • It's good, but for "PDM is frequently used on Flickr for actual public domain works" I'd use "PDM is frequently used on Flickr for works which are ineligible for copyright or where the copyright has expired" --ghouston (talk) 03:54, 1 July 2020 (UTC)
    Or more simply: "Of course, PDM is also frequently used on Flickr for its intended purpose." -- King of ♥ 04:08, 1 July 2020 (UTC)
    Ghouston's language inserted. The Squirrel Conspiracy (talk) 06:19, 1 July 2020 (UTC)
  • I would change "Many photographers mark their own photographs with the PDM" to "Occasionally some photographers mark their own photographs with the PDM", to emphasis that the practice is not to be encouraged for Commoners. -- King of ♥ 04:05, 1 July 2020 (UTC)
    Changed Many to Some. The Squirrel Conspiracy (talk) 06:19, 1 July 2020 (UTC)

New template PDMark-owner[edit]

I've mocked up the proposed template {{PDMark-owner}}:

Creative Commons Public Domain Mark This file is made available by its copyright holder under the Creative Commons Public Domain Mark 1.0.
While the Public Domain Mark is not intended to be used as a license, community consensus (insert link when discussion is closed) has found that when a copyright holder applies the PDM to their own work, they are indicating intent to release their work into the public domain. If a file is tagged PDM by someone other than the copyright holder, a more specific copyright tag such as one found at Commons:Copyright tags/General public domain must be applied.

Any comments are welcome. -- King of ♥ 03:50, 3 July 2020 (UTC)

File names containing ®, ™, ©, and other intellectual property signals[edit]

We appear to have about a thousand files containing the trademark registration symbol (®) in their file names (e.g., File:Portrait Innovations® ^ Claire's - panoramio.jpg, File:® MADRID P.L.M. CAJA MÁGICA-PANO-SUR - panoramio (3).jpg), a few dozen with the trademark registration symbol (™), and hundreds more with the copyright registration symbol (©) (here's one with both of those, File:Rua Custódio Ferreira da Costa - PU1JFC ™ ©.JPG). I propose that, other than as a stylistic element, we should remove intellectual property signals like these from file names, for several reasons:

  1. It is not the job of Commons to project or protect intellectual property claims of file uploaders
  2. It is confusing to have works on a free media site with titles that may appear to contradict the terms of our licenses
  3. We don't know (nor should it be our responsibility to know) whether a name or work actually has the registration signified by the mark
  4. Trademarks and copyrights lapse or expire eventually, so the use of the mark eventually becomes inaccurate for all of them
  5. Removing them reduces the instances of otherwise unnecessary title elements that are difficult for users to type on a standard keyboard

Unless there is already a rule to this effect of which I am unaware, this seems like a common-sense approach to me. BD2412 T 16:13, 26 June 2020 (UTC)

  • Symbol support vote.svg Support Provided that actual "copyvio" material (such as non-free logos or incompatibly licensed media) is removed at the same time. ShakespeareFan00 (talk) 17:50, 26 June 2020 (UTC)
  • Symbol support vote.svg Support Perhaps we should also just blacklist those symbols in the future, no reason to include them in a filename. -- King of ♥ 19:58, 26 June 2020 (UTC)
    • I would definitely support that also. BD2412 T 22:13, 26 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose There is nothing wrong with a © for example. See {{Attribution}} for example. If it is not our job to tell someone if there is a trademark then we should delete {{Trademarked}} for example. It is just a file name and it is not important. So no need to waste time renaming thousands of files. --MGA73 (talk) 21:43, 26 June 2020 (UTC)
And we can delete {{Wikimedia trademark}} also :-) --MGA73 (talk) 21:47, 26 June 2020 (UTC)
This has nothing to do with whether the content of the file is subject to trademark protection, only whether the itinerant symbols should be used in filenames. BD2412 T 22:12, 26 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose It is the job of Commons to denote the intellectual property claims of file uploaders; that's why we put a proper license on works. Likewise, copyrights lapse on all these licensed works, but we still include the licenses on the page. I'm not seeing the value in mass file renaming, given our usual restraint in file renaming.--Prosfilaes (talk) 22:23, 26 June 2020 (UTC)
    • It seems that quite often the symbols use in the file names do not correspond to any actual intellectual property claims of file uploaders, much less the proper license for the work. BD2412 T 22:45, 26 June 2020 (UTC)
  • Not sure that would be a great policy, but not strongly opposed.
    1. It's not the job of Commons, but it might be the job of the uploader.
    2. None of them contradict any of our licenses. Trademark-related symbols are completely unrelated, and copyright symbols simply state that copyright exists, which is necessary to license it. PD files don't need them, of course.
    3. The uploader might know. Removing them may seem to indicate we don't think they are accurate.
    4. Trademarks don't necessarily expire. They can be renewed indefinitely (but must be renewed fairly frequently). Removing copyright symbols for PD works, sure.
    5. This seems like a reasonable concern. On the other hand, filenames can be any language, and languages in non-latin scripts (or even accents) can also be just as hard to type, and we should not be touching those without reason.
  • I would definitely try to avoid these characters when constructing filenames from source text -- it seems like the Panoramio examples might be instances of that. But if an uploader intentionally puts one there, not sure it should be policy to remove them. You might even claim that it is removing copyright-protection information. Carl Lindberg (talk) 23:04, 26 June 2020 (UTC)
  • Symbol support vote.svg Support Changing existing files except if and only if that information is moved to the file description page and Symbol support vote.svg Support blacklisting those symbols in file names for future uploads. Frankly, if it's not something that can be typed on keyboard by your average user (accounting for that different countries include different characters on basic keyboard layouts), it shouldn't be in a file name, because it unnecessarily hampers re-use. A file name is also not an appropriate place to store copyright/license information, that's what the description page is for. The Squirrel Conspiracy (talk) 05:46, 27 June 2020 (UTC)
  • Meh. If those symbols doesn't mislead the user, there's no reason to remove them from the filename. They can be removed if there's another qualifying rationale at COM:FNC, or if the symbol is misleading (like © in a public domain work, unless © is related to the file itself). Blacklisting those symbols is a good idea though, since there's really no reason why those symbols should be present in the first place if the file description can do the same job but better. --pandakekok9 07:08, 27 June 2020 (UTC)
@Pandakekok9: I agree that descriptions are better than file names. And that is why I think we should rename a lot less. :-) --MGA73 (talk) 07:53, 27 June 2020 (UTC)
These symbols are always going to be misleading to some extent. Copyrights and trademarks not only expire eventually, but are also jurisdiction-specific. A term may have a trademark registration that is valid only in Korea, or only in Peru, or only in Iceland, and is invalid in the rest of the world, or even claimed by someone else in another country. At some point, they will mislead. BD2412 T 14:39, 27 June 2020 (UTC)
  • Symbol support vote.svg Support It is somehow copyrighted and I see no reason to include it in the title. BTW, I like the proposal made by King of Hearts. --A1Cafel (talk) 16:55, 29 June 2020 (UTC)
  • Should be written in guidelines for good file names, but should not be an automated filter or renaming reason. --GPSLeo (talk) 08:38, 30 June 2020 (UTC)
    I'd understand why it shouldn't be the sole renaming reason, but why not an automated filter? pandakekok9 12:24, 30 June 2020 (UTC)
    Because it is just a minor style problem and nothing that should force creating redirects with all the problems redirects have. I do not want automated filters because sometimes these symbols might be useful to describe the content and I do not want to start blocking symbols because that would open discussions on blocking of many more symbols too. --GPSLeo (talk) 12:37, 30 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose too disruptive for little benefit. Points 1, 3 and 4 are actually arguments saying we should not pay any attention to it. Separate proposals for each character would be less disruptive.--BevinKacon (talk) 16:36, 30 June 2020 (UTC)
Symbol oppose vote.svg Oppose what nonsense censorship is this?--RZuo (talk) 22:05, 30 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose Most licences require you to preseve copyright notices. For example, you can find the requirement in all Creative Commons licences with the "BY" attribute. If we remove copyright notices from file names, there's a risk that we accidentally violate the licensing terms. --Stefan2 (talk) 22:42, 30 June 2020 (UTC)
    • In that case, do you think all files for which some kind of copyright is claimed should have "©" in the filename? Otherwise, we will be leading readers to think that some files having them means those not having them have no such claim. BD2412 T 17:42, 6 July 2020 (UTC)
  • Is it possible to make the presences of these characters a warning when trying to use them, which requires a specific override step to make sure you really wanted them? Like you get when trying to upload over the same file? Carl Lindberg (talk) 00:31, 1 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose It somewhat makes sense to have a clickthrough when one uploads the file with such symbols offering to 1) remove them 2) substitute them for '(c)' '(r)' and '[tm]' or 3) keep them as is. I would definitely oppose mass renaming, especially since I really hate .jpg extention that is automatically applied to .jpeg uploads during the rename. ℺ Gone Postal ( ) 07:09, 2 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose, on generic (censorship) and specific (licensing) basis. And let’s get rid of the ban on SMP characters, where are located those pertaining to CC licenses. -- Tuválkin 21:42, 4 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose, while I fully understand the proposer's side-of-view and agree that Wikimedia Commons should try to make everything as simple as possible for re-users, Creative Commons files remain copyrighted © (excluding Creative Commons-Zero, obviously) and this symbol doesn't mean "all rights reserved" or "no re-use", many logos on Wikimedia Commons are registered trademarks and while they may be free to use, this is not always without certain legal restrictions. Plus, if a file actually represents the characters then their inclusion is very descriptive of the depicted file itself. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:08, 4 July 2020 (UTC)

Proposal_for_naval_ship_categories[edit]

See Commons_talk:Categories#Proposal_for_naval_ship_categories Stunteltje (talk) 08:12, 30 June 2020 (UTC)

Increase default number of lines of HotCat suggestion[edit]

5 for now

as per User:MPF's suggestions special:permalink/429968795#Making_Hot_Cat_easier_to_use and special:permalink/429968941#Making_Hot_Cat_easier_to_use. I think since hotcat is one of the most popular gadgets, changes should receive some broader consensus. Please state your opinion and if yes the number you like.--RZuo (talk) 22:05, 30 June 2020 (UTC)

Increase to 10.--RZuo (talk) 22:05, 30 June 2020 (UTC)
Symbol support vote.svg Support increase to 10. Buidhe (talk) 22:03, 1 July 2020 (UTC)
Symbol support vote.svg Support 10 options. —Justin (koavf)TCM 00:51, 2 July 2020 (UTC)
Symbol support vote.svg Support Good idea. --A1Cafel (talk) 02:56, 2 July 2020 (UTC)
Symbol oppose vote.svg Oppose I never use the suggestions I only sometimes accidentally click on one. Do not increase the size if there is no option to turn it off. --GPSLeo (talk) 10:09, 2 July 2020 (UTC)
Symbol support vote.svg Support I think more options is a good idea. --MGA73 (talk) 21:23, 4 July 2020 (UTC)
Symbol support vote.svg Support -- Tuválkin 21:40, 4 July 2020 (UTC)
Symbol support vote.svg Conditional support, only if it can either be turned off or will be an optional feature. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:04, 4 July 2020 (UTC)

Aggressive wording on speedy deletion template(s)[edit]

I think that some of the wording needs to be dialed back on some templates. I just got this. The file (File:Kugluktuk Airport terminal.jpg) was uploaded from Flickr and reviewed by an administrator at the time. It has since been uploaded as a larger file at File:Airport Terminal - Kugluktuk, Nunavut, Canada.jpg. It's not my file and I don't care if it is deleted but the wording on the template posted on my talk page is a bit much. It says, in part, "Wikimedia commons doesn't permit uploading personal files/copyright violations,spams and files without a source/license. If you continue to upload similar files you may have to face some strict administrative actions. Please act wisely!" So I may "face some strict administrative actions" because the file I uploaded was not large enough. Are you trying to drive people away? CambridgeBayWeather Talk 16:25, 4 July 2020 (UTC)

It clearly looks like it was written by a non-native English speaker. Can anyone find this template? I'm not able to find it. -- King of ♥ 17:05, 4 July 2020 (UTC)
@CambridgeBayWeather: This message was left by Deletion Notification Bot, which is managed by Eatcha. It uses subpages of its user page for at least some of its notifications. It looks like you got User:Deletion Notification Bot/SDEL, which is the generic speedy-deletion template. One oddity here is that it's not usual to notify the uploader that a file has been tagged with {{Duplicate}} (well, I don't, anyway), but this file was tagged with {{Speedydelete}} so the bot couldn't tell that it was tagged as a duplicate. --bjh21 (talk) 19:41, 4 July 2020 (UTC)
@King of Hearts: the template is probably this one: User:Deletion Notification Bot/SDEL. I found these similar templates also: User:Deletion Notification Bot/personalNO / User:Deletion Notification Bot/NOADS / User:Deletion Notification Bot/COPYVIO. Eissink (talk) 20:00, 4 July 2020 (UTC).
@CambridgeBayWeather: I agree that the template seems a too aggressive for a duplicate. I removed the "warning" so it does not look bad on your talk page. You can revert if you wanna keep it as a memory. Or remove it completely. --MGA73 (talk) 21:30, 4 July 2020 (UTC)
Thanks @MGA73:. I'm not bothered much about the warning on my page but that it still exists and will be put on, possibly, a new editors page anddrive them away. CambridgeBayWeather Talk 22:06, 4 July 2020 (UTC)
CambridgeBayWeather Sorry, I wasn't aware that duplicates were categorized in speedy deletion category. Removed "If you continue to upload similar files you may have to face some strict administrative actions. Please act wisely!" from the template. // Eatcha (talk) 05:05, 5 July 2020 (UTC)
And I case anybody wants to improve the templates please do so or maybe create real templates but I'm not really good at creating templates. // Eatcha (talk) 05:19, 5 July 2020 (UTC)

Belize maps for British Honduras timeframe[edit]

Should the old maps of Belize in Category:Maps of Belize by year be renamed to Category:Maps of British Honduras since Category:British Honduras covers 1862-1981? For example, Category:1861 maps of Belize goes into Category:1861 in Belize which would go into Category:Belize in the 1860s but in contrast Category:1900 maps of Belize goes into Category:1900 in Belize (I just created) which is a subcategory of Category:Belize in the 1900s which redirects to Category:British Honduras in the 1900s. Break the decade redirect with separate categories or rename the whole thing to British Honduras? I think it makes more sense to rename the map categories to British Honduras since it's the exact same area. If so, then I'll start on the complicated renaming suggestions (including the older Category:British Honduras in the 1820s which don't actually make sense). -- Ricky81682 (talk) 21:31, 5 July 2020 (UTC)

@Ricky81682: It's a bit more complicated I'm afraid. What we now refer to as "Belize" became an independent country in 1981. However, the name of the territory was officially changed to "Belize" in 1973 and it's been unofficially known as "Belize" (including on maps) since at least the early 1800s. In the 1700s, it was known as the "territory allotted to English settlers". Not sure how any of that should be reflected in our map categorization. Kaldari (talk) 17:00, 6 July 2020 (UTC)
Also the whole Category:Maps of Belize by year tree should be deleted anyway, as there is very rarely more than 1 map of Belize per year. It only serves to make the maps harder to find. Kaldari (talk) 17:01, 6 July 2020 (UTC)
@Kaldari: Many times we just use the current location names so I'd suggest call it "maps of Belize" for them (Germany as an entity didn't really exist in the 17th century or earlier). Keeping it limited to the exact 1862-1981 definition may be the cleanest option. Luckily the borders are the same or it gets really, really ugly fast. As to the yearly maps, that's rare for the older maps I agree but for the recent years (2000s and 2010s), I expect a lot of maps for different cities and states and there may be a few years with an absurd number of maps (you can always find an oddball like Category:1864 maps of Virginia) but I agree, we have way, way too many maps split to the individual year for some reason. -- Ricky81682 (talk) 21:24, 6 July 2020 (UTC)