gnu-misc-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSC 1.0 endorsement


From: Kaz Kylheku (gnu-misc-discuss)
Subject: Re: GSC 1.0 endorsement
Date: Wed, 12 Feb 2020 15:19:12 -0800
User-agent: Roundcube Webmail/0.9.2

On 2020-02-10 13:13, Ludovic Courtès wrote:
Hi Werner,

Werner Koch <wk@gnupg.org> skribis:

I, maintainer of the packages GnuPG and Libgcrypt,
endorse version 1.0 of the GNU Social Contract,
available at <https://wiki.gnu.tools/gnu:social-contract>.

There no such thing "GNU Social Contract" as of today.

What there is is a Social Contract proposal that a faction
of people (who happen to do GNU programming) would *like*,
in some revision, the GNU Project to adopt. Should that happen,
there will then be a GNU Social Contract (if that's what the
document ends up being called).

Putting up a document titled GNU Social Contract on
a website with gnu in its domain name, bearing the GNU logo,
is very misleading.

I would say, dirty and underhanded.

What's the point of respecting people's differences, like
sexual orientation, race or whatever, if your actions are
dirty and underhanded.

Most of this Social Contract is bad other than the part
about software that respect's users' freedoms.

Regarding:

  "GNU package developers work together to ensure
   consistency across packages."

Incorporating these requirements is not always feasible.
Sometimes GNU programs conform to external standards,
which are inconsistent, both internally and with regard
to other standards. Two different GNU programs implementing
different, competing standards can't be expected to be
consistent. Basically, this is a technical requirement that
has to be taken on a case by case basis.

  "The GNU Project collaborates with the broader free
   software community"

Maybe some projects do, maybe some don't? What does it mean?

People working on a project are generally focused on
that project. If they are collaborating with some other
people from some other project, then they are doing something
other than working on their own project.

If people want to collaborate in the development of some
GNU package, they join the development of that package.

If people have a problem with the way a GNU package is
being maintained, they can raise bugs or whatever.

Now, let me talk about something else. GNU provides some
fundamental pieces. It's good if those don't gratuitously
break. Now *that* is something to include in the social
contract. How about this:

  Proposed text: "The GNU Project provides some important
  programs which are critical, fundamental dependencies
  (build-time and run-time) of very large quantity of software,
  which includes other GNU software, non-GNU free software,
  and even non-free software.

  The GNU Project maintainers strive to the utmost to make
  changes to these programs in such a way that new versions
  of programs can be deployed in place of existing versions
  without breaking the user, so that the GNU Project gains
  and retains respect as a bastion of stability.

The GNU project should also critically evaluate externally
imposed requirements and reject bad ones, including ones
coming from standards bodies like ISO and IEE.

  Proposed text: "The GNU Project reviews external requirements,
  and forms its own opinion about their technical and
  non-technical merit. The GNU Project rejects requirements
  which it deems to be technically deficient or otherwise
  deleterious, even if they come from major standards bodies.
  Rejecting a requirement ranges from not adopting and implementing
  it at all, to making the implementation of that requirement
  hidden by default such that it must be explicitly enabled by
  the user.

Sometimes changes in standards are terrible. They happen because
a particular vendor is involved and gets their way due to having
clout or whatever. For instance, as a recent example, in my opinion
no C library function should implement the useless function fopen_s
that Microsoft successfully foisted unto ISO C11.

Note that the spirit of the above reflects that of "POSIX_ME_HARDER",
which should never have been renamed.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]