On Thursday, 31 January 2013 at 13:33, rupert THURNER wrote:
many thanks jon! personally i do not like that the
qrpedia domain is
registered cloaked, so nobody knows what comes out there later on.
this, and the long time the topic could not be settled is imo enough
to consider the name "qrpedia" as poisoned.
maybe it's best to just leave qrpedia to the people who registered it
and use another domain. qrcodes pointing to some website which then
redirects to some url is no rocket sience, and widely used since quite
a long time.
at WMCH we use qrcodes at least in two working groups, international
(tunesia e.g.) and GLAM. they are important to us, and i'd consider it
high risk to mount qrcode stickers physically which then link to a
site which has a cloaked owner. if qrpedia in 2 years time links to
pussy galore there is huge cost involved to change all the stickers
installed, beside the enormous reputational damage.
If no agreement is forthcoming regarding QRpedia, it would be
sensible to build an extension for MediaWiki that did HTTP
header-based language content negotiation, and use that MediaWiki
extension (or core modification, perhaps) on the various Wikimedia
projects, such that the URIs produced are actually on
wikipedia.org
(and any other WMF projects like Wikisource).
As the source code for qrwp is MIT licensed and available on Google
Code, it would be fairly trivial for a MediaWiki hacker to build the
functionality into MediaWiki itself.
One would have to be careful legally as MediaWiki is GPL2 licensed,
but the Software Freedom Law Center has a guide on how to maintain
code that is "permissively licensed" (which includes MIT licensed code)
with GPL modifications. See §2.2:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.ht…
I know that there is a general strategy in Wikimedia tech circles towards
trying to unify codebases and centralise the running of technical services.
The plans to close the Toolserver and transition the services running on
there from WMDE to WMF is one example of that.
If Wikimedia UK are unable to bring the QRpedia business to a sensible
conclusion, porting it to be an internal rather than external function of
MediaWiki would be a relatively straight-forward project for a
programmer to do.
One of the benefits of providing HTTP header-based language content
negotiation (what a mouthful) through MediaWiki itself rather than through
an external service is that currently QRpedia stores accesses of QRpedia
URLs in a database. Each time a user accesses a QRpedia URL, their
IP and the Wikipedia URL they are directed to is stored in a database.*
I am confident that the data is not being used illegitimately by Roger or
Terence. But ideally, a Wikimedia-affiliated service would not store
this kind of information given the Foundation's privacy policy. Ensuring
complete compliance with WMF privacy policy seems like a pretty
compelling reason to bring QRpedia in-house or build an
internally-supported replacement running on top of MediaWiki.
In addition, having language content negotiation done on the MediaWiki
side means that these things can be easily modified by engineers
working for the Foundation for compatibility and better integration with
new developments in mobile (smartphone apps, Wikipedia Zero etc).
* The function 'writeLog' in config.php
<https://code.google.com/p/qrwp/source/browse/trunk/config.php>
which is called on line 107 of index.php
<https://code.google.com/p/qrwp/source/browse/trunk/index.php>
before redirect to Wikipedia.
--
Tom Morris
<http://tommorris.org/>