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

Re: First call for votes for the Lenny release GR

On Sun, Dec 14, 2008 at 12:59:12PM -0800, Russ Allbery wrote:
> Bas Wijnen <wijnen@debian.org> writes:
> > On Sun, Dec 14, 2008 at 01:44:49PM -0200, Margarita Manterola wrote:
> >> Who will be in charge of stating what complies and what doesn't
> >> comply?
> > As usual, everyone judges on his/her own, and the technical committee
> > (or a GR) is needed to override a DD's decision.
> I don't believe the constitution gives the TC any say over licensing
> issues unless a DD delegates the decision to the TC.  Licensing is not a
> technical decision.  Instead, this would follow the delegate override
> path.

You have a point.

> > Proposal 5 means, as I wrote above, that those bug reports are only a
> > guess, and that we should not block our release as long as nothing is
> > proven.  If I understand the release team right, this is their position
> > as well, which is why they claim that placing those lenny-ignore tags
> > was within their power (and with this argument, they are correct IMO).
> I believe the position of at least some of the release team is that the
> secretary's interpretation of the DFSG is incorrect and the requirement in
> the DFSG that source be available does not apply to firmware blobs on the
> grounds that they're not software in the way in which the DFSG intends.
> (This is, obviously, not a position that everyone agrees with.)

If that's their argument, then I disagree with them that they have the
power to decide that.  But let's not discuss that now, we're having a
vote about it because there was no consensus. :-)

> Choice 6 I believe was intended to make that interpretation of the
> existing DFSG the project's position as a position statement, but the
> secretary did not believe such a thing should be possible and instead
> turned it into an amendment to the DFSG.

I agree with the secretary that it is a change of the current DFSG.
There is no provision to override it, so allowing that once is an
amendment (replacing it with the same text, plus the exception allowing

> Personally, I'm voting 6 highest anyway because I think amending the DFSG
> to make it completely unambiguous that we're not going to apply it to
> firmware is an even better choice than making a project statement about
> what it means.  It removes all doubt and quibbling forever going forward,
> which seems like a major win.

I agree that the DFSG should be unambiguous.  I disagree that we should
put non-free junk in main, though.  I like the idea of adding a new
section (beside main, contrib and non-free) of some non-free stuff which
is included in the installer a lot better.

But again, let's vote about that. :-)

> It's a shame that the vote was handled in the way that it was,

Actually, I think the secretary has done a very good job in preparing
the ballot.

> but I expect we'll be able to sort out something reasonable to put
> into the DFSG if it passes.

Manoj already made clear what the initial action would be: the DFSG
would be amended by adding the GR to it.  That seems like a good idea to
me; it doesn't require us to agree more than once. :-)


I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html

Attachment: signature.asc
Description: Digital signature

Reply to: