This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I suggest that CC-BY 4.0 International should be the default suggested licensing when using the upload forms in Wikimedia projects (example here at Commons) for own works, instead of the current CC BY-SA 4.0 license, sometimes with dual GFDL licensing (link to Wikipedia form as example). The main difference would be that derivatives are not required to have the same license. Reasons for changing to CC-BY 4.0 are:
It is a more permissive license.
It makes it much easier to combine and mix works. The combination of the two images at right, for example, would not have been possible at all if the images were licensed under let's say CC BY-SA 4.0 for the first one and CC BY-NC 2.0 for the other. However, if either was CC-BY 4.0 it would have been permitted. See WP:Adaptation for further information in this regard.
Most uploaders may very well be as willing to upload under CC-BY, but may not be familiar with the differences between having SA or not. The current Upload Wizard suggestion thus makes lots of works receiving a more restrictive licensing than necessary. Just because uploaders can upload under the most restrictive license Wikimedia has to offer doesn't mean they need to be presented with that option by default. Those who still want to put the additional SA restriction would still be able to actively choose so.
The currently suggested dual licensing with CC BY-SA 4.0 with GFDL such as in Wikipedia (link to form) adds two licenses that work on similar copyleft principles, but confers a lot of extra read for those who want to know what GFDL means, since it doesn't provide the short presentation as given in Creative Commons licenses (compare GFDL license page to the CC BY-SA 4.0 page. It would therefore be both easier for uploaders if we simply dropped GFDL from the default license suggestion. Again, those who do want to choose dual licensing for some reason would still be able to actively choose so.
I am now also bringing this to a Wikimedia-wide attention, with an entry in Meta, in Wikipedia, in Wikiversity, in Wikisource and in Wikinews, while the other sister projects link directly to the upload form here at Commons. I want to know if you agree with this suggestion, and we can then bring it to Wikimedia's legal team for review before implementation. I know the change is technically not that hard, since we only need to change the upload form options, not the licenses of any already uploaded works, nor the overall licensing of any wiki. Mikael Häggström (talk) 19:03, 10 September 2018 (UTC)
Difficulty of implementation is irrelevant. It would be trivial to make any licence default licence. The question is which one should be default. And as such the licence that preserves free culture aspect should be the default. ℺ Gone Postal (〠✉✍⏿) 08:23, 11 September 2018 (UTC)
Support Let's do it! Years have passed, we have discussed this continually since before its release, and there has been regular support with no convincing opposition that I have seen. Blue Rasberry (talk)21:21, 10 September 2018 (UTC)
The length of time that something was discussed is not an argument to implement change something that should not be changed. I also do not normally use CC-BY-SA licence, I use FAL, but I would not be trying to trick unknowing new users to release their work under the licence where somebody else can then slightly alter their work and disallow the original creator the right to use the result. ℺ Gone Postal (〠✉✍⏿) 08:23, 11 September 2018 (UTC)
This proposal is not about allowing people to use less free licences, it is about tricking people into the whole 'open content' mindset completely forgetting about the free culture aspect. ℺ Gone Postal (〠✉✍⏿) 08:23, 11 September 2018 (UTC)
Strongest support ever. Having more permissive licence is a very good thing as making things on top of it becomes easier and hassle-free. acagastya21:28, 11 September 2018 (UTC)
Why do you consider tricking new users into the licence, where somebody can take their work, alter it, and then refuse to share it freely with the original creator as "a very good thing"? ℺ Gone Postal (〠✉✍⏿) 13:11, 12 September 2018 (UTC)
Oppose
Oppose per my following point-by-point rebuttal.
Being a more permissive license is not per se a reason to choose CC-BY. Solely by that logic (yes, I know you give other reasons) CC0 would be more preferable. However, copyleft versus non-copyleft is an eternal debate in the free software and free culture movement which ought not need to be rerehearsed here.
Your NC example isn't relevant to Commons, and arguably isn't something we want to promote, given that Wikimedia is dedicated to Free Culture, which means avoiding NC restrictions. Your proposed derivative work would still be subject to the NC restrictions of the NC component.
BY-SA images can be used in a BY or even fully copyrighted text—so BY-SA images could be used in journals as long as the appropriate credit is given and any changes to them are released under BY-SA. This is the difference between an adaptation and a compilation.
Do you have any evidence for you claim about the willingness of uploaders?
See my comment in the discussion section.
So absent any well-argued reasons by the proposer, and out of caution of further weakening the rights of non-legally-minded casual contributors, I will oppose this. BethNaught (talk) 22:04, 10 September 2018 (UTC)
Reply: I do think being more permissive is preferable, because of the restrictions that SA confers in reusing the content in the vast amount of CC BY articles out there, where you could no longer simply state that the all content is CC-BY. Now, you must instead for example state that the text is CC-BY but that some images are CC BY-SA, or for simplicity state that the whole article is CC BY-SA, making the whole article more restrictive. Indeed NC is not relevant within the Wikimedia project, but it is used about as much as other Creative Commons licenses outside of Wikimedia (see (Wikipedia article for statistics). I would have preferred CC0 too, and that's what I use myself for all own works, but I think that would cross the line of weakening the rights of non-legally-minded casual contributors. CC BY, on the other hand, lets contributors keep credit for their work, while at the same time allowing much more ease in reusing the content, whether as adaptation or compilation. As for willingness of uploaders, I have no study, but I find lots of works uploaded as CC0 which is substantially more permissive. Mikael Häggström (talk) 04:30, 11 September 2018 (UTC)
Oppose The default won't affect me; I use CC0. But defaults are for people who need guidance. Copyleft is a foundational part of the Wikimedia projects. Defaults should stay consistent per the principle of least astonishment. For example, any text I contribute to Wikipedia I'm placing by default under a copyleft license. Changing defaults confuses people who use defaults, and it's really not nice to confuse people about the license on their own copyrighted material. Ntsimp (talk) 23:06, 10 September 2018 (UTC)
I always use CC0 too for own works, but that's on the far end of permissiveness, and using it as a default might cause those not familiar with the licenses to later regret it. I don't think that issue is that significant for CC BY, however, since they keep their credit for the works. I do think the next restrictive step to CC BY SA, however, is one step too far. Also, I think CC BY would actually be less daunting for those who are unfamiliar with licenses, because it has fewer clauses in its main terms for those who look them up, especially when compared to dual licensing with GFDL. Mikael Häggström (talk) 04:41, 11 September 2018 (UTC)
Oppose I think that the whole shift away from freedom and towards "open source" and "open access" is a poor one. There are some works which are better suited to be licenced under more permissive terms without copyleft restrictions, and nothing stops people from choosing those less freedom preserving licences, however, the default should be something that will remain free. ℺ Gone Postal (〠✉✍⏿) 00:10, 11 September 2018 (UTC)
I don't find it to be freedom when the content won't be disseminated at all to other Creative Commons works where creators are either not aware of how to (or simply do not want to put the effort in) properly applying the SA part of the license of Wikimedia works. Mikael Häggström (talk) 04:51, 11 September 2018 (UTC)
Then you are just incorrect. Freedom to restrict freedoms of others is not "freedom" it's privilege. If some reuser says "I want to take your work and be free to do whatever I want with it, but after I am done you won't be able to use your own altered work any longer, losers!" Then we do not want such reusers. ℺ Gone Postal (〠✉✍⏿) 08:16, 11 September 2018 (UTC)
I'm not a favor of such reusers either, but I don't find it as reason enough to make my work more restrictive in the first place, denying good-faith editors at CC BY platforms to use the material. Surely they can ask for permission to reuse the content in their projects, but so it is with outright copyright too. Mikael Häggström (talk) 09:17, 11 September 2018 (UTC)
"I don't find it as reason enough to make my work more restrictive in the first place" then don't, it is your work, you can do anything you want, you can actually skip an extra step and publish under proprietary licence right away. But please do not trick new users into thinking that they will publish their work and it will be freely available afterwards and that they will themselves be able to benefit from fruit of their labour; because with CC-BY that will be decided by the reuser later on and they will have no way to recall that licence. ℺ Gone Postal (〠✉✍⏿) 09:50, 11 September 2018 (UTC)
Oppose Wikimedia is in a good position to encourage the creation of yet more open projects. We don't need a more permissive license because Wikimedia is big enough that it doesn't need a few more derivatives; it is far more important that those derivatives be open, and possible to use for other open projects - including Wikimedia itself. People using uploaders' original work to create commercial content that we can't then use is not a good possibility to allow. ARR8 (talk) 04:49, 11 September 2018 (UTC)
It's a good point that CC BY does indeed allow other projects to impose a more restrictive license when reusing such works, but my impression is that the SA portion itself practically causes even more restriction, since CC BY is so common on external platforms. Mikael Häggström (talk) 06:58, 11 September 2018 (UTC)
The problem of there being a lot of CC-BY external projects and not enough CC-BY-SA or FAL ones will not be resolved by tricking new users into a less free license, making them lose the ability to later use the fruit of their own work. ℺ Gone Postal (〠✉✍⏿) 08:28, 11 September 2018 (UTC)
The main issue here seems to be which paths we believe reused work take; As I understand you believe works with the more permissive CC BY will mainly receive even more restrictive licenses, overall creating a more restricted world of knowledge. I believe the greater dissemination by CC BY itself will overcome this. Even with external restrictive licenses or copyright, the free licensing of the works here at Wikimedia will not be affected. Mikael Häggström (talk) 09:32, 11 September 2018 (UTC)
But the re-use of such derivative works in wikimedia projects can be made impossible. CC-BY is allowed on commons and other wikimedia projects and should be allowed in future. CC-BY must not be a guideline (or default) and should not even be recommended, because it thwarts the spirit of wikipedia, namely that free knowledge should remain free in the future. --Smial (talk) 11:11, 11 September 2018 (UTC)
This is my point. I don't believe that greater use of CC BY will end up creating more content; on the contrary, the main change that would come from this is removing the requirement for derivatives to remain free. Even if people will be more comfortable uploading content out of concern for creating future derivatives of their own work, the people who did not have this concern may end up further restricting derivatives of the work. This is not to mention third parties who may scour Commons for free media to use with no intention of CC-licensing any derivatives. If people anticipate creating restricted derivatives of their work in the future, they can manually license it CC BY. If people are unsure, or even have no plans to create derivatives of their work at all, we should try to encourage them to use SA. ARR8 (talk) 15:22, 11 September 2018 (UTC)
Oppose as a uploader who uploads under a CC-BY-SA-3.0-AU, why should we default the upload form/UploadWizard from CC-BY-SA-4.0 to CC-BY-4.0 because a few don't want the "burden" of having to use the same license, next we will be removing the -SA option? Bidgee (talk) 10:44, 11 September 2018 (UTC)
The currently suggested dual licensing with CC BY-SA 4.0 with GFDL ... is actually incompatible in a strict sense: this is a misleading statement. It implies that multi-licensing is somehow not allowed. Yes of course CC BY-SA and GFDL are incompatible, otherwise what would be the point of multi-licensing? Again, It would therefore be ... more legally correct if we simply dropped GFDL: as long as the work is also licensed under CC BY or CC BY-SA, there isn't a legal problem. Nothing in the WP article you link says that multi-licensing is a legal problem. BethNaught (talk) 21:51, 10 September 2018 (UTC)
Comment In favor of CC BY-SA I'd like to point out it's easy turning this license into a CC BY, because re-licensing stuff with a more permissive license is OK, isn't it? The contrary is not true: Once the user published a file with CC BY there is no turning back to CC BY-SA ('courtesy' week aside?). Since CC BY-SA is somehow the more reversible license within 'Commons licensing ecosystem', probably is not a bad choice when it comes to select the default one. strakhov (talk) 08:44, 11 September 2018 (UTC)
I'm pretty sure it's the opposite way: You can re-license stuff with a more permissive license (unless the license explicitly says otherwise, such as in SA). In this case you can make a compilation of CC BY works and release it under a CC-BY SA license, but you can't use CC BY-SA material and simply drop the SA requirement that the original creator has put there. Mikael Häggström (talk) 09:10, 11 September 2018 (UTC)
I'm talking about a pic uploaded by John Doe. If he uploads it under a CC BY license... he cannot change his mind and ask people to share that pic under a CC BY-SA license (because the CC BY part is irrevocable). On the contrary, if he initially uploads it under a CC BY-SA license, he could change that license for a CC BY (or CC0), three or four years passed. strakhov (talk) 10:08, 11 September 2018 (UTC)
To be clear: When I mention the word "reversible", your thoughts are on the re-user, mine on the uploader. strakhov (talk) 10:19, 11 September 2018 (UTC)
Your words: "Most uploaders (...) may not be familiar with the differences between having SA or not." Using CC BY-SA by default gives those uninformed uploaders the flexibility to change licensing (to CC BY or CC0) once they have get in touch with free culture and their nuances. CC BY does not. strakhov (talk) 10:26, 11 September 2018 (UTC)
Proposal to add additional language to existing block templates
Proposal has almost unanimous support, so I'm closing this as successful. I've updated the English version of the templates, but other languages will need to be updated as well. Please help with this if you can, by editing the various language subpages (e.g. Template:Blocked/ca). Guanaco (talk) 09:09, 1 September 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The current templates, such as the {{Blocked}} template, do not provide information about how to appeal a block. In addition, the {{Blocked user}} and the {{Indefblockeduser}} templates look as if they are written for administrators, rather than users. So, the following versions of the templates have been revised to be more user-friendly and provide information about how to request an unblock, should they believe they were blocked in error. The indef block also provides an email address, should the user's talk page also be blocked. This is an alternative to the above proposal for a universal block template. CaroleHenson (talk) 00:40, 13 July 2018 (UTC)
1. {{Blocked}}: You have been blocked for a duration of {{{1}}} heading
You have been blocked from editing Commons for a duration of {{{1}}} for the following reason: {{{2}}}. If you wish to make useful contributions, you may do so after the block expires. If you believe this block is unjustified, you may add {{Unblock}} below this message explaining clearly why you should be unblocked. See block log. For more information, see Appealing a block.
Azərbaycanca - Български - বাংলা - Català - Česky - Dansk - Deutsch - Deutsch (Sie-Form) - Zazaki - Ελληνικά - English - Esperanto - Español - Euskara - فارسی - Suomi - Français - Gaeilge - Galego - עברית - हिन्दी - Hrvatski - Magyar - Italiano - 日本語 - 한국어 - Македонски - മലയാളം - မြန်မာဘာသာ - Plattdüütsch - Nederlands - Norsk bokmål - Occitan - Polski - Português - Română - Русский - Simple English - Slovenščina - Svenska - ไทย - Türkçe - Українська - 中文（简体） - 中文（繁體） - +/−
You have been blocked from editing Commons. The reason for the block is available in the block log as is the name of the administrator who blocked you. If you believe this block is unjustified, you may add {{Unblock}} below this message explaining clearly why you should be unblocked. For more information, see Appealing a block.
You have been blocked indefinitely from editing Commons. See the block log for the reason that you have been blocked and the name of the administrator who blocked you. If you believe this block is unjustified, you may add {{Unblock}} below this message explaining clearly why you should be unblocked. For more information, see Appealing a block.
Azərbaycanca - Български - বাংলা - Català - Česky - Dansk - Deutsch - Deutsch (Sie-Form) - Zazaki - Ελληνικά - English - Esperanto - Español - Euskara - فارسی - Suomi - Français - Gaeilge - Galego - עברית - हिन्दी - Hrvatski - Magyar - Italiano - 日本語 - 한국어 - Македонски - മലയാളം - မြန်မာဘာသာ - Plattdüütsch - Nederlands - Norsk bokmål - Occitan - Polski - Português - Română - Русский - Simple English - Slovenščina - Svenska - ไทย - Türkçe - Українська - 中文（简体） - 中文（繁體） - +/−
Support This means, however, that the numerous subpages with translations will have to be updated too. This may take some time. De728631 (talk) 09:57, 13 July 2018 (UTC)
Support per above and my previous comments on the subject. This is a good step towards making the blocking and appeal process clearer to blocked users. clpo13(talk)15:33, 13 July 2018 (UTC)
Support the first two. Strongly oppose the last one due to the use of OTRS for this purpose. The use of OTRS for standard unblock requests is out of the remit for the volunteer response team. The only unblock requests we generally handle are those that could potentially involve personally identifiable information (such as impersonation of a real person blocks). I see no indication whatsoever that the OTRS team was even aware of this request to drastically change our remit posted to Commons:OTRS/Noticeboard or anywhere else that would allow people whose job you are changing to comment. Second, while there are 96 agents with access to the info-commons queue there are relatively few admins who have access. This proposal would invariable inundate that queue with requests that the majority of agents there would simply not be able to answer leaving actual requests they can answer buried amongst the others. Third, UTRS access is granted without question to all enwiki sysops automatically via OAuth. No request required. OTRS not only requires a request but the signing of a confidentiality agreement that I could very much imagine admins here that would otherwise process unblock requests would not want to do. If you are requesting that all admins get this access for processing these requests that would require a whole additional process and a changing of the very foundation upon which OTRS runs. Fourth, the revocation of talk page access and email that would require another method should be extremely rare anyways. Here, it is used for LTAs and (should be used only for) confirmed socks. At least in my opinion. The way forward here should not be to shove all the work for probable bad actors on the unsuspecting volunteers of OTRS who are probably not even aware of this discussion to begin with but to change the way Commons applies these blocks so that the revocation of normal unblock channels is done much more rarely. --Majora (talk) 20:24, 13 July 2018 (UTC)
The email is included in the standard block text but only mentions appealing an autoblock. Again, this is a rare occurrence and would involve private information such as IP addresses. Using OTRS for standard unblock appeals is out of our remit. --Majora (talk) 20:32, 13 July 2018 (UTC)
The support team is able to contact the blocking admin or to post a notice at one of the administrative boards. Of course, the support team does not handle the appeal itself but it can serve as messenger. --AFBorchert (talk) 13:04, 14 July 2018 (UTC)
And say what exactly? You have an unblock request but sorry we can't tell you anything about it? The confidentially agreement is a legally binding document that forbids agents from discussing the details of private conversations held inside of OTRS. Unless that admin is also OTRS with the proper access, which again see point two above, they can't be told any details. This is the way OTRS is set up to run. Any changes to this would require changing that. It is not our job to act as a messenger or a go between. That is putting an unnecessary extra burden on volunteers who give their time to answering these tickets in the first place. --Majora (talk) 13:19, 14 July 2018 (UTC)
@Majora: Again, the member of the OTRS support team can notify one of the administrative boards or the blocking admin. This is common practice at de:wp where indef'd accounts are closed and have no option to appeal on-wiki. In the reply, the OTRS member can provide a link to the opened discussion. Then we have at Commons the option to review the decision to remove talk page access. --AFBorchert (talk) 13:47, 15 July 2018 (UTC)
What is far more likely to happen, to be honest, is that these tickets will fall into a black hole never to be answered or looked at except by the few agents in that queue who actually want to deal with the extra steps that are being forced upon them. Or to deal with the screaming LTAs that are now aware of and encouraged to appeal towards that method (which we have no way to block their email addresses unless we get an OTRS admin involved). For working the permission queues I can tell you that the moment even the smallest amount of challenge arises in a ticket it goes dormant. Never to be looked at for months. If you are so concerned with getting these problems resolved in a timely manner and you picked OTRS to do that you don't know OTRS. --Majora (talk) 13:48, 14 July 2018 (UTC)
@Jeff G.: It seems to be in the blockedtext template only for the purpose of autoblocks, which is described there as a block of an IP address, not a user specifically. Could including it here be considered as expanding the scope of that avenue of appeal to all sorts of blocks, not just autoblocks? I share the concerns about OTRS not being the best avenue for this sort of thing, though if it's the only alternative, then possibly it's OK for now. But the email address was not in the templates being updated, nor the direct links from those templates, unless I'm missing something. They mention emails to administrators, but not OTRS. I'm not sure it's a good idea to include that address here. Carl Lindberg (talk) 16:16, 14 July 2018 (UTC)
(Edit conflict) In my opinion? Yes, at this time. If you really want to allow for email communications as an alternate there are potential alternative methods. Either create a private mailing list such as those that are used by Enwiki's Arbcom or Commons's oversight team. Or ask for a separate queue to be created inside of OTRS to handle these requests and change the rules so that that queue access is granted automatically to all Commons sysops. This would be equal to Enwiki's UTRS and would segregate the tasks from the info-commons due to the problems I outlined above to a different queue that is more regimented as to its purpose. --Majora (talk) 14:26, 14 July 2018 (UTC)
I don't have a problem with that, since the appealing a block link is on the template. If that's ok with others, too, do I just strike it out of the mock-up above?CaroleHenson (talk) 14:35, 14 July 2018 (UTC)
I mean, I'm apparently in the minority here so you can do whatever you wish. But I can foresee the numerous problems with doing this. OTRS is not the proper method to deal with standard unblock appeals like this and it doesn't, and won't, improve communication as has been alluded to by other people. OTRS is a black hole for any problematic tickets. All unblock requests are problematic tickets. This is the opposite of improved communication. --Majora (talk) 14:40, 14 July 2018 (UTC)
@Majora: I agree with what you're saying about permissions-commons, but info-commons tickets are answered quickly and effectively. I'm confident we can handle an increase in volume on this queue. Guanaco (talk) 00:57, 16 July 2018 (UTC)
I have my doubts as I've worked with OTRS for long enough to know what happens there. But like I said, I'm clearly in the minority here so if you wish to reinstate the email address that is completely up to you. I'm perfectly ok with the first two. I'm even ok with MediaWiki:Blockedtext having the email address for appealing specific circumstances (like autoblock). I just don't think that OTRS should be used for a standard unblock appeal process. --Majora (talk) 01:27, 16 July 2018 (UTC)
Support the first two. oppose the last one with the reference to OTRS (like Majora basically). OTRS is there to provide information about the block and its reasons, not a way to unblock. The actual wording is ambiguous. Maybe the Commons ML is the correct place to contact sysops and/or the community. However, it's ok to me if we rewrite the OTRS part, saying that further information –if needed– can be obtained there (where an agent will probably tell the user to write to the sysop that performed the block). --Ruthven(msg)08:22, 15 July 2018 (UTC)
Comment I removed the email address from the third template due to the expressed concerns. As long as the steps for appealing a block remains, I don't think it is necessary and I understand the process issues.CaroleHenson (talk) 13:22, 15 July 2018 (UTC)
Thank you CaroleHenson. I struck out my oppose above. As mentioned previously there are alternatives to using OTRS for this purpose. Mailing lists, private queues, even IRC can be logged if need be and there are bots that do just that for certain wikimedia channels right now (that seemed to be the major complaint of using IRC above). There are alternatives here that I truly believe would make for a far better alternative method to appealing blocks. --Majora (talk) 00:35, 16 July 2018 (UTC)
Comment Giving blocked users information on unblock options seems like a good thing, but on en. what often happens is that a new user responds rapidly with an unblock template that is perfectly reasonably worded from a typical angry-customer point of view (i.e. "X is an asshole and here's why") and the whole thing is on to an indef with no talk page access before the user even has a clue what the rules are. I think a better block template should make it clearer the user should calm down, read the rules first, be suitably obsequious and contrite, and only then try to make use of what may well be their one unblock opportunity before the whole thing turns into a hammer of humiliations from a jaded audience. Wnt (talk) 17:42, 15 July 2018 (UTC)
Comment The proposed updated text for {{Indefblockeduser}} includes "...you may add {{unblock}} below this message explaining....". However, the documentation for {{Indefblockeduser}} says this variant is only used on the User: page, not the User_talk: page. It should be directing any unblock request to the the user's talk page, not to their main user page. —RP88 (talk) 02:55, 17 July 2018 (UTC)
Support - I'm very surprised this was done years ago, Giving blocked users the chance to unblock themselves (under certain conditions) is obviously the right step in the right direction. Easy support. –Davey2010Talk13:09, 22 July 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.
What about transfers from local projects?
Previously, there was a consensus to deprecate GFDL only licensing for new uploads on Wikimedia Commons. Was this intended to include 'transfers' of content from other projects like English Wikipedia. Many of those images were uploaded in good faith, and I would take issue with actively discouraging them being uploaded to Commons, when (but for the licensing) they would have otherwise met the criteria. I would suggest that the GFDL deprecation proposal, be amended to allow for continued transfers PROVIDED the content was uploaded to the local project prior to whatever cutoff date is determined.
ShakespeareFan00 (talk) 17:58, 14 September 2018 (UTC)
This will have serious implications on a lot of projects, and I doubt there will be any consensus outside of this project. Jeblad (talk) 18:43, 14 September 2018 (UTC)
Can I ask that people raising "issues" give clear examples and an indication of size of the problem. I find it hard to believe that in 2018 anyone is uploading photos to Wikipedia with "GFDL" as the only licence "in good faith". The only people I've ever seen use this "backdoor -NC" licence were doing so in very much bad faith wrt our "free content" mission, and simply wanted their photos on Wikipedia and nowhere else. Nearly all of them left years ago. We've had better licences and better default licences for many many years now, so uploading photos in this manner was simply conscious subversion. -- Colin (talk) 20:07, 14 September 2018 (UTC)
If you make a general claim "I've ever seen use this "backdoor -NC" licence were doing so in very much bad faith wrt our "free content" mission, and simply wanted their photos on Wikipedia and nowhere else." then you better back it up with evidence. What you just did was bad faith. Jeblad (talk) 12:10, 15 September 2018 (UTC)
Everyone who has been around Commons for a few years knows what Colin is talking about. No need to single out users. On the other hand, a broad claim of undefined "issues" is not helpful. The decision not to allow new GFDL images has been made, if there are concrete issues left, those can be addressed, and only those. Sebari– aka Srittau (talk) 14:54, 15 September 2018 (UTC)
A total misrepresentation of the issue
The template {{GFDL 1.2 or cc-by-nc-3.0}} is a logical or of the two licenses, but the text on the page reads "Combination of license templates “GFDL 1.2” and “cc-by-nc-3.0” as well as information for commercial use." which is an grammatical and. It is quite common to write and instead of the logical or, it is confusing, and leads to this kind of mishaps as the previous voting on this project. A logical and of two licenses like the two in question does not make sense at all. One says the you are free to use the content, even for commercial purposes, and the other says you can't use it for commercial purposes. The template should be fixed so it make sense, and the only way to fix it is to change the and into a logical or.
Dual licensing and multilicensing imply you chose one of the licenses, not that you use all of the licenses. Using all of mutually exclusive licenses are simply wrong, and a total screwup. Jeblad (talk) 12:42, 15 September 2018 (UTC)
@Jeblad: no, we understand perfectly. The cc-by-nc-3.0 on its own is not an acceptable license for Commons, but this construction was designed to get around that. Nobody wants to use a photograph with GFDL license because nobody wants to include a license text that takes up more space than the actual photo. What are you gonna do, print the whole license text on a coffee mug or T-shirt? Append several pages to a magazine because a GFDL-licensed photo is used? - Alexis Jazzping plz15:03, 15 September 2018 (UTC)
@Jeblad: , I think that it comes from an attempt to speak "non-legalese" English. You are partially correct that some people would misinterpret the logical inclusive or for a common vocabulary and. But I don't think that this misunderstanding has caused many people to vote the way they did. Their misrepresentation of common use case for the images was described by Alexis Jazz quite well. ℺ Gone Postal (〠✉✍⏿) 15:12, 15 September 2018 (UTC)
Take a look at this
The main issue with GFDL is that it requires re-users to include 7 pages of text, which is generally not practical for individual pictures, video or audio. Because of this, this lead to the existence of {{GFDL 1.2 or cc-by-nc-3.0}} which is, in its very essence, a backdoor Creative Commons Attribution-NonCommercial license. After all, nobody is going to include 7 pages of text.
So, because license text is verbose it should not be used? We use a license because it is complete and to the point. This means a license will be verbose. We don't use licenses that breaks with the principle of free use. If someone creates a multilicense-scheme that breaks the principle of free reuse, then we remove that multilicense-scheme because it is logically invalid, not because we don't like verbose licenses. That is simply silly. Jeblad (talk) 15:18, 15 September 2018 (UTC)
The sheer fact that it is verbose, and it requires for it to be legally compliant, the whole of the text of the license to be represented is not only silly it was a central part of the issue. Now, in 2018 it is accepted that this goes against the understood (on commons) principles of having a free license. -- Sixflashphoto (talk) 16:26, 15 September 2018 (UTC)
Basically we are living in the world full of people too used to Twitter character limit and who refuse to understand that on the web 'including' the licence is as simple as giving a link. Soon we may consider all the attribution licences as unfree because they go against the understood principles of having a free licence. ℺ Gone Postal (〠✉✍⏿) 21:44, 15 September 2018 (UTC)
All of those claims are completely false - as with almost all your additions to this discussion - and I suggest you retract them. The pushback against GFDL is specifically because it is being used as a Trojan horse for NC licenses, as you keep ignoring. GFDL requires inclusion of the entire text, not merely the link - in contrast to every Commons-compliant free license. And your ridiculous strawman claim that attribution licenses are potentially unfree demonstrates you have no clue what you're talking about. Pi.1415926535 (talk) 22:17, 15 September 2018 (UTC)
That is a lie or at least a serious misunderstanding of the licence. Even when Wikipedia used GFDL it did not provide GFDL text on the same web page as every article. They simply provided the link on the bottom of the page to the licence. According to the licence you are required to provide the user with the text for that licence ("Include an unaltered copy of this License."[2]). It does not say that that text has to be on the same page where the image is or that the text of the licence must be incorporated into the work. In fact incorporating the text of the licence into the work would technically be prohibited (if you intend to distribute), since the licence text cannot be derived from, and the licence itself is a free licence, thus it demands that you allow derivations. The licence also allows uninfringed use of the original and modified versions, therefore you could perfectly well wear a t-shirt with the GFDL image without having to give everybody a copy of GFDL, but yes, if you want to distribute, then you would have to provide a copy to those you distribute it to. If you are zealous about it, you could just print the text on paper and give it with t-shirt, the cost of paper is negligible in comparison. I do not believe, however, that including the copy of the licence electronically during the sale would be frowned upon by any court. For example, you click buy in some e-shop and you get "You can read a licence here" link in hour confirmation email (you have included the licence with the distribution of the work). ℺ Gone Postal (〠✉✍⏿) 06:20, 16 September 2018 (UTC)
@Gone Postal: "You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License."
GFDL was never designed for things other than printed books/manuals and software manuals that would be part of an archive that could include the GFDL as a seperate file. But the license text must be reproduced when you distribute the work (called "Document" above - gee, could that be a hint it was never meant for photos?). Including GFDL.txt in a zip file counts as reproduction. GFDL wasn't made for online distribution either. Does Wikipedia/Wikimedia comply with that "reproduction" requirement by providing a link? I'm actually not sure, but linking to https://www.gnu.org/copyleft/fdl.html would not be sufficient. Wiki hosts the text, that would be the least you would have to do when using GFDL online. I think the whole text should also be included on the file page. Which leaves the question what that means for including photos in English Wikipedia. For that, the media viewer should be adjusted. It is misinforming the re-user currently. Now luckily, Wikipedia/Wikimedia mostly has little to worry about.. because there is often also a CC BY-NC license. So Jimbo is safe as long as he doesn't introduce "Wikipedia Gold". Could you get away with a coffee mug if you provided a bunch of paper with the license along with it? Probably. Buyers will probably be confused, but okay. Could you do the same with a T-shirt? The problem with T-shirts is, you will be publishing the work wherever you go and you don't have permission for that. I'm not even sure if printing the full license text on the T-shirt will solve that. GFDL was simply never designed for such applications. What about printing a GFDL-licensed photo on a billboard? Tacking a few sheets of paper to a huge billboard is not likely to be sufficient. Using a GFDL-licensed photo on a billboard may not be possible at all, but I wonder what legal experts would say about it. Could you use a GFDL-licensed photo in a commercial? Yes, but the result will be laughable at best and probably expensive and confusing.. - Alexis Jazzping plz09:12, 17 September 2018 (UTC)
It's reasonable to ask a video to include the attribution required by the Creative Commons licenses. It's not feasible for them to include several minutes of scrolling text at the end of the video or a huge chunk of text in the Youtube or Internet Archive description box.--Prosfilaes (talk) 02:46, 16 September 2018 (UTC)
You are not required to provide several minutes of scrolling text, this would be only one way to include the licence and probably the dumbest possible way to do so. ℺ Gone Postal (〠✉✍⏿) 06:20, 16 September 2018 (UTC)
@Yann: I've seen this line of arguments before, and sorry to say it but this is among the core reasons Wikipedia and other Wikimedia-projects looses contributors. Use arguments. Use dialog. Don't try to enforce weird ideas by using a w:fallacy. Yes you can get rid of new contributors with a fallacy, but it hurt the community badly. No, I'm not a new contributor, I've been around since 2005. But yes, I have stopped uploading my own photos to Commons. Jeblad (talk) 21:10, 16 September 2018 (UTC)
We don't need new GFDL or GFDL+CC BY NC contributors. We sympathize on our great old contributors who left Commons. But we're happy that we get more and more great contributors who are willing to to contribute their high resolution works with a more freely re-usable license. We prefer to think about our future than worry about keeping the narrow-minded past. Jee02:30, 17 September 2018 (UTC)
I would close this section, but as I closed the original proposal I'll leave it to someone else. Frankly, using GFDL for images is absurd and has always been absurd. The license text makes no sense unless you're licensing a predominantly text-based document. In addition to the full license text requirement, several provisions rely on a "title page". What is the title page with regard to a GFDL image on Commons? The file description page? Is the "Document" Wikimedia Commons itself?
GFDL presumes you are working with an actual document, not an image, audio, or video. One can make a good faith effort to comply with the license as much as possible, but strictly following it is either arcane or impossible for non-text works which by their nature do not have anything resembling a title page. It seems to me that GFDL-only images in general fail the precautionary principle. We could delete them all, or we could grandfather the old files and accept the new policy as a fair compromise. Guanaco (talk) 08:04, 17 September 2018 (UTC)
Guanaco agree. GFDL was historically used on Wikipedia because there was nothing else at the time. Then CC licences were created, in collaboration with WMF, precisely to solve these problems and provide licences that make sense for images, video, sound, data, etc, etc. Let's leave GDFL for the GNU software manuals it was intended for, and move on. It is 2018. -- Colin (talk) 09:44, 17 September 2018 (UTC)
The proposal has been accepted. If there are concrete issues or ambiguities remaining that are not covered by the current implementation, please raise them in a new section here or on the village pump. Sebari– aka Srittau (talk) 09:48, 17 September 2018 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
It's my belief that categories are there to assist users in finding media we host. So it should be a given that users should find media where they expect to. However, we seems to have inherited a system from en:WP of default sorting churches and pubs by location first, then name. So "St Bernard's church, Sometown" is defsorted so that it appears under "S" rather than "B" (obviously sorting under "St" is unhelpful because most would then sort under "S", which would be overwhelmed and thus useless). Similarly, "The King's Arms, Anytown" appears under "A" rather than where a user would expect to see it, i.e. under "K" (Again, "The" is redundant). There is one user who persists in perpetuating this error, as I see it, claiming that "it's the way it's always been done" is a taxonomically valid reason for the current system. So my proposal is this:
Churches and public houses in the United Kingdom should be sorted by name first, then location, except where the name is part of the category, in which case sorting by location is used..
I realise it may take some time to correct this error, but I don't see that as a reason for not doing it, as I'd prefer to get things right than confound our users, and I invite all to participate in a straw poll to determine consensus. Rodhullandemu (talk) 08:32, 10 September 2018 (UTC)
Support The location isn't part of the name, for "The King's Arms, Anytown" it would be under "King's Arms" then under "Anytown" (such as here when the name of the topic is the same, we then go by location), since the "The" is not useful, the same with "St Bernard's church, Sometown" where the "St" is redundant it should be under "Bernard's", then "Sometown". Crouch, Swale (talk) 12:02, 14 September 2018 (UTC)
Based on that discussion, I think the only reason empty categories should be speedily deleted is if they (a) were created by mistake; (b) they are abusive; (c) are obviously and unquestionably incorrect; (d) are vandalism or used only for vandalism; or (e) the sole author requests deletion and the category hasn't been used by others. These situations are all covered by other criteria (a) is G1, (b) is G3 (c) is C2, (d) is G3 and (e) is G7, so there isn't a need for a separate criterion. What is and is not an "Unuseful" category in other circumstances can only be determined by a discussion. So repeal speedy deletion criterion C3 entirely. Thryduulf (talk) 12:12, 12 September 2018 (UTC)
Oppose: a) It's not a hard job to re-create a deleted category if it is needed. b) An unuseful category had to be defined exactly and that would take a long time I think. c) It's an illusion to discuss the deletion of an empty cat, look at the CfD and DR backlogs. My 2 cents --Achim (talk) 19:50, 12 September 2018 (UTC)
@Achim55: Backlogs could be avoided by stating that unopposed deletion nominations can be closed as delete if the following people have been notified of the nomination: The creator, those with significant edits to the category or category talk page, any known major contributors, anyone who participated in previous discussions about the category (in most cases the latter three groups will not contain any members, so this is not onerous). Thryduulf (talk) 16:23, 15 September 2018 (UTC)
I Support removing that criterion altogether as stated by "User:Thryduulf" as a user could decide to upload images into a freshly created category and then due to a power outage or whatever will have to upload those files later. I used to create the category first and then upload the images but after a bad experience with a power outage I was pretty relieved to find the category not deleted when I came back and I used it for uploading. Things can take time and immediately deleting a useful page doesn't benefit the project. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:11, 28 September 2018 (UTC)
Oppose "Unuseful" is an entirely subjective feeling that would lead to incredible variation between individuals. I thought we want more consistency between admins? Not less. It is incredibly easy to recreate a deleted category if necessary (per Achim55). The CfD backlog is a black hole where things go to sit for literally years. Changing the criterion into something this vague is only going to make that worse. If you can't take the time to fill a category just remove it. It takes less than 5 clicks to get it back later if you want. Leave the status quo be please. --Majora (talk) 21:15, 28 September 2018 (UTC)
As a side note, I would be fine to add a time restriction (AKA delay) to such a deletion. Much like the no source. Say, tagged for 2 days? That should resolve the "power outage" concern above. --Majora (talk) 21:19, 28 September 2018 (UTC)
Licensed-PD-Art and nc
Hi!
First: This I isn't a proposal, that wanna support nc nd on Commons, it's only to give the uploader of PD-Art pictures more safety.
My proposal is, that we allow to use CC nc and nd with Licensed-PD-Art for reproduction published under this licensed outside of Commons and describe, why we think that it's PD, but also describe, that the uploader didn't violate the license, because he respect the conditions of the License.
I know, many commercial Platforms use, but they would also use the PD-Art picture, without NC-License on it.
{{PD-Art}} is for "a faithful photographic reproduction of a two-dimensional, public domain work of art". Typically the photographer/uploader is not the creator of the art. If the artwork is not PD then the photograph is a copyright violation, or has been taken under licence by or permission of the copyright owner. But only the owner of the copyright can licence an image with a CC licence. -- Colin (talk) 16:42, 25 September 2018 (UTC)
@Colin: I know, but the situation of PD-Art images is unclear in many states (in my view PD-Art is right), so it would more safe for the uploader, if he can do what the license want of him (To make it more clear, what I want: Here an example of what I want)
Why would we encourage authors to license such photographic rights (if they exist) under an NC license rather than a free license? If the uploader is not the author, they cannot assume licenses; the source would have to *explicitly* name CC-BY-NC as the license to make that situation valid. If there is a sort of general "non-commercial" restriction, that is not the same thing as CC-BY-NC and we can't name it that way. And at any rate, the PD-Art tag (without any licensing of the photo) is enough to upload here, and explains why we don't think the photographic copyright is valid, but if re-using in a country where it may be valid, re-users need to do further research on their own. If there is some sort of licensing statement on the photographic portion, that could be mentioned in the "Permission" section of the tag, if we want to supply that information as well (the way your example does). I don't think we need to have an explicit tag to mention such non-free restrictions in the PD-Art portion itself. Carl Lindberg (talk) 15:45, 26 September 2018 (UTC)
For example many reprodoductions of two dimensional documents here or here licensed under CC by-nc-sa 4.0. So we the uploader of reprodoductions from states, where the situation of PD-Art is unclear, more safety. Habitator terrae (talk) 19:00, 26 September 2018 (UTC)
it's unclear to me what cover you get from such verbiage: "This reproduction is licensed under CC BY-NC-SA 4.0. The uploader doesn't infriges this license, because this use is only to give Files noncomercial to all. He only describe, why the Wikimedia Foundation thing, that this is puplic domain" rather you might want to use Template:GFDL-CC-triple
I don't want to put an nc-license on a PD document. I think, like the WMF, that reproductions of two dimensional objects, are public domain. But in many states this isn't clear, for example in Germany. So we invented {{Licensed-PD-Art}}, to have a fallback for this states. My proposal is only, that the uploader, could do what the license say, if he upload the reproduction. I don't not want to upload images with nc, I only want to make, that person, that upload PD-Art images, that we could upload without any license, could upload with more safety Habitator terrae (talk) 12:24, 27 September 2018 (UTC)
(outdent) ok I think I figured out what is being asked. @Clindberg: . As Habitator terrae says, there is {{Licensed-PD-Art}} for the case where an image is confidently PD in only some jurisdictions but we offer an additional free licence for cases where it is not. For example: File:Babel 900.jpg has a CC BY 3.0 license offered by the photographer. The case of File:Carmina Burana.pdf is an image where the source image (here) is clearly licensed CC BY-NC-SA 4.0. The uploader only has WMF and a few anonymous wiki amateur's say-so that they can legally upload this image to Commons. But they can be confident that if they obey the terms of CC BY-NC-SA 4.0 that they can upload without any legal issues. And that licence requires that the CC licence is mentioned alongside the image and any attribution included. So I think Habitator terrae would like if users could supply this non-free licence as part of {{Licensed-PD-Art}} in order to personally be safe to upload. As Carl notes, any re-user would themselves need to check that the image is PD in their country before using it. I guess that may also be true of any user linking to it in a Wikipedia article, which I suspect most Wikipedians do not think about. Anyway, that's true of all PD Art where the source institution has asserted copyright. An advantage of adding it as a template parameter would be that the CC BY-NC-SA 4.0 licence creates the appropriate data to allow it to be searched/categorised whereas an ad hoc description in the "permissions" section would not.
I think this is a reasonable suggestion, as it makes our uploaders safer but doesn't change the content we permit. Al that is needed is for the documentation of the template to no longer say "free" for the licence. It might help, though, to request that non-free licences are only given where required to by the source institution, and that users uploading their own photographs and scans must offer a free licence. I'm not sure how we would handle more complex situations where the source institution has a custom non-free licence. -- Colin (talk) 14:09, 27 September 2018 (UTC)
Having it as a specific option (and there are lots of versions of CC NC/ND licenses) could also encourage people to upload their own that way. I'm not a lawyer, but it may still be possible (however unlikely) that uploading to a site which states commercial usage is OK may still be considered a violation, so it's not a guarantee for the uploader even if named -- the liability is the same if they claim innocence or not. I admit I had not thought through the attribution/linking requirements of the reproduction license, but the example given (putting them in the Permission field) should be just fine for that. Lastly, the Licensed-PD-Art template already has a "rawphotolicense" parameter to specify arbitrary wikitext where non-standard licenses could be specified, which could be used like: {{Licensed-PD-Art|PD-old|rawphotolicense={{Cc-non-compliant|CC BY-NC-SA 4.0|https://creativecommons.org/licenses/by-nc-sa/4.0/|nowarn=1}}}} which will display the link to the other license in a red box. I'm not sure we need to do anything more specific beyond that. Carl Lindberg (talk) 16:53, 27 September 2018 (UTC)
Hello! The project GureGipuzkoa holds thousands of freely licensed photos by institutions and archives in Gipuzkoa. Currently we have a category with some of this collections, but there are many more that can be really interesting. I know that Discasto has been importing some of them massively, but I don't know if there is a way to do it with a bot. Some of the collections have more than 7.000 historical images and doing it by hand could be impossible. There is an index of collections here. Most of them are cc-by-sa, but a few are cc-by-nd. Municipal photos are specially interesting, and some of them claim that their vision is to be in Wikimedia Commons.
Hi Theklan, I did the upload of several entire collections. More than 9,000 images (those in Category:Photographs from Kutxateka - Supported by Wikimedia España). The bulk of the work was not in the retrieval of the pictures (I did use some scraping and subsequently a bot uploaded the pictures with corresponding descriptions) but the actual categorization. The collections I uploaded has a description in Spanish and therefore it was "simple" to find suitable categories (in fact it wasn't that simple, it took a lot of time). I gave up subsequent upload because I can't read Basque language and therefore it is not possible to assign categories (IMHO, a massive upload of pictures with no categories is mostly useless). Anyway, if you provide some concrete examples of collections I can provide the code for the scraping and the retrieval of pictures. Next, I could help with the upload process. However, I'm running low of free time and I can't possible commit to a deadline. Let me know your thoughts --Discastotalk22:47, 28 September 2018 (UTC)
@Discasto: Thanks for the insights! For example, the collection from the Oñati Municipality can be easily uploaded into the category Oñati. And then start with a further categorization. If we can upload all of them, the second step is time consuming, but not as much as uploading them by hand. -Theklan (talk) 07:32, 29 September 2018 (UTC)
@Theklan: Sure, I can help, but I have two remarks:
I've read the licensing conditions in the Oñati archive and I don't think the license they apply to the images whose author they don't know is valid at all (in Spanish: En cambio los contenidos a los cuales no ha sido posible atribuirles la autoría se les aplica el permiso Sin Restricciones Conocidas de Derechos de Autor (No Known Copyright Restrictions)). On the contrary, those images are equally subject to copyright restrictions even if the author is unknown (in intellectural property parlance, it's what it's known as an orphan work). Therefore, I don't think such images can be uploaded to commons.
As told, I'm pretty much busy with a lot of bot-related issues (see here), I'm currently working in the items in the province of Alicante, and the management of this task will take some time.
I had the same doubt with those photos, but the Oñati Archive is the owner of the files, so I think they can safely license them as cc-by-sa. About the schedule... maybe someone else can do it, or we can do it later. Don't worry about that. -Theklan (talk) 21:05, 29 September 2018 (UTC)
@Theklan: The fact that they're the owners of the pictures does not mean they're the owner of the intellectual property. In fact, they require authors, if they recognize their works, to raise their hands so that the copyright status is updated. My suggestions would be to ask before any action in Commons:Village pump/Copyright. Best regards --Discastotalk20:15, 30 September 2018 (UTC)
Technical proofment from Wiki Commons Category (used as url) to Wikipedia
I suggest that a categegory should be checked in Wikipedia automatically before someone (admins) edit or erase the category in Wiki Commons.
Picture galleries in Wikipedia (|Commonscat=) needs a category, other possibility seems to generate special category (maybee hidden) or marks
the commonscat (with colour) to seperate them from only text based material. Otherwise nexus and the function will get broken.--Hans-Jürgen Neubert 12:20, 12 September 2018 (UTC)(talk)
Hans-Jürgen, I'm sorry but I didn't get it. Question: Meinst du, dass überprüft werden sollte, ob eine Commons-Kategorie von Wikipedia aus verlinkt ist, bevor sie auf Commons gelöscht bzw. umbenannt wird? --Achim (talk) 19:58, 12 September 2018 (UTC)
Exactlyǃ Genau das... siehe hier als ID-Beispiel "D-5-73-134-60"
Die meisten Anwender suchen in Wikipedia (Reader, read only), nicht Commons. In Commons werden hingegen die Zusammenhänge von den Bilderlieferanten (Quelle und Ziel) erstellt (Writer). Ein admin kann auf wikicommons anscheinend bisher nicht erkennen ob der Inhalt in wikipedia bereits genutzt wird.
Er müsste bei Änderungen beide Seiten bearbeiten, erst die auf commons, dann in Wikipedia und zumindestens die Material-Galerien snchronisieren.Es geht hier nicht um "leere" Kategorien (was ja gar nicht möglich ist) und auch der Hinweis "the only contributor" macht logisch keinen Sinn, einer muss ja anfangen. --Hans-Jürgen Neubert 20:19, 12 September 2018 (UTC)(talk)
At this time a solution is not feasible. The commons database contains a table called globalimagelinks that shows the use of images in other wm wiki projects. So one can see quickly where an image is in use (example: Special:GlobalUsage/Puchtastraße_47_001_(Cadolzburg).jpg). That doesn't work for categories because unfortunately there is no table globalcategorylinks. So one had to work the other way round looking up all of the ~180 wiki databases whether or not there is a link inside the iwlinks or externallinks tables pointing to the commons cat, what might take up to a few minutes per category name and thus is not practicable. I hope that one day the commons db will have a table globalcategorylinks or even the existing globalimagelinks will be extended to other namespaces. --Achim (talk) 12:27, 15 September 2018 (UTC)
Comment Since at this time this is impossible, I would like to make a policy proposal that any category that is deleted and has a link to from another project should be speedily restored as soon as the request is made. ℺ Gone Postal (〠✉✍⏿) 09:03, 11 October 2018 (UTC)
Allowing cross-namespace redirects from (Gallery)/(Main) to Category
I've been informed that cross-namespace redirects are not allowed on Commons (tho I can't seem to find the documentation). Even if we want to have that as a rule generally, I think a big exception should be from the main/gallery namespace to the category namespace. Since we mostly use categories here and have only a fraction of images as galleries, it will be very useful for incoming links and search until such time as we really populate that namespace in earnest. I think this has high value and I don't see any immediate downsides. What does everyone else think? —Justin (koavf)❤T☮C☺M☯03:21, 9 September 2018 (UTC)
Support, I actually wanted to propose this myself a couple of months ago but got distracted by other projects. It would be very handy if mainspace pages could direct to categories as it would make searching a lot easier, and this would also allow for names in different languages to be redirected to the same subject. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:22, 10 September 2018 (UTC)
Comment If you ask me: move all galleries to a dedicated Gallery: namespace and automatically redirect the "main" namespace to Category:. --El Grafo (talk) 11:53, 12 September 2018 (UTC)
Support per nominator. In addition cross-namespace redirects between Commons: and Help: namespaces should be freely permitted as there is overlap between them (see for example the location of pages in Category:Commons help). Thryduulf (talk) 23:34, 12 September 2018 (UTC)
Support per nominator. There are times that a simple gallery is best replaced with a category, but we should possibly still prefer incoming links go to the gallery page until such time that a better curated gallery is made. Carl Lindberg (talk) 01:28, 13 September 2018 (UTC)
Oppose - it gives the false impression that a gallery page exists. Also, allowing this would cause a situation in which random pages redirected to categories. If we want non existing gallery pages to link to the category, we should request a software change instead. Either all non existing gallery pages should redirect to the category or none. Jcb (talk) 15:54, 13 September 2018 (UTC)
Yes, the presence of such a redirect would depend to whether someone decided to create it. This would end up in a total mess. It's not without a reason that 'cross namespace redirect' is a valid reason for speedy deletion in our policies. Jcb (talk) 11:05, 23 September 2018 (UTC)
@Jcb: I think I understand your complaint here: whether or not there are gallery-to-category redirects would be essentially random. Would the solution be to have an automatic conversion, then? That is, some bot or feature of the wiki would always create gallery-to-category redirects? —Justin (koavf)❤T☮C☺M☯19:17, 23 September 2018 (UTC)
I think that would cause way too much maintenance. Every day a lot of categories are being deleted, so evert day we would find dozens or even hundreds of such redirects in Special:BrokenRedirects. If we would want every non-existing gallery page to link to the category name with that name (I am not convinced that we need that in the first place), we should request a software change instead, so that a non existing gallery of an existing category would redirect automatically, without having to create a redirect page. Jcb (talk) 21:25, 23 September 2018 (UTC)
SupportEl Grafo's solution, all of the main namespace should be categories, and the old main should be moved to Gallery: ℺ Gone Postal (〠✉✍⏿) 16:36, 13 September 2018 (UTC)
Comment My first choice is to redirect all non-existent galleries to the category, if the category exists, per Jcb. If the developers tell us this isn't feasible, I'll support this proposal to allow redirects. Guanaco (talk) 00:52, 14 September 2018 (UTC)
Comment Some websites with encyclopedic tendencies gives links to other websites that can talk about similar subjects. Those links are, I think, given in an automatic way, with a string of characters (a part of the web adress) and of course the name of the subject treated. I saw it several times, but I remember only one precise example "mycobank". Example, in the page Coprinopsis candidata you go to the section "Link out to external resources" and you will see that a list of links is given automatically. Then if you click on "wikimedia" you come to [3]. However we have good media files for this subject. I think is is really a kind of issue, and I think the sentence "You can search for this page title in other pages or create this page." is far not enough. But I'm neutral on the way to solve this. Christian Ferrer(talk) 17:10, 14 September 2018 (UTC) I add I think that this page should clearly say that we have media files within a existing corresponding category. Christian Ferrer(talk)17:21, 14 September 2018 (UTC)
A kind of solution could be the creation of a Wikimedia Commons template, a bit as {{Wikidata Infobox}} but with different presentation and specifically intended to the non-existing galleries. Example I just created manually Dytaster, however the totality of what is displayed (included the links to the images) is available in Wikidata, therefore this gallery could very well have been created automatically. It's a fact, and everyone agrees, that not all categories can have matching galleries, however maybe that all subjects that are worth to have both a Wikidata item (therefore notable enough) and a category here, should have a gallery. And when this gallery don't exist, it will created by a bot with a dedicated template which would bring relevant content from Wikidata, and then, we will keep the possibility to add manually some content in addition to the template, or to replace manually the template by some content. This should solve the issues for the incoming links. @Mike Peel: who is used to relationships Wikidata/Commons. Christian Ferrer(talk)08:39, 16 September 2018 (UTC)
Support, as this will allow to go around the decision to keep some really misleadingly poor galleries upod deletion request taken by some otherwise deletionist admins. Of course the proper thing to do would be to move to the concerning categories the scare gallery content that is not sheer nonsense, and then delete the whole namespace once and for all. (Some content currently in the gallery namespace should be moved to the Commons namespace instead.) -- Tuválkin✉✇23:10, 23 September 2018 (UTC)
Weak support, prefer User:El Grafo's solution. Separately: I think galleries are way under-used. There is a ton of potential there, almost none of which has been exploited. - Jmabel ! talk15:56, 24 September 2018 (UTC)
Currently, we only have one method of resolving unwanted files: deletion. This hides the file, its description, and its history from public access, making it viewable only by administrators via Special:Undelete. For copyright violations, severe personality rights issues, vandalism, and aggressive spam, this is entirely warranted. For duplicates, superseded files, low-quality redundant files, and most personal files by non-contributors, a softer approach could be just as useful, while allowing greater transparency and collaboration with non-admins.
File deprecation would be a logged action that can be performed by admins and trusted users in a new user group. It would function similarly to deletion, where one specifies a reason, clicks a box to confirm, and then the file is marked deprecated. This would have the following effects:
When viewing the file page, a reader sees a system message informing them that the file has been deprecated. This message is editable via the MediaWiki namespace. Below the system message, the file and description are displayed normally.
Transclusion of the file is disabled. If a file is currently in use, it cannot be deprecated.
The file page is noindexed.
By default, deprecated files do not appear in categories. Logged-in users can show deprecated files via a user preference. If this setting is enabled, they are instead clearly marked as deprecated files in the category listing.
Deprecated files may be redirected to other file names. Linking to such a redirect will display the target file (standard file redirect behavior).
I see the new user group having a similar level of trust as a file mover, with about the same risk of damage by a malicious user. An understanding of policies and guidelines would be needed, especially Commons:Project scope and knowing when to nominate a likely copyvio for deletion rather than deprecating.
This would of course require developer support to implement. Before I create a Phabricator ticket, I'd like to see everyone's thoughts, improve the proposal in every possible way, and determine whether this is something we want as a community. Guanaco (talk) 06:40, 19 September 2018 (UTC)
This is too thinly considered to bring it here now. What exactly must MediaWiki do with [[Image:deprecated file name.ext|…]] tags? What namely means “may be redirected to other file names” – do you mean such file may be browsed only with &redirect=no? Should deprecated files be visible in Special:ListFiles by default? Incnis Mrsi (talk) 07:10, 19 September 2018 (UTC)
I agree it's too early for voting, but I know of no better place to discuss such an idea. For [[Image:deprecated file name.ext|…]], it could show an error message similar to template loops or parser function exceptions. If this is implemented as an extension and not on all Wikimedia wikis, I think it would have to be a red link as with a non-existent or deleted file. I imagine redirects would need to be browsed using &redirect=no, which is simple enough to reach by using the (Redirected from File:Example.jpg) link. Alternatively, it could function as a soft redirect. Special:ListFiles could use a check box, right below the "Include old versions of files" option. Guanaco (talk) 07:39, 19 September 2018 (UTC)
Making some files noindexed but available for review is IMHO a clever approach. Just some notes about implementation. First, don’t press for development of all desired functionality at once. The core attributes—namely a new field in the image table, access to it from the Web interface, and noindexing—must be deployed before further refinement of the feature by the Commons community. Second, some changes and clarifications in the criteria should follow. Third, an awareness campaign (first, targeting sysops only) must be conducted after deployment and “old-style” deletions should become discouraged wherever the deletion request indicates that the file(s) is to be deprecated. Fourth, a guidelines for converting deleted files to deprecated have to be set and the respective process should start soon – otherwise I don’t see much room for application. Incnis Mrsi (talk) 17:13, 20 September 2018 (UTC)
Not sure I understand the "personal files by non-contributors" use-case. Are we not creating a semi private "dropbox" storage space for "trusted" users to host their own out-of-scope photos. Most users would want deprecated files hidden, as would any IP I assume, so such a stash of unwanted images would may lay undiscovered. If such images were to be discussed in a forum or talk page, I'd need to go to preferences, change my setting, view the image, then reverse my preferences. What is this buying us? -- Colin (talk) 18:01, 23 September 2018 (UTC)
I used the phrase "personal files by non-contributors" because it's one of the new criteria for speedy deletion. Contributors can have some files in userspace, but using Commons as a personal webhost is and still would be unacceptable. It's technically possible someone could upload excessive personal files and attempt to conceal them via deprecation. However, the motivation for this is limited with such abundant, free services as Google Drive, and the risk of being called out on COM:AN/U would be high. Admins can do this more effectively via deletion; so far I've never heard of such abuse. Regarding your second concern, direct links to a deprecated file would work without any change in preferences. They would only be hidden from categories and other content space. Guanaco (talk) 22:47, 24 September 2018 (UTC)
Ok, can you describe some use-cases where file deprecation gives us advantage over deletion. I'm struggling to find a reason why non-admins need to see these files, vs the extra admin hassle that people can still try to link to them or edit them with vandalism or upload a new image over the top of them that is problematic. People doing category maintenance would have the problem that they'd either have to (a) also maintain this junk or (b) leave the junk in the wrong place because they don't see it. -- Colin (talk) 11:39, 25 September 2018 (UTC)
Support, but can files be reinstated if they are used on another project? Let's say that a user uploads an image of A famous building in a rather remote area but its not the best quality, another user uploads a better quality image with the OTRS template but the ticket turns out to be invalid because the photographer can only agree to a non-commercial license and is deleted as a copyright violation, would this inferior photograph be unable into the Wikipedia article it was removed from as the only useable free file or would undeletion be have to be requested as with deleted files? Are categories then removed or do they appear as "invisible" unless enabled? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:41, 26 September 2018 (UTC)
In that situation, the lower-quality photo should never have been deleted (or deprecated) in the first place. "Better" or "superseded" should never result in deletion. The "redundant" or duplicate type of deletions are the one case where I could sort of see this, but not sure it's worth the development or maintenance effort -- if there an argument on a validly licensed work, it's best to simply keep both. Commons is about providing as many options as possible, and let others decide "best" for their situation. We don't curate, or decide "best" because even if a photo is not as good for one particular Wikipedia article, maybe it is better for some other aspect of a Wikibook, or something like that. I would not want a deprecation feature to give further freedom to deprecating works that we currently keep. And Colin's point of abuse possibilities is a good one; if such files are linkable from the outside (which they would almost have to be, if you can still go to the image page and see the image), such files could be used to simply use Commons as image storage. There have been examples of that in the past (for example see Commons:Village pump/Proposals/Archive/2017/06#Restrict_Video_Uploading), and it may make such things harder to find, and would require careful implementation to not allow additional avenues of abuse. I'm not sure this feature is worth it. Files with different licenses should not be "redundant" and deleted in the first place, for reasons like you give. Carl Lindberg (talk) 16:15, 26 September 2018 (UTC)
Support as proposer. Mikael Häggström (talk) 19:03, 10 September 2018 (UTC)
Oppose per my following point-by-point rebuttal.
Comment Thank you for explanation of the difference between an adaptation and a compilation. —andrybak (talk) 23:22, 10 September 2018 (UTC)
Strongly oppose
--Discasto talk 22:47, 28 September 2018 (UTC)
Question: Meinst du, dass überprüft werden sollte, ob eine Commons-Kategorie von Wikipedia aus verlinkt ist, bevor sie auf Commons gelöscht bzw. umbenannt wird? --Achim (talk) 19:58, 12 September 2018 (UTC)
.jpg){kind=link}
