Re: GR Proposal: GFDL statement
ot; For example, books are often written > by individuals, while programs are written by teams, so proper credit > for a book might be more important than proper credit for a program. > > On the other hand, free software is often written by a single person, > and free software documentation is often written by a larger group of > contributors. And the line between what is documentation and what is > a program is not always so clear either, as content from one is often > needed in the other (to provide online help, to provide screenshots or > interactive tutorials, to provide a more detailed explanation by quoting > some of the source code). Similarly, while not all programs demonstrate > creativity or could be considered "works of art", some can, and trying > to determine which is the case for all the software in Debian would be > a distraction from our goals. > > In practice, then, documentation simply isn't different enough to warrant > different standards: we still wish to provide source code in the same > manner as for programs, we still wish to be able to modify and reuse > documentation in other documentation and programs as conveniently as > possible, and we wish to be able to provide our users with exactly the > documentation they want, without extraneous materials. > > (4) How can this be fixed? > > What, then, can documentation authors and others do about this? > > An easy first step is to not include the optional invariant sections in > your documentation, since they are not required by the license, but are > simply an option open to authors. > > Unfortunately this alone is not enough, as other clauses of the GFDL > render all GFDL documentation non-free. As a consequence, other licenses > should be investigated; generally it is probably simplest to choose > either the GNU General Public License (for a copyleft license) or the > BSD or MIT licenses (for a non-copyleft license). > > As most GFDL documentation is made available under "the terms of the GNU > Free Documentation License, Version 1.2 or any later version published > by the Free Software Foundation", the Free Software Foundation is able > to remedy these problems by changing the license. The problems discussed > above require relatively minor changes to the GFDL -- allowing invariant > sections to be removed, allowing transparent copies to be made available > concurrently, and moderating the restrictions on technical measures. > Unfortunately, while members of the Debian Project have been in > contact with the FSF about these concerns for the past four years, > these negotiations have not come to any conclusion to date. > --- Seconded. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: GR Proposal: GFDL statement
On Sun, Jan 01, 2006 at 06:17:57PM -0800, Russ Allbery wrote: > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > The release team has spoken, and they decide what goes in a > > release. If they have decided, under advice from debian-legal, that > > GFDL docs are RC bugs, then that is that. > I've now also found: > <http://release.debian.org/removing-non-free-documentation> > which is basically the statement that I had been looking for. > Given that, I'm not sure that a GR is really necessary, although I still > don't think it could hurt. I'm in favor of a GR because it gives us the means of measuring the consensus within the project about *what* makes this a non-free license; the release team is convinced that it's not a Free Software license, but I'd rather have broad agreement about what *would* make it a free license before we start telling people they need to change. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: GR Proposal: GFDL statement
On Wed, Jan 11, 2006 at 09:53:43PM +1000, Anthony Towns wrote: > On Fri, Jan 06, 2006 at 11:37:37AM +1000, Anthony Towns wrote: > > So, I've updated the wiki [0] in response to most of the suggestions > > on the list so far. > Okay, given the lack of further response (except for dato's alternate > proposal!), I've tweaked the wording one more time, and I think this > is the final version. Seconds appreciated. > I propose the Debian project release the following statement on the GFDL: Seconded. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ > = > > Why the GNU Free Documentation License is not suitable for Debian main > -- > > Context > --- > > Within the Debian community there has been a significant amount of concern > about the GNU Free Documentation License (GFDL), and whether it is, in > fact, a "free" license. This document attempts to explain why Debian's > answer is that it is not free enough for the Debian distribution. > > It should be noted that this does not imply any hostility towards the > Free Software Foundation, and does not mean that GFDL documentation > should not be considered "free enough" by others. Debian itself will > continue distributing GFDL documentation in its "non-free" section, > which does not have such strict requirements. > > This document covers the GFDL version 1.2, which is the most current > version at the time of writing. Earlier versions of the GFDL have similar, > related problems. > > What is the GFDL? > - > > The GFDL is a license written by the Free Software Foundation, who > use it as a license for their own documentation and promote it to > others. Notably, it is also used as Wikipedia's license. The GFDL is a > "copyleft" license in that modifications to documentation made under the > GFDL must in turn be released under the GFDL, not some more restrictive > license. > > How does the GFDL fail to meet Debian's standards for Free Software? > > > The GFDL conflicts with Debian's traditional requirements for free > software in a variety of ways, some of which are expanded upon below. As > a copyleft license, one of the consequences of this is that it is not > possible to include content from GFDL documentation directly into free > software. > > The major conflicts are: > > Unmodifiable Sections > - > > The most troublesome conflict concerns the class of unmodifiable sections > that, once included, may not be modified or removed from the documentation > in the future. These are Cover Texts, Dedications, Acknowledgements, > and Invariant Sections. Modifiability is a fundamental requirement of > the DFSG, which states: > > 3. Derived Works > > The license must allow modifications and derived works, and must > allow them to be distributed under the same terms as the license of > the original software. > > These components create particular problems in reusing small portions of > the work (since any invariant sections must be included also, however > large), and in making sure that documentation remains accurate and > relevant. > > Transparent Copies > -- > > The second conflict is related to the GFDL's requirements for "transparent > copies" of documentation (that is, a copy of the documentation in a form > suitable for editing). In particular, Section 3 of the GFDL requires > that a transparent copy of the documentation be included with every > opaque copy distributed, or that a transparent copy be made available > for a year after the opaque copies are no longer being distributed. > > For free software works, Debian expects that simply providing the source > (or transparent copy) alongside derivative works will be sufficient, > and that users need not be forced to obtain the source with every copy > of the binary they download, but this does not satisfy either clause of > the GFDL's requirements. > > Digital Rights Management > - > > The third conflict with the GFDL arises from the measures in Section 2 > that attempt to overcome Digital Rights Management (DRM) technologies. In > particular, the GFDL states that "You may not use technical measures > to obs
Re: For those who care about the GR
On Sun, Jan 22, 2006 at 12:53:00PM -0600, Manoj Srivastava wrote: > On Sun, 22 Jan 2006 19:25:58 +0100, David N Welton <[EMAIL PROTECTED]> said: > > Manoj Srivastava wrote: > >> On Sun, 22 Jan 2006 13:59:15 +0100, Martijn van Oosterhout > >> <[EMAIL PROTECTED]> said: > >>> 1. debian-legal is wrong, the GFDL is compatable with the DFSG and > >>> thus should be included in main. > >> Looking over the arguments for and against it in -legal, I am > >> trying to ascertain if this stance has a leg to stand on. > > ... and ? > And what? If someone tries to bring through a GR stating that > MS office warez can be distributed in main since it meets the DFSG, > one might rule that as frivolous and a waste of time. I'm not convinced the constitution gives the secretary the power to make such a ruling. There are no provisions in the constitution for the Project Secretary to dismiss a GR -- *even* a GR stating that the Debian Project holds the value of pi to be 3 -- so long as the GR has the requisite number of seconds. In the present case, I understand that the proposed ballot option is ambiguous wrt whether it constitutes an implicit amendment to the foundation docs, and that in the absence of clarification (in the form of a re-worded proposal) on the part of the proposer, it is the project secretary's prerogative to specify a supermajority requirement. But I don't think that extends to dismissing a GR that you happen to believe is inconsistent with reality. FWIW, aside from not being covered as a constitutional power of the secretary, I think trying to stop a GR this way would be pretty darn futile. If half of the project wants to vote in favor of saying pi=3, we're pretty well screwed whether or not the vote actually happens. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: For those who care about the GR
On Mon, Jan 23, 2006 at 12:40:30PM -0500, Anthony DeRobertis wrote:
> On Sun, Jan 22, 2006 at 03:42:39PM -0800, Steve Langasek wrote:
> > > And what? If someone tries to bring through a GR stating that
> > > MS office warez can be distributed in main since it meets the DFSG,
> > > one might rule that as frivolous and a waste of time.
> > I'm not convinced the constitution gives the secretary the power to make
> > such a ruling. There are no provisions in the constitution for the Project
> > Secretary to dismiss a GR -- *even* a GR stating that the Debian Project
> > holds the value of pi to be 3 -- so long as the GR has the requisite number
> > of seconds.
> I suspect the Secretary could effectively do so by declining to take the
> vote under Section 2.1.1 ("[n]othing in this constitution imposes an
> obligation on anyone to do work for the Project.") It seems then that
> the secretary has no obligation to actually perform 4.2.3 or 7.1.1.
Which would be grounds for removing the secretary from office, if necessary
by appealing to the SPI board under 7.2. of the constitution.
> > In the present case, I understand that the proposed ballot option is
> > ambiguous wrt whether it constitutes an implicit amendment to the foundation
> > docs, and that in the absence of clarification (in the form of a re-worded
> > proposal) on the part of the proposer, it is the project secretary's
> > prerogative to specify a supermajority requirement.
> I think that under 7.1.3, it'd be the Secretary's job/power to determine
> supermajority requirement regardless of what the proposed ballot option
> says.
Correct, it is the secretary's job to determine supermajority requirement in
all cases. It would also be an abuse of power to establish a supermajority
requirement other than that specified by the constitution.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: DFSG, GFDL, and position statementsd
On Tue, Jan 24, 2006 at 08:36:19AM +0100, Josselin Mouette wrote: > Le dimanche 22 janvier 2006 à 13:13 -0600, Manoj Srivastava a écrit : > > A) The delegates decision that the GFDL licensed works are non-free is > >wrong, the GFDL meets the DFSG. Override the delegated decision, > >and issue the following statement "..." > > B) The delegates decision that the GFDL licensed works are non-free > >does not hold for works without invariant sections, modify the > >delegated decision to allow works with no invariant sections in > >main, and issue the following statement "..." > I fail to see why these positions don't require 3:1 supermajority. As > currently, no sane interpretation of the DFSG can lead to such > statements, especially for A), we would have to modify the DFSG to fit > the requirement. Because the constitution does not specify a standard for sanity or rationality. It may be *irrational* for the project to claim that the GFDL with invariant sections meets the DFSG's requirements, and the passing of such a GR might leave me with no confidence whatsoever in the judgement of this project, but neither of those is grounds for imposing a 3:1 supermajority requirement. Indeed, if 50% of voting developers are sufficiently out of their minds (or sloppy in the exercise of their duty) that they'll vote for a ballot option that contradicts reality, keeping them from winning this particular GR isn't very comforting at all... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 10:11:29AM +0200, Fabian Fagerholm wrote: > On Mon, 2006-01-23 at 17:39 -0600, Peter Samuelson wrote: > > I think everyone is forgetting this one (IMHO pretty reasonable) > > option: > > - Works licensed under the terms of the GNU FDL but with no > > invariant-foo comply (or may comply) with the DFSG, but we still > > refuse to distribute them, because of the significant practical > > problems that this would cause both for us and for our users. > A valid point, but at least the three problems you list don't seem > sufficiently problematic. > > The notable practical problems I'm alluding to would include: > > - All Debian mirrors must retain source packages one year after the > > corresponding binary packages are deleted > This is hardly impossible, or even difficult. We still retain sources > for Woody, released in 2002. Yes, and under this license we would still have to keep those sources around for a year *after* we stop distributing woody in binary form. And provide for backups & network reliability, since losing our copy would leave us in violation of the license. Given that archive space has been a big issue for us over the past year, I don't see how you can assume this is "trivial". > > - Debian CD vendors must either ship source CDs to all customers > > regardless of whether a customer wants them, or maintain their own > > download mirrors. > I don't see how GNU FDL, section 3, paragraph 3, amounts to CD vendors > having to maintain their own mirrors. If Debian already retains source > for a year, then "reasonably prudent steps" on their part would be to > point the customer to the Debian mirror network and cease distribution > when Debian does so. Wow, you think it's "prudent" to rely on an external organization with whom you do not have a contract for your compliance with a license? Most businesses would *not*, and I doubt most judges would either. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 10:05:12AM +0100, David N. Welton wrote: > Steve Langasek wrote: > > Wow, you think it's "prudent" to rely on an external organization with whom > > you do not have a contract for your compliance with a license? Most > > businesses would *not*, and I doubt most judges would either. > Aren't those same organizations relying on us to, say, not attempt to > distribute Oracle as a .deb in main? Are you telling me you don't see any difference between trusting Debian to fulfill *our* obligations under copyright law and relying on us for the fulfillment of *their* obligations? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 10:09:53PM +0200, Anton Zinoviev wrote:
> On Tue, Jan 24, 2006 at 04:27:25PM +0200, Kalle Kivimaa wrote:
> > So you agree that using permission bits is obstructing the reading, as
> > defined in the GFDL?
> > >From WordNet (r) 2.0 [wn]:
> > obstruct
> >v 1: hinder or prevent the progress or accomplishment of; "His
> > brother blocked him at every turn" [syn: {blockade}, {block},
> > {hinder}, {stymie}, {stymy}, {embarrass}]
> The following is my reasoning (and similar for "control").
> "Progress or accomplishment" means that the process that is being
> hindered or prevented has already started. Hence you can not
> "obstruct the reading" if the process of reading has not started yet.
> When the permission bit for reading is not set then the reading can
> not start.
You must be an aspiring lawyer, because this attempt to twist common English
words is stupid. That, or you need to look up the meaning of "prevent" as
well; sorry, I'm having a hard time guessing whether there's a language
barrier here, or you're being deliberately perverse. Your argument is
equivalent to saying that since the police failed to stop you, there was no
arrest, and therefore you were not resisting arrest.
There's also a nice charge called "obstruction of justice", btw, for which
shouting "TANJ" at the judge is not a defense...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 31, 2006 at 10:10:11AM +1100, Craig Sanders wrote: > On Mon, Jan 30, 2006 at 04:12:09PM +0100, Wouter Verhelst wrote: > > On Tue, Jan 31, 2006 at 01:34:45AM +1100, Craig Sanders wrote: > > > On Mon, Jan 30, 2006 at 01:08:36PM +0100, Wouter Verhelst wrote: > > > > I'm willing to debate whatever you want to debate about the GFDL, but > > > > not with insults and shouting. > > > no, the truth is, you're not. you're blinkered and inflexible and > > > determined to twist every little thing until anyone reasonable just > > > gives up. > > That's simply not true. > > You may have discussed this with other people in the past, but not with > > me. You have sent me all of two mails that were full of insult, none of > > which contained anything which could pursuade me into buying your > > argument. > you'll have to excuse me if i see all you faceless drones who parrot the > exact same mindless lies as interchangeable Zealot Propaganda Units. > with one of you, as with all, there's no point in engaging in debate or > any kind of civilised discourse. no, the truth is, you're blinkered and inflexible and determined to twist every little thing until anyone reasonable just gives up. it's really not worth the bother of "debating" with extremist nutcases, you just go around and around in circles over the same ground. and you can't win. no matter what points you make, you jerks will just ignore them and THEN CONTINUE WITH THE SAME OLD LIES, NO MATTER HOW OFTEN OR HOW RECENTLY THEY HAVE BEEN DISCREDITED. and when that isn't working, or perhaps just for variety, you lot throw in all sorts of stupid non-sequitirs and tangents to distract and side-track any argument so that it gets bogged down in irrelevancies. for months. or years. and again and again and again.[1] -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ [1] http://lists.debian.org/debian-vote/2006/01/msg00316.html for those playing along at home and not catching the irony signature.asc Description: Digital signature
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 31, 2006 at 01:31:30PM +1100, Craig Sanders wrote: > On Mon, Jan 30, 2006 at 06:13:14PM -0800, Steve Langasek wrote: > > no, the truth is, you're blinkered and inflexible and determined to > > twist [...] > how long did it take to train you? can you do other tricks? Yes, I can also organize bug-squashing parties, work with the ftp and QA teams to ensure obsolete packages are removed from the archive, do NMUs in order to fix bugs in others packages, and propose release schedules. And what is it that you do for Debian again? Defender of the faith and arbiter of orthodoxy, was it, whose reasoning is so self-evident that it needs no defense but always justifies being an asshole to your fellow developers? Oh, oops, I've gone off script. I mean... "chicken butt." -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Anton's amendment
On Wed, Feb 01, 2006 at 08:09:15PM +1100, Craig Sanders wrote: > > Specifically, I am looking at the SC: > > >> 1. Debian will remain 100% free > > > > And the DFSG: > > >> The license must allow modifications and derived works, and must > > >> allow them to be distributed under the same terms as the license > > >> of the original software. > > > > We would need to change the must allow modifications bit, as I > > see it -- since a license attached to a work must allow modifications > > to the work, as it is currently stated. (I do not consider the > > license to be part of the work). > no, it's not necessary to change anything. > DFSG patch clause. > read it. > explains all. > restricting modifications to original + patch only is explicitly > permitted. Restricting *source* modifications to original + patch is explicitly permitted; this compromise was allowed because it was understood that it still allowed us to put anything we want to in the *binary* packages generated from this patched source, and is therefore not a substantial restriction on our and others' ability to do what we want to with that software. The question of whether an integrity of author's work exception should be extended to binary packages in the case of documentation has never been voted on by Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Anton's amendment
On Wed, Feb 01, 2006 at 11:33:49PM +0200, Anton Zinoviev wrote: > On Wed, Feb 01, 2006 at 03:28:30PM -0300, Daniel Ruoso wrote: > > 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... > I understand you point but I really belive that it is impossible to > think out better examples than the examples you already gave. I am > positive that if it is at all possible to think out interesting > example for a task that can not be solved because of the features of > GFDL then the same task could not be solved with some other license > that we already accept as free. Which license and which task, please? Not just handwaving. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Anton's amendment
On Wed, Feb 01, 2006 at 12:24:34PM -0800, Russ Allbery wrote: > > If we had the right to remove the GNU Manifesto, the Free Software > > Movement would slowly lose its influence. People, especially young > > people, tend to forget how this started and what ideals the movement > > follows and why they are important. > This is a stock RMS talking point that many of the rest of us don't agree > with, including some of us who are fairly political about free software > (not everyone in Debian is). I think he's being far, far too paranoid, > and I doubt that the GNU Manifesto in the manuals is anywhere near the > most effective way that he has of reaching people. In fact, I'm fairly > sure that his current policy is actually counter-productive, since this > inexplicable support of (IMO) badly worded, non-free licenses drives away > people like me who are otherwise members and supporters of the FSF and who > would otherwise be lauding the FSF through word of mouth. And I guarantee > you that, at least *now*, far more people learn about the origins of free > software and the importance of those ideals through word of mouth than > some appendix to some manual that few people read cover-to-cover. As a data point, I think I've only ever read the GNU manifesto on the FSF website, not in any of their manuals. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Anton's amendment
On Wed, Feb 01, 2006 at 07:29:51PM +, Stephen Gran wrote: > This one time, at band camp, Thomas Bushnell BSG said: > > Stephen Gran <[EMAIL PROTECTED]> writes: > > >> So, would you regard a license which permitted the modification of > > >> some features of a program, but not others, to be free? I would > > >> not. > > > In 1997, at the time of the writing of the DFSG, the BSD clause > > > contained the obnoxious advertising clause. Yet it still made the > > > list of 'licenses we consider free'. Is the advertising clause > > > substantially different from an invariant section in intent? > > I can't see any case in which the advertising clause restricts a > > modification of the program. Can you? (Note that it is a *part of > > the license*, not a part of the program.) > It does prohibit code reuse, which I think is one of the things under > discussion here. Code under this license can't be mixed with code under > the GPL, as I'm sure you're aware. Similarly one could say the GFDL > does not prohibit modification of the program, merely of *part of the > manual*. The DFSG does not say that permission to modify can be limited to programs. The Social Contract has been amended to say that all works we distribute in Debian need to be held to the same standard. By what standard should it be ok to distribute manuals that we can't modify to taste? Combining works is a separate issue; there are plenty of mutually-incompatible licenses in Debian, but each of those licenses individually permits you to make modifications to the affected works. Advertising clauses are a separate issue; they are not a restriction on modification of the code, only a restriction on certain types of supplementary speech (i.e., advertising). You may say that there are some parallels between these issues, but I don't think that's a good reason to expand the set of restrictions that we're willing to consider free, which is effectively what all license debates on debian-legal amount to. Of course the fact that documentation with invariant sections has been in the archive for years, apparently below the radar, makes it more difficult for us as a community to sort out whether this is a "new" restriction -- even though most individuals probably do have an opinion on the question... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Anton's amendment
On Thu, Feb 02, 2006 at 06:22:41PM +1100, Craig Sanders wrote: > and, in any case, we're only talking about SECONDARY sections here, not > about the primary topic(s) of the work - ancillary comments, copyright > and credit notices, political rants, and so on. whether you agree with > what the invariant section is saying or not, you don't have the right to > put other words in the author's mouths. if you disagree with them and > feel strongly enough about it, then leave their words alone and add your > own. Neither removing political rants, nor editing them *with proper amendment of the attribution*, constitutes putting "other words in the author's mouths" [sic]. Kindly put your inflatable strawman back in the closet. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: A clarification for my interpretation of GFDL [was: Anton's amendment]
On Fri, Feb 03, 2006 at 11:38:21AM +0200, Anton Zinoviev wrote: > On Fri, Feb 03, 2006 at 04:31:18AM +, MJ Ray wrote: > > The current opinion of FSF, at least. > I know the policies of FSF well enough to be confident that this is > not just "current opinion". This has always been the opinion of FSF. > > In the past, RMS has worked against advertising clauses far less > > obnoxious than the FDL ones. You could summarise what's happening > > today with http://www.gnu.org/philosophy/bsd.html and doing > > s/BSD/FDL/g; s/sentence/chapter/g; s/system/manual/g; s/University > > of California/GNU Manifesto/g and similar > In 2003 Stallman tried to explain in debian-legal the difference > between invariant sections and the advertising clause. > If you use a software with advertising clause then you are obliged to > say some fixed sentence whenever you are mentioning some features of > that software. If you write completely independant program and it > mentions these "features" your program has to display this fixed > sentence. If you are writing some documentation that mentions these > "features" you also have to add the fixed sentence. False. The advertising clause is: 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. Documentation is not "advertising materials". > Think now what would happen if you use quiet a large number of programs > that are licensed in this way. I think I do use quite a large number of programs that are (or were) licensed in this way, but I'm not in the habit of advertising products using them in such a way that I have to sprinkle such acknowledgements around. Obnoxious though it is, the BSD advertising clause is much more like trademarks in its effect than it is like the GFDL's invariant sections. You don't need to advertise *anything* in order to use, modify, or copy software; the advertising clause only comes into effect when you choose to advertise, in a particular way. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Anton's amendment
On Sat, Feb 04, 2006 at 01:21:12AM +0200, Yavor Doganov wrote: > At Fri, 03 Feb 2006 16:46:47 -0300, > Daniel Ruoso wrote: > > 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. > Well, it is not said explicitly, so this is an interpretation. I'm > quite certain that rephrasing is not allowed. I really don't like > dissections of licenses, This doesn't exempt you from actually reading and understanding them before opening your mouth publically about them. The GPLv2 does *not* require you to retain existing copyright notices verbatim. > but if I write a GUI program that shows that notice moving on the status > bar (or as a background, ala "Star Wars" movie), I guess your fork must > include the same. You guess wrong. The GPLv2 does not require the notice to be retained in any particular form; just that it be "print[ed] or display[ed]" when the program is started for interactive use. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Anton's amendment
On Fri, Feb 03, 2006 at 03:10:49PM +0200, Anton Zinoviev wrote: > On Fri, Feb 03, 2006 at 12:43:35PM +, Matthew Garrett wrote: > > > The license of work 1 requires you to distribute the sources of the > > > combined work in the form original_work_1+patch_for_work_1. In the > > > same time the sources of the combined work should be distributed in > > > the form original_work_2+patch_for_work_2. > > What license do you believe work 1 to be under? Most patch clauses do > > nothing to forbid this. > I didn't mean one specific license, but the requirement of DFSG: >The license may restrict source-code from being distributed in >modified form _only_ if the license allows the distribution of >"patch files" with the source code for the purpose of modifying the >program at build time. > So the license may require the distribution as original_source+patch_file. Do I understand correctly that you are now arguing that the interpretation of the DFSG as *not* requiring permission to make arbitrary modifications by arguing that some other hypothetical license that we've never seen and never had an opportunity to decide on the freeness of as a community *also* passes a strict literal reading of the DFSG? How is this at all productive? The pervailing sentiment on debian-legal (and, TTBOMK, among the ftp team) is *not* "if there is at least one way the license passes the letter of the DFSG, it must be ok for main", so I don't see how providing your own interpretation of the DFSG that allows a hypothetical license Debian has never considered to pass the patch clause really does anything to support your thesis. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: {SPAM} Re: Anton's amendment
On Thu, Feb 02, 2006 at 03:56:45PM -0800, Russ Allbery wrote: > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > I have been thinking about this (originally brought up by > > Russ). I have also been re-reading the SC/DFSG, and the time they > > were written. I also started with the idea that the SC/DFSG are to > > be considered to be consistent, unless strong evidence exists to the > > contrary. > > So, the DFSG are what they say they are -- > > guidelines. However, some licenses were deemed by the project to be > > de-facto free, even if they do contravene some of the guidelines, > > hence explicitly naming the GPL and the bsd licenses. The naming > > them specifically removes the requirement that they meet all the > > guidelines. > Admittedly, I'm somewhat new to these parts, but I've been following this > discussion for long enough that I'm pretty uncomfortable with this > interpretation. It doesn't seem to match what other people have said > about the beginnings of the DFSG and feels contrary to the language of the > DFSG. The DFSG specifically calls those licenses *examples*, not > exceptions, which isn't the language that I'd expect to be used if this > was the case. > I'd be a lot more comfortable with an interpretation that says that > anything in the GPLv2 or four-clause BSD (the Artistic License has the > problem of not being clearly written and is hard to use for comparison > purposes) that appears to contradict the DFSG indicates that the DFSG > aren't being applied in the manner that they were intended to be applied. While I wasn't around for the drafting and approval of the DFSG, conversations I've had since then (debian-legal, etc.) suggest that it's closer to the truth that the bothersome 2c clause of GPLv2 probably wasn't even noticed by most people involved, because it's so rarely invoked. I.e., even if 2c *is* non-free, GPLv2 would still be free in the common case because most GPL works are interactive (either command-line or GUI) and don't include such announcements, so there's no requirement to include one when modifying the work. I suppose the idea of a "sometimes-DFSG-compliant" GPL isn't much more attractive, but this isn't the only clause in the GPL that's been considered borderline in the past: plenty of people think that a GPL which lacked the 3a option for source code distribution would be non-free, because of the data retention obligations imposed by 3b. Anyway, whether you consider these bits of the GPL kosher or not, I do agree with you that the DFSG shouldn't be read as treating GPL and BSD as getting special exceptions. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, Feb 09, 2006 at 12:24:09PM -0800, Thomas Bushnell BSG wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > > On Feb 09, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > >> Moreover, while I think a majority of the developers are surely > >> honorable, this is not true of everyone. Now that this is the *third* > >> time we are being asked to vote on essentially the same question, I > >> suspect that many of the proponents of the measure are simply > >> unwilling to let it drop, and will continue to pester the rest of the > >> project forever. This is not honorable behavior. > > Well, maybe the people who mislabeled the "everything is software" vote > > as an "editorial change" and deceived many other developers should have > > tought about this. > What about the second vote? How many votes do you need to lose, > before you decide that you have lost, and stop bringing it up over and > over again? Thomas, I really think your attempts to suppress use of Debian's standard resolution procedure are inappropriate. The constitution says that any K developers have the right to bring a resolution before the project for consideration. While I think there are cases where using a GR to override a decision is unwise and divisive, I don't think that a group of developers sincerely feeling that a previous vote has gone awry are one of those cases. If you think that they're *wrong* about whether these changes represent a majority opinion in the project, why spend any effort at all arguing on the mailing list? All you really need to do is cast your vote against the GR when it comes to vote. OTOH, maybe you don't think they're a vocal minority; maybe you think that they're genuinely a majority, or that their arguments are winning supporters. In that case, I think you would be better off arguing the issues instead. At the very least, I don't think we should be seeking to disenfranchise such a majority if it does exist. And if nothing else, letting opponents of 2004-03 bring this issue to vote on their own terms would put to rest the question of whether this vote was representative. Not that this is what we have here; *this* GR is about issuing a position statement that the GFDL is *not* acceptable to Debian, which makes it doubly inappropriate to object to developers seeking to have their views represented as an option on the ballot. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, Feb 09, 2006 at 12:16:43PM +0100, Jérôme Marant wrote: > Quoting Marco d'Itri <[EMAIL PROTECTED]>: > > > Well, maybe the people who mislabeled the "everything is software" vote > > as an "editorial change" and deceived many other developers should have > > tought about this. > > The only people it made happy are extremists. See #207932. Yes, thanks, that's a great example of how there are people on both sides of this issue that are capable of acting like children. Pass on giving it a second reading, it was nauseating enough to see it come through my mailbox the first time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Fri, Feb 10, 2006 at 08:58:23AM +1100, Hamish Moffatt wrote: > On Thu, Feb 09, 2006 at 01:49:41PM +0100, Simon Richter wrote: > > The binutils package generates part of its documentation from header > > files in order to get the structures and constants right. The headers > > are GPLed, the compiled documentation is under the GFDL. For this > > relicensing to happen, one must be the copyright holder, or have an > > appropriate license, which after a quick glance does not seem to be > > there. Thus, only the FSF may build the binutils package. I'd be very > > surprised if that were to meet your definition of free software. > Isn't it obviously the copyright holder's intention that you be able to > build the software, including the automatic relicensing? Isn't there an > implicit grant of permission? No. What good is an implicit grant of permission under copyright law? It's probably not an intended effect, but that doesn't mean it couldn't be exploited to harm us if we leave it unaddressed. (Not necessarily by the current FSF regime, but copyrights can be transferred, yadda yadda.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: GFDL GR, vote please!
On Thu, Feb 09, 2006 at 11:16:45PM +0200, Anton Zinoviev wrote: > On Thu, Feb 09, 2006 at 09:45:43PM +1000, Anthony Towns wrote: > > [ ] Choice 3: GFDL is DFSG-free and suitable for main in all cases [3:1] > I need to correct this. The title for my proposal is > [ ] Choice 3: GFDL is compatible with the current DFSG > First, the whole text of my proposal talks entirely about the current > DFSG. > Second, my proposal doesn't revoke automatically the decision of the > release team to remove the GFDL-documents from main. If my proposal > wins, it is the release team who will have to change this decision Frankly, I have no idea what the release team is expected to do in this circumstance. In spite of the Project Secretary's determination that this ballot option requires a 3:1 supermajority because it modifies the DFSG, given that I can't reconcile these claims that the GFDL always complies with the DFSG with any (IMHO) reasonable reading of the DFSG themselves, I am left without a suitable consistent interpretation that I can apply in the exercise of my own duties. I guess I could: - ignore that the Project seems to have gone insane and issued a position statement that I can't grok, and continue treating GFDL works as RC for etch - ignore the Project Secretary's interpretation that this amendment implicitly modifies the DFSG, and continue treating GFDL works as RC for etch - accept that I don't understand how the Project as a whole interprets the DFSG, and defer to either the Technical Committee or the FTP Team regarding the RC-ness of all licensing bugs - start a new GR - resign and let somebody else deal with it - have an existential crisis Of course, 1 and 2 are pretty monomaniacal options and likely to piss off anyone who voted for the GR, eventually leading me to 5 or 6; 3 sounds pretty unsustainable, and likely to lead directly to 6 and then to 5 anyway over my inability to understand how people think; and 4 is a bunch of crap work that I really have no desire to do because it's a ridiculous side show to the work of actually building a free operating system... so might result in me defaulting to 5. The ambiguity of this ballot option, both in not actually proposing text modifications to the DFSG proper and in advancing a partial, one-off interpretation of the DFSG which does not provide any real guidance on the question of what limits on modification *are* acceptable to Debian, are IMHO a serious problem. Not only will I be voting this option below "None of the above" (which, apparently unlike Anthony[1], I believe to be the normal and proper thing to do with a ballot option I consider unacceptable even if I don't really want to *discuss* it further), I will be fervently hoping that this option doesn't win. Of course, if people actually believe that this ballot option is *true*, they should naturally still vote for it -- I just have no idea what it means for someone to believe it's true, and would much prefer a ballot option that advanced a consistent interpretation of the DFSG. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ [1] http://lists.debian.org/debian-vote/2006/02/msg00415.html signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Fri, Feb 10, 2006 at 09:02:01AM +0100, Jérôme Marant wrote: > Quoting Steve Langasek <[EMAIL PROTECTED]>: > > On Thu, Feb 09, 2006 at 12:16:43PM +0100, Jérôme Marant wrote: > > > Quoting Marco d'Itri <[EMAIL PROTECTED]>: > > > > Well, maybe the people who mislabeled the "everything is software" vote > > > > as an "editorial change" and deceived many other developers should have > > > > tought about this. > > > The only people it made happy are extremists. See #207932. > > Yes, thanks, that's a great example of how there are people on both sides of > > this issue that are capable of acting like children. > > Pass on giving it a second reading, it was nauseating enough to see it come > > through my mailbox the first time. > I'm glad you enjoyed. It was a great fun. But, you know, since I'm not > subscribed to -legal, I had to find another way. There was a choice between > simply closing the silly bug, or playing a bit with extremists for free (as > beer!!!) Yeah, um, if you had closed the bug, I would have reopened it immediately. Unless you persuade the release managers that the GFDL complies with the DFSG, amend the DFSG so that it *does* comply, or invoke the technical committee, this is a release-critical issue for etch as listed on <http://release.debian.org/etch_rc_policy.txt>; playing BTS tennis isn't going to make that go away. I'm sorry, but whether something is a release-critical bug is just not your decision to make personally. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: GFDL GR, vote please!
On Fri, Feb 10, 2006 at 12:43:30PM +0200, Anton Zinoviev wrote: > On Fri, Feb 10, 2006 at 06:59:04PM +1000, Anthony Towns wrote: > > On Fri, Feb 10, 2006 at 12:22:12AM -0800, Steve Langasek wrote: > > > In spite of the Project Secretary's determination that this ballot > > > option requires a 3:1 supermajority because it modifies the DFSG, > > > given that I can't reconcile these claims that the GFDL always > > > complies with the DFSG with any (IMHO) reasonable reading of the > > > DFSG themselves, I am left without a suitable consistent > > > interpretation that I can apply in the exercise of my own duties. > > The interpretation being proposed seems to be "the DFSG allows certain > > restrictions on modifications, including the GPL's interactivity > > notification stuff and the GFDL's unmodifiable sections, with others > > potentially to be determined later". That seems reasonably easy to apply: > > deal with the existing ones as is, and assume there'll be another vote > > in future should any more come up. > The interpretation that I hold is the following: >The license must give us permissions to modify the work in > order to adapt it to various needs or to improve it, with no > substantive limits on the nature of these changes, but there > can be superficial requirements on how they are packaged. > However this interpretation is not part of my proposal. My proposal > invalidates some possible interpretations of DFSG but it doesn't state > which interpretation is the correct one. Which is for me a big problem, given that mine is one of those interpretations that's invalidated -- and, according to my reading, so is *yours*, since being unable to remove multiple pages of essays when borrowing a few paragraphs of text is a "substantive limit". I don't really have anything to replace it with; Anthony's interpretation is certainly pragmatic, but I find it fundamentally unsatisfying. I'd probably take it over an existential crisis, though. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Fri, Feb 10, 2006 at 11:37:59AM -0500, Raul Miller wrote: > > You can't argue that since the constitution doesn't explicitly forbid the > > Secretary to take it upon him/herself to interpret the DFSG for everyone > > else, that therefore he/she must do so, in order to discharge the > > constitutional duty of placing 3:1 supermajorities on amendments, etc. > > That's backwards. Essentially you'd be asserting that any delegate has _any > > power_ he or she deems necessary to fulfill his or her view of their own > > constitutional duties, unless explicitly forbidden, item by item, by the > > constitution. > That's not my argument. > And, likewise, you can't argue that the secretary must treat an option > as accepted when preparing the ballot. Treating controversial > general resolution proposals as if they'd already won the vote before > the vote begins would be the very abuse of power you're alluding to. So by this reasoning, is the original GR proposal not "controversial", whereas the other two amendments are? What's the key difference, if it isn't that the Project Secretary thinks one is correct and the others are not? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: GFDL GR, vote please!
On Fri, Feb 10, 2006 at 01:58:28PM +0200, Anton Zinoviev wrote: > On Fri, Feb 10, 2006 at 03:06:03AM -0800, Steve Langasek wrote: > > > > The interpretation being proposed seems to be "the DFSG allows certain > > > > restrictions on modifications, including the GPL's interactivity > > > > notification stuff and the GFDL's unmodifiable sections, with others > > > > potentially to be determined later". That seems reasonably easy to > > > > apply: > > > > deal with the existing ones as is, and assume there'll be another vote > > > > in future should any more come up. > > > The interpretation that I hold is the following: > > >The license must give us permissions to modify the work in > > > order to adapt it to various needs or to improve it, with no > > > substantive limits on the nature of these changes, but there > > > can be superficial requirements on how they are packaged. > > > However this interpretation is not part of my proposal. My proposal > > > invalidates some possible interpretations of DFSG but it doesn't state > > > which interpretation is the correct one. > > Which is for me a big problem, given that mine is one of those > > interpretations that's invalidated -- and, according to my reading, so is > > *yours*, since being unable to remove multiple pages of essays when > > borrowing a few paragraphs of text is a "substantive limit". > I think the following is an useful test. If the license forbids some > modification that is necessary in order to adapt the document to some > need, then the document is non-free. Otherwise, that is if the > license does not forbid any necessary modification, the document may > be free. Yes, I've read all your mails on the subject. I don't find them persuasive. People *have* identified ways in which the GFDL fails to meet their needs when adapting documentation, and the response has been to rationalize why these needs are not significant. Frankly, the only standards I see by which the GFDL can meet the DFSG are "the rules are different for documentation than programs", which is decisively not what the Foundation Documents currently say; or "it's free because it's from the FSF", which isn't so much a principle as it is a game of follow-the-leader. Anyway my post wasn't meant to be taken as a request to sell me on your point of view; I was really hoping it would prompt you to clarify your proposal to spell out what standards we should be using for judging DFSG-compliance, instead of just legislating a conclusion that I (and plenty of others) disagree with. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
questions for all candidates
The campaign period is open according to <http://www.debian.org/vote/2006/vote_002>, so here are two questions for all of the candidates. 1. The past two years have seen higher numbers of candidates standing for DPL than in the past. While our voting system has no problem scaling to seven candidates, comments I've heard from a number of developers suggest that a high number of candidates makes it more difficult for voters to navigate the ballot and cast informed votes. I'm sure when platforms are posted you'll tell us why each of you believes that you personally should run, but what do you think about having seven candidates in this election? Is it a healthy thing that we have so many developers willing to sit in the hot seat, or is it a sign of fragmentation in the project and a lack of strong leadership? 2. If you are elected, do you currently think you would be interested in running for re-election next year? Why or why not? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: GFDL position statement ballot invalid
On Tue, Feb 28, 2006 at 04:35:27PM +0200, Kalle Kivimaa wrote: > On a related topic, should the constitution define that overriding a > decision by the secretary conserning 7.1.3 requires a 3:1 > supermajority? Currently it is entirely possible for a simple majority > of the developers to bypass the constitution. The project secretary is not a DPL delegate. I don't see anything in the constitution that allows the developers to override a decision of the project secretary directly. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Questions for all candidates: role models
Questions for all candidates: If elected, you will be the ninth Project Leader in Debian's history. Of the preceding eight DPLs, which one do you admire most as a leader and why? Candidate platforms always tend to focus on what's wrong with the project; this is somewhat natural, since if you don't believe anything's wrong, you're not likely to go to the trouble. My question is: what will you do to inspire your fellow developers to greatness in the year to come? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Question for Bill Allombert: independence
Hi Bill, You write in your platform that -- I am independent, so I will be able to represent all the developers. What is it that you're independent from that other candidates aren't, and how exactly does independence help you "represent" developers? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Question for Ari Pollak: joint leadership group
Hi Ari, Why haven't you gotten Zeke neutered yet? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Reflections about the questions for the candidates
On Sun, Mar 05, 2006 at 09:49:29AM +0100, Thijs Kinkhorst wrote: > Hello Enrico, > > But there's more than that. In the last year as part of the DPL Team, > > people have been criticising the last year for the lack of reports. But > > I don't remember a single one sending in a mail like "Dear DPL[-Team], > > what happened last week?". > > It would have been a pleasure to answer such a question with something > > like "Hi, thanks for asking. It was mainly reasoning about the Security > > Team, plus approving expenditure of $300 for flying person X to > > conference Y". > If that would have been a pleasure, I'm wondering why your team did not do > that. > I've sent just a couple of mails to leader in the past term, less than a > handfull. Of those, I have received exactly zero replies from the DPL, you > or the rest of the team. Uh, for one thing, "[EMAIL PROTECTED]" != "DPL Team". It was Branden's decision to not auto-forward the leader address to the DPL team, so that anyone could feel comfortable contacting leader@ about confidential matters; the flipside is that responsiveness to that address was definitely contingent on Branden's personal availability. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Question for Bill Allombert: independence
On Tue, Mar 07, 2006 at 01:01:36AM +0100, Bill Allombert wrote: > On Wed, Mar 01, 2006 at 11:45:35PM -0800, Steve Langasek wrote: > > Hi Bill, > > You write in your platform that > > -- I am independent, so I will be able to represent all the developers. > > What is it that you're independent from that other candidates aren't, and > > how exactly does independence help you "represent" developers? > There are about one thousand Debian developers and we are a very diverse > community. If your work in Debian is too focused on one aspect you will > not be able to see the point of view of the others developers. It is > important the DPL has a large view to balance the interest of every one. I'm sorry, I don't feel that you've answered my question. In your platform, you've specifically claimed that your "independence" is a reason developers should vote for *you*, i.e., instead of the other candidates. I want to know what you think makes the other candidates less "independent" than you are -- are they accountable to someone other than the Debian Project? The only reading of this comment that makes sense to me is that you're saying the other candidates are going to be biased because of allegiances they've developed through working on Debian. I guess that's possible, but I don't think the absence of such allegiances is /independence/, I think it's /uninvolvement/, so I'd like to understand what you think these biases are that the other candidates will be unable to overcome, and why you think you'll be more free of such biases than they will. FWIW, I do appreciate your holistic approach to upgrade testing, and think it contributed positively to the quality of the sarge release. Perhaps this is part of what you mean by independence, i.e., taking a big-picture approach as opposed to being focused on one's own personal packages? But again, I see many of the other candidates as also having worked on big-picture stuff in Debian, and think they're capable of doing so as DPL as well. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Question to all candidates about stable point releases
[M-F-T set appropriately] On Wed, Mar 08, 2006 at 12:18:32AM +0100, Marc 'HE' Brockschmidt wrote: > Anthony Towns writes: > > On Sat, Mar 04, 2006 at 01:02:20PM +0100, Marc 'HE' Brockschmidt wrote: > >> Though Martin 'Joey' Schulze as stable release manager presents lists of > >> packages that are accepted into the next stable point release on a > >> regular basis, they normally are not released "roughly two months after > >> the last update" (which is the official plan). > >> Do you know why this doesn't work as planned? What would you do to > >> make regular point releases possible? > > I think the first thing to note is that irregular point releases aren't > > a big deal -- since they are almost solely security updates that are > > already available via security.debian.org, and TTBOMK there haven't > > been any installer updates to either woody or sarge. > They're not really important as technical upgrade, but they give the > impression that Debian releases something - after our last painful > release cycle, many people have decided not to use Debian because of our > (seemingly) slow development. Stable point releases are a nice touch to > get a bit of trust back. Huh? We had point releases on a more or less regular basis throughout sarge's release cycle. Why would the existence of sarge point releases inspire confidence in our release cycle? Why *should* it inspire confidence? The two processes are almost entirely unconnected. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Question to all candidates about stable point releases
On Wed, Mar 08, 2006 at 08:19:19AM +0100, Marc Haber wrote: > On Wed, Mar 08, 2006 at 02:12:16AM +1000, Anthony Towns wrote: > > On Tue, Mar 07, 2006 at 04:59:30PM +0100, Marc Haber wrote: > > > > On Tue, Mar 07, 2006 at 04:10:29PM +0100, Marc Haber wrote: > > > > > > Feb 6th, Joey mails indicating he'd like to release the update > > > > > > at the end of Feb (27th/28th) or a little bit later at > > > > > > the end of February. "let me know if this is ok for > > > > > > you - or if this is not ok for you" > > > > > I note that it took you 16 days to reply, > > > > It wasn't a reply to Joey's mail, which I hadn't thought had needed a > > > > reply. > > > . You have even _QUOTED_ the direct question asked by Joey. > > > Will you think questions as "not needing a reply" as a DPL as well? > > Like I said, I didn't think it needed a reply. > Am I the only one who sees this as a misconception of epic proportions? Living in a world where one unanswered mail is "epic" must be very exciting for you. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Question for all candidates: handle debian-admin more openly
On Thu, Mar 09, 2006 at 01:03:47PM +0100, Sven Luther wrote: > > Are bruckner and voltaire overloaded or do they lack services the developers > > need? > The release team has called for a multi-arch implementation to support > powerpc64 userland over the biarch situation. This calls for a machine capable > of building *and running* powerpc 64 code, which is not the case of existing > powerpc 32bit machines. Er, the demand for powerpc64 userland support did not come from the release team; and the problems with building powerpc64 binary packages on a powerpc system aren't specific to multiarch (obviously -- since multiarch hasn't actually happened yet, and we've been having problems building glibc on voltaire since last year). Multiarch just happens to be (IMHO) the best technical approach to building extra packages for targets such as ppc64. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: question for all candidates
On Fri, Mar 10, 2006 at 10:26:47PM +0100, Andreas Schuldei wrote: > > > At that time I emphazised several times that replacing the teams > > > was only the very last, desperate option, which we were trying to > > > avoid but for completeness sake had considered along with a > > > variety of less drastical ones. > > No. Making somebody a constitutional delegate does precisely one thing - > > it gives the DPL the power to fire someone. > The great majority of people I talked with considered the core > teams delegates already. > I would not think that delegates in Debian need to live with the > fear of being fired. It never happend before. Leaders are happy > if there are people who do the work. The idea of delegating to > someone in order to fire him is novel in itself and was certainly > not on our mind. > I would like to know if anyone else besides you ever got that > idea. Er, I raised this exact objection when these "clarification" delegations were being discussed. It was clear from the context, and from what *roles* people were looking to have delegated, that this was an attempt to exercise control over certain "problematic" teams: even though the release team occupies the same ambiguous status in Debian of never having been a formal DPL delegation, all of the focus was on delegating teams like the security team because there's a public perception that the release team works well and that the security team doesn't. And since the only real control delegation gives is the power of the DPL to dismiss the delegate, it's not a stretch for someone to think that making someone a delegate in an area they're already responsible for means you *want* to fire them. I cautioned that delegation was only relevant to improving the functioning of these teams if the plan was to replace the current team members. Ultimately, though, it seems we in fact *don't* want to fire these teams, since this GR didn't come to pass. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Question for all candidates: handle debian-admin more openly
On Fri, Mar 10, 2006 at 11:20:47PM +0100, Martin Schulze wrote: > Such requests and requirements change the situation. However, I have > to admit that I first read about this particular requirement here. I > noticed some babbling about ppc64, sparc64, mips64 and s390x > architectures but nothing that ended up in "will be included in the > archive, hence, requres buildd and development machines". > If this has changed, most probably debian-admin won't deny two > machines for these purposes. > -- > Question to the release and archive people: Is there such a > requirement? Will such architectures indeed be included the archive? > Do we really need machines of the particular 64 bit architectures? If > so for which architectures exactly? > -- No decision has been made about including such partial architectures in the archive yet. I think it's the logical way to go once multiarch matures, but it hasn't really been discussed in-depth. The need for autobuilders capable of running binaries of these types exists whether or not we implement multiarch, though, because we already have sparc, powerpc, i386, and s390 library packages in the archive providing 64-bit variants for these architectures; having 32-bit autobuilders stumble over security builds of glibc would be a bad thing. But this may have been largely mitigated in the meantime by some changes to dpkg-dev (dpkg-shlibdeps) that eliminate the dependency on ldd. If the existing lib packages can be autobuilt, I don't see any need to rush additional 64-bit autobuilders, since I think the current biarch approach to libraries is pretty lousy and shouldn't be expanded given that multiarch is on the horizon. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Reply to Fabian Fagerholm from Ted (Re: Questions for all candidates: the DPL as a creator of public opinion)
On Sun, Mar 12, 2006 at 01:01:16PM -0800, Ted Walther wrote: > Debian "feels" less libertarian now than it did eight years ago. Back > in the day, it was unheard of for Debian Developers to be banished from > Debian's mailing lists and official IRC channels just because of a > personals political, social, or religious viewpoint. These things have > been happening more and more frequently, leading to a perception of > creeping authoritarianism. Since to the best of my knowledge it is *still* unheard of for developers to be banished from mailing lists or IRC channels because of *viewpoints*, I can only assume you're referring here to your own banning from debian-women@lists.debian.org by the listmasters, and from #debian-devel on irc.freenode.net by me. Neither of these bans were a result of your viewpoint; they were a result of your disruptive, off-topic and inflammatory *speech*: e.g., <http://lists.debian.org/debian-women/2004/07/msg00217.html>, <http://lists.debian.org/debian-women/2004/07/msg00239.html>. In the case of #debian-devel, you were banned from speaking on the channel as a result of your attempts to make the religious beliefs of other channel participants a topic of discussion, in spite of repeated indications to you that this was unwelcome. When I removed this channel ban, it was because you indicated your understanding and consent that further attempts to troll channel participants about their religious beliefs would be grounds for another ban. Since then, you've been a participant in the channel for quite some time without incident. Should I be considering this mailing list post of yours a retraction? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Question for all candidates: handle debian-admin more openly
[redirecting to -devel where this belongs] On Mon, Mar 13, 2006 at 12:11:59PM +0100, Martin Schulze wrote: > > > -- > > > Question to the release and archive people: Is there such a > > > requirement? Will such architectures indeed be included the archive? > > > Do we really need machines of the particular 64 bit architectures? If > > > so for which architectures exactly? > > > -- > > No decision has been made about including such partial architectures in the > > archive yet. I think it's the logical way to go once multiarch matures, but > > it hasn't really been discussed in-depth. The need for autobuilders capable > > of running binaries of these types exists whether or not we implement > > multiarch, though, because we already have sparc, powerpc, i386, and s390 > > library packages in the archive providing 64-bit variants for these > > architectures; having 32-bit autobuilders stumble over security builds of > > glibc would be a bad thing. > Glibc in woody can by autobuilt. > Glibc in sarge can by autobuilt. > Glibc in etch can most probably by autobuilt. For a while, it was *not* possible to autobuild glibc for etch on i386 and powerpc. As I said, I think that's been fixed now. > Which security updates are you talking about? The ones for etch. > > But this may have been largely mitigated in the meantime by some changes to > > dpkg-dev (dpkg-shlibdeps) that eliminate the dependency on ldd. If the > > existing lib packages can be autobuilt, I don't see any need to rush > > additional 64-bit autobuilders, since I think the current biarch approach to > > libraries is pretty lousy and shouldn't be expanded given that multiarch is > > on the horizon. > So the conclusion is that we currently don't need these machines. > Please correct me if I'm wrong. There is no release-critical need for them. I think it would be nice if the project had a 64-bit ppc porter machine, though, so that maintainers/NMUers of such 64-bit lib packages could test and debug when necessary. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Question for candidate Schuldei
On Fri, Mar 17, 2006 at 02:59:49AM +0200, Daniel Stone wrote: > #dplteam2006: > < stockholm> - the littel oppinon poll that i did (asking ~30-40 people) > was totally overwealming: everyone but mjg would have been > in favour [of the proposed GR to force people into > DSA/security/ftpmaster -daniels] and could not really > believ that the ftp-masters/DSA would honestly say that > they could not be delegated > < Maulkin> stockholm: Not true. > < Maulkin> I didn't say that. > < vorlon> stockholm: er, was I part of your opinion poll? > < stockholm> vorlon: no, you werent > Andreas, > If you lie and seek to misrepresent the truth, to your own DPL team, why > do you expect to be trusted with the entire Project? Additionally, do > you believe that a DPL team can be effective and successful if they are > provided with incorrect information? Could you explain why the last two lines quoted are relevant to your question? They don't look particularly relevant to me. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Question for the DPL Teams
Apologies for not getting to this in the campaign period; since I'm not standing for DPL, I'm going to assume it's still kosher for me to answer now. On Wed, Mar 15, 2006 at 05:22:52PM +1000, Anthony Towns wrote: > So this is for the members of the various DPL teams. > (1) Did you join the (proposed) DPL team as an endorsement of the > candidate or the team concept, or because it seemed the best opportunity > for you to assist Debian in the event that candidate was elected? I was asked by both Jeroen and Andreas to serve on their DPL team if elected, and agreed because I think it's a worthwhile thing for me to do: not necessarily because I think there needs to be a designated "DPL Team" per se, but that in general I think making myself available to the DPL for advice and assistance is worthwhile. If called upon I certainly expect to make myself available in this manner to whoever's elected, whether or not they believe in a formal team structure. As such, agreeing to participate in the DPL team is not intended as an endorsement of any particular candidate. I think that if developers like the DPL Team idea and want to vote for a candidate for that reason, that's great, but I think candidates should stand and fall on their own merits rather than being propped up by the identity of their advisors. For this reason, I've consciously avoided being linked to the campaign process as much as possible, both last year and this year. > (2) Should one of the other candidates be elected, do you expect to > contribute as much as you would if your DPL team won? If not, what > contributions do you feel you wouldn't be in a position to make? What, > if anything, could the other DPL candidates or the project in general > do to encourage your contribution? I think it's a fair bet that my involvement in Debian is going to be pretty constant regardless of which candidate wins, seeing how I'm pretty much at saturation... For the most part, I think the contributions I would make within the context of project political leadership would largely depend on how much the DPL candidate in question chose to involve me. F'rinstance, you and I chat a fair deal on IRC about project matters, which I imagine would be likely to continue if you were wearing the DPL mantle. > (3) Will you all be going to debconf6 in Mexico, and can we therefore > expect you to flip a coin to see who gets Steve and Raphael for an > exciting game of five-a-side football or ultimate frisbee? Yes, but only if Manoj referees. > (4) When asked about why things didn't work last year, both Andreas [0] > and Jeroen [1] seem to have mostly pointed to Branden not doing things > that, if elected, they will. What, if anything, will you do this year > as a member of a new DPL team to provide the new DPL with more support > than Branden had? Honestly, I don't think there's going to be much proactive difference on my part. If the DPL wishes to avail himself of me, then I'll be here; but I think the role of "DPL team member" only has as much significance as the DPL assigns it. > (5) How would you rate the importance of your participation on the DPL > team compared to your other roles in Debian? Pretty low. I made it clear last year that my participation was conditional on the understanding that it was likely to be the first thing I'd cut if I found myself overcommitted. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Constitutional Amendment GR: Handling assets for the project
On Thu, Jul 20, 2006 at 08:12:54PM -0500, Manoj Srivastava wrote: > SPI and Debian are separate organisations who share some goals. Debian > is grateful for the legal support framework offered by SPI. Debian's > Developers are currently members of SPI by virtue of their status as > Developers. This paragraph was marked as unchanged in your diff, however it was actually changed below: > SPI and Debian are separate organisations who share some > goals. Debian is grateful for the legal support framework offered > by SPI. Debian's Developers are eligible for contributing > membership in SPI by virtue of their status as Developers. and should be clearly marked as part of the changes. Seconded, if you approve this editorial change to the GR. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Proposal: The DFSG do not require source code for data, including firmware
e works under DFSG #2; and 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. == Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 22, 2006 at 06:19:08PM -0500, Manoj Srivastava wrote: > On Tue, 22 Aug 2006 15:18:04 -0700, Steve Langasek <[EMAIL PROTECTED]> said: > > Hi folks, Ever since the sarge release, an ongoing question has > > been: what do the DFSG require for works that are not "programs" as > > previously understood in Debian? Several rounds of general > > resolutions have now given us answers for some subclasses of > > non-program works, but debate still rages regarding one particularly > > important class: firmware for peripheral devices. > Actually, I disagree What point are you disagreeing with? That there is debate about firmware in Debian? That the previous common understanding of "programs" in Debian did not include firmware? If it's the latter, I maintain that this is precisely the subject matter of the proposed GR; we obviously *don't* have agreement in Debian over what should or should not be considered a "program", so I think that's begging the question. > and, even worse, so does the common definition of the phrase > computer program: If 55% of the voting developers in Debian don't agree with this "common" definition as pertains to the DFSG (which I doubt most laymen would agree with either where firmware is concerned), why do they need the consent of another 20% of the voters in order to proceed accordingly? > What is firmware, then? Speaking as en electrical engineer, I > would say that firmware is just compiled binary programs that are > meant to be executed by a processor (that often lives on the > mainboard) which happens not to be the contral processing unit. Yes, these are reasonable definitions of both "program" and "firmware." They're also not the ones that Debian has been operating under for most of its history; the previous version of the Social Contract said that Debian would remain 100% free software, and I don't think anyone will argue that there are programs which aren't software. So if firmware was already supposed to be covered under the DFSG, how is this reconciled with the fact that no one ever worried about firmware in Debian until the past couple of years? The two possible explanations I see are that 1) Debian simply was not reading (or following) the DFSG, 2) the definition of "program" that everyone was using was not the obvious dictionary definition. > Why is freedom of software only important for the central > processing unit, but immaterial for other processing usints? This isn't a question I can answer for you. I've never argued that software freedom isn't important for firmware, I've argued that different aspects of software freedom are of different relative importance for different classes of software, and in particular that source code is not important enough for firmware that it should be a condition for inclusion in main. > And, given the trend of multiple processing usints, and not > all of them being symmetric (the cell, for example, the central > processing unit serves as little more than a traffic cop), with > processing increadsingly off loaded to the graphics processing unit, > physics processing units, encryption processors, biometrics > processors, peripheral processing units, we should be careful about > how we define processing units for which software freedom in > unimportant/ That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? > > 4. determines that for the purposes of DFSG #2, device > >firmware shall also not be considered a program. > This would require us to amend the foundation document of the > DFSG, and define that what Debian defines as software program > is different from the common definitions of the term > In order for us to have a meaninglul foundation document, we > can't debate and use our own "special" definitions of common terms, > since the definition in turn uses words that can be "defined" in a > "special" fashion. In fact, I don't think that any document of substance written in English could be so ironclad that it would eliminate all doubts about the meaning. There are enough questions about the application of the US Constitution to keep a large system of appellate and circuit courts quite busy; not because the Constitution was badly written, but because differences of interpretation are inevitable. Debian specifies that the Project Secretary adjudicates interpretation of the Debian constitution and decides matters of procedure when voting, but there is no defined procedure for resolving questions of interpretation of the DFSG and the
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 01:12:25AM +0100, Stephen Gran wrote: > I would like to see some language to the effect that we make the > exception for firmware only in the cases of data that use the moral > equivalent of the kernel load_firmware interface, so that it's clear we > aren't talking about the sort of completely non-free things like that > adsl driver with a userspace binary library or the drivers from > sangoma's site. First of all, I'm not asking for an exception; I'm asking the project to confirm whether "programs" should be understood to include firmware. Only if the project votes this GR down would it be time to consider making exceptions (which would definitely require 3:1 majority), I think. I would welcome any suggestions about how to make the language of the resolution clearer on this point. That said, then, I'm not sure there's any value in worrying over wording to make it clear that userspace binary libraries aren't covered. AFAIK, no one is arguing that such a library isn't covered by DFSG #2 because it's not a program; it's clear to me that it is part of a program when used, and is covered by DFSG #2. If someone did try to claim it wasn't covered by DFSG #2, we would have to amend the DFSG to close whatever loophole they were using, and I don't think it's worth speculating about what that loophole would be before someone actually tries it, so I don't see any point in tying this GR to a DFSG amendment unnecessarily. OTOH, if you think people -- either Debian developers or others in the community -- will be confused into thinking this GR means closed userspace tools are also ok, then by all means please tell me where you think the ambiguities lie so that we can eliminate them. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 02:41:22PM +0200, Sven Luther wrote: > > >Si, am I silly and alone in thinking that firmware is binary > > > computer programs? Let us ask google to define: firmware: > > You are silly in pretending that the DFSG and the widely shared > > consensus among developers always intended considering them non-free > > and inappropriate for main. > The last of the three pre-sarge non-free GRs confirmed the fact that firmware > is indeed a code binary, and should have source. No, it did not. Reread the GR that passed; it says nothing about firmware or source code. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment (Was: Proposal: The DFSG do not require source code for data, including firm
On Wed, Aug 23, 2006 at 09:09:31AM +0200, Sven Luther wrote: > As i have warned you on irc, when you first asked the kernel team about this > GR, i think that the whole reasoning you propose is flawed, based on patently > wrong assumptions. > There is no way you can just decide that firmware is not code, especially as > there is overwhelming evidence in some case that it is indeed code (or > microcode as some call it), This GR doesn't use the word 'code'. > Furthermore, if you start going down this way, ignoring blatant issues like > the lack of source code for those firmware blobs, some of which are defacto > under GPL, and thus becoming fully non-distributable, and making the linux > kernel non-distributable, This is FUD. Nothing in this proposal says that we will ignore licenses when distributing firmware or any other works. > 1) We aknowledge that there are some firmware blobs which consist of actual > code running on an processor embedded in a peripheral device, or > configuration code for fpgas and such, as opposed to pure register dumps, > which need actual source code to be considered free enough to pass the DFSG. > 2) But, as the removal of those firmwares and drivers cause a major > inconvenience on the usability of the system, and > 3) Peripherals allowing for uploadable firmwares are orders of magnitude > more free than peripheral where everything is hardcoded, or peripherals > where the firmware blob is embedded on a rom or flash or similar. > 4) Upstream has long resisted considering the firmware situation, and is now > slowly setting up infrastucture to handle these cases, and removing those > firmwares from the main linux code, so the problem, will solve itself in the > future. > 5) There is no way the kernel team alone or even with help, can solve all > the legal and technical issues in a timely fashion in order to not let the > etch release slip. > 6) Given the above, and the fact that every past release of debian included > those non-free firmware blobs, the fact of delaying etch in order to solve > the issue, or releaseing etch with the non-free firmware blobs and then > working the solution, is not going to change anything with respect of the > released and development versions of debian. > 6) We thus ask the project to temporarily waive the DFSG requirement for > those non-free firmware blobs, in order to let the etch release to ship in a > timely fashion, and let us work on these issues, within the kernel and > related affected teams, the project as a whole (The DPL could mandate a > delegate or delegate team to contact manufacturers and such), but also > upstream, in a calm and posed way, not hurried by the needs of the release, > and other such pressure. > I welcome help to turn the above in a GR, as i believe that this would be a > better and more honest way to allow non-free firmware in main, in all good > concience. I would prefer it if you would strike references to "non-free" in the above and replace them with the term "sourceless", to keep the scope the same as the current GR proposal. With that change made, I would encourage you to propose the above as a formal amendment -- I would reject the amendment, of course, since it doesn't agree with my views on the matter, but I think it's a viewpoint that deserves to be represented on the ballot. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 10:30:33AM +0200, Bas Zoetekouw wrote: > You wrote: > > 3. supports the decision of the Release Team to require works such > > as > > images, video, and fonts to be licensed in compliance with the DFSG without > > requiring source code for these works under DFSG #2; and > > 4. determines that for the purposes of DFSG #2, device firmware > > shall also not be considered a program. > Would it be possible to vote on these two issues seperately? It would certainly be possible, but I don't see any value in voting on the first of these points on its own because I think the release team is already doing the right thing and doesn't need a GR to confirm it. It's only the latter point that's a question in my mind, so if someone wants to vote on the former point alone they'd need to propose their own GR. N.B., I would object to having any ballot options on the same GR that consist of this same draft with point #4 stricken, because assuming rational voters I would expect the voters who approve of that option to be a strict superset of those who approve of my proposal, and I would call on the Project Secretary to exercise his authority to keep these two proposals on separate ballots to avoid prejudicing the outcome in favor of a "watered down" option. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Hi Enrico, On Wed, Aug 23, 2006 at 09:48:18AM +0100, Enrico Zini wrote: > I second most of the proposal, however: > [...] > > THE DEBIAN PROJECT therefore, > > > > 1. reaffirms its dedication to providing a 100% free system to our > > users according to our Social Contract and the DFSG; and > > > > 2. encourages authors of all works to make those works available not > > only under licenses that permit modification, but also in forms that make > > such modifications practical; and > > > > 3. supports the decision of the Release Team to require works such > > as > > images, video, and fonts to be licensed in compliance with the DFSG without > > requiring source code for these works under DFSG #2; and > > > > 4. determines that for the purposes of DFSG #2, device firmware > > shall also not be considered a program. > I'd personally prefer the 4th point to read: > 4. determines that for the purposes of DFSG #2, device firmware > shall also not be considered a program until it will become practical > to do so. > This would make it clear that we don't pretend to make fine-line > statements on what is a program and what is not; also, it would not rule > out the vision of some of us who'd like to see source code for most > firmware as well, maybe not in etch, or etch+1, or etch+n, but possibly > in etch+n+1. As you and I discussed previously on IRC, I don't agree with this amendment. The premise of my proposal is that we are *not* granting an exception nor redefining any terms, we are merely recognizing a latent definition of "programs" that has guided Debian since its inception in spite of standing in contrast to the dictionary definition of the word. If I felt that we were actually redefining terms at this juncture, I would wholeheartedly agree with Manoj that it should be done by modifying the DFSG with a 3:1 supermajority. And it seems to me that your proposed amendment falls on the other side of this line, where you would have us define "program" to mean one thing now and something else later. It may be that this discussion will lead me to the conclusion that the distinction between "stating what our definition of 'program' is" and "redefining 'program'" is too subtle, in which case I expect that I'll go for an amendment to the DFSG instead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Hi Florian, On Wed, Aug 23, 2006 at 12:27:07PM +0200, Florian Weimer wrote: > * Steve Langasek: > > - The author's preferred form for modification may require non-free tools > > in order to be converted into its final "binary" form; e.g., some > > device firmware, videos, and graphics. > I would prefer if the term "firmware" would be defined or at least > explained in the GR. Something like: > firmware (data which is sent to attached devices for processing and > which is not, directly or indirectly, executed on the host CPU) I don't object to this. Is there agreement among the GR sponsors that this is the definition of firmware that should be used? > I'd actually see some restriction with regard to interoperability > (i.e. some reasonably documented interface between the firmware and > the driver code), but getting this right is likely not worth the > effort. Hmm, I'm not sure what that would look like at all; as someone else noted, one generally doesn't talk to the firmware even, one talks to the device. > A completely different issue is whether we take upstream's word for > GPL compability, or if we claim that something is not redistributable > because it contains a firmware blob *and* is licensed under the GPL as > a whole. Yes, I agree that this is a completely different issue. :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 02:57:54PM +0200, Martin Schulze wrote: > > 4. determines that for the purposes of DFSG #2, device firmware > > shall also not be considered a program. > I have some problems, publically saying that binary firmware blobs > that most probably contain a lot of small programs "shall also not be > considered a program" (regardless of "a" or "several"). We're not > saying Pi is 3.14 either. > We do know that there are programs included in binary firmware blobs > most of the time after all. > How about the following instead? > 4. supports the decision of the Release Team to require device > firmware > to be licensed in compliance with the DFSG without requiring source code for > possibly enclosed software. > I could imagine to say acknowledge that Debian consideres it ok to include > binary firmware blobs without their source to code to be licenced DFSG-free. a) the Release Team hasn't made such a decision, so it's not possible for the project to support it. :) Andi and I deferred making any such decision until we could have a GR to see where the project sits on the question. b) if it's the consensus view of the project that "program" does encompass firmware, then I think allowing sourceless firmware into main for etch requires overriding the DFSG, which I believe is best done with a formal amendment to the DFSG or at least a clear statement that we know we're overriding the DFSG. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 03:40:49PM +0100, Matthew Garrett wrote: > We never included non-free applications in main because we felt that > there was no need to. And, indeed, even in 1993 it was possible to use a > computer without any non-free applications. > That doesn't hold with the firmware argument. With applications, we had > the choice between "Free but less functional" and "Non-free but more > functional". With firmware we have the choice between "Non-free but on > disk" and "Non-free but in ROM". There isn't a "Free" option at all yet. > So I think the real question is "How does us refusing to ship non-free > firmware help free software?". If a user wants to use Debian, then the > obvious thing for them to do will be to buy hardware that has the > non-free firmware in ROM. Ironically, this will actually make it harder > for them to ever use free firmware! > I think it's reasonable to refuse to ship non-free code when there's > actually a choice or when it's likely to provide an incentive to > implement a free version. But right now, I don't see any evidence that > refusing to ship non-free firmware will do anything other than cost us > users without providing any extra freedom. AFAICS, there has never been a debate about whether to ship non-free firmware, only about where to ship it. If not having source for firmware makes it non-free, then it seems obvious to me that under the DFSG, it shouldn't be shipped in main. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment (Was: Proposal: The DFSG do not require source code for data, including firm
On Thu, Aug 24, 2006 at 08:58:20AM +0200, Sven Luther wrote: > > I would prefer it if you would strike references to "non-free" in the above > > and replace them with the term "sourceless", to keep the scope the same as > Well, the DFSG clearly state that programs need to have sources to be free. so > i don't really see why you are afraid to use the right word for it ? It is not the "right" word for it, it is a *different* word, which changes the scope of the resolution. The GR I've proposed does not excuse non-free firmware in general, it only states that sourceless firmware is permitted. Whether you consider sourceless firmware to be non-free or not, changing "sourceless" to "non-free" is a change of scope. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 08:30:31PM +0200, Kurt Roeckx wrote: > On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote: > > > > THE DEBIAN PROJECT therefore, > > > > 1. reaffirms its dedication to providing a 100% free system to our > > users according to our Social Contract and the DFSG; and > > > > 2. encourages authors of all works to make those works available not > > only under licenses that permit modification, but also in forms that make > > such modifications practical; and > > > > 3. supports the decision of the Release Team to require works such > > as > > images, video, and fonts to be licensed in compliance with the DFSG without > > requiring source code for these works under DFSG #2; and > > > > 4. determines that for the purposes of DFSG #2, device firmware > > shall also not be considered a program. > I'm a little confused as to what this means exactly. > Point 2 seems to say that we consider "source" to be such a form of the > work that modifications are practical, but without actually saying > anything. However, I think such a definition of source would be a good > thing. > But this point really doesn't say much about Debian, it just says we > encourage others to do something. So I don't see why this belongs in > the GR in the first place. A position statement tells the wider community, not just Debian's own developers, Debian's views on a subject. "Don't worry about source code for firmware, no one cares about it" is not a message I want to send. This clause states that we *do* care about source code for firmware: we just don't consider it worth the trade-offs to *require* such source code as a condition of inclusion in Debian. > Point 3 then seems to go the other way around and say we don't need > sources for of few types of works. My main problem with this is that > still a little vague about which types of works don't require source. What problems do you consider this vagueness to cause? What changes would you suggest to make this less vague? > I guess point 4 is saying the firmware should be considered the same as > the other works in point 3 and the source isn't needed for firmware. Correct. > However, it doesn't say anything about other points of the DFSG. Nope, nor was it my intention that it do so. > So we should still need a license that allows atleast derived works. Correct. > And I don't see how we're going to make derived works of firmware without > the source for it. That seems to be orthogonal to the licensing question, though? Anyway, the answer I had in mind was a hex editor or a decompiler. If the firmware in question *is* code, and we know what the chip in question is that the code is running on, both options seem within the realm of plausibility to me. No, of course they're not the *ideal* means of editing such a work, but AFAIK most firmware is on the order of what programmers used to program directly in assembly, so it's also not totally *insane* to try to edit such a binary directly as it would be for most modern userspace apps, for instance.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment (Was: Proposal: The DFSG do not require source code for data, including firm
On Thu, Aug 24, 2006 at 09:25:20AM +0200, Sven Luther wrote: > On Thu, Aug 24, 2006 at 12:15:40AM -0700, Steve Langasek wrote: > > On Thu, Aug 24, 2006 at 08:58:20AM +0200, Sven Luther wrote: > > > > I would prefer it if you would strike references to "non-free" in the > > > > above > > > > and replace them with the term "sourceless", to keep the scope the same > > > > as > > > Well, the DFSG clearly state that programs need to have sources to be > > > free. so > > > i don't really see why you are afraid to use the right word for it ? > > It is not the "right" word for it, it is a *different* word, which changes > > the scope of the resolution. The GR I've proposed does not excuse non-free > > firmware in general, it only states that sourceless firmware is permitted. > sourceless firmwares are non-free. By calling them sourceless instead of > non-free, you kind of excuse keeping them in main, and kind of implies that > even if they are lacking source, they still are DFSG free, which is a clear > contradiction with both our principles, common sense, and what debian has > stood for all those years and confirmed in the pre-sarge GRs. > > Whether you consider sourceless firmware to be non-free or not, changing > > "sourceless" to "non-free" is a change of scope. > Indeed, you pass from word nit-picking and duisguising the truth to saying > things squarely as they are. I see that, as usual, your very small brain doesn't afford you the luxury of having a rational discussion about this subject without resorting to insulting anyone who doesn't agree with you. My pity for your mental handicap is stretched to its limits; please find a proxy with better command of social interaction if you have anything further to say to me on this subject, because I won't be reading or replying to your posts from here on. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 10:24:58AM -0500, Manoj Srivastava wrote: > On Thu, 24 Aug 2006 01:16:42 -0700, Steve Langasek <[EMAIL PROTECTED]> said: > > A position statement tells the wider community, not just Debian's > > own developers, Debian's views on a subject. "Don't worry about > > source code for firmware, no one cares about it" is not a message I > > want to send. This clause states that we *do* care about source > > code for firmware: we just don't consider it worth the trade-offs to > > *require* such source code as a condition of inclusion in Debian. > I am afraid that this distinction was too subtle for me in the > form of the proposal as written. Suggestions for improvement are welcome. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 12:57:58PM -0600, Hubert Chan wrote: > On Wed, 23 Aug 2006 15:25:49 -0700, Steve Langasek <[EMAIL PROTECTED]> said: > > N.B., I would object to having any ballot options on the same GR that > > consist of this same draft with point #4 stricken, because assuming > > rational voters I would expect the voters who approve of that option > > to be a strict superset of those who approve of my proposal, and I > > would call on the Project Secretary to exercise his authority to keep > > these two proposals on separate ballots to avoid prejudicing the > > outcome in favor of a "watered down" option. > Maybe I don't quite understand your concern correctly, but isn't this > one of the advantages of using Condorcet? i.e. if we had points [1-3] > on the same ballot as points [1-4], even though the number of votes for > [1-3] compared to NOTA would obviously be higher than the number of > votes for [1-4] compared to NOTA, the thing that would determine whether > [1-3] wins, or [1-4], would be the ranking between those two options > (assuming both win compared to NOTA). So those who agree with point 4 > should rank [1-4] higher than [1-3] (and those who don't would obviously > rank it lower). Hence if more people agree with #4 than disagree with > it, then [1-4] should win over [1-3]. http://lists.debian.org/debian-vote/2003/10/msg00168.html This old thread describes a mechanism by which to ensure that any resolution fails by losing out to a watered-down version of itself, regardless of how much support the resolution in question enjoys among developers. Our voting mechanism is *clone*proof, preventing multiple identical ballot options from influencing the outcome; but it's not proofed against influence by toothless variants that will inevitably appeal to a broader constituency because they say less of substance. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 03:42:28PM -0700, Steve Langasek wrote: > On Thu, Aug 24, 2006 at 12:57:58PM -0600, Hubert Chan wrote: > > On Wed, 23 Aug 2006 15:25:49 -0700, Steve Langasek <[EMAIL PROTECTED]> said: > > > N.B., I would object to having any ballot options on the same GR that > > > consist of this same draft with point #4 stricken, because assuming > > > rational voters I would expect the voters who approve of that option > > > to be a strict superset of those who approve of my proposal, and I > > > would call on the Project Secretary to exercise his authority to keep > > > these two proposals on separate ballots to avoid prejudicing the > > > outcome in favor of a "watered down" option. > > Maybe I don't quite understand your concern correctly, but isn't this > > one of the advantages of using Condorcet? i.e. if we had points [1-3] > > on the same ballot as points [1-4], even though the number of votes for > > [1-3] compared to NOTA would obviously be higher than the number of > > votes for [1-4] compared to NOTA, the thing that would determine whether > > [1-3] wins, or [1-4], would be the ranking between those two options > > (assuming both win compared to NOTA). So those who agree with point 4 > > should rank [1-4] higher than [1-3] (and those who don't would obviously > > rank it lower). Hence if more people agree with #4 than disagree with > > it, then [1-4] should win over [1-3]. > http://lists.debian.org/debian-vote/2003/10/msg00168.html Sorry, let's get a more refined reference here; the thread following from that particular post is long and scary, and mostly irrelevant to this discussion. http://lists.debian.org/debian-vote/2003/11/msg00051.html http://lists.debian.org/debian-vote/2003/11/msg00066.html http://lists.debian.org/debian-vote/2003/11/msg00074.html -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 08:29:49PM +0200, Kurt Roeckx wrote: > On Thu, Aug 24, 2006 at 01:16:42AM -0700, Steve Langasek wrote: > > > Point 3 then seems to go the other way around and say we don't need > > > sources for of few types of works. My main problem with this is that > > > still a little vague about which types of works don't require source. > > What problems do you consider this vagueness to cause? What changes would > > you suggest to make this less vague? > It lists "images, video, and fonts". And I'm assume it's going to cover > more than just that. I'm also not sure that this is something we want > for all types of data. I think we *want* the best possible form for modification for all types of data. I don't think the DFSG *requires* this, and therefore I don't think *we* should require it. Do you disagree? > For instance when they're raster images or fonts, I'd rather have the > source, if there ever was a vector based format of it. But I don't care > if there never was a vector based format, so nothing that would be a > more prefered way of changing it. "Rather have" != "Insist on for inclusion in main", though? > > Anyway, the answer I had in mind was a hex editor or a decompiler. If the > > firmware in question *is* code, and we know what the chip in question is > > that the code is running on, both options seem within the realm of > > plausibility to me. No, of course they're not the *ideal* means of editing > > such a work, but AFAIK most firmware is on the order of what programmers > > used to program directly in assembly, so it's also not totally *insane* to > > try to edit such a binary directly as it would be for most modern userspace > > apps, for instance.) > I don't see a hex editor useful for much, and a decompiler only slightly > better. If a decompiled version was useful to do derived work, it > would be the same as source, so not requiring source doesn't make sense > to me. > The difference with source is that you actually have names of functions > and variables, you have comments with it. Those things make it easy to > understand what it's trying to do. So it's easier to make changes too. OTOH, the source may require a non-free tool to render it into a binary firmware form. If you don't have that tool, and maybe even no hope of getting access to it, is it any longer evident that the source is more useful than the binary for derived works? Yes, from there we get into discussions about defining "source" as "whatever form people prefer to work from" -- hmm, redefinition? -- and whether we can ship anything in main that we don't have a full toolchain for; but a) is that actually required by the DFSG, and b) is that the right standard to set, either today or in the future? > It would also be useful to have a list of firmwares we're currently are > talking about, and what license they have. Are there any that only fail > DFSG 2, or will this part of GR have no effect at all? Larry Doolittle has prepared a very helpful table at <http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html>. A number of these are marked as being under a "BSD-ish" license, which would qualify; a number of others are listed as GPL but sourceless, which nominally makes them non-distributable, but it seems unlikely that any copyright holders on these would refuse to relicense under more appropriate terms even if they weren't willing/able to release source. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 10:21:21AM -0500, Manoj Srivastava wrote: > > N.B., I would object to having any ballot options on the same GR > > that consist of this same draft with point #4 stricken, because > > assuming rational voters I would expect the voters who approve of > > that option to be a strict superset of those who approve of my > > proposal, and I would call on the Project Secretary to exercise his > > authority to keep these two proposals on separate ballots to avoid > > prejudicing the outcome in favor of a "watered down" option. > Speaking with my secretary hat on, it seems to me that options > 3 and 4 are somewhat orthogonal -- inasmuch that it appears eminently > reasonable for someone to have differing opinions on these two > options. So people may approve of 3, and disapprove of 4: and this > makes me think that they do not belong on the same ballot, since they > are unrelated wrt to voting (though obviously addressing related > areas) I agree that points 3 and 4 are potentially orthogonal, but I believe I have the right under the constitution to ask for the project to vote on a resolution that includes both of these points. If someone were to bring an amendment that eliminates point 4 while leaving the rest of the resolution intact and unchanged, those two ballot options would have orthogonal elements, and I would ask that they be treated on separate ballots so that voters have the opportunity to vote on this position statement per se without having to compete with ballot options that remove one of the axes of content. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal: Apologize for releasing etch with sourceless/non-free firmware
On Fri, Aug 25, 2006 at 07:54:59PM +0200, Mike Hommey wrote: > I'd add something to say that this is *really* the last time we postpone > the fixing of the issue and that no further GR should change that. Why? That can't possibly be binding? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Apologize for releasing etch with sourceless/non-free firmware
On Fri, Aug 25, 2006 at 04:34:44PM -0500, Manoj Srivastava wrote: > On Fri, 25 Aug 2006 13:16:28 -0700, Steve Langasek <[EMAIL PROTECTED]> said: > > On Fri, Aug 25, 2006 at 07:54:59PM +0200, Mike Hommey wrote: > >> I'd add something to say that this is *really* the last time we > >> postpone the fixing of the issue and that no further GR should > >> change that. > > Why? That can't possibly be binding? > What makes you think that? The developers, by a GR, can > preemptively take the release decision that etch + 1 would not be > released with non-free software in the kernel, and that non-dfsg bits > in main, which violate the SC, would, for once, actually be really > considered RC. > Why does this not fall under takeing decisions that the > delegates are empowered to take bit? Because it was specified that *no other GR* would change this. You can't legislate that, it's entirely up to the developers at the time to decide whether or not they pass another GR --- and a later GR would certainly supersede the earlier one. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Fri, Aug 25, 2006 at 08:04:51PM +0200, Kurt Roeckx wrote: > On Thu, Aug 24, 2006 at 05:08:33PM -0700, Steve Langasek wrote: > > On Thu, Aug 24, 2006 at 08:29:49PM +0200, Kurt Roeckx wrote: > > > On Thu, Aug 24, 2006 at 01:16:42AM -0700, Steve Langasek wrote: > > > > > Point 3 then seems to go the other way around and say we don't need > > > > > sources for of few types of works. My main problem with this is that > > > > > still a little vague about which types of works don't require source. > > > > What problems do you consider this vagueness to cause? What changes > > > > would > > > > you suggest to make this less vague? > > > It lists "images, video, and fonts". And I'm assume it's going to cover > > > more than just that. I'm also not sure that this is something we want > > > for all types of data. > > I think we *want* the best possible form for modification for all types of > > data. I don't think the DFSG *requires* this, and therefore I don't think > > *we* should require it. Do you disagree? > I think we should require it. Well, you're entitled to your opinion on that, of course. I disagree, because I don't see that the DFSG requires it, and I don't think it's worth delaying a release over (which is how I understand "require"). > The DFSG says we need the source, and I understand that as the best > possible form for modification. The DFSG says we need the source for programs. > For instance, bison/yacc generates a C file. You could consider that > C file a source, but it's not. We want the original file that was used > to generate that C file. There might be several layers of tools that > are used to generate an object file from it's source, but it's the > source we want. Presumably we're all in agreement that this is a program, though, not data... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Amendment: special exception for firmware because of technical ?limitations
On Sat, Aug 26, 2006 at 11:50:11AM +0200, Marco d'Itri wrote: > >Rationale: most of us want to release etch ASAP, and most of us want to > >remove the firmwares from the kernel ASAP. This is a way that shouldn't > This is false: most of us do not mind at all distributing sourceless > (or even not modifiable) firmwares in the kernel packages. I don't think you can legitimately claim to speak for *most* developers on this issue. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > Debian needs to make a decision on how it will deal with this legal > minefield. That is higher priority than the entire discussion going on > right now, because it determines whether Debian will distribute these 53 > BLOBs *at all*, in 'main' or in 'non-free'. > Oddly enough nobody has proposed a GR addressing this, Because voting is an absurd means of settling questions of legal liability. It's the domain of the ftp team to determine whether we can legally distribute a package on our mirrors. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote: > > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > >> Debian needs to make a decision on how it will deal with this legal > >> minefield. That is higher priority than the entire discussion going on > >> right now, because it determines whether Debian will distribute these 53 > >> BLOBs *at all*, in 'main' or in 'non-free'. > >> Oddly enough nobody has proposed a GR addressing this, > > Because voting is an absurd means of settling questions of legal > > liability. It's the domain of the ftp team to determine whether we can > > legally distribute a package on our mirrors. > Actually, letting an overworked team of four with (to my knowledge) zero > legal expertise settle questions of legal liability is pretty absurd too. They are the team responsible for vetting the legality of what's distributed on the mirrors. None of them have any legal expertise to my knowledge; but they do know where the lawyers are if they have questions, and they *are* the ones in the hot seat(s). > Should the ftpmasters, who have even less legal expertise, Judging by some of the nonsense that debian-legal is typically riddled with, if I were an ftpmaster I would find that claim insulting. The only claim to expertise that debian-legal has is in the area of analyzing license terms and how they stack up against the requirements of the DFSG. That is an important function, but it is *not* legal expertise. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Constitutional Amendment GR: Handling assets for the project
On Sat, Sep 02, 2006 at 09:01:05AM -0500, Manoj Srivastava wrote: > On Fri, 1 Sep 2006 18:22:08 +1000, Anthony Towns > said: > > On Tue, Aug 22, 2006 at 11:46:54AM -0500, Manoj Srivastava wrote: > >> Yet another draft. There are major changes in this version, so I > >> think we'll need to have people who seconded re-second the version > >> that comes out of this discussion. > > This has gone for about a week and a half without further comment, > > and has been seconded by: > > Don Armstrong > > martin f krafft > > Anthony Towns > > Adrian von Bidder > > Kalle Kivimaa Anibal > > Monsalve Salazar > > which makes it formal, afaics. Are we right to move to a vote this > > coming Tuesday? > Well, the previous draft had been seconded also by > a) Steve Langasek <[EMAIL PROTECTED]> > b) Martin Wuertele <[EMAIL PROTECTED]> > c) Ian Jackson <[EMAIL PROTECTED]> > d) "Benj. Mako Hill" <[EMAIL PROTECTED]> > e) Alexander Zangerl <[EMAIL PROTECTED]> > If any of these people have changed their minds, or ratified > the new version, I have missed those mails. Could we get some > clarification from the above, please? (As ti stands, 5 people are > enough to have the old draft be on its own on the ballot, which is > something we do not necessarily want :) I'll accept the judgement of the original proposer of the previous version that the new draft should supersede, and withdraw my sponsorship of the first proposal. I am not sponsoring the second draft at this time, as I haven't taken the time to read it thoroughly yet. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Firmware & Social Contract: GR proposal
On Thu, Sep 07, 2006 at 01:30:25AM -0700, Thomas Bushnell BSG wrote: > > On Wed, Sep 06, 2006 at 10:21:18AM -0700, Thomas Bushnell BSG wrote: > >> We could have met those expectations of the d-i and kernel teams had > >> taken the issue seriously before now. Their failure to do so does not > >> translate to an emergency on my or Debian's part. > > The failure to do this is no more the responsibility of the d-i or > > kernel teams than it is yours or mine. They are volunteers, just as you > > or I are, and they have no more responsibility to work on anything they > > choose not to do so, than you are personally responsible for ensuring > > Debian meets its commitment of providing a non-free area in its archive > > and supporting users who need the software there. > So does this work for me too? Can I go and stash non-free stuff in my > packages, and if others complain, simply raise a stink and insist that > nobody has the right to order me to remove it? Feel free, but unlike the installer and the kernel, which are both release-critical components in and of themselves, your package is likely to be removed from the release altogether if you do this. There's also something of a difference, IMHO, between dropping sourceless firmware from the kernel with the result that some users will be unable to install etch at all, and requiring that you not add arbitrary other non-free stuff to your packages that should be in non-free. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firmware & Social Contract: GR proposal
On Tue, Sep 05, 2006 at 12:32:15PM +0200, Sven Luther wrote: > > firmware that's not tied to etch's release; Joss's is temporary, tied to > > the the development of "technical measures" that will allow firmware to be > > separated; Don's isn't an exception at all, and won't allow us to release > > etch on time without a further proposal; and Frederik's is an exception > > just for etch, in the same way the last reversion was an exception just > > for sarge: one that may well be repeated next time if nothing getsdone. > Frederik's proposal is a common position from the kernel team and the release > team I am not happy that Frederik's proposal was presented this way after I specifically asked that this not be done. TTBOMK, the only members of the release team that were consulted before its publication were Andi and myself; and to the extent that I've endorsed this proposal, I was endorsing it as a suitable point of departure for further public discussion, not as an option that I was certain to rank first on any ballot. > It explicitly gives an exception for etch only, because we are confident > that the issue can be solved in the etch+1 timeframe. Who is confident of this, and why? I'm not confident of this at all; I'm not sure that the idea of forcing sourceless firmware out of main is even an idea that the majority of developers agree with, and Joey Hess has pointed out to us reasons why providing separate free/non-free install media might be a strategically poor use of our time in the *long term*, even if the work of splitting out this firmware proved manageable and there were sufficient volunteers to do this work. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firmware & Social Contract: GR proposal
On Fri, Sep 08, 2006 at 12:01:37AM -0700, Thomas Bushnell BSG wrote: > One of the people hinting at this has been Steve, who basically said > to me recently that for some packages, they would get booted from the > release for violating the DFSG, and for other packages, we just wink > and nod. > Now we have it flat out: Steve thinks perhaps we will simply never > bring the kernel packages into compliance with the DFSG. I demand that you retract this slanderous remark. It may be the case that the kernel packages are never brought into compliance with the DFSG *as currently written*, or *as you would like them to be interpreted*, but I would not be spending my time on this discussion if I didn't think it mattered to bring the kernel packages in line with the DFSG. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Withdrawn: The DFSG do not require source code for data, including firmware
Hello, Under §A.4. of the Debian standard resolution procedure, I am hereby withdrawing my proposal of August 22 (Message-ID: <[EMAIL PROTECTED]>). While I still believe that this proposal represents a reasonable position for the project to take, the discussion over the past two weeks makes it clear to me that a large enough fraction of our developership disagrees strongly with this interpretation that it's not in the best interest of the project to push forward with this proposal. There are a number of other options on the table which have the same basic aim of reconciling Debian's handling of kernel firmware with the DFSG; I would encourage the seconders of this original proposal to consider seconding one of those other options rather than stepping up to be a proposer of this withdrawn proposal. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: kernel firmwares: GR proposal
Hi Frederik, On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote: > Overview: I asked you this question before privately and haven't seen an answer. You say below "So we propose this GR:"; does that mean that everything up to that is rationale, and not part of the text that developers will be voting on? This is very unclear to me; if the intent is to vote on the whole document, I think some wording tweaks are needed. If the intent is to vote only on the part beginning with "1. We affirm [...]", then I think it's much shorter than it should be. > 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. FWIW, while I originally thought that "sourceless firmware is ok for main" and "non-free firmware stays in main for etch" should be two separate questions, after reviewing the list of kernel blobs that Larry prepared, I see that the difference between the two is very small: the only blobs currently shipping under a non-free license are for AppleTalk, token ring, and USB audio, and none of those are relevant to the installer. So if we are going to make an exception, I think we should take care to make the smallest exception necessary. If we don't *need* to grant exceptions for firmware based on their license, only on whether or not they include source, I don't think we should include such firmware in the exception. This prevents anyone from trying to add such firmware to etch that isn't already included, which would be a regression vis-à-vis freeness. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Proposal - Defer discussion about SC and firmware until after the Etch release
On Tue, Sep 12, 2006 at 01:47:18AM +0200, Frans Pop wrote: > The project acknowledges that a lot of progress has been made with regard > to the removal from the distribution (main) of "software" that could be > considered non-free given the current wording of the Social Contract. > However, in some cases for valid reasons, this work is not finished and I suggest striking the above phrase, which adds nothing of substance to the resolution. > requiring this to be finished before the release of Etch would result in a > serious delay of the planned release. > There are also indications that a significant group of people within the > project feels that the current Social Contract does not meet the best > interests of the project in that the current wording is too restrictive and > that a limited and conditional inclusion/support of some types of > "software" should be possible. Example: support for loading sourceless > firmware during installation. This paragraph seems to be speculation about the intent of other people; I think it would be better to either leave it out, or make it a statement about the voters' *own* views. > The Debian Project resolves that: > (a) The inclusion in main of sourceless firmware and support in Debian > Installer is not a release blocker for the release of Etch. > (b) For the release of Etch, the Release Managers are given discretion > to waive RC issues in other cases where the letter of the Social > Contract is currently not being met, provided there is no regression > relative to the Sarge release and that waivers are done consistently > and with proper consideration of past resolutions (e.g. GDFL) and GFDL > work already done on other (comparable) packages. > (c) Following the release of etch, the Debian Project Leader shall: > i. ensure that the Debian community has a good understanding >of the technical and legal issues that prevent the Debian >Free Software Guidelines from being applied to logos and >firmware in a manner that meets the needs of our users; > ii. ensure that project resources are made available to >people working on addressing those issues; ^^^ and > iii. keep the Debian community updated on progress achieved >in these areas. > (d) Following the release of etch, the Debian Project as a whole shall > reopen the question of which commitments should be codified in the > project's Social Contract. This shall include both an online > consultation with Debian developers, users, Debian derivatives and > the free software community, and a public in-person discussion at > DebConf 7 in Edinburgh in honour of the 10th anniversary of the > original publication of the Social Contract on the 4th of July 1997. As a release manager, I am comfortable with this proposal as a solution that lets us proceed with etch according to the schedule. Even though it doesn't amend a foundation document, I do understand it as overriding one, so would likely expect a 3:1 majority requirement for it (i.e., if it passes with a lesser majority, I'm not sure I would take that as an endorsement by the project). Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
On Mon, Sep 18, 2006 at 01:42:14PM -0500, Debian Project Secretaru wrote: > , > | THE DEBIAN PROJECT therefore, > | 1. reaffirms its dedication to providing a 100% free system to > |our users according to our Social Contract and the DFSG; and > | 2. encourages authors of all works to make those works > |available not only under licenses that permit modification, > |but also in forms that make such modifications practical; and > | 3. supports the decision of the Release Team to require works > |such as images, video, and fonts to be licensed in > |compliance with the DFSG without requiring source code for > |these works under DFSG #2; and > | 4. determines that for the purposes of DFSG #2, device > |firmware shall also not be considered a program. > ` For the record, this is not the full text of the votable resolution which I proposed; the preceding text was preambulatory text, not rationale, and was submitted as part of the resolution itself. This is mostly irrelevant now since it's been withdrawn, but the proposers of the other resolutions may want to confirm that the full text of their resolution has been cited. In particular, I believe Josselin's proposal was initially submitted as an amendment to mine changing only the last point, which would logically mean this preambulatory text is missing from his as well, leaving him with a GR that begins with the silly opening phrase "The Debian project therefore". -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: The Sourceless software in the kernel source GR
On Mon, Sep 18, 2006 at 05:32:10PM -0500, Manoj Srivastava wrote: > On Mon, 18 Sep 2006 12:36:17 -0700, Steve Langasek <[EMAIL PROTECTED]> said: > > For the record, this is not the full text of the votable resolution > > which I proposed; the preceding text was preambulatory text, not > > rationale, and was submitted as part of the resolution itself. > Which is it, a preamble to the resolution, or the resolution > itself? It is a preamble, and a preamble is a votable component of a resolution. Or perhaps you think no one ever intended to ratify "We the people"? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
On Tue, Sep 19, 2006 at 10:15:28PM -0400, Branden Robinson wrote: > I don't think it is too much to ask that the proposers and/or seconders of > General Resolutions create and maintain wiki pages, for example, when their > initiatives demand a lot of background material to appropriately inform and > persuade the electorate. No one has asked that the vote.d.o pages include "background material". I have asked that the text of resolutions not be misleadingly edited to exclude preambulatory material which has been properly proposed and seconded as part of that resolution. This is about whether developers are being denied the ability to put position statements to a vote that include preambulatory material as part of the statement, about whether their fellows are being denied the opportunity to vote on those position statements, and about whether after the vote is concluded, the section of the debian.org website set aside for listing these position statements is going to include the text that was proposed and seconded, or a subset that complies with the current Project Secretary's notion of what constitutes a "proper" resolution. If there is a disagreement among the proposer and sponsors of a resolution over what the resolution *is*, then of course it's not ready to be put to a vote. If OTOH it's been stated clearly by the proposer what text is being submitted to the developership for ratification, and there are no objections from the seconders, how is it proper for the PS to put something other than this text, or a direct reference to this text, on the ballot? That is the state that <http://www.debian.org/vote/2006/vote_004> was in last time I looked at it; anything not preceded by a number had been elided, and each ballot option was prefaced by the prejudicial statement that "[t]he actual text of the resolution is as follows. Please note that this does not include preambles to the resolutions, [...]", implying that preambles are not part of the resolution and are not votable. Now the page includes the full original mail body from each of the proposers; well, this is at least an improvement over the previous state of affairs in that it is no longer excluding parts of the proposed resolution, but it also seems Manoj is being deliberately perverse in claiming that Don's Burning Man [vac] notice is part of the resolution. :/ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
On Wed, Sep 20, 2006 at 07:44:20PM -0500, Manoj Srivastava wrote: > > No one has asked that the vote.d.o pages include "background > > material". I have asked that the text of resolutions not be > > misleadingly edited > Miisleadingly edited? Wittingly or unwittingly? Are you > claiming that the intent was to mislead? Since I have no way of knowing what your intent is, I assume as always that you are acting in good faith. Nevertheless, based on statements from the proposer of one of these resolutions (Don), I believe it is your intent to represent the text of this resolution to be something other than what the proposer has intended to propose, thus misleading the electorate as to what they have been asked to vote on as a result of what I think is an error of judgement. I don't object to you exercising judgement in subsetting the signed text in an effort to discern the boundaries of a resolution's text, even though I find your preference for excluding preambulatory text outlandish and at odds with the practices of every legislative body with which I am familiar. But if you are going to subset the signed text, I *do* object to your apparent unwillingness to receive clarification from proposers who tell you that you've sliced at the wrong place. Your new guidelines address my concerns by removing the ambiguity, so I'm ok with that as solution. Guess I need to become minimally fluent in wml now, though. > > to exclude preambulatory material which has been properly proposed > > and seconded as part of that resolution. > Either it is preambulatory material, or it is part of the > resolution -- their lies the crux of the disagreement. Yes, I wholeheartedly disagree with the preceding statement. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Counter-proposal: reaffirm support for the elected DPL
On Thu, Sep 21, 2006 at 10:08:41AM +0200, Loïc Minier wrote: > 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. A recall vote falls under §4.1.1 of the constitution, and a position statement such as the one you proposed falls under §4.1.5. I'm not sure if these belong on the same ballot? I guess it's not so different from having a ballot where some options amend foundation documents and others don't. > The Debian Project reaffirms its support to its DPL. > The Debian Project does not object to the experiment named "Duck Tank", Dunc :) > lead by Anthony Towns, the current DPL, and Steve Mc Intyre, the Second in led > Charge. However, this particular experiment is not the result of a > decision of the Debian Project. FWIW dunc-tank.org does not say that it is run by Anthony and Steve; they are listed as two members of a five-member board. So it seems a strange defense against accusations of abusing his position to at the same time claim he's "running" an organization that he doesn't claim to run :-) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal : Freeze of the GR process until the etch release, hoping tempers will have calmed down by then.
On Thu, Sep 21, 2006 at 01:02:40PM +0200, Sven Luther wrote: > === START OF GR PROPOSAL = > Given that the current set of issues held up to > vote, as well as the dispute over them and over > whether the secretary can excercice common sense > and judgement when casting the ballot, the debian > project thus resolves that : > > In order to not distract our developpers from > their technical work and the timely release of > etch, the GR voting procedure, both currently > ongoing and future, will be frozen until the > release of etch, hoping that tempers will have > calmed until then. > > Currently ongoing votes will be delayed until a > week after the etch release, where the normal > time counting will restart, an no new proposals > will be accepted. > === END OF GR PROPOSAL = I would consider such a statement completely non-binding on me and would ignore it in favor of continuing to pursue a resolution to the firmware question. Moreover, the reason the firmware question was being put to a vote in the first place is because I'm not willing to put my name on a release of etch that includes sourceless firmware without first getting a statement from the project that this is the right thing to do, and *why* this is ok if it contradicts the current DFSG. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Recall the Project Leader
On Thu, Sep 21, 2006 at 01:08:17PM +0200, Pierre Habouzit wrote: > just let me rephrase it then. > 1. The DPL is the one that appoints the RM as per constitution You know, this is true only in the most hypothetical sense. Neither Colin, nor Andi nor I, nor any of the current release assistants, were ever the subject of a formal delegation by the DPL, any more than your typical package maintainer is. The release team has had the /support/ of the DPL for as long as I've been involved in it, but we're not here as a consequence of the DPL's approval per se. I suppose the DPL has the authority to dismiss a release manager, but I don't think that makes it a delegated position after the fact. > that's a big conflict of interest. It's IMHO a major fault coming from a > delegate (and especially the DPL) to take a role in such an > organisation. It's just not compatible. Um, terminology disconnect here; the DPL isn't a delegate, the DPL is the DPL. And if you're really claiming that no one who holds any delegated position in Debian should be allowed to be involved in any organization that funds Debian developers... I quite frankly find that to be an insane position to hold. I can only imagine it decreasing the number of people willing to serve Debian in a delegate capacity. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Amendement firmware GR] - Best effort / no regression
On Fri, Sep 22, 2006 at 12:33:28AM +0200, Bill Allombert wrote: > === > THE DEBIAN PROJECT: > 1. reaffirms its dedication to providing a 100% free system to > our users according to our Social Contract and the DFSG; and > 2. encourages licensors of all works to make those works > available not only under licenses that permit modification, but also in > forms that make such modifications practical; > 3. commits itself to remove firmwares without source code and > more generally firmwares that does not meet the Debian Free Software > Guidelines (designed below as "non-free firmwares") from the main and > contrib section of our archive; > 4. will make a best effort to remove as much non-free firmwares > as time allows before our next stable release (code-named "Etch"); > 5. encourages its developers to work on this issue; > 6. urges its developers not to delay or to block inclusion of > works done toward that goal; > 7. will allow our next release to include non-free firmwares > in the main section if we did not manage to remove them on time, provided > they were also present in Sarge main section. > === > What I want to avoid is the result GR _preventing_ people to work > on removing non-free firmwares for Etch because their work will be > rejected with "this is a post-Etch issue". I hope 4,5, and 6 achieve > that. 7 is a compromise I find acceptable and force us to make > _some_ progress on the issue before releasing Etch (which will keep us > honest with respect to 3.). 4 does not seem to account for the fact that removing such firmware may mean having to choose between losing support for certain hardware in our installer, and releasing etch according to schedule. Did you mean for 4 to say "remove as much non-free firmware as time allows without negatively impacting the installer", or something like that? Otherwise, per the recent polls, this doesn't seem to reflect the priorities of the Debian community? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
[Dropping -release from cc anyway; there's no possible reason this needs to be cross-posted to 4 lists] On Fri, Sep 22, 2006 at 07:12:53AM +0200, Sven Luther wrote: > On Thu, Sep 21, 2006 at 02:58:31AM -0500, Bill Allombert wrote: > > On Thu, Sep 21, 2006 at 08:52:15AM +0200, Sven Luther wrote: > > > There won't be any GR, there will be a new pet proposal until forever, and > > > endless discussions as we start recalling the DPL, and bashing on the > > > secretary and what not. > > In the absence of GR, the current situation is that sourceless > > firmwares are not allowed in main. This is the reason the RM > > proposed this GR in the first place. > The current consensus is that it is well among the power of the RMs to > ignore a number of bugs for the sarge release, including this one. I see no evidence that there is a consensus on this point. Since it's the RMs who have to make this decision to ignore these bugs, you're not going to get very far if the RMs don't actually feel empowered to make this decision on their own. > > Re-adding them at this stage > > 1) is against the current social contract > Yes, but then so is shipping the firmware actually still in main, So two bugs is better than one? > and i guess one could evoke the "won't discriminate" clause of the > SC/DFSG, That's not what the DFSG says. > Now, as said, this is a step back to better jump, and the real solution on > this is to follow on with what has been done (by upstream) on the qlogic > drivers, whose firmware is actually already in non-free, even though d-i > doesn't support it yet. This is an upstream work, and as thus will take time > to come to debian, but we, the debian kernel team (or at least me and > Frederik) take the engagement to work on this during etch+1 devel cycle. If it is the consensus of the project that sourceless firmware doesn't belong in main, this is a conscious regression in DFSG-compliance relative to sarge. I don't think that's acceptable. We obviously do have the means to remove this particular subset of non-free firmware from main (technically imperfect though it may be), and of the firmware that was removed for sarge the only one that was important enough to get me glared at personally was qla2xxx -- so what are these other already-removed firmwares that are so important to have re-added now? (I did ask for a list, which no one has provided yet; I can't find the pruning script in the kernel team's svn repo, or I would look it up myself.) > But due to everyone (including you), trying to pull the glory to themselves, > and proposing their pet GR to muddle the issue, without any respect for the > GRs proposed previously, and because of the loophole in the constitution, I don't believe there is any loophole there. The constitution defines what it means for an amendment to be accepted, and it does not apply to additional related resolution proposals, it only applies to amendments to a resolution that are *accepted by the proposer*. Which means independent draft proposals are not supposed to reset the minimum discussion period. (FWIW, it took a hint from AJ for me to recognize that this is what the constitution actually says, but Ian Jackson -- original author of the constitution -- has recently confirmed this understanding.) Anyway, I think we'd be able to get to the point of holding a vote much sooner if we weren't having distracting side discussions like this one. I know it's sucking up time that *I* would rather be spending examining the various resolutions that are already out there. > So, given the defaillance of the GR system, there is no point in worrying > about the vote or not, and always remember, that debian was at the base, and > still is to a mesure, a system where those who do the work get to do the > decision, so you know what you have to do if you want those firmwares not to > be in main :) Well, all /I/ have to do to keep the reintroduced firmware blobs from being in etch is to freeze the linux-2.6 package at 2.6.17 :/ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Recall the Project Leader
On Sat, Sep 23, 2006 at 02:17:08PM -0700, Russ Allbery wrote: > Clint Adams <[EMAIL PROTECTED]> writes: > > Now, if you become the release manager, and your employer makes your > > compensation contingent on Debian not releasing before February of 2010, > > no one can NMU the release. Theoretically, we could replace you, but we > > cannot fix the problem directly. > > Would you not agree that this affects the risk assessment? > If I became the release manager and some other distribution offered me > $50,000 if Debian doesn't release before February of 2010, the situation > is the same. What you're talking about here, in my opinion, is a simple > question of ethics. The conflict could come from any number of sources, > including ones that aren't even monetary, and the risk is present whether > I'm being paid to work on Debian or not since it doesn't have to come from > my employer. > The solution to this sort of situation is, again, a matter of ethics. As > a Debian Developer, I agreed to be part of this project. To me, that > carries an ethical obligation to make decisions for the general good of > the project. Should I be put into a situation where I don't feel like I > can do that without conflicts of interest, I would recuse myself. Should > someone offer me a bargain like the above, I would refuse it. Should the > Debian project as a whole not trust me to act ethically, it shouldn't > trust me with that sort of position. Indeed, the only solid defense against such a conflict of interest is the ethics of the person holding the privileged position. If the premise is that the release managers are willing to sell their souls and the release schedule for personal enrichment, I don't see how any amount of oversight can effectively prevent that. I'm pretty sure that a company looking to sabotage the release process isn't going to feel out the idea on debian-private first. The other option is to eliminate privileged roles. In this case, I think that amounts to eliminating stable releases; I don't think Debian is capable of pulling off a stable release without a focal point in the form of a release team, and while I think sharing the burdens with a larger release team has worked well, I don't think you want to make all decisions by committee... Now, dunc-tank hasn't asked me to compromise myself as an RM; releasing etch this year is already a stated goal of mine, dunc-tank merely seeks to facilitate this goal, and it's understood that this relationship isn't going to bring with it any obligation to cut corners, make particular package decisions that favor the donors, or even to release on schedule if the RMs determine that this is not the correct technical decision at the time. So as far as conflicts of interest are concerned, I don't see one here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Amendement firmware GR] - Best effort / no regression
On Sun, Sep 24, 2006 at 10:55:59PM +0200, Bill Allombert wrote: > On Thu, Sep 21, 2006 at 09:47:22PM -0700, Steve Langasek wrote: > > 4 does not seem to account for the fact that removing such firmware may mean > > having to choose between losing support for certain hardware in our > > installer, and releasing etch according to schedule. Did you mean for 4 to > > say "remove as much non-free firmware as time allows without negatively > > impacting the installer", or something like that? > I did not. Providing support for users that need non-free software is > generally done on a best-effort basis and this GR does not need to hammer > the point. I am quite open to wording improvement, though. Well, I don't see any benefit to spending time improving the wording in this case, since I would vote against it for this reason. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Splitting out Choice #1 from vote_004
Hi Don, On Sun, Sep 24, 2006 at 08:11:58PM -0700, Don Armstrong wrote: > On Sun, 24 Sep 2006, Don Armstrong wrote: > > As far as placing it or not placing it on a separate ballot, it > > would be nice to have it separate, as it deals with clarifying the > > firmware problem before exceptions are granted, but I don't have any > > objections to it being on the same ballot as the other options. [In > > case of a split, I would expect the clarification option to be > > overridden to the extent necessary by the other options; either by > > being voted on slightly before or by a specific amendment saying > > such.] > After some discussion on IRC, I believe that splitting out Choice #1 > (DFSG #2 applies to all programmatic works) from the rest of the > options is a proper course of action. > This is primarily because it was never intended to deal with affirming > or vacating decisions about exceptions for firmware for the purpose of > releasing etch, but only to clarify what the DFSG says in regards to > the source code requirements for works, and what Debian should be > doing about source for works in general, both those that we distribute > and those we do not. And with my original proposal withdrawn, is it still your opinion that this resolution warrants a vote of its own? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Splitting out Choice #1 from vote_004
On Mon, Sep 25, 2006 at 11:32:59PM +0200, Frans Pop wrote: > On Monday 25 September 2006 05:11, Don Armstrong wrote: > > Baring objection, I plan on calling for a vote with a suggested balot > > containing only this option in a few days (no later than 09-27).[1] > > [The Secretary, of course, can override this suggested ballot.] > I strongly object to separating this proposal out and calling for a vote > without any alternative proposals or amendments, for the foolowing reasons: I agree with Don. If this proposal is going to go to a vote, it should go to a vote separately from the votes about exceptions, so that we can get a clear answer to the exception question without the outcome being tainted by either voter confusion leading to strategic voting, or orthogonal statements that are widely supported by the community but which tell us nothing about what we should do for etch. > 2) Without any alternatives, a vote on this proposal will be based purely on > theory and ideals, without any discussion on the practical implications, > for example on the usability of the Debian installation system for users > with hardware that depends on sourceless firmware. > 3) If the proposal is voted on on it's own, it is my belief that the vote > will be heavily biassed towards accepting it. The reason for this is that > for developers who have not followed the discussion on d-vote, this > proposal will seem fairly innocent and the ideals it promotes are noble. > Without a counterweight that shows the practical implications people will > be inclined to support it without thoinking to much about it. Neither of which matter, because having a vote on Don's proposal does not, procedurally speaking, prevent or delay us from moving forward with the (IMHO more important) vote on the question of an exception for etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Splitting out Choice #1 from vote_004
On Tue, Sep 26, 2006 at 01:20:12PM +0200, Sven Luther wrote: > So, you also agree that we need to : > 1) first vote on the exception for etch. > 2) in a second phase vote for what to do with non-free firmware ? What? *Neither* of these is the subject of Don's resolution. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes (Was: kernel firmwares: GR proposal)
On Tue, Sep 26, 2006 at 10:41:24AM +0200, Sven Luther wrote: > As seconder of the below proposal, which has reached enough seconds since > august 31, and as there where no ammendments against this proposal, i now > officially call for a vote, as per section A.2 of our constitution. > === > 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. > === > As per section A.2.3, i should also propose a ballot, and i believe that the > ballot should be of the form : > [ ] Include non-free kernel firmware in etch (this proposal). > [ ] Further discussion. As I mentioned previously, I don't think point 3. here is the compromise I would like to see. "Without further conditions" is so broad that it seems to even *require* us to include firmware in main that lacks any sort of proper distribution license. And indeed, the upload of a completely unpruned 2.6.18 package to unstable suggests that this is not an accident of wording, but the actual view of the present kernel team. If this option appears on a ballot alone, I am likely to vote "further discussion" on it and encourage others to do so as well. I don't want this GR to be a *mandate* that the release team allow firmware under clearly non-free licenses into main for etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes
On Wed, Sep 27, 2006 at 08:21:21AM +0200, Sven Luther wrote: > Two questions here. > First, this means that this proposal needs seconds, right ? Or can Frederik > just incorporate it into his proposal ? Frederik does have the option of incorporating it into his proposal, in which case all of the sponsors have the choice of renewing their second for the changed resolution, or rejecting the change and becoming the new proposer of Frederik's original resolution. > > , > > | 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 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 formware is > > | distributed under a DFSG free license. > > ` > I will let Frederik comment, but this ammendment is a total reversal of the > proposition, doesn't allow for a "timely release of etch", so contradicts > itself, and is just the status quo anyway. What are you claiming is the status quo -- that we're not legally allowed to distribute the firmware in question, or that it's not made available under a DFSG-compliant license? If they're illegal to distribute, the project can pass GRs until they're collectively blue in the face, and it won't matter to me -- I'm not going to give my ok as RM to releasing something that I *know* is a violation of someone's copyright. If you think that the firmware at issue is not distributed under a DFSG-compliant *license*, then you and I seem to be looking at different firmware. Of the binary firmware that Larry Doolittle has identified as still included in the Debian kernel (as of 2.6.17), only three drivers use blobs that don't have a DFSG-compliant license: an appletalk driver, a token ring driver, and a USB audio driver. So if we trust for the moment that everyone involved is acting in good faith and the "GPL" blobs are intended to be distributable and modifiable even though they don't include source, a simple "sourceless firmware is ok for main" exemption gives us 100% coverage of the firmware that matters to the installer, and 85% coverage of *all* the redistributable binary firmware in the kernel packages today, including those readded in 2.6.18. That leaves "only" 15% of the firmware that the kernel team would have to decide how to support for etch, and that includes those drivers that were *already* dropped before sarge's release and just now readded. And if 2 1/2 months isn't long enough to solve just the kernel question of how to package and distribute these drivers/firmware when we know they aren't needed by the installer, then I can expect you to be suitably ashamed of having blamed the debian-installer team for all the delays, right? Then again, I guess the difference between "sourceless" and "non-free" is "just words", and I shouldn't expect you to pay any attention to me until I start drawing Venn diagrams for you. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
On Wed, Sep 27, 2006 at 09:53:58PM +0200, Frederik Schueler wrote: > > , > > | 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 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. > > ` > I accept the amendment. And I second the above amended resolution. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Call for votes (Was: kernel firmwares: GR proposal)
On Thu, Sep 28, 2006 at 11:48:49AM +0200, Sven Luther wrote: > On Wed, Sep 27, 2006 at 04:56:40PM +, Sune Vuorela wrote: > > On 2006-09-27, Kurt Roeckx <[EMAIL PROTECTED]> wrote: > > > On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote: > > >> 2. We acknowledge that there is a lot of progress in the kernel firmware > > >> issue; however, it is not yet finally sorted out; > > > So, what progress has been made? > > All firmwarez have been readded to the debian package. > But with this amendment, they will have to go again anyway, so ... As we've discussed on IRC, 4 of the 6 firmware blobs reintroduced in 2.6.18 apparently have no license statement whatsoever that is intended to permit us to redistribute them, *even* in non-free. So they should go away regardless of the kind of exception the project grants for etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
On Thu, Sep 28, 2006 at 11:05:33PM +0200, Frederik Schueler wrote: > I thought accepting the amendment would imply a second, but if this is > not the case: In fact, by accepting the amendment, you remain the proposer of the amended resolution. So you can't second it, the seconds have to come from people who are *not* the resolution's proposer. :) (If you did *not* accept the amendment, *then* Manoj would have the option of proposing it as a separate ballot option and requesting seconds.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
On Fri, Sep 29, 2006 at 08:16:04AM +0200, Sven Luther wrote: > > > 2) firmware under the GPL, but with missing source. The GPL is > > > free, but the absence of source code for the firmware blobs > > > makes it a violation of the GPL, and thus undistributable. > > I was very careful to state that shipped upstream under a > I don't understand this. You added a couple of lines to Frederik's proposal, > and those have manifestedly be miscompreheneded, because people seconded it > while missing the implication for tg3. The possible implications for tg3 were missed because of a lack of information about tg3's status, not because of any misunderstanding of the amended proposal. Larry's webpage documenting the status of firmware listed the tg3 blob as "BSD-ish". Well, there's obviously nothing BSD-ish about a license that doesn't grant permission to modify. But in spite of <[EMAIL PROTECTED]>, sent on September 10th, no mention was made of tg3's current non-free license until after Manoj's amendment (offered in response to my comments) had been accepted by Frederik. Yes, now that we're aware of tg3, that needs to be factored into any plan which hopes to ensure etch ships with support for installing on the maximum range of hardware. But I've already outlined a theory under which I think the tg3 blob would meet the requirements without having to further amend the proposal. > > compliant license -- which this case seems to meet. Arguable (and > > highly improbably), the firmware hex dump could be the preferred form > The mention of : "Derived from proprietary unpublished source code", in the > later licence, clearly and without doubt says that this is not the prefered > source for modification. Doubts about whether it was the preferred form for modification were never the basis for deciding to permit binary-only GPL firmware for etch; the decision was based on the assumption that the authors were acting in good faith and *intended* to grant us a license permitting redistribution, failing only due to a technicality. > Now, the RMs seem to have some notion, from the hurried discussion we had > yesterday, that they seem to interpret your post as allowing to distribute > sourceless GPLed firmware, because the GPL licence is DFSG free. Er, yes, because that's what the resolution *says*. It says that for firmware in etch we're only going to worry about licenses, *not* source. > I also strongly dislike the notion that it is acceptable to have a sourceless > firmware (and yes, if i say sourceless, it means the hexdump itself is *NOT* > the prefered source), as long as the actual licence is one that is DFSG free, > even though the sourceless nature of it violates the GPL or the DFSG. What in the world is your point? How do arguments that GPL firmware blobs are a GPL violation do *anything* to advance the goal of shipping etch with full hardware support? You keep arguing against this amended proposal by presenting reasons why sourceless firmware is bad. These aren't arguments in favor of the original proposal: the original proposal would have allowed (or even required!) even *more* bad stuff in main, like firmware that has no source *and* has a license prohibiting modification. So how do you figure that telling us about everything that's wrong with sourceless firmware is an argument in favor of the original proposal, when the amended proposal is aimed at permitting *just* the specific DFSG problems that affect sourceless firmware? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Summary? (Or: my vote is for sale!)
On Tue, Oct 03, 2006 at 09:08:30AM +0200, Martin Schulze wrote: > Sven Luther wrote: > > Jurij, i still think your draft is lightyears more clear and to the point > > than > > most GRs out there. > One comment. As BLOB stands for Binary Large OBject, binary blob > is somewhat "strange". This is a retcon; "blob" is an English word meaning "an indistinct, shapeless form". -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "do not modify" blobs
On Tue, Oct 03, 2006 at 03:19:51PM -0700, [EMAIL PROTECTED] wrote: > >Has anyone done a survey to see how many "do not modify" blobs > >we are talking about here? > Not counting files already removed in 2.6.17, > drivers/net/appletalk/cops_ffdrv.h use-only (2) > drivers/net/appletalk/cops_ltdrv.h use-only (2) > drivers/net/tg3.credistr-only > drivers/net/tokenring/3c359_microcode.h use-only (2) > drivers/net/typhoon-firmware.h redistr-only > drivers/scsi/qla2xxx/ql2100_fw.c redistr-only (1) > drivers/scsi/qla2xxx/ql2200_fw.c redistr-only (1) > drivers/scsi/qla2xxx/ql2300_fw.c redistr-only (1) > drivers/scsi/qla2xxx/ql2322_fw.c redistr-only (1) > drivers/scsi/qla2xxx/ql2400_fw.c redistr-only (1) > drivers/usb/misc/emi26_fw.h redistr-only (2,3) > (1) deprecated upstream, removed upstream as of 2.6.18? > (2) marked for deletion by recent "Kernel team position statement" > (3) redistributable as part of a Linux or other Open Source operating > system kernel Which means that, at most, we have two installer-relevant firmware blobs distributed in the upstream kernel (typhoon and tg3) that are not covered by the exception in Frederik's revised proposal. If typhoon-firmware.h isn't needed to run any hardware, and is used only for performance reasons (I don't know if this is the case), that count is down to one. I'm inclined to think that the amount of work being spent on drafting a GR with principles allowing us to include tg3 and typhoon in main is disproportionate. Would it not be more straightforward to add these two firmware blobs to the exception by name? That way, there's no doubt left to voters that this GR will be used as a justification for adding a bunch of new firmware to main on the grounds that it's "needed" by the installer for new hardware. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Wed, Oct 04, 2006 at 10:28:20AM +0200, Sven Luther wrote: > There is some claims that some of those blobs represent just register dumps, This is a strawman, and Sven knows this as I have told him quite plainly that this is not my claim. > So, the RMs are making claims that those sourceless GPLed drivers don't > cause any kind of distribution problem, This is a red herring. The *relevant* claim I have made is that it is inappropriate to use our GR mechanism to attempt to *decide* whether GPLed drivers cause a distribution problem. The release team, the ftp team, and I suspect even most of the kernel team have no interest in a GR that authorizes any distribution of software which it at the same time asserts is illegal. It is not reasonable for the project to vote on questions of legality, nor is it appropriate to rely on debian-legal for questions of legality. If the relevant delegates/maintainers have questions about the legality of distributing a particular piece of software, they should consult a lawyer. Sven is incongruously insisting both that these firmware blobs must be included in etch, *and* that they're illegal to distribute. This is nonsense; trying to convince the release team and the ftp team that these are illegal to distribute is contrary to his stated goal of including maximum hardware support in etch. He can't have it both ways, because no GR can compel the release team or the ftp team to knowingly break the law. > while i strongly believe that the GPL clause saying that all the > distribution rights under the GPL are lost if you cannot abide by all > points, including the requirement for sources. I have previously given my own understanding of why it is not a problem for us to distribute GPLed firmware blobs pending license clarifications, but I don't see any indication that Sven is interested in understanding that POV, only in tilting at strawmen; so I don't intend to lose any more time on discussing this point beyond this single clarification email. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
On Thu, Oct 05, 2006 at 05:04:32PM +1000, Anthony Towns wrote: > I don't think it's worth further delaying this vote to include this > position statement; as per [0] the minimum discussion period for Manoj's > amendment as accepted by Frederik [1] ended 4th Oct 2006 19:53:58 UTC, > which is about 11 hours ago; so we could get on with calling for a vote > and have this over and done with in a little over a week if the proposers > and seconders are willing. Given the latest accepted draft this seems to leave us without a clear statement regarding the tg3 and typhoon firmware blobs, which are relevant to the installer and do not have a license permitting modification. Though if the Project passes that GR rather than attempting to twiddle the language further to explicitly cover those two blobs, I'm probably willing to go out on a limb as RM and allow their inclusion in main for etch along with the others. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
