Wikitech talk : Cloud Services Terms of use

Possible typo

User:Andrew Bogott : I think you meant "(May 2023)" instead of "(August 2013)" at the added line at the end. (Currently the August 2013 one is linked twice.) whym ( talk ) 02:21, 9 September 2023 (UTC)

I believe this is still applicable. whym ( talk ) 14:47, 2 February 2024 (UTC)

Fixed! Thank you. andrew ( talk ) 16:17, 2 February 2024 (UTC)

Open Source License

Hi :)

1. Please do this diff for all occurrences:

-http://opensource.org/
+https://opensource.org/

2. I noticed we only mention licenses approved by the Open Source Initiative. Is it a desired situation to have no mention about licenses approved by Free Software Foundation ? I think it's just an omission in good faith and for reasons of keep things clear and short, but philosophically, avoiding mentioning this altogether is perhaps not the best condition. Do you know any previous discussion about this topic? -- Valerio Bozzolan ( talk ) 10:16, 2 December 2023 (UTC)

The OSI is a standards body that owns the definition of "Open Source". The FSF is an organization that has defined a number of software licenses, but they are not a standards body. The OSI's list of certified Open Source licenses includes (all?) FSF licenses. -- BryanDavis ( talk ) 14:51, 2 December 2023 (UTC)

@ BryanDavis : Premising that this old SPARQL query of mines would answer your nice question about OSI/FSF appproved licenses ... but it's in timeout nowadays :( lol

https://www.wikidata.org/wiki/User:Valerio_Bozzolan#Free_Open_Software_licenses

In short, I remember well, and you may love to know that " w:WTFPL " is not an OSI-approved license, while is FSF-approved.

https://www.gnu.org/licenses/license-list.html#WTFPL

Additionally, Creative Commons Zero is not OSI-approved, while is FSF-approved.

https://www.gnu.org/licenses/license-list.html#CC0

Anyway, I think nobody would disqualify FSF as an authority body on the topic of "Free Software". Not even OSI. Maybe unrelevant but OSI mentions FSF like ~20 times in their authority page.

https://opensource.org/about/authority

In short maybe it's a good idea to just add

... or code under a free software license, as defined by Free Software Foundation.

Valerio Bozzolan ( talk ) 15:27, 31 March 2026 (UTC)

I mean, I don't know the right way to start such proposal. Valerio Bozzolan ( talk ) 15:28, 31 March 2026 (UTC)

See phab:T152581 . The TL;DR is that this needs to be changed by WMF Legal. -- BryanDavis ( talk ) 20:34, 1 April 2026 (UTC)

@ BryanDavis : Damn! That was a good time traveller trick!

You asked which FSF-approved are not OSI-approved.

You travelled back in time to give the best possible answer https://phabricator.wikimedia.org/T152581#2859128

and guess the date of the previous message? 1st of April! lol

Nice trick my friend Valerio Bozzolan ( talk ) 15:15, 21 May 2026 (UTC)

Github

3. Please do this diff:

-Github
+Github

Premising that, we probably should encourage to adopt Wikimedia GitLab, instead of only mentioning a proprietary platform acquired by Microsoft for billions. Any proposal would be lovely to improve this phrase to don't just promote GitHub in a Terms of use. -- Valerio Bozzolan ( talk ) 10:22, 2 December 2023 (UTC)

The mentions of GitHub are deliberate. One reference is to a specific policy exception that has been granted and in the other we are explaining that 3rd party code forges are acceptable for publishing source code and in doing so we explicitly mention the single largest 3rd party code forge in use by the movement today. -- BryanDavis ( talk ) 15:00, 2 December 2023 (UTC)

Looking at my proposed diff I don't even remember anymore what was the diff about... I was maybe crazy that morning. Sorry for bothering lol Valerio Bozzolan ( talk ) 15:44, 31 March 2026 (UTC)

Tools: requiring a Public Issue Tracker

I think it may be nice to propose the introduction of a new requirement for WMCloud tools: having at least 1 public issue tracker (/ bug tracker) 🥰

I mean, this is not a "new thing"... I guess 99.999% of tools are already compliant. But I've found at least 1 "important" tool in this interesting situation:

• code only on GitHub.com
• but GitHub.com issues are disabled 🥶

I think we can discuss about this, and eventually consider a transition period, so everybody is informed, and we endorse a positive adoption, effectively enabling collaboration even more.

What do you think about? Valerio Bozzolan ( talk ) 15:41, 31 March 2026 (UTC)

Hmm, doesn't Striker already do that when creating Wikimedia Phabricator projects? (I'd rather phrase it as a single, canonical location where to report bugs/issues and feature requests which the maintainer(s) are supposed to watch.) aklapper ( talk ) 20:56, 31 March 2026 (UTC)

Striker makes it possible to create a Phabricator tag for each project, but it does not mandate that this is done. Similarly we have a self-service mechanism for creating gitlab projects for tools, but no mandate. Mandates in general beyond the OSI license requirement have been avoided as much as possible in Toolforge because bureaucracy increases friction for use of the system.

A non-trivial number of tools are short lived experiments of various types: weekend proof of concept projects, GSoC/Outreachy "take-home" projects set by mentors, one-off fix scripts, etc. I really doubt that we are hoping that each and every one of these has every artifact of a well maintained project. @ Valerio Bozzolan mentioned "important" in this policy change request; there is some undefined threshold of that before anyone would really care. This then likely becomes a new requirement for the requirement: you must have an issue tracker once your tool is important. Now we just need to define importance and decide how to punish people who don't comply encourage people to comply. Maybe we do that by forcibly disabling tools once they become important? That feels like punishing the users who decided the tool was important though.

In User:BryanDavis/Developing community norms for critical bots and tools I generally proposed that the users of tools apply social pressure to tool maintainers for better support. That essay/presentation is now nearly 10 years old, but I don't think my position has changed. Users are making a decision when they pick a tool to help them contribute to the Wikimedia projects. They have the power to choose not to use a tool just as much as they have the power to choose to use a tool. Letting a tool maintainer know that their work seems valuable, but that it could also use some better feedback mechanisms, documentation, runtime support, or whatever feels to me like a better way to encourage adoption of better practices than a legal document that honestly approximately nobody reads.

I mean, this is not a "new thing"... I guess 99.999% of tools are already compliant

I doubt that there is anything in Toolforge with 5 9s of adoption. -- BryanDavis ( talk ) 21:04, 1 April 2026 (UTC)

Is there a way to count tools without the field "Issue tracker" populated? I'm curious now. But I'm quite optimist. Valerio Bozzolan ( talk ) 21:09, 1 April 2026 (UTC)

The easier thing to count is how many tools have a toolinfo record in the Striker database that includes an issue tracker value of some kind. select count(distinct tool), count(*) from tools_toolinfo where issues is not null; on the non-public Striker database says that 595 tool accounts have published 606 toolinfo records with a non-null issue tracker value. There are currently 3938 total tool accounts in Toolforge and 2861 distinct tools that have some toolinfo.json data available. -- BryanDavis ( talk ) 23:17, 1 April 2026 (UTC)