On 4/1/07, Daniel Kinzler <daniel(a)brightbyte.de> wrote: Uploaders page is often not the copyright holder. My view is that it should translucde the page text like commons wiki does on the other projects, and correctly fix up all the links. Image revocation is a must solve feature before we could activate it on commons. Part of the reason that we don't get in deep-crap with more copyright holders is that when they contact us we make the file go bye-bye quickly. If many other sites are invisibly and automatically mirroring commons content without human oversight and ignoring our deletions, then this kills our ability to effectively take down infringements and keep copyright holders happy. It would be in our interest to block access to sites which continue to distribute copyright infringements which we have deleted.

On 4/1/07, Delphine Ménard <notafishz(a)gmail.com> wrote: It's just a software feature. We might not use it. I would strongly suggest that we not use it until we have good answers to these questions. As far as handling new users goes, ... we need to improve that for ourselves even without the extra pressure of instantcommons. Many things have been proposed, few implemented. As far as free content or not sites goes, It would be be very interesting when some of our commons users start enforcing the copyleft terms of their images licenses against sites using instant commons images in sites which are non-free. For the copyright related concerns I raised earlier in the thread, here is a fun datapoint: 177,734 files uploaded to commons in Jan and Feb 2007, of those files 20,741 have already been deleted which is a bit under 12%. There have been 45,810 total image deletions on commons since Jan 1st. This graph is also interesting: http://72.165.205.81/dimage_life3.png It shows the distribution of age at time of deletion for files deleted on commons. The green curve is the most recent quarter, the purple is prior quarter. It's clear that the introduction of bot-deletion for backlogs has had a substantial impact on the timing of our deletions. The slope of the CDF after it initially stabilises would indicate that once a file has passed 15 or so days old the probability of us deleting on any given day is just a small constant. This wouldn't be bad if old deletions weren't such a substantial fraction of our total deletions.

On 4/1/07, Daniel Kinzler <daniel(a)brightbyte.de> wrote: The dupe issue will hopefully be solved after we get image redirects. ;) Even in the case of NC/ND material we don't want our name being associated with such files. Other policy issues, sure, but this isn't trivially addressable so long as all deletions look the same to the software. :)

On 4/1/07, Erik Moeller <erik(a)wikimedia.org> wrote: Yes, and I whined about the copyright issues then, and I've yet to see fully satisfactory answers. With around 200k out of 1.5million images deleted thus far and more every day,I do not believe commons is yet at a point of maturity where the automatic redistribution of our images would be a socially responsible action. In order to get there I think we need to take at least two major steps forward in the quality of our work. We're making good progress but, like all things, it takes time. We need to be mindful that one of the major differentiators between commons and other user contributed online image repositories is our responsiveness to copyright infringement concerns. We are remarkably more responsive than most other user contributed image repositories, and and automated image-live-mirror system without automated revocation puts that status in jeopardy. It can be argued that we're already have the mirror problem with text, but text has a long term trend of far fewer copyright complaints per item than media, and with things like automated text copyright violation detection (http://en.wikipedia.org/wiki/Wikipedia:Suspected_copyright_violations) our review mechanisms for text are clearly more sophisticated. Text mirrors also tend to be either fairly spammy sites whos violations no one would fault us for, or live feed recipients which preserve our responsiveness.

On 4/2/07, Platonides <Platonides(a)gmail.com> wrote: [snip] After giving it some more thought I think it should work something like this: *To get instant commons access to commons sites must agree to **Display an instant commons notice (like what the wikimedia wikis do for commons content) and include the attribution and license data. **Poll a deletion feed at least once a day If an image is indicated as deleted, the software will then remove the commons notices from the image, and the image will look like a local upload with no mention of commons. This should be a mandatory requirement for instantcommons access to Wikimedia commons. The instant commons software should have also feature to automatically 'delete' these images, so that they can be undeleted by the site operator. This feature should default to on, but site operators can turn it off at their own peril. If we do end up implementing something like what Platonides suggested, a review status for all images (including deleted ones) then the instant commons auto-deletion setting could depend on the review status. More simply, we could add a deletion reason dropdown to the deletion dialog and just store the deletion cause code in the deletion log. /* Non-free open content license (nd, nc...) */ /* Duplicated image */ /* Superseded */ /* Quality problems */ /* other */ /* Missing copyright status */ /* Known copyright violation */ /* Privacy or Libel issues */ I am pretty sure that requiring sites to remove the commons notice on images is something we must do. We need to make it crystal clear that we can not, do not, and will not take any responsibility for an image we've deleted. Nor should we be encouraging anyone to automatically keep images commons has deleted. Sites should only keep images auto-pulled from commons then deleted on commons after they have made an informed decision to do so, not as a result of the software. I would be inclined to say that we should not permit instantcommons access to sites which won't use autodeletion for at least the last two causes, if we do end up with detailed deletion cause codes. But I'm less sure about that.

On 4/2/07, Platonides <Platonides(a)gmail.com> wrote: Yes, we have some good users who can craft a lovely clear message when the time comes. Another reason why autodeletion and deletion cause codes are important... "Maintaining a user submitted image library is *hard*, let the experts at Wikimedia Commons handle it for you" .... The initial access to the content is just a little part of the cost of having media on your website. :) The delay makes sense.. Based on our deletion rates a ~10day delay would be best.. Perhaps the way to deal with that is to include an over-ride on the receiving site and figure a way to auto-fire it for content submitted by the sites users?

On 4/3/07, Platonides <Platonides(a)gmail.com> wrote: Not at all impossible, it would just take a little work. We setup a landing page they they direct their upload to commons link to, ... it sets a cookie indicating the site they came from (either one landing page per site, or grab the referrer. Make upload grab the cookie and stuff it in the database someplace.. I think that this would be very useful data even among our own projects. SUL will reduce the need for it internally, but it would still be useful with instantcommons.