Page MenuHomePhabricator

Expand the Tool Labs definition of "free license" to include FSF-approved and DFSG-compatible licenses
Open, NormalPublic


The current terms of use for Tool Labs includes the clause "You can use any OSI-approved license."

In the discussion of the right to fork policy @Legoktm suggested that this could be expanded to include licenses that have been vetted and found to be free by the Free Software Foundation (FSF) and/or are compatible with the Debian Free Software Guidelines (DFSG). @greg agreed that these additional authorities were trustworthy for vetting licenses to avoid the crayon license problem of non-enforceable licenses.

Event Timeline

bd808 created this task.Dec 7 2016, 1:45 AM
Restricted Application added a project: Cloud-Services. · View Herald TranscriptDec 7 2016, 1:45 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
bd808 added a subscriber: ZhouZ.

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.

bd808 added a comment.Dec 9 2016, 2:03 AM

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 ( which I didn't realize is technically a violation of the labs TOS until now...

bd808 added a comment.Dec 9 2016, 3:28 AM

The OSI list also does not explicitly cover older versions of the approved licenses. There are a number of tools like 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.

scfc triaged this task as Normal priority.Feb 16 2017, 11:02 PM
scfc moved this task from Triage to Backlog on the Toolforge board.

Possibly relevant... I noticed that the license parameter in specifies:

license governing use of this extension, as one of the codes found in

though it technically only recognizes a subset of those via (hence some of the 500+ items in )
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 (Eiffel Forum License, version 2, which does appear in OSI, but needs to be added to somehow. I ran out of brain before poking at the Lua code though.))