Page MenuHomePhabricator

Make sure tools can be taken over after they are abandoned
Open, MediumPublic

Description

This is not covered well by the current Labs TOU:

  • While it requires an open source license for all code, it does not require publishing the source making actual tool recovery difficult in practice; and
  • It does not specify or require specification of a default license for code, making code that is not explicitly licensed (by neglect or design) not open in a way that is difficult to fix after the fact (in the case of abandonment, for instance).

Related Objects

StatusAssignedTask
OpenNone
Resolved bd808
Resolved bd808
Resolved bd808
Resolvedmmodell
Resolvedmmodell
Resolved bd808
Resolved dpatrick
Resolved bd808
Resolvedmmodell
Resolvedjcrespo
Resolved bd808
Resolved bd808
Resolved bd808
Resolved bd808
Resolved bd808
Resolved bd808
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
OpenNone
OpenNone
ResolvedJeanFred
ResolvedJeanFred
OpenNone
OpenNone
OpenNone

Event Timeline

coren created this task.Jun 10 2015, 9:28 PM
coren raised the priority of this task from to Medium.
coren updated the task description. (Show Details)
coren added a project: Cloud-Services.
coren added subscribers: coren, yuvipanda, valhallasw and 2 others.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 10 2015, 9:28 PM

I think we should reduce scope of this to Tool Labs, since it has more unique problems than Labs in general and also better solutions.

scfc added a comment.Jun 11 2015, 2:46 AM

I don't think that's helpful. Requiring publication of the sources would unnecessarily increase the cost of developing tools, and turn people volunteering their time and creativity into TOU offenders in a moment.

Sharing the sources to invite improvements by others is very much a goal literally shared by the broader Wikimedia community as evidenced by the model of Wikipedia & Co. I think it is best fostered by lauding excellent examples like Magnus's tools or the Pywikibot developers' work to encourage others to develop brilliant software in an open fashion as well. Amending the TOU could instead summon demons who threaten volunteers with legal action like it has been hinted at on labs-l.

If there are tools communities find "mission-critical" where the sources are not published today, the communities should push the developer(s) to publish the code. If they don't "comply", they shouldn't be forced to, but the communities instead should develop alternatives. Otherwise, if the forced developers plant easter eggs or just publish sources that do not correspond to the deployed code, the communities can be robbed of tools essential to their work irrespective of what the TOU might say.

yuvipanda renamed this task from Amend Labs TOU to Find ways to get more tools to publish their codd.Jun 11 2015, 8:55 AM
yuvipanda set Security to None.

Retitled to state problem, with many potential solutions. I agree that 'making it publicly available is painful' is a problem that should be fixed first (see subtask)

yuvipanda renamed this task from Find ways to get more tools to publish their codd to Find ways to get more tools to publish their code.Jun 11 2015, 8:58 AM
valhallasw renamed this task from Find ways to get more tools to publish their code to Make sure tools can be taken over after they are abandoned.Jun 11 2015, 9:07 AM
valhallasw updated the task description. (Show Details)

Hi all,

WMF Legal will be happy to work with everyone on potentially modifying the Labs TOU but obviously we will not do so unless we have reached an agreement on this issue.

Let me know if you have any questions.

Zhou

Ricordisamoa added a subscriber: Ricordisamoa.

What to do with OAuth keys? I'm afraid of adding co-maintainers to some of my tools because of the TOU...

Which part of the terms of use? If the OAuth TOU somehow effectively disallow multi-maintainer projects, that sounds like an issue with the OAuth TOU that needs to be solved. The only OAuth TOU I could find was

By submitting this application, you acknowledge that we reserve the right to disable your application, remove or restrict you or your application's access to this site, and pursue any other course of action we deem appropriate if we believe, in our sole judgment, that you or your application are violating any policy, guideline, and guiding principle of the this site. We can change this Application Policy at any time without prior notice, at our sole discretion and as we deem necessary. Your continued use of OAuth constitutes acceptance of those changes.

at the bottom of the application form, which doesn't sound too problematic?

Which part of the terms of use? If the OAuth TOU somehow effectively disallow multi-maintainer projects, that sounds like an issue with the OAuth TOU that needs to be solved. The only OAuth TOU I could find was

By submitting this application, you acknowledge that we reserve the right to disable your application, remove or restrict you or your application's access to this site, and pursue any other course of action we deem appropriate if we believe, in our sole judgment, that you or your application are violating any policy, guideline, and guiding principle of the this site. We can change this Application Policy at any time without prior notice, at our sole discretion and as we deem necessary. Your continued use of OAuth constitutes acceptance of those changes.

at the bottom of the application form, which doesn't sound too problematic?

@ZhouZ can you confirm? What level of secrecy do you expect from developers of OAuthenticated apps?

That's a good point @Ricordisamoa.

I think ideally, we do want developers to keep their OAuth key private only to themselves while providing access to other parts of their app. We will talk to operations to see how this might be workable.

csteipp added a subscriber: csteipp.Jul 7 2015, 5:09 PM

@Ricordisamoa, since the OAuth Consumer key allows you to act as that app for any user who has authorized you, that key should be kept private to whomever controls the app-- i.e., don't distribute the key in javascript, mobile apps, or publish it on github. But if another person has control of the Consumer's source code or the machine where the Consumer runs, they can arbitrarily act on behalf of authorizing users anyway. So keeping the key secret from other maintainers (other than exposing the key to more places/ways it can be compromised) doesn't improve the security of the system.

If there's any concern that the secret was compromised, you can always regenerate the secret, and everything will work as normal.

Eventually, it's been clear that we need to be able to update the owner of an app (I'm pretty sure there's a task for that). When that's available, then transferring ownership should include a secret regeneration too.

Thanks @csteipp!

@Ricordisamoa, I hope this answers your questions. I don't see more questions related to what you originally raised on the legal side but let me know if that's not the case.

Thanks @csteipp and @ZhouZ!
Should I ensure that co-maintainers have read the OAuth TOU and promised not to publish keys?

@Ricordisamoa, the only agreement is the notice on the bottom of the application, which valhallasw pointed out, so yes, they should be aware that by using OAuth, we reserve the right to revoke the Consumer if it seems like it is being misused.

They should also be familiar with https://www.mediawiki.org/wiki/OAuth/For_Developers, which generally specifies our expectations of how they will use OAuth.

they should be aware that by using OAuth, we reserve the right to revoke the Consumer if it seems like it is being misused.
They should also be familiar with https://www.mediawiki.org/wiki/OAuth/For_Developers, which generally specifies our expectations of how they will use OAuth.

I'm disheartened again...

ZhouZ moved this task from Backlog to Assigned on the WMF-Legal board.Apr 14 2016, 1:07 AM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptApr 14 2016, 1:07 AM
Qgil moved this task from To triage to Team radar on the Developer-Advocacy board.May 3 2016, 10:09 AM
Qgil added a subscriber: Qgil.Oct 27 2016, 1:34 PM

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

waldyrious added a subscriber: waldyrious.
scfc moved this task from Triage to Backlog on the Toolforge board.Dec 4 2016, 8:11 PM
Huji added a subscriber: Huji.
Restricted Application added a subscriber: jeblad. · View Herald TranscriptAug 25 2017, 8:00 PM
GTirloni removed a subscriber: GTirloni.Mar 21 2019, 9:11 PM