This is not covered well by the current Labs TOU:
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.
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.
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)
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
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?
@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.
@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.
@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.
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
I think T87730: Set up process / criteria for taking over abandoned tools and the subsequent work to apply the process by the Toolforge-standards-committee has resolved the core issue here.