Re: Q for all candidates: license and copyright requirements
Le Sun, Mar 21, 2010 at 01:01:40PM -0700, Manoj Srivastava a écrit : If we want to change our foundation documents, and remove the awoval to the concept of being 100% free, or to say that Debian, and thus the parts of Debian covered by the DFSG, are just the binary bits, then we can do so via constitutionally approved methods like GR's with appropriate majority requirements. Is this what is being considered? Le Mon, Mar 22, 2010 at 02:04:06PM +0100, Holger Levsen a écrit : If I understand your correctly you seem to think that your proposal wouldnt need a GR if a DPL that supports it (e.g. you) would be elected. How so? In my GR proposal, there are three options, and none of them change the DFSG. The first of them apperars quite consensual. The only problem is that if everybody agrees that we are wasting time on over-documenting debian/copyright, why don't we change our archive policy? I think that if a DPL that agrees with that change is elected, he will have a strong position to discuss with the FTP team, and a GR will be unnecessary. The second option aims at clarifying what is the source of the Debian operating system. It is controversial. Despite it does not change our fundation documents, I think that a GR would be needed to make sure that there is a general agreement. Also, I think that GRs should be used to move forward when a choice is needed, but should be avoided when the result is to demotivate many developers. I will not push the second option if this is the case (not to mention that I think that a GR should be started only if it has good chances of being accepted). I hope this explains, -- Charles -- 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/20100323150300.ga3...@kunpuu.plessy.org
Re: Q for all candidates: license and copyright requirements
Hi Charles, On Wed, Mar 24, 2010 at 12:03:00AM +0900, Charles Plessy wrote: The second option aims at clarifying what is the source of the Debian operating system. It is controversial. I would like to say, for the record, that I believe you've lost track of what lives in Debian if you claim this. I agree with you that having to repack software for Debian is annoying, and that it may be a waste of time. I've had to do it myself, for beid, and it's not the most fun part of my involvement in Debian. However, I do think you're completely and utterly wrong in your above claim. Over the years, I've talked to many a Debian Developer, at FOSDEM, Debconf, or other gatherings, and never did I meet anyone who would even talk about this. If it indeed was controversial, as you claim, one would think that this would have happened a few times? -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Q for all candidates: license and copyright requirements
On 03/23/2010 11:03 AM, Charles Plessy wrote: The second option aims at clarifying what is the source of the Debian operating system. It is controversial. To some of us, the Debian operating system is at least as much about the packaged source as it is about the packaged binaries. If you were to claim that DFSG freedom only mattered for things shipped in the binary packages, and not the things shipped in the source packages, i would find that upsetting. Our users includes not only an individual with a single computer who never sees the source, but also derivative distributions, private organizations, system administrators, etc, all of whom may need to modify the source for their own purposes. Knowing that the source of any package in main is free is a valuable feature of the Debian operating system. --dkg signature.asc Description: OpenPGP digital signature
Question to all (other) candidates
So, since part of the reason that I joined the race was to make sure it wouldn't get too boring, I was hoping there'd be a bit more life on this list. Since there isn't, allow me to ask a few questions myself. Oh, and before anyone asks: hey, I can vote too, and we have a Condorcet voting system. So there. (The alert reader will notice that some of the points in this mail have not been mentioned in my rebuttals. This is because these are *questions*, not statements of what I believe is wrong; the latter belong in rebuttals, the former do not) These questions have names, but don't let that stop any of the other candidates from answering those questions they want to answer, if any. Stefano: You make a point of transparency and availability in your platform. As you yourself note, many past DPLs and DPL candidates have made similar promises/points, yet few have managed to actually be able to do so. You mention that you will attempt to succeed where others have failed by providing a feed of DPL activity news. While the specifics of your plan may be innovative, the idea itself of constantly providing updates rather than bulk ones has been promised by others in the past (e.g., Steve mentioned it in his 2008 platform). As such, I'm not convinced this will help all that much; How do you believe it will, and how do you think you are different from other DPLs who have tried and failed to be more communicative? Charles: In your platform, in the Program section, you mention four ideas that could reasonable be described as being about the things that, respectively, the DAM and NM frontdesk, the ftp-masters, and the Release Managers (twice) are responsible for. Did you talk with these teams about your ideas before running for DPL? If not, do you believe this may cause problems? Are you still planning to, and may your ideas change if you do? If you did talk to these teams beforehand, did your plans change any as a result, or do you anticipate that still happening? Marga: In my rebuttal, I mention that I lack a sense of vision in your platform. In case that wasn't clear, this is because the ideas you mention, while they might work to some extent, seem to be a bit superficial; I'm afraid they will not strike at the heart of the issues we face. Do you believe this is correct? If not, can you clarify? Also, you seem to have received a great deal of help in writing your platform. In the interest of clarity, can you shine a light on how this happened? To mention two possible extremes, was this more of a I'd like to run, but would need a platform, please send me some ideas, or rather hey, $RANDOM_PEOPLE, here's a platform, please give me some comments? (I realize the truth is probably somewhere in between those two, but would like to know exactly what we get if I were to vote you second...) If any of the other candidates have questions they would like to ask me, I would be glad to answer them. Also, I will provide my own answers to some of the above questions (where that would make sense), but would like to see the other candidates' answers first. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
DPL consultations with the community [was: Re: Question to all (other) candidates]
Hi Wouter-- You probably didn't mean to have this to come out this way, but: On 03/23/2010 01:49 PM, Wouter Verhelst wrote: Charles: In your platform, in the Program section, you mention four ideas that could reasonable be described as being about the things that, respectively, the DAM and NM frontdesk, the ftp-masters, and the Release Managers (twice) are responsible for. Did you talk with these teams about your ideas before running for DPL? This comes across as calling Charles out for not consulting other people (or at least not acknowledging their contributions). Marga: [...] Also, you seem to have received a great deal of help in writing your platform. In the interest of clarity, can you shine a light on how this happened? This comes across as calling Marga out for consulting too many other people (or at least for acknowledging their contributions too much). But you can't have it both ways ;) How much consultation with other members of the community is appropriate for the DPL? How prominently should an acknowledgment of those contributions be presented? I see no acknowledgments of outside input in your own platform. Did you consult with other members of the community in drafting it? (or did i miss it when i read your platform?) Thanks for keeping things stirred up, --dkg signature.asc Description: OpenPGP digital signature
Re: Q for all candidates: license and copyright requirements
Charles Plessy ple...@debian.org writes: The second option aims at clarifying what is the source of the Debian operating system. It is controversial. Despite it does not change our fundation documents, I think that a GR would be needed to make sure that there is a general agreement. For whatever it's worth, I believe the second option changes the foundation documents and would require a 3:1 majority. The person who's canonical on that is the Secretary, of course, but I wanted to note publicly that even the above statement about the nature of the proposal is controversial. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87vdcmyi63@windlord.stanford.edu
Re: Q for all candidates: license and copyright requirements
The second option aims at clarifying what is the source of the Debian operating system. It is controversial. It is a lot but not controversial, actually its pretty clear. For that statement alone *I* hope NOTA will have a big win over you, sorry. It shows you are way off with actual project. -- bye, Joerg Mr. Scorpio says productivity is up 2%, and it's all because of my motivational techniques -- like donuts and the possibility of more donuts to come. -- 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/87ljdiu7b3@gkar.ganneff.de
Getting more people involved in core teams.
I think that one of issues we have is that there is alot of work to be done by some teams, some of them even regularaly mail that they need more members, but they seem to have a hard time keeping the numbers up, burning the other team members out. What are your ideas to make sure those teams keep running? Kurt -- 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/20100323222539.ga8...@roeckx.be
Re: Q for all candidates: license and copyright requirements
Le Tue, Mar 23, 2010 at 12:04:01PM -0400, Daniel Kahn Gillmor a écrit : Our users includes not only an individual with a single computer who never sees the source, but also derivative distributions, private organizations, system administrators, etc, all of whom may need to modify the source for their own purposes. Hi Daniel and everybody, 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. 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. I think that we should have the possibility to redistribute a bit-identical upstream archive when possible. 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 ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100323232743.ga5...@kunpuu.plessy.org
Question for the other candidates: supermajority.
Le Tue, Mar 23, 2010 at 12:03:32PM -0700, Russ Allbery a écrit : For whatever it's worth, I believe the second option changes the foundation documents and would require a 3:1 majority. The person who's canonical on that is the Secretary. Dear Russ, Stefano, Wouter and Margarita. I would like to take the opportunity of Russ's comment to ask to the other candidates their opinions about the supermajority votes. After the very painful GR about “Lenny and resolving DFSG violations”, discussions started about our voting system, and the fact that it does not accomodate well with mixture of supermajority and regular options. Also, disagreements whether an option needs the supermajority often starts bitter debates. Do you think it is a problem that you would like to solve as a DPL? During the discussions that started after the GR, I suggested that the GR proposer should have more control about the options put to the vote. In particular, it would be useful if he can refuse an option that would disequilibrate the voting system. That would make him responsible for the success of the GR: discarding a popular option is taking the risk that the whole GR is refused and the option is accepted as a separate GR, which is the kind of public failure that I expect that people will avoid. For the supermajority, I think that it should be used only when modifying directly foundation documents. As a compensation, we may let the Secretary declare a GR ‘unconstitutional’ and refuse to let it be applied. This would remove a lot of meta-discussion in GRs that already produce many emails. In contrary with our current sytem, constitutionality of an option would only be decided after it gets the Condorcet majority. I do not think that it would create more problems than the current system, where the results of the vote can be analysed afterwards to show, if it is the case, that an option did not pass the supermajority but would be the choice of a simple majority of the developers. This is a crisis situation in general, whatever the vote system is. This said, I have not mentionned supermajority issues in my platform, since I think that the main points I propose would keep me busy enough if I am elected. I would be pleased however if somebody would self-appoint and lead this debate, if there is the impression that it is needed. Have a nice day, -- Charles Plessy, Tsurumi, Kanagawa, Japan -- 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/20100324002445.gb5...@kunpuu.plessy.org
Re: Q for all candidates: license and copyright requirements
Very interesting thread. == In short == tarballs must be redistributable, unpacked debian source package should be DFSG-free, debian binary package must be DFSG-free. == Long == 1. Upstream tarball is not debian source Cause you cannot build/run/understand anything if you just have a bunch of tarballs. 2. If tarball is not redistributable It belongs in non-free, or must be repackaged to become redistributable 3. Debian source is tarball + debian diff/tar unpacked I you would like to guarantee to the users that unpacked debian source is DFSG we should hook into unpack (similar to DpkgSrc3.0 / quilt) and remove DFSG blobs at maintainers discretion for example by parsing debian/copyright. 4. Pristine tarballs on mirrors are a benefit They are still our build-dependency both for source and binary packages. But if we keep them pristine in the archive we will become mirrors for those upstreams. And it will give our users an opportunity to learn/study/use those DFSG blobs which are not part of debian source (definition 3 above). 5. This will reduce maintenance time This change will result in maintainers spending less time by recuding effort required for packaging software with non-DFSG-pristine-tarball. Debian developer time is precious and very limited and IMHO should be used as efficiently as possible. 6. Above is inline with DFSG DFSG are guidelines and this is my interpretation. I am not lawyer / DD. -- 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/86ecb3c71003231732r7a82fefare15fe3f07d89c...@mail.gmail.com
Re: Q for all candidates: license and copyright requirements
Dmitrijs Ledkovs dmitrij.led...@ubuntu.com writes: 2. If tarball is not redistributable It belongs in non-free, or must be repackaged to become redistributable I think people are missing the degree of complexity in this. For instance, files included the source tarball that aren't used by the Debian build but are under a no commercial use license would mean that the Debian source packages can no longer be distributed by a commercial CD or DVD retailer. Binaries containing encryption code that can't be rebuilt from the sources in the source package, even if never used in Debian, suddenly potentially run afoul of US crypto export requirements. Etc. I suspect the original motivation is really limited just to files that are DFSG-compatible except for limitations on specific types of derivative works that don't involve commercial use, such as GFDL documents with invariant sections or IETF RFCs. But I think drawing a line around just that case, even if we all agreed it was desirable to do so, is harder than it looks. We did talk about this during http://www.debian.org/vote/2006/vote_001, I believe. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87k4t2o82f@windlord.stanford.edu
Re: Question to all (other) candidates
Le Tue, Mar 23, 2010 at 06:49:51PM +0100, Wouter Verhelst a écrit : Charles: In your platform, in the Program section, you mention four ideas that could reasonable be described as being about the things that, respectively, the DAM and NM frontdesk, the ftp-masters, and the Release Managers (twice) are responsible for. Did you talk with these teams about your ideas before running for DPL? If not, do you believe this may cause problems? Are you still planning to, and may your ideas change if you do? If you did talk to these teams beforehand, did your plans change any as a result, or do you anticipate that still happening? Hi Wouter, I have not contacted these teams in private or in public. I expect the three weeks of campaign to be long enough to openly discuss what I propose. Also, I do not think that we need a conclusion now; what we need is to agree that a door is open to change some of our practices. In my platform, I have separate sections for ‘Program’ and ‘What I will do as DPL’. In short: vote for my if you like my program, but I will not come to the core teams with a long shopping list of things to do. This is not fun, nor it gives trust to the teams that do the work. If I am elected, I will contact the core teams about the main points of my program as general directions that, together, collected a majority of the votes in this election, and propose to discuss them in public. I want the outcome of these discussions to be open: we can find other ideas. Have a nice day, PS: interestingly, I just rediscovered an email that covers part of my platform in my ‘postponed’ folder, that I wrote for -devel last year but never sent. Last time I tried to discuss about not building everyting on all arches I was insulted, and this made me affraid to discuss this again in public for a while… -- Charles -- 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/20100324015421.gd5...@kunpuu.plessy.org
