On Tue, Dec 31, 2019 at 12:49:03PM +0100, Mark Wielaard wrote:
> The latest version of the GNU Social Contract can be found here:
> https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00358.html
> There were some minor wording suggestions since on the list.
Thanks. I think that was the version I used, but I got the date wrong.
> > In response to that request, earlier on-list feedback, and expressed
> > support for having a couple of
> > succinct documents that describe the structure and mission of the GNU
> > project, I composed a version
> > based on Andreas Elke's draft that attempts to address some of the
> > problems that were raised.
>
> Thanks. But I think your version mixes why, what and how a little.
Can you elaborate on that? I have an inkling about what you could mean by
the "why", "what", and "how", but I wouldn't want to spend time answering the
wrong questions.
> The social contract says what users and the free software community can
> expect from the GNU project, but doesn't prescribe how GNU volunteers
> working on it do it, or how the project is structured precisely.
That could be considered a shortcoming.
Andreas Enge, in response to the difference between a "Social contract" and a
"Code of Conduct" writes on the 6th of November[1]:
"a social contract, which is a "mission statement" and statement of the general
principles
of an organisation, as well with respect to the inner workings as well as an
engagement
to the outer world"
which could be summed up as:
- a statement of the general principles of an organisation,
- a statement with respect to the inner workings
- a statement regarding an engagement to the outer world
Has this layout changed?
> It
> looks like your document and the social contract could be separate
> documents because they don't really conflict. That might make it more
> clear what you are precisely proposing.
There have been various statements in support of a general document that would
"describe the structure and mission of the GNU project", even allegedly by
rms himself[2]
Since no such document exists, it would need to be agreed on by everyone who
could be loosely defined as "part of the GNU project" to serve as any sort of
guideline.
The "GNU social contract" as it is, is not agreed on by everyone.
The "GNU - Principles and Guidelines" attempts to address that. It's an
adjusted version
of the social contract that hopefully at some point can be agreed on
by everyone, and serve as a first solid step towards finding a new governance
model for the GNU project.
> > This amended version:
> >
> > - is closer to the situation as it currently exists and as such
> > should need no additional agreement
> > or undersigning of existing maintainers since it should describe the
> > status quo.
>
> Maybe you could state what in the GNU Social Contract doesn't describe
> the status quo?
A fairly significant change would be that maintainers would be required to sign
an extra document.
This has been mentioned repeatedly [3] by the writer of the first version of
the
social contract, Ludovic Courtès.
Has this idea been dropped?
If it has not been dropped, questions about enforcement have been fielded by
Federico Leva [4] but not been readily addressed.
Another point where the social contract deviates from the status quo is the
complete absence of the FSF or existing governance.
The social contract, as it is, simply gives "the GNU project" project-wide
governance without precisely defining "the GNU project".
Before entities are bestowed with formal agency, their makeup should to be
precisely defined,
otherwise you might end up with a cabal, alleged or otherwise.
> I don't see it as a problem that GNU
> maintainers outside their GNU work might not fully adhere to the social
> contract as long as we can trust each other to do when we are working
> together on the GNU project itself.
My apologies. I meant GNU maintainers adherence to software freedom
in the course of their GNU work.
As things are, GNU maintaners can use non-free operating systems,
even in publicly giving presentations about their GNU work. They
can also, for example, be drawn to GNU maintenance for the
technical challenge it provides instead of promoting the wider
ideas that are usually associated with the GNU project.
Given that they abide by the license of their GNU software, there
is no conflict here, but the fact remains that being a GNU
maintainer doesn't automatically gives one the right perspective to
safeguard software freedoms.
Of course, maintainers could be asked to sign a document that promises they
will live up to the GNU project's standards, but what is to be done with
existing GNU maintainers who are working on GNU for reasons other than
software freedom? Will they be excluded from GNU project decision making?
And maybe more importantly: will the GNU project reject aspiring maintainers
who
will not sign a document that puts the responsibility of maintaining the larger
ideas of
software freedom on their person?
> > - guarantees GNU maintainers can continue to work on the project as a
> > loosely associated group of hackers
> > if they so desire even though a more regimented approach can be
> > implemented within each seperate component
> > or package.
>
> The GNU Social Contract doesn't mention Maintainers, or any other
> volunteer role. Could you say which parts of the GNU Social Contract
> would block hackers working together on the GNU project in a loose or
> rigid fashion?
"It [the GNU project] commits to providing a harassment-free experience for all
contributors."
I'll refrain from addressing the latter portion at this time, since I expect
it might prove contentious, but as things are, there is no single party that
can commit to something,
let alone provide any sort of experience with a single vision.
regards,
Andreas
[1] https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00274.html
[2]
https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00341.html
https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00351.html
https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00306.html
[3]
https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-10/msg00011.html
https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-10/msg00081.html
https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00188.html
[4] https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-11/msg00388.html
