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.
|Open||None||T193303 Add CC0/public domain license option to striker|
|Open||None||T152581 Expand the Tool Labs definition of "free license" to include FSF-approved and DFSG-compatible licenses|
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.
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.
Licenses recognized as Free by the FSF and not approved by the OSI:
- GNU All-Permissive License
- Clarified Artistic License
- 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
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.))