Re: second draft of Charter for Foundation


I'm pretty much happy with this document (congrats to Nat and Bart),
some random comments:

Bart Decrem <> writes: 
> GNOME is Free Software
> ----------------------
> Free software licensing has always been a mainstay of GNOME, and we must
> ensure that this tradition continues. The foundation must not allow any
> software module to become a core GNOME component unless it is licensed
> under the GPL, or a GPL-compatible license. GNOME should strive to be
> free, while still being friendly to ISVs and commercial developers.

I already said this, but I still think we should accept MPL for

Of course, maybe we can make an MPL thing part of GNOME without making
it a "core GNOME component" - "core GNOME component" is pretty vague
however, I'd like to avoid that phrase unless it gets defined somehow.

How about in the charter we just say something like "GNOME includes
only free software," then the board can make the final call on
specific licenses as they arise, perhaps choosing to exclude software
that's free but problematic.

> GNOME is a Meritocracy
> ----------------------
> Participation in the foundation should only be available to those people
> who are responsible for actual contributions to the software which makes
> up GNOME. A corporation, organization or individual should not be
> granted a place in the foundation unless its presence is justified by
> the merits of its contribution. Money cannot buy influence in the GNOME
> project: show us the code (or documentation, or translations, or
> leadership, or webmastering...).
> In the past, being a part of the GNOME project has simply meant "I wrote
> some code" or "I hang out on the mailing lists and build the thing from
> CVS frenetically every three hours." There is no reason to change this.

I see some tension between this and the paragraphs about openness
earlier in the document. On the one hand, we're saying anyone at all,
on the other we're saying "no 500 noncontributors from Evil
Corporation Foo."

In practice I think this tension is nonexistent, because we have a
good proposal to handle membership (allow anyone that asks, with a
rubber-stamp by a membership committee just to prevent completely
ridiculous things like the aforementioned 500 noncontributors).
Still, I would like to merge these two paragraphs with the openness
paragraphs, because that will make us be more clear.
> It should be apparent that these two tasks (defining GNOME and doing
> releases) are deeply interrelated: defining GNOME is just determining
> which modules are a part of any given release. You can't coordinate a
> release without knowing what you're releasing. The set of packages which
> comprises GNOME is defined at every release. And so releasing GNOME and
> defining GNOME are one and the same task.

This is not _quite_ true, to nitpick: releasing GNOME is actually
defining a particular release of GNOME. We fell into this trap arguing
over Evolution and GNOME 1.4, when we discussed whether Evolution
counts as part of the desktop. Which wasn't really the issue; the
issue was whether it was part of the 1.4 desktop, or the 2.0 desktop.
And so we got on an irrelevant metaphysical tangent about "what is the
The point is, probably we want to be able to say (at least informally)
that something is part of GNOME though it isn't known yet that it will
be in a specific release. This probably shouldn't go in a charter -
I'd say the official GNOME should be the GNOME releases - but we
should certainly keep it in mind when we talk to each other.
> Election of a board members and slates will be executed just like voting
> on a referendum.

I don't think this works, because you have multiple slates, while a
referendum is a yes/no question and 2/3 must vote yes. cf. previous
discussion of voting systems.
> The board of directors shall have at least 7 members and no more than 15
> members.

I would expect the membership to prefer larger slates to avoid voting
against any people they like, so I'd expect to always end up with 15
members, and 15 seems like too many to me still. I'd prefer a range of

> The board of directors will be responsible for authorizing the release
> of a new version of GNOME. The board will determine the set of modules
> which will make up the release at least 60 days in advance of the
> release date, subject to unanimous approval of the module maintainers.

Didn't someone already comment on this paragraph?

IIRC they said the 60-days-in-advance thing shouldn't be hardcoded in
the charter, and I agree; let's just say the board will organize the
release, set roadmaps, establish technical direction, etc. and let the
board decide how many days in advance they have to announce in order
to do that.

"subject to unanimous approval of the module maintainers" is too vague
- who are the module maintainers, can you remove a module from the
release if the maintainer won't give approval, do we actually take a
vote here, etc.

As someone may have said, maintainers already effectively have the
power to boycott a release plan, so there's no real reason to
formalize said power. (However I think we should strongly encourage
people to work together to make releases, and consider such a boycott
an antisocial stunt in the same category as forking, because we simply
can't make releases without everyone's cooperation. So a boycott
should be based on some strong reason, such as "evil Microsofties
control the board", it should not be acceptable to boycott because
someone wants to rewrite gless to be the ultimate text viewer. If we
vote to approve a release plan, people should try to go along with
> If a new module is being included in a release, all its contributors
> have the option to become part of the membership.

This is actually a stricter membership criterion than what we decided
on earlier in the document, if we distinguish "GNOME" from "particular
release of GNOME." cf. the Evolution example, we don't know what
release that is in, but it is part of GNOME.
Probably best to just strike this sentence, and keep all stuff about
membership qualifications in one place in the document.

> ======================================
> VI. Bootstrapping the GNOME Foundation
> ======================================
> The membership will be populated with all the (consenting) members of
> the gnome-hackers mailing list, people holding CVS accounts, and anyone
> else who speaks out and wants to join when asked.
> The board of directors will be primed by the election of a slate of
> initial members. Anyone may propose a slate, so long as it is approved
> by at least 10 Members.

And we'll do this in the next few weeks. This morning we discussed
setting this process in motion, since people seem to agree.
> 1. Can the membership voting system actually be done? I think the
> software is pretty trivial. But will it be used? Does democracy work?
> Are we going to get gerrymandered?

I think it will work fine.

This morning Owen brought up the issue of defunct memberships; often
people lose interest after a year, and after a few years we might have
a large fraction of people on the membership list who aren't around
anymore, making it hard to get 1/3 participating in elections.

To solve this, Bart suggested that the board (maybe delegating to the
membership committee) go through and ping everyone once per year. 
We might mention this process in the document.
> 2. How does standards definition *really* work? This is going to be
> really important some day, and someone should be cogitating on it.

This isn't specific enough to resolve, I don't think, let's remove it
from the list of outstanding issues. Or maybe someone can clarify what
needs deciding in the short-term.

> 3. Can we really expect to use a system of non-enforcement and *still*
> maintain a legally defensible trademark? Ok, this is getting marginal...

I doubt it, but in any case this is a matter of asking a lawyer rather
than resolving it ourselves, right?

> 4. There was a discussion about the Licensing provision under "GNOME is
> Free Software". Did we decide on a change to that paragraph?

Perhaps we should allow the membership/board to make the call on
specific licenses, and in the charter just say that proprietary
software is excluded. That gives us future flexibility.

> 5. There was a discussion about the 60 day waiting period in Release
> Engineering.  Did we decide on a change to that paragraph?

I vote to change that one.


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