2009/7/11 David Gerard <dgerard(a)gmail.com>:
> It gets better: the editor they sent the threat to is an American.
> So, to recap: A UK organisation is threatening an American with legal
> action over what is unambiguously, in established US law, not a
> copyright violation of any sort.
> I can't see this ending well for the NPG.
In fact, the more legal success they have with this approach (and they
do have a plausible cause in the UK, if they throw enough money at
arguing so), the more *utterly radioactive* the publicity for them
will be.
I’ll be calling the NPG first thing Monday (in my capacity as “just a
blogger on Wikimedia-related topics”) to establish just what they
think they’re doing here. Other WMF bloggers and, if interested,
journalists may wish to do the same, to establish what their
consistent response is.
- d.
Hi all,
As a tangent to the national portrait gallery thing, I though I'd raise
something which I've chatted about previously (possibly here, but certainly
with various community members) which seems unresolved.
My understanding of the status quo is that when a commons administrator
deletes an image, that image remains available to all other commons
administrators. In the context of the NPG's request, I thought it was
interesting to confirm that even if Derrick deleted all his uploaded images,
they do, in fact, remain available to him, and all other 'community' members
with the sysop. flag - I'm unsure as to the implications / consequences of
this in terms of the NPG action, who presumably would be pretty frustrated
if Derrick deleted all the images, and another, perhaps more pseudonymous,
administrator, were to restore them all (likely with the support of 'the
community' at this point).
I chatted with User:Lar about this a bit here;
http://commons.wikimedia.org/wiki/User_talk:Lar#permanent_deletion
and gave the example which concerns me more there - which is illegal and
potentially illegal images of children on foundation projects. Commons
administrators will be able to see an image here;
http://commons.wikimedia.org/w/index.php?title=File:Brip.jpg&action=edit&re…
which I considered to be borderline at best, and maybe an illegal image. I
consider the fact that I can write 'Commons administrators will be able to
see an image here' to be the heart of the problem! I hope the foundation
might consider a software tweak of some sort to allow for permanent deletion
- along with this tweak I feel sure the foundation staff could propose a
sensible set of criteria which would have broad support.
cheers,
Peter,
PM.
*Hi, I want to remind you that on 26 Nov 2008 **
http://lists.wikimedia.org/pipermail/foundation-l/2008-November/047554.html*<http://lists.wikimedia.org/pipermail/foundation-l/2008-November/047554.html>
* you have promised that subdomain name mo will become mo-cyrl, it's July
now and mo is still not yet renamed.*
* *
*If you cannot rename please delete it altogether.
Hope to get a ETA, or to know at which point is the progress.
Brion Vibber and his superiors, please make a room for this task to be done,
also I (as a programmer) can volunteer to help you do this thing if you have
a lack of resources !
IT'S IMPORTANT !
*
Point of clarification -- the Wikimedia Foundation sends out press releases to international media, not just US media. We have no plans to send out a press release on this issue.
Thanks,
Sue
------Original Message------
From: Thomas Dalton
Sender: foundation-l-bounces(a)lists.wikimedia.org
To: Wikimedia Foundation Mailing List
ReplyTo: Wikimedia Foundation Mailing List
Sent: Jul 11, 2009 10:31 AM
Subject: Re: [Foundation-l] About that "sue and be damned" to the NationalPortrait Gallery ...
2009/7/11 Geoffrey Plourde <geo.plrd(a)yahoo.com>:
> Lets finish up the press releases and drop this thread. NPG can read it too. Has a US press release been sent out?
I doubt it. The WMF handles US press releases and they aren't stupid
enough to talk to the press until they know what they're talking
about.
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
... the National Portrait Gallery appear to be sending legal threats
to individual uploaders, after the Foundation ignored their claims as
utterly, utterly specious.
http://commons.wikimedia.org/wiki/User:Dcoetzee/NPG_legal_threat
The editor in question is US-based.
So. What is WMF's response to this odious attempt to enclose the commons?
- d.
We're in contact with Derrick. We're looking at ways we may be able to help.
I think that since this case involves an individual (at least right now),
we'd probably do best not to game out strategy on it in a public mailing
list. So while discussing the general theory of copyright as it relates to
this case is fine, I don't think it's a good idea to talk about specific
responses here just yet.
--Mike
There has been a technical discussion on wikitech-l regarding the
recommendation of a browser for the high quality open video experience.
Some native implementations are ~presently~ non optimal and the java
cortado applet we use where no native support is available is a poor
user experience relative to native support. Therefore we are considering
informing people who want to view video that for a high quality
expericne with free formats they should use a particular browser.
Presently that browser is Firefox 3.5. Key to this recommendation is we
will continue to support playback in other browsers the best that we can
but we should inform people that a better experience is possible. This
hopefully will encourage other browser vendors to improve the free
format experience and support or lose market share.
== Technical Support Considerations ==
* Mozilla Firefox 3.5 release version -- has worked closely with the
xiph community and supports html5 ogg theora video natively with a high
quality experience across all platforms.
* Apple Safari -- supports html5 video but recommends the h.264 as the
format. To support ogg you must install the xiph qt components written
by xiph.org community members. The installation involves downloading a
file, mounting an install image and dragging a component to the
library/components folder on the target machine.
** In the present release version of Safari its difficult to reliably
detect if the browser support the video tag with free formats.
** Seeking past what has already been downloaded does not work.
** The quicktime framework / ogg component does not work well with
server side seeking helpers we have been developing.
* Google Chromium -- supports h.264 and ogg theora video natively. Again
ogg performance is not very high quality. It uses the ffmpeg library
which features a non-optimal theora decoder. Things like seeking
presently don't work very reliably.
* Opera -- Was one of the first browsers to demo ogg theora support in
their browser. They are presently working on re-including it in a
release. ~presently it does not support the video tag~
* Microsoft IE -- has no support for the video tag and no support for
ogg theora. We support playback in IE via the java cortado applet.
** the java cortado applet is a fall-back for browsers that don't
support the native video tag. Its not a very high quality user
experience. Sometimes java crashes the browser, it generally takes a
while to startup; seeking does not work very well and video is not
cached causing more expenses to the wikimedia foundation on repeat video
views.
== Institutional Support Considerations ==
Institutional the Mozilla foundation has worked with Wikimedia and the
xiph.org community to realize Ogg Theora video in the open web platform.
They supported wikiemdia/xiph.org with a 100k grant early this year to
improve the ogg libraries for playback, improve codec encoding quality
and develop open source server side technologies for improved seeking
performance.
While Apple does at least support adding in of codecs into the quicktime
system and some people form Apple have had friendly conversations with
us. The Apple Corporation essentially says "it can't ship default
support for xiph because of perceived patent risk". With Google shipping
Chrome with ogg support the submarine patent argument (that no other
large company is shipping ogg) would appear to be less valid. Perhaps we
as "wikimedia" could help apple do the right thing?
Also have not heard much from Microsoft regarding free formats. Again I
think market pressures are the only thing that will drive adoption in
this case.
== Proposed Approach and Proof of Concept ==
Presently the proposed solution is to soft link to the Mozilla Firefox
browser: see mockup:
http://metavid.org/blog/wp-content/uploads/2009/07/upgrade_to_firefox.png
or see it in action:
http://metavid.org/wiki/File:FolgersCoffe_512kb.1496.ogv
Note that informing the user that a better experience is possible with
alternative browser software, it will not disable or remove our
fall-back java support.
peace,
--michael
http://www.nytimes.com/2009/07/10/world/asia/10iht-malay.html
The Malaysian government has declared that science instruction will be
conducted in Bahasa rather than English. Parents, teachers and
professors are very unhappy because "English is the language of
science."
This sort of thing affects the quality of our projects in languages
other than English.
I'm not sure what to suggest, but it struck me as relevant to language
issues we face.
- d.
geni geniice at gmail.com wrote:
> I assume you are pointing to the "Downpreffed VLC because it crashes
> my browser all the damn time -- TS" comment.
> Still another problem with recommending an option is well when this happens:
> http://commons.wikimedia.org/wiki/File:Videoscreengrab_of_Morris_C8_towing.…
> As you can see following the recommended course of action results in a
> far from idea experience. Now to be fair [[File:Morris C8 towing.ogv]]
> is known to cause problems when played but it does work on the VLC
> plugin with firefox 3.0 at least on my system.
Mozilla is quite responsive. (I fixed quite a few video bugs prior to release)
But in this case there doesn't appear to be any real firefox problem.
You've got a >6mbit/sec Ogg/Theora file. The stalling is because
firefox doesn't prebuffer and your connection isn't fast enough to get
ahead of it. Once the file is transferred moving the playhead back to
the start gives smooth video.
Prebuffering can be achieved by setting the autobuffer parameter
before playback begins. The current way video is launched by the site
defeats that. Other playback methods will hold the initial playback
until some buffer has filled, so they don't exhibit the same behavior.
This situation can be improved by managing the buffering process using
JS or simply making good use of autobuffer.
But the real flaw here is expecting a 6mbit/sec file to stream…
Unfortunately until we have some trans-coding infrastructure that will
remain a problem.
I was thinking about running a bot to take all uploaded videos shrink
them to 480px (if larger) and encode at reasonable streaming friendly
bitrates, then uploading back as filename_thumb480 and replacing them
in articles. I'm not sure how people will feel about that but it will
greatly improve video playability without encouraging people to upload
at low qualities which are completely unsuitable for editing.
