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

Re: Social Contract GR's Affect on sarge

Well, there's certainly a lot of hot air.  And the situation is rather

It seems to me that:

 * The social contract as amended is unambiguous, and prevents the
   release of sarge as-is.


 * The Developers must decide whether to waive or amend the social
   contract.  If no waiver is forthcoming (3:1 supermajority, by my
   reading), then sarge will not be released.

   I'm pleased to see this discussion is happening and will probably
   result in a resolution in time.  So:

 * The Release Manager should plan for such a resolution to either
   grandfather the existing situation, or permit the release of sarge
   some other way.  To do anything else would be to prejudge the

 * Since we are in something of a hurry, and there will be time to
   clarify the situation at more length later, IMO any grandfather
   resolution authorising the release of sarge should be as short as
   possible.  IMO it would be a bad idea to write a long document
   `under the gun'.  Any such grandfather resolution should probably
   delegate reasonably wide discretion about scope and interpretation
   to the Release Manager, the Project Leader, the Committee or some
   other similar person or body, to ensure that it's sufficient and we
   don't need _another_ GR.

Some other comments:

 * There has been some argument about the definition of `source'.  It
   seems perfectly clear to me that `source' means the preferred form
   for modification in the GPL.  Anyone who argues differently is
   probably engaging in sophistry.  The effect of this on (eg) the
   status of fonts is not entirely clear in every case, but it seems
   obvious that at least some fonts we currently distribute are not

 * The GFDL issue is big problem too.  IMO the Debian Developers
   should formally express our regret at the position taken by the
   FSF.  But writing up such a GR can wait until we've dealt with the
   immediate priority.

 * Our Secretary seems to be under the impression that a vote must be
   started within a certain period of a resolution being proposed.  I
   don't think this is the case.  The discussion period quoted in
   4.2(4) is a _minimum_.  According to A.2(1), it is up to the
   proposer or a sponsor to call for a vote, and there is no need to
   hold a vote until they do so.

   I would ask all proposers and sponsors of resolutions to avoid
   calling for a vote before reaching consensus on the wording of a
   resolution.  I would also ask _oponents_ of any resolution to help
   the process by proposing constructive criticisms and changes to the
   wording so that the resolution may better express the intent of its
   sponsors !  It is in the whole project's interests that the
   resolution that gets voted on is clear and well-worded - even if it
   is going to be rejected.

 * It is unfortunate that these problems weren't spotted before the
   vote on the `editorial amendments'.  I would like to ask
   particularly people whose work might be directly affected by a GR
   to read the text in detail to discover problems earlier !

 * The Technical Committee has no formal authority in this area.
   The questions being disputed don't seem technical to me.  So any
   authority we have derives only from Anthony because he's asking us
   the question - and of course from our authority to just pronounce
   our opinions.

Anthony, do you still want a formal statement of this from the whole
committee or is informal opinions from some of us individually enough
for you ?

Does anyone on the committee disagree with anything I've said above ?


Reply to: