On Sun, 13 Apr 2025 at 11:20:47 +0000, Andrew M.A. Cater wrote:
Leaving aside any political topics of disagreement between Debian and OSI
(and leaving aside the OSI position on AI for the moment):

Are there any software licenses that the OSI recognise that Debian doesn't?

Unfortunately, probably yes. According to https://wiki.debian.org/DFSGLicenses, Debian (or at least debian-legal) does not consider the Apple Public Source License (APSL) v2 to be DFSG-compliant, but according to https://opensource.org/licenses, the OSI considers it to be open-source. There are probably other counterexamples.

(A reminder that Debian does not publish an official list of licenses that are or are not DFSG, and neither debian-legal nor that wiki page is authoritative; the archive administrators (ftp team) have the final say on whether an individual package is or is not considered DFSG-compliant. But it seems plausible to me that the archive administrators would also say that software under APSL is not DFSG-compliant.)

This is in a work/commercial context

I am not a lawyer and this is not legal advice. If your business relies on particular legal properties, please consult an actual lawyer.

The software licensing mavens are now pointing people at the OSI site
which has a search engine to search for OSI-approved licenses at
https://opensource.org/licenses

The licensing mavens are taking this as authoritative and are suggesting
that software found there is FLOSS and can be used by developers for work
(but still at their own risk to some extent).

There is a subtle distinction between "a license that meets the Open Source Definition" and "an OSI-approved Open Source License". Lots of licenses (especially permissive BSD/MIT variants) clearly meet the requirements of the DFSG and the OSD, but have never been formally approved by the OSI.

For example, comparing https://spdx.org/licenses/ (a list of common open-source and nearly-open-source licenses) with https://opensource.org/licenses, we can see that the MIT license variant identified by SPDX as "MIT-open-group" has never been approved by the OSI; but it's a simple permissive license, so it's hard to see how its open-source or not-open-source status could differ from the MIT license variant identified by SPDX and OSI as "MIT" (the one used by Expat). Debian certainly treats the MIT-open-group license as DFSG-compliant and is happy to include software under that license.

If you are not willing to redistribute software under the MIT-open-group license, then you can't have xauth(1), for example. (If you are using X11 then you almost certainly need this.)

All of the "usual, well-known" open source licenses like the GPL, LGPL,
Apache license and the most common BSD/MIT variants are FLOSS by anyone's definition (Debian, FSF, OSI, etc.); the problem area is when you get into the weirder, usually vendor-specific or project-specific licenses, like the APSL, where the various groups that have strong opinions on the acceptability or unacceptability of particular licenses might reasonably disagree on finer details.

Given that the Open Source Definition is the DFSG with the identification
labels changed - am I still reasonable in my "If it's DFSG, it will
definitely be OK with the OSI / our developers"?
(It's often just as quick to check in a Debian mirror / an apt-cache search
for the software that's already packaged in Debian).

Software that "easily" meets the DFSG certainly also meets the Open Source Definition (as you say, they are basically the same), but different authorities interpret those definitions differently when dealing with edge cases.

Having software that meets the OSD also does not mean that it is necessarily under an OSI-approved license (counter-example: MIT-open-group).

Conversely, software that is under an OSI-approved license does not necessarily mean that Debian considers it to be DFSG-compliant (possible counter-example: APSL).

"If it's in Debian main, it's FLOSS and free to use and you won't have to
pay licensing fees / run special software update servers"

"Free to use and you won't have to pay licensing fees / run special software update servers" is a considerably weaker requirement than either the DFSG or the OSD - for example, most "freeware" ("free as in free beer") licenses like CC-BY-ND would meet that weaker requirement, even without source code availability or permission to modify. If that weaker requirement is enough for you, then I don't see how any OSI-approved or DFSG license could fail to meet your requirements.

Most packages in non-free and non-free-firmware would also meet that weaker requirement despite being non-DFSG.

    smcv

Reply via email to