I would love to see these adopted for Commons photographers. The issue
will become knowing when these principles are being violated. For
example, if you're going to alter audio to serve your own POV, you're
not going to make it obvious you've done so. Detection is one problem,
but even if you've detected that the audio was edited, there's no
telling what the audio should have been, and whether the editing was
deceptive. So, as a practical matter, I don't see that this is easily
resolved. As a matter of principle, I think these represent an ideal we
should strive for as a community.
On Wed, 2009-04-22 at 12:57 -0400, Anthony wrote:
> On Wed, Apr 22, 2009 at 12:46 PM, Anthony <wikimail(a)inbox.org> wrote:
> > On Tue, Apr 21, 2009 at 11:21 PM, Brianna Laugher <
> > brianna.laugher(a)gmail.com> wrote:
> >> 2009/4/21 Michael Snow <wikipedia(a)verizon.net>:
> >> > The Wikimedia Foundation takes this opportunity to reiterate some core
> >> > principles related to our shared vision, mission, and values. One of
> >> > these values which is common to all our projects is a commitment to
> >> > maintaining a neutral point of view.
> >> I find it a bit strange to talk of Wikimedia Commons as having a NPOV
> >> policy.
> > Should commons allow images which are biased?
> > More concretely, in terms of photography, should photographs adhere to the
> > standards of ethics adopted by photojournalists?
> Here's the NPPA Code of ethics:
> 1. Be accurate and comprehensive in the representation of subjects.
> 2. Resist being manipulated by staged photo opportunities.
> 3. Be complete and provide context when photographing or recording
> subjects. Avoid stereotyping individuals and groups. Recognize and work to
> avoid presenting one's own biases in the work.
> 4. Treat all subjects with respect and dignity. Give special
> consideration to vulnerable subjects and compassion to victims of crime or
> tragedy. Intrude on private moments of grief only when the public has an
> overriding and justifiable need to see.
> 5. While photographing subjects do not intentionally contribute to,
> alter, or seek to alter or influence events.
> 6. Editing should maintain the integrity of the photographic images'
> content and context. Do not manipulate images or add or alter sound in any
> way that can mislead viewers or misrepresent subjects.
> 7. Do not pay sources or subjects or reward them materially for
> information or participation.
> 8. Do not accept gifts, favors, or compensation from those who might seek
> to influence coverage.
> 9. Do not intentionally sabotage the efforts of other journalists.
> 1, 2, 3, 5, 6, 7, and 8 all deal with neutrality. Should they apply to
> photos made for commons?
Last post on this thread.
On Thu, Apr 23, 2009 at 5:38 PM, private musings <thepmaccount(a)gmail.com> wrote:
> There are many shots clearly 'posed' - which I personally feel means that
> permission is clearly granted by the subject - however there are also many
> which don't indicate that the subject has any idea the image is being
Where on Commons is the best place to discuss this? I haven't seen
anything that looks like a very good processlist for checking that an
image has a model release... though I reckon there's a template for
suggesting one does not.
> The addition of this material to commons, and to multiple user
> galleries (and user pages) - often with captions / titles like 'hot' or
> 'sexy' I feel is at best crass, and at worst an embarrassment to the
I don't see anything wrong with calling encyclopedic or otherwise
useful, release images, hot or sexy, or with making galleries out of
them. you can leave out this tangent.
> I believe it's desirable to respect the subjects of photography featuring
> nudity to the degree that no matter what the copyright status of the image,
> permission of the subject is in some way assessed, and if found wanting -
> the media should be deleted.
I don't think copyright has anything to do with this; again you can
leave out that comment entirely. Permission of subject should be
assessed, period. If you assess it by saying 'it is from a library
archive and is 80 yrs old', that works as a first pass.
An aside on work-safety:
Earlier, John wrote:
> While creating software would be needed for a good solution, I think
> we can create a simple solution by renaming all images with nudity so
> that they begin with NSFW (not safe for work), as I mentioned here:
I don't think this is a good idea in the slightest.
I know I mentioned NSFW before, and I meant it in a totally different
context. What I was suggesting is:
- pages which might be unexpectedly come across (name and context
don't give away media content) and are considered NSFW by a reasonable
minority of people should have some indication on the page [not on the
It's not meaningful to look for consensus on what is SFW or NSFW, and
media cannot be SFW or NSFW without context. [for any given image or
block of text, there is some workplace where it is appropriate if not
I think the Board's statement is quite commendable if unremarkable
(which is I guess part of the reason for the silence - nothing new,
which is as it should be!). Only one comment actually surprised me.
2009/4/21 Michael Snow <wikipedia(a)verizon.net>:
> The Wikimedia Foundation takes this opportunity to reiterate some core
> principles related to our shared vision, mission, and values. One of
> these values which is common to all our projects is a commitment to
> maintaining a neutral point of view.
I find it a bit strange to talk of Wikimedia Commons as having a NPOV
policy. Like Wikiquote, our "unit" of interest is something that
typically has a strong authorial voice rather than being a synthesis
of multiple contributions. (Unlike WQ, it does in some circumstances
make sense to edit a file, unlike a quote -- but usually if the edit
radically changes the meaning, it should become a separate, derived
We are also, like WQ, bound by the creations of others, especially in
relation to past events. If there is some past conflict, where the
(free) media is available only represents one side of the conflict,
there is nothing we can do to "balance" that. So there is an external
limit on how "neutral" we are able to be.
I also find there is some tension between the views of 1) "Wikimedia
Commons as a service project" and 2) "Wikimedia Commons as a project
in its own right".
According to 1), the files in Commons are "context-free", waiting to
be used somewhere and given context. And context is a major part of
NPOV. As a service project, it would not be up to us to decide
questions of "proportional representation", because that would all
depend on how they are used in the projects.
According to 2), the Commons community would have a role to play in
deciding appropriate proportional representation, and we would assume
the Wikimedia Commons itself is a context of use for the files.
This plays into the question of how much autonomy the Wikimedia
Commons community has. If we have a curatorial role beyond being
"license police" and enforcing our necessarily very broad project
scope, then that must be negotiated between these two views. I
definitely believe it is not Common's role to decide "for" projects,
which free media they should use. So this is something of a constraint
It *may* make sense to talk to NPOV for Wikimedia Commons, but I don't
think it is necessarily obvious, or that it should be assumed everyone
has a shared understanding of what that means.
Of interest: <http://commons.wikimedia.org/wiki/Commons:Project_scope/Neutral_point_of_vi…>
They've just been waiting in a mountain for the right moment:
> Message: 2
> Date: Mon, 6 Apr 2009 20:40:37 +0100
> From: geni <geniice(a)gmail.com>
> Subject: Re: [Commons-l] Court: Congress can't put public domain back
> into copyright
> To: Wikimedia Commons Discussion List <commons-l(a)lists.wikimedia.org>
> Content-Type: text/plain; charset=ISO-8859-1
> 2009/4/6 Yann Forget <yann(a)forget-me.net>:
>> This will have implications for Commons too.
> No since commons respects the copyright of the country of origin.
I consider the answer no or yes depending on the copyright status of
the country of origin. If published outside the USA only, without
complying with the US formality and thus once considered in the public
domain in the USA before the URAA restoration, it may benefit Commons
if now PD in the source country even if still copyright-restricted at
home in 1996 and then caused what I would call as the "American
non-acceptance of the rule of the shorter term".
This will have much more implications for Wikisource as some works
hosted at Canadian Wikilivres may be able to be sent back to
Wikisource if this ruling opinion becomes final.
I and my wife have worked on Trees of Agra and have identified some 150 plants growing at various places including historical monuments, educational institutions, public parks, gardens, roadside and country side. We wish to donate this work to the common users hence our choice has fallen on Wukimedia. Will you please accept this work on yuor web? Awiting an early response
Ram Kishore Singh Rathore
R K S Rathore
10, Govind Nagar
AGRA 282 010
This will have implications for Commons too.
On Mon, Apr 6, 2009 at 11:54 AM, GerardM <gerard.meijssen(a)gmail.com> wrote:
> This is of sufficient merit that I do it this way.
> Aan u verzonden door GerardM via Google Reader: Court: Congress can't
> put public domain back into copyright via Ars Technica door
> nate(a)arstechnica.com (Nate Anderson) op 6-4-09
> In 1994, Congress jammed a batch of foreign books and movies back into
> the copyright closet. They had previously fallen into the public domain
> for a variety of technical reasons (the author hadn't renewed the
> rights with the US Copyright Office, the authors of older works hadn't
> included a copyright notice, etc.) and companies and individuals had
> already started reusing the newly public works. Did Congress have the
> right to put a stop to this activity by shoving the works back into
> copyright? On Friday, a federal court said no.
> "Traditional contours of copyright"
> 1994's Uruguay Round Agreements Act (URAA) brought US intellectual
> property law in line with that of other countries. Section 514 of URAA
> better aligned US copyright law with the international Berne
> Convention, one of the earliest international intellectual property
> treaties. Though Berne had first been signed back in 1886, the US
> hadn't joined up until a century later, in 1988.
The URL, for those wanting the rest of the story:
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikisource.org/ | Bibliothèque libre
http://wikilivres.info | Documents libres
---------- Forwarded message ----------
From: Ævar Arnfjörð Bjarmason <avarab(a)gmail.com>
Subject: [Wikitech-l] ANNOUNCE: OpenStreetMap maps will be added to
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, OSM-Dev
Openstreetmap <dev(a)openstreetmap.org>, Talk Openstreetmap
There has been rapid progress on the subject of adding OpenStreetMap
maps to Wikimedia projects (e.g. Wikipedia) during the MediaWiki
Developer Meet-Up taking place right now in Berlin.
We now have a clear plan of action for getting OpenStreetMap maps
embedded in Wikimedia wiki (e.g. Wikipedia) pages:
* Wikimedia will set up a database to mirror the OSM data (Planet.osm)
* Wikimedia will set up its own rendering infrastructure for rendering
tiles & other maps from the OSM data
* The existing MediaWiki extensions for displaying OSM data in a
MediaWiki article will be improved to work acceptably in production on
To prototype all this we'll be using new infrastructure provided by
Wikimedia Deutschland. Once things have been tested there they'll
eventually be deployed on the main Wikimedia sites.
After discussion with the Wikimedia operations people (including Brion
Vibber, Mark Bergsma et al) there seem to be no objections to the
above plan as long as:
* The tools involved are improved to be relatively stable & deployable
on Wikimedia, e.g. being able to embed more than one slippy map, the
internationalization of error messages etc.
* The end product (the generated tiles or map files) are cachable so
that they can be thrown at the frontend squids, as they're static
images this should be easy.
The featureset that we're aiming for to be able to deploy this on
Wikimedia sites from the view of the user (more can be added later
once we've got it working) is:
* The ability to embed OSM maps in articles with something like the
Simple image extension, perhaps automagically turning into a Slippy
Map if the browser supports it
* A static or slippy map that can be used by geotagged articles so
we can have maps without explicit inclusion of a <map> tag.
We'll also set up a map toolserver for experimenting with other uses
of OpenStreetMap data on Wikimedia. People with relevant projects can
get access to this toolserver to try out their ideas for tools that
could eventually be integrated on the main Wikimedia sites.
This project is seeking help from anyone who's interested who'd like
to be a part of making this happen, if you want to be a part of adding
free maps to the world's largest encyclopedia please subscribe to this
And/or read/edit/comment on the relevant wiki coordination pages:
Wikitech-l mailing list
They've just been waiting in a mountain for the right moment:
The add media Wizard is in testing see blog post:
If no one objects (or has any blocker bugs that I have missed) I will
add the gadget option for firefogg / add media wizard to commons
shortly. (for wider testing) We could also add the basic commons search
as a gadget for wikipedia proper. (making commons image inserts much easier)
more about add_media_wizard:
The searching remote repository and in-line upload and template via url
component that is working on test.wikimedia.org is not as easy to push
out. The implementation on test.wikimedia.org is limited to files that
it can copy in less than 30 seconds (php time out ) and is parsing html
page output to determine errors. To move the add media wizard searching
and insert into production we will need to deploy the new-upload branch.
I will be targeting fixes to upload bugs 18200, 18201, 18202 to the
Looking beyond English language gadgets ... Localization is dependent
more about js server: http://www.mediawiki.org/wiki/Extension:ScriptLoader