I have been looking for social networking service that would be fair: not abusing personal data, funded by community, respecting privacy, accepting anonymity, free/libre/ open source etc. Haven’t found many. The Diaspora* Project is not moving forward very fast and the Mastodon is more a microblogging service rather than a social network service.
Would it make sense for Wikimedia movement to build its own social network service?
In the "2017 Movement strategy” we state: “By 2030, Wikimedia will become the essential infrastructure of the ecosystem of free knowledge”. If we consider discussions and information shared on social network services to be “knowledge”, I think we should have a role in here too.
We have 33 million registered users and fulfil all the requirements of being a “fair service”. A minimum list of features to make Wikimedia Social would be:
(1) Status updates
I am pretty sure that by integrating this to other Wikimedia services (Commons etc.) we could achieve something awesome.
Thank you for your answer, Sebastian.
Publishing the Gutachten would be fantastic! That would be very helpful and
Regarding the relicensing, I agree with you. You can just go and do that,
and given that you ask for attribution to DBpedia, and not to Wikipedia, I
would claim that's what you're doing. And I think that's fine.
Regarding attribution, commonly it is assumed that you have to respect it
transitively. That is one of the reasons a license that requires BY sucks
so hard for data: unlike with text, the attribution requirements grow very
quickly. It is the same as with modified images and collages: it is not
sufficient to attribute the last author, but all contributors have to be
This is why I think that whoever wants to be part of a large federation of
data on the web, should publish under CC0.
That is very different from licensing texts or images. But for data
anything else is just weird and will bite is in the long run more than we
might ever benefit.
So, just to say it again: if the Gutachten you mentioned could be made
available, that would be very very awesome!
Thank you, Denny
On Thu, May 17, 2018, 23:06 Sebastian Hellmann <
> Hi Denny,
> On 18.05.2018 02:54, Denny Vrandečić wrote:
> Rob Speer wrote:
> > The result of this, by the way, is that commercial entities sell modified
> > versions of Wikidata with impunity. It undermines the terms of other
> > resources such as DBPedia, which also contains facts extracted from
> > Wikipedia and respects its Share-Alike terms. Why would anyone use
> > and have to agree to share alike, when they can get similar data from
> > Wikidata which promises them it's CC-0?
> The comparison to DBpedia is interesting: the terms for DBpedia state
> "Attribution in this case means keep DBpedia URIs visible and active
> through at least one (preferably all) of @href, <link />, or "Link:". If
> live links are impossible (e.g., when printed on paper), a textual
> blurb-based attribution is acceptable."
> So according to these terms, when someone displays data from DBpedia, it
> is entirely sufficient to attribute DBpedia.
> What that means is that DBpedia follows exactly the same theory as
> Wikidata: it is OK to extract data from Wikipedia and republish it as your
> own dataset under your own copyright without requiring attribution to the
> original source of the extraction.
> (A bit more problematic might be the fact that DBpedia also republishes
> whole paragraphs of Text under these terms, but that's another story)
> My understanding is that all that Wikidata has extracted from Wikipedia is
> non-copyrightable in the first place and thus republishing it under a
> different license (or, as in the case of DBpedia for simple triples, with a
> different attribution) is legally sound.
> In the SmartDataWeb project https://www.smartdataweb.de/ we hired lawyers
> to write a legal review about the extraction situation. Facts can be
> extracted and republished under CC-0 without problem as is the case of
> infoboxes.. Copying a whole database is a different because database rights
> hold. If you only extract ~ two sentences it falls under citation, which is
> also easy. If it is more than two sentence, then copyright applies.
> I can check whether it is ready and shareable. The legal review
> (Gutachten) is quite a big thing as it has some legal relevancy and can be
> cited in court.
> Hence we can switch to ODC-BY with facts as CC-0 and the text as
> share-alike. However the attribution mentioned in the imprint is still
> fine, since it is under database and not the content/facts.
> I am still uncertain about the attribution. If you remix and publish you
> need to cite the direct sources. But if somebody takes from you, does he
> only attribute to you or to everybody you used in a transitive way.
> Anyhow, we are sharpening the whole model towards technology, not
> data/content. So the databus will be a transparent layer and it is much
> easier to find the source like Wikipedia and Wikidata and do contributions
> there, which is actually one of the intentions of share-alike (getting work
> pushed back/upstream).
> All the best,
> If there is disagreement with that, I would be interested which content
> exactly is considered to be under copyright and where license has not been
> followed on Wikidata.
> For completion: the discussion is going on in parallel on the Wikidata
> project chat and in Phabricator:
> I would appreciate if we could keep the discussion in a single place.
> Gnom1 on Phabricator has offered to actually answer legal questions, but
> we need to come up with the questions that we want to ask. If it should be,
> for example, as Rob Speer states on the bug, "has the copyright of
> interwiki links been breached by having them be moved to Wikidata?", I'd be
> quite happy with that question - if that's the disagreement, let us ask
> Legal help and see if my understanding or yours is correct.
> Does this sound like a reasonable question? Or which other question would
> you like to ask instead?
> On Thu, May 17, 2018 at 4:15 PM Rob Speer <rob(a)luminoso.com> wrote:
>> > As always, copyright is predatory. As we can prove that copyright is the
>> enemy of science and knowledge
>> Well, this kind of gets to the heart of the issue, doesn't it.
>> I support the Creative Commons license, including the share-alike term,
>> which requires copyright in order to work, and I've contributed to
>> Wikimedia projects with the understanding that my work would be protected
>> by CC-By-SA.
>> Wikidata is engaged in a project-wide act of disobedience against
>> I would say that GerardM has provided an excellent summary of the attitude
>> toward Creative Commons that I've encountered on Wikidata: "it's holding
>> back", "it's the enemy", "you can't copyright knowledge", "you can't make
>> us follow it", etc.
>> The result of this, by the way, is that commercial entities sell modified
>> versions of Wikidata with impunity. It undermines the terms of other
>> resources such as DBPedia, which also contains facts extracted from
>> Wikipedia and respects its Share-Alike terms. Why would anyone use DBPedia
>> and have to agree to share alike, when they can get similar data from
>> Wikidata which promises them it's CC-0?
>> On Wed, 16 May 2018 at 21:43 Gerard Meijssen <gerard.meijssen(a)gmail.com>
>> > Hoi,
>> > Thank you for the overly broad misrepresentation. As always, copyright
>> > predatory. As we can prove that copyright is the enemy of science and
>> > knowledge we should not be upset that *copyright *is abused we should
>> > welcome it as it proves the point. Also when we use texts from
>> > and rephrase it in Wikipedia articles "we" are not lily white either.
>> > In "them old days" generally we felt that when people would use
>> > it would only serve our purpose; share the sum of all knowledge. I still
>> > feel really good about that. And, it has been shown that what we do;
>> > maintain / curate / update that data that it is not easily given to do
>> > well as "we" do it.
>> > When we are to be more precise with our copyright, there are a few
>> > we could do to make copyright more transparent. When data is to be
>> > (Commons / Wikipedia or Wikidata) we should use a user that is OWNED and
>> > operated by the copyright holder. The operation may be by proxy and as a
>> > consequence there is no longer a question about copyright as the
>> > holder can do as we wants. This makes any future noises just that,
>> > annoying.
>> > As to copyright on Wikidata, when you consider copyright using data from
>> > Wikipedia. The question is: "What Wikipedia" I have copied a lot of data
>> > from several Wikipedias and believe me, from a quality point of view
>> > is much to be gained by using Wikidata as an instrument for good
>> because it
>> > is really strong in identifying friends and false friends. It is
>> > as a tool for disambiguation.
>> > About the copyright on data, the overriding question with data is: do
>> > copy data wholesale in Wikidata. That is what a database copyright is
>> > about. As I wrote on my blog , the best data to include is data that
>> > corroborated by the fact that it is present in multiple sources. This
>> > negates the notion of a single source, it also underscores that much of
>> > data everywhere is replicated a lot. It also underscores, again, the
>> > that data that is only present in single sources is what needs
>> > It needs tender loving care, it needs other sources to establish
>> > credentials. That is in its own right what makes any claim of copyright
>> > moot. It is in this process that it becomes a "creative" process
>> > the copyright held on databases.
>> > I welcome the attention that is given to copyright in Wikidata. However
>> > attention to copyright is predatory in two ways. It is how can we get
>> > around existing copyright and how can we protect our own. As argued,
>> > Wikidata shines when it is used for what it is intended to be; the place
>> > that brings data, of Wikipedias first and elsewhere second, together to
>> > used as a repository of quality, open and linked data.
>> > Thanks,
>> > GerardM
>> > 
>> > On 11 May 2018 at 23:10, Rob Speer <rob(a)luminoso.com> wrote:
>> > > Wow, thanks for the heads up. When I was getting upset about projects
>> > that
>> > > change the license on Wikimedia content and commercialize it, I had no
>> > idea
>> > > that Wikidata was providing them the cover to do so. The Creative
>> > > violation is coming from inside the house!
>> > >
>> > > On Tue, 8 May 2018 at 03:48 mathieu stumpf guntz <
>> > > psychoslave(a)culture-libre.org> wrote:
>> > >
>> > > > Hello everybody,
>> > > >
>> > > > There is a phabricator ticket on Solve legal uncertainty of Wikidata
>> > > > <https://phabricator.wikimedia.org/T193728> that you might be
>> > interested
>> > > > to look at and participate in.
>> > > >
>> > > > As Denny suggested in the ticket to give it more visibility through
>> > > > discussion on the Wikidata chat
>> > > > <
>> > > > https://www.wikidata.org/wiki/Wikidata:Project_chat#
>> > > Importing_datasets_under_incompatible_licenses>,
>> > > >
>> > > > I thought it was interesting to highlight it a bit more.
>> > > >
>> > > > Cheers
>> > > >
>> > > > _______________________________________________
>> > > > Wikimedia-l mailing list, guidelines at:
>> > > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
>> > > > https://meta.wikimedia.org/wiki/Wikimedia-l
>> > > > New messages to: Wikimedia-l(a)lists.wikimedia.org
>> > > > Unsubscribe:
>> > > > <mailto:email@example.com
>> > > _______________________________________________
>> > > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
>> > > wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
>> > > wiki/Wikimedia-l
>> > > New messages to: Wikimedia-l(a)lists.wikimedia.org
>> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>> > > <mailto:firstname.lastname@example.org?subject=unsubscribe>
>> > _______________________________________________
>> > Wikimedia-l mailing list, guidelines at:
>> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
>> > https://meta.wikimedia.org/wiki/Wikimedia-l
>> > New messages to: Wikimedia-l(a)lists.wikimedia.org
>> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> > <mailto:email@example.com?subject=unsubscribe>
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
>> New messages to: Wikimedia-l(a)lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> Wikidata mailing listWikidata@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikidata
> All the best,
> Sebastian Hellmann
> Director of Knowledge Integration and Linked Data Technologies (KILT)
> Competence Center
> at the Institute for Applied Informatics (InfAI) at Leipzig University
> Executive Director of the DBpedia Association
> Projects: http://dbpedia.org, http://nlp2rdf.org,
> http://linguistics.okfn.org, https://www.w3.org/community/ld4lt
> Homepage: http://aksw.org/SebastianHellmann
> Research Group: http://aksw.org
I'm delighted to announce that the Wikimedia Foundation's Annual Plan for
FY18-19 is now on Meta.
This year, we have organized our efforts around three goals that focus on
making critical improvements to our systems and structures to ensure that
we’re better positioned for our coming work against the strategic
direction. The Foundation’s goals for this year should not only move us
closer to knowledge equity and service, but will prepare us to execute
against the 3- to 5-year strategic plan which we intend to develop this
year in order to guide the Foundation’s work into the future.
As you’ll see, we’ve made some changes to the structure of this year’s
annual plan. This year’s plan is organized around three goals for the
Foundation’s work in the year to come. By restructuring the Annual Plan, we
have written a plan for the whole Foundation, rather than an aggregation
of plans from all of our departments and teams. In this sense, we’re
seeking to become a better-integrated institution, rather than a collection
of teams and departments with disparate goals.
We’ve also reduced the overall length of the published Annual Plan. We
wanted to make sure that the focus and goals of our work don’t get lost in
the details. Of course, we know that many community members enjoy reading
the particulars of our planned work, so you can still access the details of
departmental programs through links to their descriptions on Meta or
MediaWiki.org. These links will provide interested readers with detailed
departmental programs, which describe the specific and detailed program
goals, impact and outcomes. This change does not sacrifice the depth and
rigor of our planning process, but rather, it is meant to keep the Annual
Plan lean and focused while allowing interested readers to dive deep into
Finally, we’ve expanded the planning framework we instituted last year for
cross-departmental programs to all of our programs across the Foundation.
This allows us to clearly link a program’s resources to outcomes and
measures. As such, we’ve presented the Annual Plan budget in terms of our
investments in the three defined goals rather than in terms of our internal
Thank you all for your support over the past year. I'm really looking
forward to your feedback on this year's proposed plan during the open
comment period -- a reminder it runs through May 15th.
1 Montgomery Street, Suite 1600
San Francisco, CA 94104
+1 (415) 839-6885 ext. 6635 <(415)%20839-6885>
+1 (415) 712 4873 <(415)%20712-4873>
to better serve the technical communities that build free and open source software for the movement as well as the communities who use Wikimedia's APIs to interact with our projects, the Wikimedia Foundation is making some structural changes. The Technical Engagement team is a new team in the Technology department of the Wikimedia Foundation reporting to the Foundation's Chief Technology Officer (CTO), Victoria Coleman. This new team has two sub-teams: the Wikimedia Cloud Services team and the Technical Advocacy team. Bryan Davis will manage the Technical Engagement teams. He will also lead the hiring process for a new Developer Advocacy Manager position, which will take over some of the management duties.
The Wikimedia Cloud Services team will continue to focus on maintaining the Wikimedia Cloud VPS infrastructure as a service <https://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.…> platform, the Toolforge platform as a service <https://en.wikipedia.org/wiki/Platform_as_a_service> project, and additional supporting technologies used in the Cloud Services environment such as the Wiki Replica databases and the hosting infrastructure for dumps.wikimedia.org <https://dumps.wikimedia.org/>. The existing team of Andrew Bogott, Arturo Borrero Gonzalez, Brooke Storm, and Chase Pettet will be joined by James Hare in the role of Product Manager. The team is also hiring for a fifth Operations Engineer and for a part-time technical support contractor.
The Technical Advocacy team will focus on creating improved documentation for Wikimedia APIs and services as well as providing support for technical contributors and API consumers. The new team is being formed by moving the Foundation's Developer Relations team to the Technology department, with the exception of Rachel Farrand who will remain in Community Engagement in close collaboration with other event organizers. Andre Klapper and Srishti Sethi are both taking the role of Developer Advocate in the new team. A developer advocate is someone whose primary responsibility is to make it easy for developers to use a platform. Typically they do this by producing example software, tutorials, and other documentation explaining how to use the platform's products and services. Sarah R. Rodlund will also be joining the team as a Technical Writer. Technical writing has many subspecialties. Sarah will be focusing on improving our existing documentation by helping create a style guide and editing existing documentation to fit with that guide. She will also be supporting volunteers who are interested in practicing their technical writing skills on Wikimedia documentation. The team will be hiring for a Developer Advocacy Manager role in July. This new person will help round out the skills of the team and will take the lead in developing their programs.
The Technical Engagement team will work with other teams inside the Wikimedia Foundation as well as groups at affiliate organizations and the larger Wikimedia volunteer community to provide technical outreach services and support. We hope to continue to grow the number of people involved in our programs until we can confidently say that we are providing the best help possible to the hundreds of volunteer developers, designers, technical writers, and end users of the Wikimedia movement's APIs and services. We will continue to be involved in existing programs to attract and support new technical contributors like the Wikimedia Hackathons, Outreachy, and Google Summer of Code. We also hope to find new ways to connect with new and existing technical contributors as we support the Wikimedia movement's 2030 strategic direction and the shared goals of knowledge as a service and knowledge equity.
Very excited to be getting started down the path of strengthening our developer advocacy program!
Chief Technology Officer
1 Montgomery Street, Suite 1600
San Francisco, CA 94104
My main worry, during my daily patrolling, is if we manage to neutralize
the bad editing (vandalism, POV pushing) or if the destructive editing
is slowly successfully degenerating the great content we have created in
In todays Sign-post it indicates an accelerating rate of decrease of
admins on enwp, and some likewise tendency on dewp. Is this a sign that
the "good" powers are losing out to the "bad" ones?
I also seen a very passive response to two massPOV editing . One, on 35
versions, is related to Hans Asperger, to state he was a nazi doctor
(false, even if he was somewhat passive in some cases). Here dewp
reacted quickly and after a while enwp, so these articles are OK, but in
most of the other 35 this false info lies unchanged. Also I react to the
effort from GazProm promoting their propaganda article /Football for
Friendship / in up to 80 version, and where almost noone has neutralized it.
Are we slowly losing the battle against the "evil" forces? And if so,
is then our new strategy (being good in itself) and the plan to
implement it all too naive? For example I like very much the ambition
to help out on areas in the world where Wikipedia etc is not
established, but would it be more correct to put effort in regaining
control of the very many Wikipedia versions, that is definitely
degenerating and we are loosing what has been done on these. (as a test
look at "latest changes" on some of the versions with low editing, it is
depressing to see that there often are more vandal editing, not being
undone, then proper new material)
Would it be most appropriate if we all in a 2-3 years effort
concentrated on getting (back) control on our material in our projects,
before we start efforts in implementing the strategy we have agreed
upon. Perhaps a number of paid admins, vandal/pov fighters, about as
many as there are stewards today, would be necessary not to lose out.
Based on the limited information that I have, it seems to me that there are already numerous contribtors who are paid to engage in promotional activity on Wikipedia, whether declared or undeclared, and the community does not have adequate human resources to patrol and investigate all of these. I expect that the problem will continue to get worse unless WMF gets more energetic about investigating TOS violations involving undeclared COI and WMF becomes predictable about extracting financial penalties that are severe enough to deter most of the undeclared COI contributors. Unfortunately, as far as I know, WMF has been largely passive about the problem of undeclared COI and has not announced any plans to become more aggressive.
As nice as it would be if everyone could afford and was willing to work for free, this is not the case. If it was then we could safely eliminate the salaries of the entire WMF staff. However, I think that financial support makes sense for some paid staff to handle activities like network operations, interface design, legal defense, and responses to safety problems.
Some types of Wikimedia activities are better suited to volunteer work than others. I encourage volunteers to avoid burning themselves out; there are some activities that I did in the past that I would not do again as a volunteer. Better to be an occasional and long-term contributor than to get burned out.
I have some ideas about how to pay people to do certain types of work that, so far, WMF has not funded. Unfortunately these are merely ideas and not likely to become reality in the short term. Perhaps later this year or in the next few years I will have specific proposals with reasonable chances for sustainable success.
I share the concern that paid participants in the Wikiverse, like staff of WMF and affiliates, WMF grantees, and potentially like the paid contributors that I have in mind, may become so numerous that they can drown out the consensus of the volunteers. Unfortunately I do not have easy solutions for this issue. We could prohibit all paid contributors from participating in RFCs and related decision processes, but we would be largely relying on people to self-disclose their paid status, which seems unlikely to be adequate.
Perhaps the issues that we are discussing in this conversation should be included in the Structures and Systems prong of the WMF strategy process. I am pinging Nicole to ask for her input about that idea. However, keep in mind that the strategy process is financially sponsored by WMF, and it is not free of potential conflicts with the interests of WMF.
I wish that I could be more optimistic. These are difficult topics.
( https://meta.wikimedia.org/wiki/User:Pine )
Benjamin Lees wrote: "No, French Christians are just tagged with
subcategories of Category:French Christians. The "requiring diffusion"
category that you complain of is in fact a way to tell editors that
pages in the category should really be in subcategories instead."
Aha! You're right, I had not realized that "diffuse" (disseminate/spread
widely) was being used as specialized en-wiki-jargon for
"subcategorize". It might be wise to give that hidden category a more
I looked into one of the many BLP entries with an unscourced
Category:French Jews tag, and found a review of a book they wrote. In
that book, the person stated that while they had a Jewish mother, they
did not consider themselves Jewish.
Given that the category French Jews contains more members than the
category French Roman Catholics, and that there are living people
included in both categories... I seriously wonder what it is that
motivates folks to anonymously tag others in this way (i.e. whether they
want to be tagged or not).
The Library of Congress, the BNF, Wikidata, etc. don't label people
according to religion, unless their notability is due specifically to
their religion (e.g. Alfred Dreyfus, Maimonides, etc.). On en.wp people
being labeled as Jewish/Catholic, etc. tend to be industrialists,
politicians, journalists, bankers etc. I don't think this is "best
practice" and I'm afraid I do not agree that en.wp is mostly "getting it
right" with regard to this specific question. Fr.WP and Wikidata are
doing much better.
The relevant section on "data subject" privacy rights in the GDPR (in
English) is based on the 1978 French law I cited earlier (though it has
become more restrictive since -- see below). As David Gerard noted, it
is quite likely that this affects not only Wikipedians (who can petition
to have libel/slander concerning their *online identity* (cf. definition
of data subject) removed from (inter alia) block logs), but also the
*content* of biographies of living people in the encyclopedia.
== GDPR (Article 9)==
*Processing* of personal data revealing racial or ethnic origin,
political opinions, religious or philosophical beliefs, or trade union
membership, and the processing of genetic data, biometric data for the
purpose of uniquely identifying a natural person, data concerning health
or data concerning a natural person's sex life or sexual orientation
shall be prohibited.
As one who has contributed to the projects since 2006, I am posting this
here not because I wish to sow dissent, but because I think some quick
thinking and corrective action is needed.
The Wikimedia Foundation Anti-Harassment Tools team enlisted the assistance
of Alex Hollender, a User Experience designer at Wikimedia Foundation to
create wireframe designs of Special:Block with the Granular block feature
Our first wireframes are based on the discussions on the Granular block
talk page, the Wishlist proposal, and in Phabricator to date.
Because the Special:Block page is already at its limits with its current
layout, we would like to propose a new organized layout for Special:Block.
This will make it easier to add the granular blocking (page, category,
namespace, etc) and whatever is to come in the future. All of the same
functionality is available on this new layout, but in a more organized,
Take a look at the wireframes and leave us your feedback on Meta.2
Please spread the word and forward this email to others (especially
administrators) who might be interested in helping re-design
For the Anti-Harassment Tools team,
Trust and Safety Specialist
Trust and Safety team;
Anti-harassment tools team