I'm not generally concerned that the FSF and DFSG lists are not reputable, but I don't know if there are other reasons that the OSI list is currently considered canonical for Tool Labs. It may just be that as @Legoktm pointed out in the earlier discussion that this particular list was chosen for the WMF employment contracts. I'd like to get a general opinion on the change from @ZhouZ or another representative of the WMF-Legal team before going much further.

Hi bd808,

I believe historically we only listed one-single reference (OSI) for the sake of consistency and practicality. It's the most comprehensive, and it's usually the most permissive. I believe in general the FSF list and the DFSG list are more limited and may have more peculiarities associated with approval. Further, if there are licenses that are allowed by FSF or DFSG, then they should also be recognized by OSI -- since we are OSI members, we can also potentially ask them to recognize new licenses if we need it.

The upshot is that I think we can expand to also use FSF or DFSG but perhaps it would be a good idea to think whether practically it would make a difference. Are there particular licenses on those lists that are not available under OSI right now? It's also nice currently that the OSI idea is used consistently elsewhere in places like the employment agreement and in the Open Access Policy.

In T152581#2859075, @ZhouZ wrote:

Are there particular licenses on those lists that are not available under OSI right now?

Licenses recognized as Free by the FSF and not approved by the OSI:

• GNU All-Permissive License
• Clarified Artistic License
• CC0
• The Clear BSD License
• Cryptix General License
• EU DataGrid Software License
• Freetype Project License
• License of the iMatix Standard Function Library
• License of imlib2
• Independent JPEG Group License
• Intel Open Source License
• OpenLDAP License, Version 2.7
• SGI Free Software License B, version 2.0
• Standard ML of New Jersey Copyright License
• Unicode, Inc. License Agreement for Data Files and Software
• The Unlicense
• License of WebM
• WTFPL, Version 2
• Zope Public License, versions 2.0 and 2.1
• Affero General Public License version 1
• Apache License, Version 1.1
• Apache License, Version 1.0
• BitTorrent Open Source License
• Original BSD license
• Common Public License Version 1.0
• Condor Public License
• Eclipse Public License Version 1.0
• Gnuplot license
• Jabber Open Source License, Version 1.0
• LaTeX Project Public License 1.3a
• LaTeX Project Public License 1.2
• Netizen Open Source License (NOSL), Version 1.0
• Netscape Public License (NPL), versions 1.0 and 1.1
• Old OpenLDAP License, Version 2.3
• OpenSSL license
• Phorum License, Version 2.0
• License of Python 1.6b1 through 2.0 and 2.1
• Sun Industry Standards Source License 1.0
• License of xinetd
• Yahoo! Public License 1.1
• Zend License, Version 2.0
• Zimbra Public License 1.3

I think the main ones in that list that people are going to want to use will be CC0, Unlicense, and WTFPL. I have some CC0 code on tool labs (https://github.com/legoktm/wikidata#license) which I didn't realize is technically a violation of the labs TOS until now...

The OSI list also does not explicitly cover older versions of the approved licenses. There are a number of tools like https://tools.wmflabs.org/hatjitsu/ that are just deployments of FLOSS software rather than custom developed code. It would be very annoying to have to undeploy a tool because the OSI increments their version number to match the latest version of a license. This is one of those places where the letter and the intent of the rule likely diverge. The FSF list tends to include the older versions while noting that they are likely not the best choice for new software development.

Possibly relevant... I noticed that the license parameter in https://www.mediawiki.org/wiki/Template:Extension specifies:

license governing use of this extension, as one of the codes found in https://spdx.org/licenses/

though it technically only recognizes a subset of those via https://www.mediawiki.org/wiki/Module:Extension (hence some of the 500+ items in https://www.mediawiki.org/wiki/Category:Extensions_with_unknown_license )
Maybe those 2 listings should both be recognized (at Toolforge and/or for Extensions)? or only 1?
Maybe the modules should be updated to be 100% complete?

(Context: I was trying to determine how to fix the single page in https://wikitech.wikimedia.org/wiki/Category:Tools_with_unknown_license (Eiffel Forum License, version 2, which does appear in OSI, but needs to be added to https://wikitech.wikimedia.org/wiki/Module:Tool somehow. I ran out of brain before poking at the Lua code though.))

I looked into this and wanted to update this ticket.

https://opensource.org/licenses/unlicense is now an approved license. No creative commons license is recognized by OSI, see https://opensource.org/faq#cc-zero for CC0. I know both of these amongst others were mentioned as a way of having a "public domain" license on a tool.

Given there is also a process to have a license reviewed for approval, https://opensource.org/approval, is this still needed? I'm not sure of the requirements or time commitments to have OSI review a license, but assuming it's not an overly long timeline this should be a way to host software under an OSI license, even if the license in question isn't yet approved.

Lastly, I do think there is a lot of value gained in avoiding bespoke licenses, especially in a community setting like this. Potential contributors would also need to read and understand any license a tool utilizes.

For those affected by this, does the current OSI list meet your needs? Is their a specific license you would like to see support for?

IMO the lack of CC-0 approval is still going to be a problem if we want strict adherence to the letter of the policy. I think we would all agree that using CC-0 code is within the spirit of the Cloud TOS. So...do we just expect people to take CC-0 code and slap Unlicense on it? At that point, why not just allow CC-0?

I only started thinking about it recently, but there likely is some CC-BY-SA licensed code on Toolforge, for compatibility with being used on-wiki. Again, meets the spirit of the TOS, but not the letter of being OSI-approved. Given that CC-BY-SA is a bad code license hopefully we can guide most of these cases into a dual-licensing scheme.

@Legoktm, thanks for your input! I'd welcome others to share as I'm not completely informed on this topic.

Speaking only for myself, I think in both of the examples you mentioned (CC-BY-SA and CC-0), I would encourage the authors to move to a compliant OSI license. It feels very easy to simply grant exceptions for licenses we consider within the spirit of Cloud TOS -- but that puts us collectively into a position of reviewing licenses. It's my understanding this is why instead the movement as a whole looks to a trusted body like OSI to instead do this work. I would advocate for informing and supporting versus chastising or banning tools or authors.

That said, Creative Commons licenses being utilized heavily across the movement, yet not being usable for source code is perhaps confusing and impactful for contributors. Is it? I'm not informed enough to know if this is the case or not. If so, and we feel it's important to allow or encourage this use case, I think the original ideas raised on expanding the definition with Legal would be a better fix than just within Cloud.

Again, I would love others feedback on this. I am glad OSI has expanded licenses to allow for more choices in the interim.

[Just noting a CC use-case]

In T304737#7842276 I recommended the use of a CC-BY 4.0 Python advisory database: https://github.com/pypa/advisory-database (entirely forgetting about this ticket in the process) over a non-freely licensed one.

In T152581#2859136, @Legoktm wrote:

I think the main ones in that list that people are going to want to use will be CC0, Unlicense, and WTFPL. I have some CC0 code on tool labs (https://github.com/legoktm/wikidata#license) which I didn't realize is technically a violation of the labs TOS until now...

2026 :) We have even more tools (since WMCloud is awesome) so I guess we have more probabilities than more tools are under the same «technically a violation».

About keeping everything as-is: I do not think that encouraging every individual project to dual-license their work is really a feasible solution (not simpler legally, technically, or socially). Anyway we still need to contact them.

About changing things: also, I understand that, before contacting Legal, we should have done an exploration.

→ So, in all cases, we need answers. And we can produce a small export with:

• tool name
• license
• repo link

Unfortunately I do not know Toolforge internals (Striker internals? etc.) to produce such export. But this sounds like a feasible sub-task.

In T152581#11945389, @valerio.bozzolan wrote:

→ So, in all cases, we need answers. And we can produce a small export with:

• tool name
• license
• repo link

Unfortunately I do not know Toolforge internals (Striker internals? etc.) to produce such export. But this sounds like a feasible sub-task.

The Toolhub search API is probably our best sourcing for this kind of information. It is not going to be anywhere near perfect, but the toolinfo records from Striker end up there along with more self-reported and community sourced data. https://toolhub.wikimedia.org/api-docs#get-/api/search/tools/

In T152581#11945754, @bd808 wrote:

→ So, in all cases, we need answers. And we can produce a small export with:

The Toolhub search API is probably our best sourcing for this kind of information. It is not going to be anywhere near perfect, but the toolinfo records from Striker end up there along with more self-reported and community sourced data. https://toolhub.wikimedia.org/api-docs#get-/api/search/tools/

Sounds like an hackathon-able project. Noted on the fridge and credited you: T427037: Export a dataset of licenses of Toolforge tools (Toolforge Licenses Catalogue)