Re: Proposed GR: State exception for security bugs in Social Contract clause 3
On 14/01/17 01:25, Sean Whitton wrote: > Hello, > > On Fri, Jan 13, 2017 at 11:38:25AM -0600, Gunnar Wolf wrote: >> Of course, I take it as my fault (maybe because I recognized Sean as >> quite active already in the project, overestimating his grip of our >> common practices and general views) that I didn't give enough >> background on similar experiences we had in the past (i.e. the long >> flamefest¹ that followed "Editorial amendments"² and that quite >> clearly delayed Sarge for over a year), which in turn explain why our >> community views GRs as something that should be very sparingly used. > > For the record, I do not take Gunnar to be at any fault here. However, > it is true that had Gunnar not expected my GR to be uncontroversial, I > probably wouldn't have proposed it. > > While I stand by my GR in principle, I agree with those who have said > that it is not worth spending time on something like this unless it's > going to pass without opposition. Since this GR /has/ turned out to be > quite controversial, I hereby withdraw it. > >> Now, the arguments that have been given so far regarding this topic >> are strong, and I do think I should have thought better my answers as >> an AM. I did feel a moral obligation to answer to this thread. I >> understand Sean must be frustrated by the lack of empathy to his drive >> for correcting reality impedance; maybe it should not be via an >> amendment to a foundation document, but by prominently enough >> (somebody please define "enough") clearly documenting that we adhere >> to reasonable embargo disclosure guidelines, such as the one mentioned >> by Russ. > > I just created this: https://wiki.debian.org/SocialContractFAQ > > My understanding of the policy that Russ linked to was that the security > team are de facto bound to that policy because all the other distros are > following it. Is that right? If so, it could be added to the new FAQ. > > After some polishing, maybe the WWW team could add a link to the new FAQ > from the Social Contract itself. That would adequately respond to the > reasons I had for proposing this GR: a newcomer who was particularly > concerned about transparency would soon find their way to this page. Maybe there should be a note about how we handle embargoed vulnerabilities here: https://www.debian.org/security/faq Cheers, Emilio
Re: GR: welcome non-packaging contributors as Debian project members
Hi, On 18/09/10 16:43, Toni Mueller wrote: On Tue, 14.09.2010 at 17:53:46 +0900, Stefano Zacchiroli lea...@debian.org wrote: in recent events I've attended as DPL, the topic of welcoming non-packaging contributors as project members has been a recurring one. Since it was also part of my platform and since DPL terms don't last forever, I feel it's time to have a project-wide decision on the topic. I understand the proposal to mean that there'll be a third class of people inside the project, besides DDs and DMs, and they can enter the project w/o passing through NM. Right? Nope. The proposal, AFAIUI, is about accepting non-packagers as DDs, but (possibly) without upload rights. There is ongoing discussion about whether they should or shouldn't have upload rights, and whether they should have an (additional) different name, but most likely they will just be 'DDs'. They will need to go through NM, except for TS, since they won't have upload rights. Regards, Emilio -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c94dc13.5060...@debian.org
Re: Q for all candidates: license and copyright requirements
On 24/03/10 00:27, Charles Plessy wrote: Our users, if they want to modify, study, redistribute or use after rebuild our system, need the source. At no moment these operations involve modifying a RFC or a binary program that is aimed at run on a Windows system. I conclude that that kind of file, although present in our source packages, are not part of the source of our operating system. To me, the sources of Debian are the source packages. Saying that something shipped in the source packages is not part of the Debian sources sounds a bit contradictory :) I understand well Stefano's point of view that we serve better our users by making things clear and removing these files from our source packages so that we can say that anything that is in our main section is DFSG-free. I do not think it is so useful, however, since one can not blindly use DFSG-free material as we tolerate advertisement clauses, renaming clauses, and clauses forbidding to sell the software alone. Not to mention patents and trademark issues. You can assume that the Debian sources are DFSG free. No more, no less. Arguing that since you can trust the sources are patent-free we should stop making them DFSG-free doesn't sound too logical to me. I think that we should have the possibility to redistribute a bit-identical upstream archive when possible. We have. I do it all the time. When the upstream tarball is free. In the title of my platform, I wrote ‘more trust’. What we can do with repacked tarballes, we can do with pristine ones. If we do not trust each other that a couple of useless non-DFSG-free files can be ignored, what else can't we trust ? We trust each other not to introduce non-free works in the upstream tarballs when packaging new releases. Isn't that trust? I don't buy how 'trust that a developer introduces non-free works' is anything we want. Emilio -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ba9ebff.2010...@debian.org
Re: Draft GR: Simplification of license and copyright requirements for the Debian packages.
Hi, On 24/01/10 15:47, Charles Plessy wrote: The Debian binary packages contain an exhaustive summary of the licenses of the files it contains. This summary also contains a reproduction of the copyright notices when the license require it. Additional documentation is encouraged but not necessary. I'd like to hear our ftpmasters' opinion on this (CC'ing them). As I expressed some months ago on -devel, I agree with this, but since they may be responsible for what is distributed on our archive (I'm not sure whether they are or not), I don't think forcing this through a GR is the best idea. A lawyer has been consulted AFAIK, so this is already being done (although slowly). Also, the wording suggests that the requirement to specify where the source was downloaded (and everything else we write on debian/copyright that is neither the license nor the copyright holders) is no longer required, but only encouraged. Is that on purpose? If not, maybe the wording should be changed. The Debian source packages can contain files that are not free according to our guidelines, provided that they are not used to build nor distributed in the binary packages that constitute the Debian system. I don't like this one. Rather than ignoring the DFSG, I think it should be changed instead (and I'm against doing so, FWIW). Cheers, Emilio -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Supermajority first?
Stefano Zacchiroli wrote: For instance, it would be very useful to know whether the current secretary would consider Peter's proposal on firmware to require super majority or not. If the secretary does _not_ think it will imply supermajority, it would be pointless to delay the vote on the basis of that. As some people already have said, making all the choices in such a ballot modify the Foundation Documents would make the supermajority problems in the previous vote go away, and would more likely solve this issue once and for all (or probably not only affecting the current release or whatever), as it would be written in the FDs. Emilio signature.asc Description: OpenPGP digital signature
