Re: Alternate proposal for Declassification of debian-private archives
Em Qui, 2005-12-01 às 08:32 -0600, Manoj Srivastava escreveu: > a) The post contained sensitive material. > In this case, if a reasonable case has been made for the > material being sensitive, and one that the declassification > teams accepted, then the material should be redacted from the > post, and every post it has been quoted in. If it is sensitive > in one post, it is sensitive in another. So it's not a declassification after all, it's just a proccess of getting the posts that shouldn't be on -private out of it It's obvious to me that many posts on -private are there because they *are* sensitive material, and if we're not going to open that, then it's not declassification at all. This is a hard decision, I know, but that's why it is a GR. The question is if we do want to expose our internals! if we do, we should really do it, not just publish some selected things, it can't be called declassification if we select which materials are of our interest to be public. daniel P.S.: I know, the current proposal isn't exactly that way (I agreed to make it happen), but this alternate proposal is getting too far from the original idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposal for *Real* Declassification of debian-private archives
As dicussion follows, I decided to formalize a proposal for a real declassification of the content on -private. As I said before, if we're going to choose which material is made public, we can't call it "declassification". The main points are: 1) Everything except financial information about others then Debian and vacation announcements is published. - Vacation announcements are a requirement of the project, and reveal no other information than where a developer was at some time, which is irrelevant to the project as a whole. - Third-party financial information would not give any information about Debian itself. - Everything else will be made public. - This means that some damage is expected, but if we're going to take it serious, that's a unavoidable side effect. 1) Five years, instead of Three. - This is to reduce the possible negative impact of -private messages to its authors, since a five years old message has fewer chances of causing damage than a three years old one. --- In accordance with principles of openness and transparency, Debian will seek to declassify and publish posts of historical or ongoing significance made to the Debian Private Mailing List. This process will be undertaken under the following constraints: * The Debian Project Leader will delegate one or more volunteers to form the debian-private declassification team. * The team will automatically declassify and publish posts made to that list that are five or more years old, with the following exceptions: o posts that reveal financial information about individuals or organisations other than Debian, will have that information removed; o vacation announcements or posts that have no content after information is removed (according to the above constraint), will not be published, unless the author requests they be published; --- This way, I think we would have a *real* declassification process. daniel signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: Proposal for *Real* Declassification of debian-private archives
Em Sex, 2005-12-02 às 21:16 +0100, Florian Weimer escreveu: > * Daniel Ruoso: > > In accordance with principles of openness and transparency, Debian > > will seek to declassify and publish posts of historical or ongoing > > significance made to the Debian Private Mailing List. > What is the "Debian Private Mailing List"? > [EMAIL PROTECTED], or any other alias pointing to this > address? Well, I do think it's about all posts in -private archive. If something was an alias to that, then that's included. > This distinction is important because for years, [EMAIL PROTECTED] > was an aliases for debian-private, and people who sent mail to that > address might be very surprised that it's subject to declassification > (and that it was sent to hundreds of Debian developers in the first > place). Even if it is a five years old message? I do think security problems released 5 years ago are already fixed, or are you talking about something else? daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private
Hi, I'll try to move forward in the direction of a more consensual proposal about the declassification. In this discussion, two points were made clear to me: 1) It would be really nice to have the d-p archives available to those who want to understand better how debian works, and from this perspective, the selection of which content will be made available is not a desirable thing. 2) On the other hand, some sensitive material should not be indexed by google, nor be available without any criteria. This is certainly the point that is raising most of the disagreement. So, my conclusion is that it would be nice to have two types of publications: 1) Selected Readers 2) Selected Content The first type of publication could embrace the entire content of debian-private, but restrictions will be applied for those who want to read, basically, the need of identification of the reader and the agreement to a NDA on the same terms applied to every debian developer about the privacy of the mailing list. The second type would be open to the public in general, and then could be strictly opt-in, since this would be indexable by google, and it's desirable that the authors have a choice on that. This way, I'd like to formalize a new Proposal. -- In accordance with principles of openness and transparency, Debian will seek to declassify and publish posts of historical or ongoing significance made to the Debian Private Mailing List. This publication will be made in two different ways, both managed by a declassification team assigned by the Debian Project Leader: 1) 3 or more years old posts will be made available on a public site, but the access to this content will be regulated by the following constraints: * The declassification team will ellaborate a NDA in the same terms of the policy applied to every Debian Developer concerning the privacy of the mailing list. * The prospective reader will have to identify himself to the declassification team, and will need to have a GPG key signed by a Debian Developer. * The prospective reader will have to send a GPG signed email in which he will agree to the NDA. * The declassification team will send username, password and the url in a GPG sined and cyphered email to the prospective reader. * The access logs of this content will be kept. 2) 3 or more years old posts will be made available on a public site with public anonymous access according to the following constraints: * The declassification team will request approval for publication of the posts to its authors, which can request: a) to keep the entire post private, b) to remove his identification from the post, c) to remove certain parts of the post, d) to publish the post as it is. * If an author requests that some post or some parts of it needs to be kept private, the references to it will be removed from other posts. * If the author doesn't reply to the request for publication, the entire post will be kept private. * If the post already contains a "you're allowed to quote me outside debian-private"-like statement, the declassification team will not need to contact the author, and the post will be published. --- I hope this is closer to a consensus... daniel signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: {SPAM} Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private
Em Qui, 2005-12-08 às 00:08 +0100, Gaudenz Steinlin escreveu: > On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote: > > The first type of publication could embrace the entire content of > > debian-private, but restrictions will be applied for those who want to > > read, basically, the need of identification of the reader and the > > agreement to a NDA on the same terms applied to every debian developer > > about the privacy of the mailing list. > One of the main goals of the original GR was to make the archives > available for research. How will you be able to publish the results > of such research if you agreed to an NDA. One of the main principles > of scientific research is to make your results reproducible by others. > This is impossible if you base your research on data which is only > available under an NDA. As a Social Scientist, I must say that it's completely normal to make researchs using confidential resources. This only tells you that you should respect the privacy, but still lets you understand better the object of your research. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private
Em Qui, 2005-12-08 às 01:39 +0100, Wouter Verhelst escreveu: > On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote: > > I hope this is closer to a consensus... > Afraid not. This proposal basically creates a second class of people -- > those who we want to sign NDA's to be able to read stuff. Well, if you're going to get access to information that if published could damage people, that's not surprise. There's a lot of personal information inside debian-private, which can be usefull for someone doing a research, but even then, should not be available to general public. > That's even further away from 'openness and transparency' than the > status quo. The idea that developers sometimes have private things > to say is at least defendable; the idea that Debian is joining the NDA > crap is not, IMNSHO. Well, Debian Developers today agree to a non-formal NDA about debian-private. I'm just suggesting that this could be extended for others who want to get access to the debian-private archive. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private
Em Qui, 2005-12-08 às 08:07 +0100, Lionel Elie Mamane escreveu: > On Thu, Dec 08, 2005 at 01:39:15AM +0100, Wouter Verhelst wrote: > > On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote: > >> The first type of publication could embrace the entire content of > >> debian-private, but restrictions will be applied for those who want > >> to read, basically, the need of identification of the reader and > >> the agreement to a NDA on the same terms applied to every debian > >> developer about the privacy of the mailing list. > Well, if we let anybody read it, it has absolutely no point asking for > an NDA. Your proposal says that anybody can get read it, if he signs > an NDA. This procedure could be a useful tool if we restricted it to, > say, people like Biella Coleman that have a "real use", sanctioned by > Debian and all, out of the_whole_ archive. (This should not keep us > from opening up nearly everything else.) Well, I just wanted to keep my hands off judging for who we want to show it, I'm just saying "hey, if you want to read, you can, as long as you respect the privacy of the mailing-list as every debian developer". But I want to remember that there is still the second form of publication, in which we select which content will be made public, and this will be available to anonymous readers. > >> I hope this is closer to a consensus... > > Afraid not. This proposal basically creates a second class of people > > -- those who we want to sign NDA's to be able to read stuff. > > That's even further away from 'openness and transparency' than the > > status quo. The idea that developers sometimes have private things > > to say is at least defendable; the idea that Debian is joining the > > NDA crap is not, IMNSHO. > NDA's have a bad reputation in our community; sometimes they make > sense. They are just a formal version of "yes, I understand the > information I get is confidential; I will treat it as such". I think > it makes sense for very selected readers that have a good use of the > whole archive. It is indeed a bit silly if anyone can just sign it and > get access. Why? I'm just saying it will be kept private, I mean, not going to be indexed by google, not appearing in a newspaper and, this way, protecting the authors. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private
Em Sex, 2005-12-09 às 00:49 +1000, Anthony Towns escreveu: > On Thu, Dec 08, 2005 at 11:24:52AM -0300, Daniel Ruoso wrote: > > There's a lot of personal information inside debian-private, > There is? I got 36 of 494 messages (7%) for the month I did, with an > additional 55 odd spam messages (11%). See master:~ajt/d-p.200211 and > d-p.200211.boring. > I'd love to see a second take on that sort of analysis, either for the > same month or different ones. Well, I said that with some specific threads on mind, maybe "personal information" is not well suited, better would be "information that is sensitive for some people". daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Em Qui, 2006-01-19 às 20:30 -0800, Thomas Bushnell BSG escreveu: > Christopher Martin <[EMAIL PROTECTED]> writes: > > It was my understanding that this is what the amendment was attempting to > > do > > - to establish a position statement stating that > > GFDL-minus-invariant-sections was problematic but still DFSG-free (and > > therefore acceptable in main). Is your point that the amendment wasn't > > sufficiently explicit? > No. I understood the amendment exactly as Manoj has characterized it: > it was an amendment to permit the GFDL in, whether or not it is > DFSG-free. Just to make it clear: "We consider that the GNU Free Documentation License version 1.2 conflicts with traditional requirements for free software in a variety of ways, explained in detail in the Problems of the GFDL section below." And later, on "Problems of the GFDL" "The DRM Restriction [...] Transparent And Opaque Copies [...] Invariant Sections" So, the amendment do recognize the other problems, but still... "We believe that works licensed under the GFDL that include no such unmodifiable sections do fully meet the spirit of the Debian Free Software Guidelines, and have a place in our distribution despite the other problems (minor, in comparison) that the GFDL has." It's something like, "Hey GFDL has problems, but it has the *spirit*, so the other problems doesn't matter"... Unfortunally, spirit doesn't changes the license... And also: "Despite the compromise above, GFDL'd documentation is still not free of trouble: as an example, it is incompatible with the major free software licenses, which means that GFDL'd text can't be incorporated into free programs." So... If the intention was to refute the interpretation of the GFDL license that thinks the other problems do exist? Shouldn't it be forced to say that the problems doesn't exist? If the amendment recognizes that the other problems exists but still wants to includes it in main, so it changes the DFSG. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
Em Seg, 2006-01-23 às 10:28 +0100, Wouter Verhelst escreveu: > On Mon, Jan 23, 2006 at 10:41:25AM +0200, Anton Zinoviev wrote: > > If you do not have any access to my encrypted or "chmod -r" copy, then > > I am not controllyng your reading or further copying > Really. If you maintain a copy of a GFDL'ed work on one of your > debian.org home directories without the world-writable read bit set, you > are in violation of the license, as written. Hmmm... This made me think twice... The license is an agreement that regulates one action: the distribution, right? Is this clause enforcable to your private copies (considering it as a bug)? or just to the copies you distribute... I mean, I know the license says "the copies you make or distribute", but, by definition, wouldn't it apply only to the act of distribution? daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How many GRs?
Em Qua, 2006-01-25 às 10:35 +0200, Fabian Fagerholm escreveu: > Some people want to have one big GR with all the options on it. > Other people (like me) think it's better to have two separate GRs: > * one to decide if GNU FDL is free or not and > * one to decide how we should explain our decision. > Adeodato's amendment was for the "one big GR" setup. > My proposal was for the "two separate GRs" setup. > If there is not enough support for the "two separate GRs" setup, then I > will consider modifying my proposal to fit into the "one big GR" setup. > But I first want to see if there is any support. I, personally, think that we must have the lesser number of GRs we can... GRs are a quite expensive (in the sense of energy) way of dealing with stuff... And also, the public statement about GFDL is a natural consequence of the first GR, so, if we do need to vote for a statement (which I doubt), let's vote it together with the decision itself... Like, a) Debian thinks GFDL is non-free and will publish the following statement... b) Debian thinks GFDL without invariant sections is free and will publish the following statement... c) Debian thinks GFDL is free at all and will publish the following statement... d) Debian can't decide right now and will keep the things as they are now (won't say anything, but will keep the delegate's decisions)... I don't see a reason to split it into two GRs... And I don't think a proposal to include it in main even being considered non-free would get enough seconds... What I would suggest to the project's secretary is to re-start this GR process, as it seems too confusing by now (can it be done?)... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Re: The invariant sections are not forbidden by DFSG
Em Ter, 2006-01-31 às 16:53 +0200, Anton Zinoviev escreveu: > invariant sections with offensive material give us a similar example > -- documents that contain such invariant section would also be > non-free. The problem is using one thing as media for unrelated stuff. As most people would just remove the unrelated stuff (so it fits to their need as it reduces paper cost, disk usage, increases usability in a particular media), FSF made it invariant to make sure it will be there. IMHO, adding other invariant sections to subvert the first will not solve the problem, as you still won't be able to just remove it so it fits to your needs (as stated in the freedom 1, which clearly is the direct reference, and the real meaning, of DFSG3). It can be argued that software must be treated in a different way than texts, documentation and other works. But Debian has already decided to treat it in the same way. I can see no workarounds without modifications in GFDL. Considering the pourpose of the invariant sections is to preserve the author's integrity (in the sense of DFSG4), a reasonable solution is requiring derived works to change the work's name before removing invariant sections. Was this already suggested to FSF? daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
Em Qua, 2006-02-01 às 11:53 +0200, Anton Zinoviev escreveu: > Unfortunately DFSG are not unambiguous and obviously the people > understand them in various ways. Well, the text in DFSG3 may be not well tight. But I think we should look at its direct reference, which can be said as the most sane interpretation. It's clear to me that there is a reference to freedom 1[1], and then, it can guide the interpretation of DFSG3. Freedom 1 clearly says: "The freedom to study how the program works, and adapt it to your needs". So, In some cases removing the invariant sections is needed to adapt it to whoever needs (be it a library that wants to reduce paper cost, be it a embedded apps developer that wants to reduce disk usage, or be it a debian packager who wants to include part of some GFDL doc in a man page). So, IMHO, it's quite unreasonable to say that invariant sections fit in DFSG3. And this way, Anton's proposal do require a change in DFSG3, which in this proposal means an exception to GFDL. > If we decide that the invariant > sections are free, this will require some of us to change their > interpretations of DFSG. > Because of this ambiguity I realy belive that we need to modify DFSG > in some future GR. Sorry, but I don't think that's possible. Your proposal means adding a "except for GFDL invariant sections" in DFSG3. Even if it automatically doesn't change that text, it does change it's use, which IMHO, is the same thing. daniel P.S.: One thing I don't know if has been already suggested to FSF is to require changing the work's name before removing the invariant sections, as it's clear to me that the invariant sections exists to preserve the author's integrity (in the sense of DFSG4), this way, it would fit in the exception already stated there. [1] http://www.gnu.org/philosophy/free-sw.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
Em Qua, 2006-02-01 às 20:12 +0200, Anton Zinoviev escreveu: > If the invariant sections are unreasonably long then I'd agree the > document is non-free. However some developers object even short > invariant sections. It has nothing to do with the size of the invariant section (and indeed, GFDL doesn't impose a size limit on Invariant Sections). It's just the fact of being invariant. The use cases I gave are just examples, I could think in other examples to show you the fact that they being invariant prevents it from fitting in a particular need, but that's not what's going to make us move forward... The fact is that it doesn't allows me to modify it to fit my needs (be it whatever needs), plain that. You do have the right of thinking this restriction is not important, this is your proposal, actually. But this *does modify* DFSG3. This was what I tried to show you, not the opposite. My interpretation of DFSG3 is guided by freedom 1, which says "adapt it to your needs". Invariant sections are a restriction not covered by it. > > P.S.: One thing I don't know if has been already suggested to FSF is to > > require changing the work's name before removing the invariant sections, > > as it's clear to me that the invariant sections exists to preserve the > > author's integrity (in the sense of DFSG4), this way, it would fit in > > the exception already stated there. > FSF would not accept this. The purpose of the secondary sections is > to express "the relationship of publishers or authors of the Document > to the Document's overall subject (or to related matters)... The > relationship could be matter of historical connection with the subject > or with related matters, or of legal, commercial, philosophical, > ethical or political position regarding them". How bad... To me, it's like using one thing as media to unrelated stuff, and as most people would remove the unrelated stuff, they force it to be there anyway. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
Em Qua, 2006-02-01 às 11:13 -0700, Wesley J. Landaker escreveu: > On Wednesday 01 February 2006 09:41, Manoj Srivastava wrote: > > "The license must permit modifications". No if, and, or > > buts. So no, I do not think that is actually true. > Sure, it says it must permit modifications, but it doesn't way that it must > permit ALL modifications. The way it reads, literally, could be interpreted > as it must permit ALL modifcations, or as it must permit at least two > modifications (so that "modifications" is plural). Please, We all know that DFSG wasn't raised without any references... The freedom 1 (which is clearly one direct reference of DFSG) already says "adapt to your needs", and *does not specify which needs are valid*, and also it *does not judges if something already fits to whoever needs*. It's *up to the user* to decide if something fit to his needs or not, and invariant sections *prevents the user* from deciding that. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
Em Qua, 2006-02-01 às 23:00 +0200, Yavor Doganov escreveu: > Since you and the Secretary (probably others as well) are interpeting > the DFSG in a different way, perhaps it is a good idea to clarify that > particular sentence, but it is not an obstacle for the current GR. Well, it has been argued that this ?different? interpretation is the only reasonable interpretation of DFSG3. This has been based in many things, but IMHO, the deffinitive argument is backing up to the software freedom 1[1], which clearly says that you must be able to "adapt it to your needs", and *does not specify* which needs are that, and ensures that *the user judges if something fits or not*. Following this interpretation, Invariant Sections doesn't fit in DFSG3. (you do agree with that, don't you?) You surely can argue that this interpretation is not valid, but I still didn't see any references that bases this interpretation, except by reading the DFSG without taking into account anything else, like, er..., it's history. daniel [1] I've said this before. DFSG3 clearly refers to Freedom 1 and Freedom 3. So, if you're in doubt, you could use it to understand DFSG better... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
Em Qua, 2006-02-01 às 23:28 +0200, Anton Zinoviev escreveu: > On Wed, Feb 01, 2006 at 03:11:25PM -0300, Margarita Manterola wrote: > > Ok, but by being invariant they are turning the documentation into > > non-free documentation. As you say, people won't be able to change it, > > therefore, it's a non-free text. > The modifications that are permited by GFDL are enough to make useful > modifications, that is to adapt the document and to improve it. I must remeber that, in this case, you're not letting the user judge if something fits or not to his needs. This breaks freedom 1[1], which DFSG3 clearly refers to. > Yes, you can not do whatever you whish but this is not necessarily > the right interpretation of DFSG. Can you please give us references that support your argument? As I said more than three times in this thread, I can show you one document[1] that DFSG clearly refers to which contradicts your interpretation. Can you show me something like this that contradicts my argument? daniel [1] http://www.gnu.org/philosophy/free-sw.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
Em Qua, 2006-02-01 às 23:33 +0200, Anton Zinoviev escreveu: > On Wed, Feb 01, 2006 at 03:28:30PM -0300, Daniel Ruoso wrote: > > This was what I tried to show you, not the opposite. My interpretation > > of DFSG3 is guided by freedom 1, which says "adapt it to your needs". > > Invariant sections are a restriction not covered by it. > I still belive that my interpretation of DFSG3 is the same as yours. Ok, now I'm lost... What are you trying to say? daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
Em Qui, 2006-02-02 às 12:44 +0200, Anton Zinoviev escreveu: > On Wed, Feb 01, 2006 at 06:32:50PM -0300, Daniel Ruoso wrote: > > I must remeber that, in this case, you're not letting the user judge if > > something fits or not to his needs. > > This breaks freedom 1[1], which DFSG3 clearly refers to. > Notice that freedom 1 doesn't talk about distribution. However if you > interpret "need" as "need" and not as "whatever the user decides are > his needs" then this modification would be useful and required by > freedom 3. Sorry, it's "adapt to your needs", not "adapt to the needs the author judges reasonable"... You're forcing your interpretation beyond reasonable limits... > > As I said more than three times in this thread, I can show you one > > document[1] that DFSG clearly refers to which contradicts your > > interpretation. Can you show me something like this that contradicts my > > argument? > I hope in this message I answered you. No, you didn't. You're still using your own words to subvert the common-sense interpretation of freedom. Please, point me to the references that support your arguments. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Re: Anton's amendment
Em Qui, 2006-02-02 às 01:09 +0200, Kalle Kivimaa escreveu: > Yavor Doganov <[EMAIL PROTECTED]> writes: > > As explained on http://www.gnu.org/licenses/fdl-howto.html, the > > Invariant sections serve a special purpose, which is the case of the > > GNU Manifesto. Many users, including myself, consider it a more > > important part than the GNU Emacs Manual itself. How removing the > > document, that inspired thousands to join the efforts, will make > > Debian more free, I cannot tell... > So, if I were to write a program, which at startup displays the > entiretity of the GNU Manifesto, and wrote a license, which would be > GPL with the addition that the startup display may not be modified, > only amended, you would consider this program a DFSG program and it > could go into main? IMHO, it's non-free. It's completely reasonable to want to remove the startup display at all... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
Em Qui, 2006-02-02 às 18:49 +, Stephen Gran escreveu: > This one time, at band camp, Daniel Ruoso said: > > > So, if I were to write a program, which at startup displays the > > > entiretity of the GNU Manifesto, and wrote a license, which would be > > > GPL with the addition that the startup display may not be modified, > > > only amended, you would consider this program a DFSG program and it > > > could go into main? > > IMHO, it's non-free. It's completely reasonable to want to remove the > > startup display at all... > Except that the GPL already explicitly precludes modifications of this > type (not this scope, but this type, mind you), and our foundation > documents consider the GPL a free license. GPL is very clear about that: "to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License." The GNU Manifesto is *not* an copyright notice, and you're not required to display the entire license, only that it is licensed under the GPL and where to get it. So, I would not violate the license if I (even not as the copyright owner) modify the way this is displayed and the text displayed, as long as I keep: 1) The copyright notice: "Copyright(c) 2006 Whoever ([EMAIL PROTECTED])" 2) The "No Warrant" notice: which can have the text changed. 3) Legal: "This is a GPL software. You can get a copy of the lincence at http//wherever.com" I'm not forced to display this the same way the original author did, and not even the same text. I.e.: If the original author popped up a dialog box with a OK button, I still can show this information in the splash screen without any user confirmation... This has nothing to do with invariant sections. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
Em Sex, 2006-02-03 às 11:42 +0200, Anton Zinoviev escreveu: > What I wrote was the following: if your modifications solve some real > need, not just your whims, then your modifications are usefull and > freedom 3 gives you the right to distribute them. It's quite hard to read that freedom 3 is more restrictive than freedom 1. It still looks like you're forcing it to mean what you want... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Re: Anton's amendment
Em Sex, 2006-02-03 às 11:43 +0200, Anton Zinoviev escreveu: > If GPL didn't contain the clause we are discussing then you > would say that a license with such clause is non-free. I still don't know why you think this GPL clause has something to do with invariant sections... GPL only says: "to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License." This only says I must include a copyright notice, a warranty notice and a where-to-get-the-license notice. And *doesn't say I must present them in the same way the original author did, and not even with the same text*... Even if the original author popped up a dialog box with a long text asking the user to press OK, I still can display 3 lines (that's all needed to satisfy this clause) with an text by myself in a splash screen. And only if it's an interative program. There is nothing here that looks like invariant sections. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anton's amendment
Em Qui, 2006-02-02 às 02:11 +0200, Yavor Doganov escreveu: > | Everything must be modifiable I'm still not convinced GPL prevents that. You're still allowed to rephrase the copyright,no-warrant,where-is-the-license notices and to present it in a way that fits to your needs. It doesn't force you to use in the same way and with the same text the original author did. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Em Qui, 2006-02-09 às 21:18 -0500, Christopher Martin escreveu: > To impose the 3:1 requirement requires, beforehand, a judgment concerning > the DFSG. And so to remove it... If it's a judgement for one side, it's a judgement for the other... > Since no one has found a Secretarial basis for that power, it > follows that to arbitrarily impose 3:1 supermajorities is not proper. Ok, let me give you some "Secretarial basis": 0) The formal documentations in Debian usually are raised from the common practice. a) The Debian Policy is built only using common practices. b) The DFSG was build after knowing wich licenses Debian consider as free. So, on doubt with "written down" documents, you can revisit its origins and the common practice that raised it. 1) No license (even before the DFSG exists) with this type of restriction was accepted as free (Please, GPL 2c has absolutely nothing to do with invariant sections). 2) This way, the proposed amendment open the way for a new type of restriction, which was never accepted as free, and so causes a implicit change to DFSG3. > That the 3:1 bit is mentioned in the constitution is quite irrelevant. Are you sure? I just explained it does changes DFSG3, and therefore, it should *as the constitution says* require a 3:1 majority. The constitution would be violated if manoj didn't apply that. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Question about GFDL licensed works
Em Dom, 2006-02-12 às 09:22 -0600, Manoj Srivastava escreveu: > If people who sponsored the second amendment can explain to me > why something that prevents me from using SELinux when all I am doing > is unpack and copy make sources is deemed free, I would be, err, > grateful. Hmmm... I still didn't buy this argument... But it has been argued that it is not the intent of this license clause and that, because of that, it would not be enforceable, as, even the text not saying that, some other references around are sufficient to disable this type of enforcement of the license. I don't know where are these references (probably RMS comments), but, as we agree it is a bug in the license, it's quite possible that such text exists (there is a message from RMS saying he never thought this could be applied with GFDL terms). I'm not sure this is acceptable, but: 1) This proposal recognizes that the referred application of such restriction is, indeed, non-free. 2) but also says this application is not what the license wants to say and is not enforceable because of that (using other references to clarify that). The same thing could be applied to the transparent copies problem... As I said before, I still didn't buy this argument, but I have to admit it has some logic... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposal: Apologize for releasing etch with sourceless/non-free firmware
Hi, As I understand Debian's view on Free Software did not change, and as the firmware split is, indeed, an unsolved question, I think a more honest position would be to accept that we couldn't deal with the firmware issue in the timeframe for etch. As the question itself seems quite immature (including the question about the freeness of sourceless firmware), and, as we want to release etch in time, I think the most sane thing to do is to say: "Hey, we couldn't deal with this issue but we do want to release etch in time" and mature the question without the time pressure for releasing etch. I propose the following option to the GR: The Debian Project reaffirms its commitment of providing a 100% free operating system, and reaffirms the decisions taken by GR 2004-03, but some technical issues regarding firmware couldn't be solved in the timeframe to release etch, and, therefore, the next Debian release, codename etch, will still contain sourceless/non-free firmwares. The Debian Project apologize for this, and will continue to work on finding a way to solve this issue. I think this needs a 3:1 majority... Daniel signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: kernel firmwares: GR proposal
Qua, 2006-08-30 às 23:06 +0200, Frederik Schueler escreveu: > So, we propose this GR: > > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue; however, it is not yet finally sorted out; > 3. We give priority to the timely release of Etch over sorting every bit > out; for this reason, we will deliver firmware in udebs as long as it is > necessary for installation (like all udebs), and firmware included in > the kernel itself as part of Debian Etch, without further conditions. Seconded. Daniel Ruoso -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Qui, 2006-08-31 às 09:19 +0100, Daniel Ruoso escreveu: > Qua, 2006-08-30 às 23:06 +0200, Frederik Schueler escreveu: > > So, we propose this GR: > > > > 1. We affirm that our Priorities are our users and the free software > > community (Social Contract #4); > > 2. We acknowledge that there is a lot of progress in the kernel firmware > > issue; however, it is not yet finally sorted out; > > 3. We give priority to the timely release of Etch over sorting every bit > > out; for this reason, we will deliver firmware in udebs as long as it is > > necessary for installation (like all udebs), and firmware included in > > the kernel itself as part of Debian Etch, without further conditions. > > Seconded. > > Daniel Ruoso Oops, now signed... :) signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: {SPAM} Counter-proposal: reaffirm support for the elected DPL
Qui, 2006-09-21 às 10:08 +0200, Loïc Minier escreveu: > There's always None of the above, but I am pissed enough by the > attitude of some developers that I want to reaffirm support for the > elected DPL whatever he does to suppose Debian outside of the project. > > (The text of the proposal is attached.) The Debian Project reaffirms its support to its DPL. The Debian Project does not object to the experiment named "Duck Tank", lead by Anthony Towns, the current DPL, and Steve Mc Intyre, the Second in Charge. However, this particular experiment is not the result of a decision of the Debian Project. The Debian Project wishes success to projects funding Debian or helping towards the release of Etch. - I second this proposal with or without typos... And I hope my ISP's MTA doesn't mess with my signature... :) daniel signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Qua, 2006-09-27 às 12:38 -0500, Manoj Srivastava escreveu: > , > | 1. We affirm that our Priorities are our users and the free software > | community (Social Contract #4); > | 2. We acknowledge that there is a lot of progress in the kernel > | firmware issue; however, it is not yet finally sorted out;=20 > | 3. We assure the community that there will be no regressions in > | the progress made for freedom in the kernel distributed by > | Debian relative to the Sarge release in Etch > | 4. We give priority to the timely release of Etch over sorting every > | bit out; for this reason, we will treat removal of sourceless > | firmware as a best-effort process, and deliver firmware in udebs as > | long as it is necessary for installation (like all udebs), and > | firmware included in the kernel itself as part of Debian Etch, > | as long as we are legally allowed to do so, and the firmware is > | distributed upstream under a license that complies with the DFSG.=20 > ` I second this proposal. Daniel Ruoso signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: GR Proposal: Declassification of -private
Em Ter, 2005-11-15 às 12:08 +1000, Anthony Towns escreveu: > I think the easiest way to do that is to adopt an approach similar to that > of governments that deal with classified documents; that is by setting a > specific time after which -private posts will be required to be considered > for declassification (ie, publication) and redacting only those posts (or > portions of posts) for which there's still a good reason to keep private. Yes, and I do think even this GR being rejected, such declassification process should be defined for future content. Is there a way to combine such votings? so we don't have to vote once again on that. Or even, do we need to vote on that? > According to the interweb, classified US government documents relating > to national security have to be released after at most ten years (unless > there're particular reasons to extend that); the oldest mail in the > -private archives turns ten on January 21st next year. I don't want to > see Debian be more secretive than the US military industrial complex :) This is a sensitive matter for people in Brasil. The question is that when the millitary gov created a lot of documents, they weren't intended to become public at any time, but in the democratic transition, such process was defined. Why am I saying this? Well, because that's the reason I second this proposal (instead of the manoj's modification). I've been in Debian for a short time by now, but I didn't see any content on -private that couldn't be open after some time (taking off the VAC notification, personal money info and stuff like that), and just because we can't get a reply it doesn't means it doesn't matter. So, I second this proposal. Em Ter, 2005-11-15 às 12:08 +1000, Anthony Towns escreveu: > Thus, I propose that the Debian project resolve that: > > --- > In accordance with principles of openness and transparency, Debian will > seek to declassify and publish posts of historical or ongoing significance > made to the Debian Private Mailing List. > > This process will be undertaken under the following constraints: > > * The Debian Project Leader will delegate one or more volunteers > to form the "debian-private declassification team". > > * The team will automatically declassify and publish posts made to > that list after three years, with the following exceptions: > > - the author and any named recipients of messages being reviewed > will be contacted, and allowed between four and eight weeks > to comment; > > - posts that reveal financial information about individuals or > organisations other than Debian, will have that information > removed; > > - posts of no historical or other relevance, such as vacation > announcements, or posts that have no content after personal > information is removed, will not be published, unless the author > requests they be published; > > - publication of posts that would reveal otherwise unpublished > security vulnerabilities in currently supported releases of a > Debian distribution will be deferred; > > - requests by the authors of posts, or others who would be affected > by the publication of the post, will be taken into account by > the declassification team; > > - the list of posts to be declassified will be made available to > developers two weeks before publication, so that the decisions of > the team may be overruled by the developer body, if necessary. > --- daniel signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: GR Proposal 2: Declassification of -private
Em Sex, 2005-11-18 às 16:09 +1000, Anthony Towns escreveu: > Seconds so far: >Don Armstrong (original or Manoj's changes) >Joey Hess (original only, no comment on Manoj's changes) >Wouter Verhelst (Manoj's changes, no comment on original) >Bas Zoetekouw (Manoj's changes, no comment on original) >Daniel Ruoso (original preferred over Manoj's changes) > Five's enough to second a proposal, but only if they all second the same > one :) I change my position as it seems that's needed to take it to the vote. I consider the whole proposal more important than the differences between them, so I extend my second to the original and to manoj's changes. And, I think it would be interesting to get the process applied to future content even if it don't passes for the past content. So... I propose to include an option on the vote for applying the same rules, but only to future content. daniel signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: GR Proposal 2: Declassification of -private
Em Sex, 2005-11-18 às 16:09 +1000, Anthony Towns escreveu: > Thus, I propose that the Debian project resolve that: > > --- > In accordance with principles of openness and transparency, Debian will > seek to declassify and publish posts of historical or ongoing significance > made to the Debian Private Mailing List. > > This process will be undertaken under the following constraints: > > * The Debian Project Leader will delegate one or more volunteers > to form the "debian-private declassification team". > > * The team will automatically declassify and publish posts made to > that list that are three or more years old, with the following > exceptions: > > - the author and other individuals quoted in messages being reviewed > will be contacted, and allowed between four and eight weeks > to comment; > > - posts that reveal financial information about individuals or > organisations other than Debian, will have that information > removed; > > - requests by the author of a post for that post not to be published > will be honoured; > > - posts of no historical or other relevance, such as vacation > announcements, or posts that have no content after personal > information is removed, will not be published, unless the author > requests they be published; > > - comments by others who would be affected by the publication of > the post will also be taken into account by the declassification > team; > > - the list of posts to be declassified will be made available to > developers two weeks before publication, so that the decisions > of the team may be overruled by the developer body by General > Resolution, if necessary -- in the event such a resolution is > introduced (ie, proposed and sponsored), the declassification > and publication of messages specified by the resolution will be > deferred until the resolution has been voted on. > --- > The changes since the original: > >- authors have a veto over publication (Manoj's changes) >- people quoted in messages rather than other recipients should be > contacted >- security problems don't get special treatment; they can be vetoed > by the post's author though >- specific details for overriding the team's decisions by the > developers Ok, Following what I've said in the last post, I second this proposal. daniel signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
GR Proposal 3: Declassification of -private - Future content only
Just to formalize what I've already said... I think this should be considered for future -private content even if the GR Proposal 2 (which I second) is rejected, considering one argument against it is that people didn't expect to have it's private posts revealed. -- Thus, I propose that the Debian project resolve that the process defined in GR Proposal 2 will be applied *only* for the future content of debian-private mailing list. -- To me, it's a second option that would make possible to avoid creating more un-declassificable material on -private even if the GR Proposal 2 is rejected. daniel signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
Re: GR Proposal 3: Declassification of -private - Future content only
Em Sáb, 2005-11-19 às 12:29 +1000, Anthony Towns escreveu: > On Fri, Nov 18, 2005 at 11:41:34AM -0300, Daniel Ruoso wrote: > > -- > > Thus, I propose that the Debian project resolve that the process > > defined in GR Proposal 2 will be applied *only* for the future content > > of debian-private mailing list. > > -- > So obviously as proposer of the origianl GR, I'm not going to accept that, > so it'll have to get voted on separately as per A.1(1-3). Big surprise, > I know :) Not just no surprise, but actually, that was my intention... To offer a second option in the case of rejection of the first (which I've seconded, and I'll vote for). daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPL election IRC Debate - Call for questions
Em Seg, 2005-02-28 às 06:29, Helen Faulkner escreveu: > We would therefore like to call for suggestions for questions to be put > to the candidates during the debate. We hope to be able to choose a set > of questions which reflect the concerns and interests of Debian > Developers in general. Ok, here's a suggestion... * I had recently post a message to debian-project[1] suggesting that we could plan structural changes in Debian, I mean, We all know that "Debian releases when it's ready", but few people know what the "it" means. For example, if the init maintainers decide to define the locale environment variables at the boot process, many packages would break and then Debian would be far from being ready. I'm not criticizing this structural changes, but I do think that the DPL could coordinate this sctructural changes in a way more people know what it means by "when it's ready". I would like the candidates to comment on this topic. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-women obscurity, was: Clarification about krooger's platform
Em Qua, 2005-03-09 às 17:07, Amaya escreveu: > When I first became a developer, I found debian-devel frightening, > hostile and very intimidating, I must admit this was not so because of > gender issues. I would like to remember everybody the mencal flamewar (one of the most stupid flamewars I have ever seen on debian-devel), that *was* a gender issue. []'s daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Election 2005 Results
For those who are tired of pressing page up/page down to understand the listing... a s/Option \d/$candidates[$1]/ge is helpfull... Branden Robinson defeats Mathew Garrett by ( 248 - 220) = 28 votes. Anthony Towns defeats Mathew Garrett by ( 244 - 221) = 23 votes. Mathew Garrett defeats Angus Lees by ( 350 - 60) = 290 votes. Mathew Garrett defeats Andreas Schuldei by ( 249 - 185) = 64 votes. Mathew Garrett defeats None of the Above by ( 384 - 75) = 309 votes. Branden Robinson defeats Anthony Towns by ( 245 - 222) = 23 votes. Branden Robinson defeats Angus Lees by ( 352 - 95) = 257 votes. Branden Robinson defeats Andreas Schuldei by ( 244 - 184) = 60 votes. Branden Robinson defeats None of the Above by ( 376 - 107) = 269 votes. Anthony Towns defeats Angus Lees by ( 375 - 80) = 295 votes. Anthony Towns defeats Andreas Schuldei by ( 264 - 196) = 68 votes. Anthony Towns defeats None of the Above by ( 390 - 101) = 289 votes. Andreas Schuldei defeats Angus Lees by ( 307 - 99) = 208 votes. Angus Lees defeats None of the Above by ( 261 - 184) = 77 votes. Andreas Schuldei defeats None of the Above by ( 346 - 120) = 226 votes. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
