On Thu, Sep 08, 2022 at 11:55:43AM +0200, Jonathan Carter (highvoltage) wrote: > On 2022/09/08 11:27, Phil Morrell wrote: > > 5. Works that do not meet our free software standards > > > > We acknowledge that our users may require the use of works that do > > not conform to the Debian Free Software Guidelines. Such packages > > are not part of the Debian system, but we provide the enabling > > infrastructure as a convenience to our users. This includes the bug > > tracking system, installation media, mailing lists and separate > > archive areas. > > bug fixes and security updates depend entirely on their upstream developers
This is definitely not *universally true*, think of e.g. GFDL invariants
or packages that are "merely" non-commercial. Debian package maintainers
can make absolutely any technical improvements they wish to these
packages, the only thing they can't do is change the license to be
DFSG-free. There's probably less motivation to work on non-free
software, and there may not even be any remaining upstream, but I assume
you were primarily thinking of non-free-firmware when drafting this
phrase.
> We
> encourage software vendors who make use of non-free packages to carefully
> read the licenses of these packages to determine whether they can distribute
> it on their media or products.
I deliberately removed mention of software vendors and their media as
our Social Contract wouldn't bind them anyway. #5 should be relevant for
all our users, third party redistributors are just a subset.
> An added goal I'm trying to achieve with this change is to explain some
> practical consequences of redistributing non-free software. It's not like we
> provide the non-free archives and it's *wink* *wink* kind of official
> because Debian people provide it but it's not, instead it's the case that
> everything that makes Debian great really doesn't apply to these packages.
It'd be nice having a fourth sentence that is a bit more negatively
worded to put people off non-free where feasible. How about:
We encourage careful review of the licensing for your use-case and
how they put limits on our packaging efforts.
Disclaimer: I'm not a DD (yet) so cannot formally propose any of this
and please take with a lump of salt.
signature.asc
Description: PGP signature
