Re: GNU - Principles and Guidelines (was: Re: A GNU “social contract”?)

[Andreas R.]

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