On Thu, Sep 08, 2022 at 08:00:09AM +0200, Didier 'OdyX' Raboud wrote:
> Le jeudi, 8 septembre 2022, 07.14:09 h CEST Russ Allbery a écrit :
> > Didier 'OdyX' Raboud <odyx@debian.org> writes:
> > > While we're at updating the Social Contract's article 5, what about a
> > > more invasive cleanup, to reflect reality ?
> > >
> > Going *way* out on a limb (and to be honest I'm leaning hard against
> > proposing this because I think this level of change would require more
> > than a week's worth of discussion)
> >
> > 5. Works that do not meet our free software standards
> >
> > We acknowledge that some of our users require the use of works that
> > do not conform to the Debian Free Software Guidelines. We have
> > created areas in our archive for these works. These packages have
> > been configured for use with Debian and we provide some
> > infrastructure for them (such as our bug tracking system and mailing
> > lists), but they are not part of the Debian system. We encourage
> > distributors of Debian to read the licenses of the packages in these
> > areas and determine if they can distribute these packages on their
> > media. The Debian official media may include firmware from these
> > areas that is otherwise not part of the Debian system to enable use
> > of Debian with hardware that requires such firmware.
>
> As-is (that is: "changing only SC5 with a 3:1 majority") seems to be one very
> simple way to express the change we (some of us) want. The "statement of the
> day" is a nice addition, but can risk being nitpicked-upon. I'd definitely
> second a ballot option that would propose just this.
In that spirit, some more wording suggestions and justification below.
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.
* "some of" implies a minority, but the GR was raised due to a lack
of available new hardware meeting this except via ROM
* "configured for use" always seemed like strange wording to me
* "enabling" rather than supporting to avoid endorsing
* "convenience to our users" shows up in some Disclaimers
* "separate" applies to the archive areas, but not the install media?
* "archive areas" to allow e.g. renaming contrib to non-free-depends
* by mentioning installation media as infrastructure, shipping it
ourselves with firmware, it becomes superfluous to "encourage" others
to follow our recommendation in our own Social Contract (it's my
understanding that was there back in the day so CDs wouldn't just
limit to main out of paranoid safety, doing a disservice to users)
* focussed on being short rather than mentioning every consequence -
it's supposed to be a guiding mission statement, not Policy
I'd like to include something around "otherwise meets all our other high
standards" and "anything including these works will always remain
clearly identified" (like non-free Disclaimer, sadly our ISO needs to
include non-free firmware etc.) but I couldn't find a good wording.
> From my sparse reading of the discussion so far, it now seems clear that the
> SC needs amending; not doing so and finding convoluted ways to interpret its
> actual version risks creating more confusion and misunderstandings than it
> solves.
Having contributed to some of those convoluted interpretations, I think
you're right that there's enough support for change. I haven't seen much
in the way of actual objections to the Images Team intention beyond the
existence of Proposal D and complaining it's a breach of the SC.
Attachment:
signature.asc
Description: PGP signature