headers
Alex G | 1 Apr 01:04
Picon

Re: Just how reviewed is a Flickr review?

Hmm, yeah, that's a feasible solution. Changing the attitudes/instructions might take a while, but it'd probably be worth it in the end.

On Mon, Mar 31, 2008 at 11:13 PM, Platonides <Platonides-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Change the way to do flickr reviewing. If the image differs from flickr,
put {{speedy}}
I use to delete those images with flickr source which don't have a free
license, because it's too improbable that an image uploaded two days ago
has changed its flickr license to an unfree one.

_______________________________________________
Commons-l mailing list
Commons-l@...
https://lists.wikimedia.org/mailman/listinfo/commons-l
Permalink | Reply | 1 comment |
headers
Nilfanion | 1 Apr 02:37

Re: Just how reviewed is a Flickr review?

We do need tackle this problem somehow, but I'm not sure what I'd
think is the best way to do it.

I think redirecting the possibly unfree category to {{speedy}} is a
mistake - simply because its such a vast change.  Note also there are
files awaiting review that were uploaded in 2007, so the backlog is
still a nuisance; and with files coming through other wikimedia
projects that problem isn't going to go away either.

I do think that we should try our best to empty Commons of "possibly
unfree Flickr images" in their entirety, not just the recent
additions. The proposals here
http://commons.wikimedia.org/wiki/Commons_talk:Flickr_images#Reviving
might be appropriate. Overly bureaucratic maybe, but I'd rather have a
process that is administratively difficult, but the community can
accept, than a slicker process that annoys the community. That
strongly indicates a "slow" deletion process to me - maybe a variant
on {{no permission since}}.

As an aside: Flickr users are perfectly entitled to cease to offer an
image under a free license, and instead use a non-free on, but they
can't stop other people distributing it under the license if they got
it freely. That makes using Flickr a pain in the neck for any
downstream user, like us, as we cannot prove the license here was ever
valid.. (and round in circles we go)

On 01/04/2008, Alex G <g1ggyman@...> wrote:
> Hmm, yeah, that's a feasible solution. Changing the attitudes/instructions
> might take a while, but it'd probably be worth it in the end.
>
>
> On Mon, Mar 31, 2008 at 11:13 PM, Platonides <Platonides@...> wrote:
>
> >
> >
> >
> >
> > Change the way to do flickr reviewing. If the image differs from flickr,
> > put {{speedy}}
> > I use to delete those images with flickr source which don't have a free
> > license, because it's too improbable that an image uploaded two days ago
> > has changed its flickr license to an unfree one.
> >
> >
> >
> >
> >
> > _______________________________________________
> > Commons-l mailing list
> > Commons-l@...
> > https://lists.wikimedia.org/mailman/listinfo/commons-l
> >
>
>
> _______________________________________________
>  Commons-l mailing list
>  Commons-l@...
>  https://lists.wikimedia.org/mailman/listinfo/commons-l
>
>
Permalink | Reply | 0 comments |
headers
Brianna Laugher | 1 Apr 05:16
Picon
Gravatar

Re: Commons API

On 01/04/2008, Magnus Manske <magnusmanske@...> wrote:
>  * code now in MediaWiki SVN, under trunk/tools/commonsapi
[...]
>  If someone wants to co-maintain it on the stable toolserver, welcome! :-)
>  Otherwise, please help extending the software and fixing bugs, or just
>  try to break it and report the crime scene to me ;-)

Great. So...
I'm kind of confused about how it's in wikimedia svn and yet runs at
your toolserver account. are you keeping distinct copies?

should we discuss it at wikitech, here, mediawiki-api, or a new
mailing list? (I'm inclined to a new list, to avoid lots of traffic
for uninterested people)

Also I'll be happy to put my hand up for comaintenance on the stable
ts - maybe when it gets a bit more stable? :P

Brianna

--

-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
Permalink | Reply | 0 comments |
headers
Magnus Manske | 1 Apr 10:52
Gravatar

Re: [MediaWiki-CVS] SVN: [32642] trunk/tools

On Mon, Mar 31, 2008 at 9:52 PM, Bryan Tong Minh
<bryan.tongminh@...> wrote:
> On Mon, Mar 31, 2008 at 10:16 PM, 
<magnusmanske@...> wrote:
>  >  +
>  >  +// Fake user agent
>  >  +ini_set('user_agent','MSIE 4\.0b2;');
>  >  +
>  You should probably fake your own user agent? Something like commonsapi/1.0

I'm only faking it because with the default agent (whatever it is for
PHP), requests often don't work on Mediawiki sites.
Not sure what would happen if I make my own...

>  >  +// get file data via "normal" API
>  >  +$ii_url =
"http://commons.wikimedia.org/w/api.php?format=php&action=query&prop=imageinfo&iilimit=500&iiprop=timestamp|user|url|size|sha1|metadata&titles=Image:"
. $img ;
>  Needs an urlencode($img);
>
>  >  +       if ( $m == 'Quality images' ) {
>  >  +    $titles['qualityimage'] = 1 ; // Just to make sure...
>  >  +    continue ;
>  >  +       }
>  >  +       if ( substr ( $m , 0 , 19 ) == 'Pictures of the day' ) {
>  >  +    if ( !isset ( $titles['potd'] ) ) $titles['potd'] = trim ( substr ( $m , 21 , 4 ) ) . "0000" ;
>  >  +    continue ;
>  >  +       }
>  You can get this as well from the [[Commons:Machine readability]] system.

I already do. This is mostly a fallback system for pages that don't
use {{Information}}, but are still quality or potd. Not sure how many
of those are there (or if any), but so what...

>  Looks nice :) I would like to co-maintain this but unfortunately I
>  already have too much work at my hands :( I'll probably be committing
>  some occasional stuff to svn.

Cool, thanks.

Magnus
Permalink | Reply | 2 comments |
headers
Daniel Kinzler | 1 Apr 11:38
Picon
Favicon
Gravatar

Re: [MediaWiki-CVS] SVN: [32642] trunk/tools

>>  You should probably fake your own user agent? Something like commonsapi/1.0
> 
> I'm only faking it because with the default agent (whatever it is for
> PHP), requests often don't work on Mediawiki sites.
> Not sure what would happen if I make my own...

It will work. Actually, it's semi-officially requested/recommended that you use
your own descriptive user agent string, including some means to learn more about
the tool and/or contact you -- or selectively block it if things go wrong. And
it does work, I use it for my own stuff.

General request to ALL bot and script makers, for any purpose: Please DO NOT
FAKE UA STRINGS! Please set your own, descriptive ones! This is a question of
good netizenship (as in "follow the spec" and "be cooperative").

Thank you
-- Daniel
Permalink | Reply | 1 comment |
headers
Florian Straub | 1 Apr 19:08
Picon
Gravatar

Re: Just how reviewed is a Flickr review?

Von: David Gerard <dgerard@...> wrote on sun, 30 mar 2008
23:18:49 
+0100:

> 2. There's no protection against someone changing the licensing.

What about the reviewer bot emailing a screenshot of the checked flickr 
page to a special, direct to archives OTRS queue?

Just an idea,

Flo
Permalink | Reply | 5 comments |
headers
Brion Vibber | 1 Apr 19:59
Picon
Gravatar

Re: [MediaWiki-CVS] SVN: [32642] trunk/tools


Daniel Kinzler wrote:
>>>  You should probably fake your own user agent? Something like commonsapi/1.0
>> I'm only faking it because with the default agent (whatever it is for
>> PHP), requests often don't work on Mediawiki sites.
>> Not sure what would happen if I make my own...
> 
> It will work. Actually, it's semi-officially requested/recommended that you use
> your own descriptive user agent string, including some means to learn more about
> the tool and/or contact you -- or selectively block it if things go wrong. And
> it does work, I use it for my own stuff.
> 
> General request to ALL bot and script makers, for any purpose: Please DO NOT
> FAKE UA STRINGS! Please set your own, descriptive ones! This is a question of
> good netizenship (as in "follow the spec" and "be cooperative").

Basically, if we catch you faking a browser UA we will block you without
mercy. :)

Default UAs for various standard libraries are unfortunately blocked due
to past abuse. We strongly recommend using a specific user-agent string
which includes your software's name and some sort of contact
information... a URL or email address helps... so that problematic bots
can be tracked down and the problem worked out.

-- brion vibber (brion @ wikimedia.org)
Permalink | Reply | 0 comments |
headers
Robert Rohde | 1 Apr 20:07
Picon

Re: Just how reviewed is a Flickr review?

There is an additional problem that a license change may legitimately be a correction rather than malfeasance.  It's not the world's most common problem, but I have seen several instances where a Flicker user copied a CC-SA or CC-NC work from someone else but mis-stated the license as PD or CC-BY, etc.
 
In a couple cases where it has happened with my own works, I've contacted the Flickr user to get a correction.
 
This goes to the general question of how much are you willing to rely on the accuracy of statements made by largely anonymous people on the internet, really?  And do you really want to be in the business of assuming that their first statement was more correct than their current one.
 
Personally, if you can't establish authorship more specifically than an online screenname, I'm inclined to favor deleting images when things like ambiguous/contradictory licensing claims come up.
 
Also, it's worth noting that even if you have ironclad documentation that a legitimate license had been communicated, that only addresses that you were acting in good faith.  Good faith actions eliminate the possibility for punitive damages, but if you rely on a license declaration that is incorrect (for example because the Flickr user stole it from someone else), you are still potentially liable for actual and/or statutory damages.  Which is why professional publishers usually expect a clearer chain of authorship to avoid getting duped.
 
-Robert Rohde

 
On Sun, Mar 30, 2008 at 3:42 PM, Platonides <Platonides-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
David Gerard wrote:
> checkuser-l is chasing cross-wiki vandals. Problems we've noticed:
>
> 1. Flickr review just checks whether an image is marked on Flickr as
> cc-by or cc-by-sa.
> 2. There's no protection against someone changing the licensing.
>
> The actual threat model is someone bringing a case of copyright
> infringement. Would screenshots of the licence as was be enough for
> 2.?
>
> - d.

It's a flickr problem on not preserving logs for license changes.
We're flickr reviewing to be sure if that image was free or not. So it
can be reviewed either by
a) The bot
b) An admin or trusted user (and it is in checked that the template was
set by a trusted user).

Both of which are trustable. If any of them would be willing to trick
the system, they could easily fake a screenshot as well.

Also, we have no way of dealing with people uploading copyvios to
flickr, then taking here with flickr as source (other than manual
reviewing).

_______________________________________________
Commons-l mailing list
Commons-l@...
https://lists.wikimedia.org/mailman/listinfo/commons-l
Permalink | Reply | 1 comment |
headers
Robert Rohde | 1 Apr 20:11
Picon

Re: Just how reviewed is a Flickr review?

On Tue, Apr 1, 2008 at 11:07 AM, Robert Rohde <rarohde-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
<snip>
Also, it's worth noting that even if you have ironclad documentation that a legitimate license had been communicated, that only addresses that you were acting in good faith.  Good faith actions eliminate the possibility for punitive damages, but if you rely on a license declaration that is incorrect (for example because the Flickr user stole it from someone else), you are still potentially liable for actual and/or statutory damages.  Which is why professional publishers usually expect a clearer chain of authorship to avoid getting duped.
 
 
P.S.  If found liable, you could subsequently sue the Flickr user to recover your losses, if you could find him...  But that's more trouble and risk than I think most professionals would want.
 
-Robert Rohde
_______________________________________________
Commons-l mailing list
Commons-l@...
https://lists.wikimedia.org/mailman/listinfo/commons-l
Permalink | Reply | 0 comments |
headers
jimbo.rules | 1 Apr 20:37
Picon

Re: [MediaWiki-CVS] SVN: [32642] trunk/tools

And how can I fake a browser UA?
On Tue, Apr 1, 2008 at 11:07 AM, Robert Rohde <rarohde <at> gmail.com> wrote:
<snip>

> Also, it's worth noting that even if you have ironclad documentation that
> a legitimate license had been communicated, that only addresses that you
> were acting in good faith.  Good faith actions eliminate the possibility for
> punitive damages, but if you rely on a license declaration that is incorrect
> (for example because the Flickr user stole it from someone else), you are
> still potentially liable for actual and/or statutory damages.  Which is why
> professional publishers usually expect a clearer chain of authorship to
> avoid getting duped.
>
>

P.S.  If found liable, you could subsequently sue the Flickr user to recover
your losses, if you could find him...  But that's more trouble and risk than
I think most professionals would want.

-Robert Rohde

On Tue, Apr 1, 2008 at 11:07 AM, Robert Rohde <rarohde <at> gmail.com> wrote:
<snip>
Also, it's worth noting that even if you have ironclad documentation that a legitimate license had been communicated, that only addresses that you were acting in good faith.  Good faith actions eliminate the possibility for punitive damages, but if you rely on a license declaration that is incorrect (for example because the Flickr user stole it from someone else), you are still potentially liable for actual and/or statutory damages.  Which is why professional publishers usually expect a clearer chain of authorship to avoid getting duped.
 
 
P.S.  If found liable, you could subsequently sue the Flickr user to recover your losses, if you could find him...  But that's more trouble and risk than I think most professionals would want.
 
-Robert Rohde
_______________________________________________
Commons-l mailing list
Commons-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l


_______________________________________________
Commons-l mailing list
Commons-l@...
https://lists.wikimedia.org/mailman/listinfo/commons-l
Permalink | Reply | 0 comments |

Gmane