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
