Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
On Thu, Jul 21, 2016 at 7:15 PM, Wouter Verhelst wrote: > A "Chairman" is a person. A "Chair" may be an object. https://en.wikipedia.org/wiki/Chair_%28disambiguation%29 "Chair or Chairman, the highest officer of an organized group"
Re: Counter-proposal: reaffirm support for the elected DPL
On Thu, Sep 21, 2006 at 10:39:52AM +0200, Loïc Minier wrote: >The Debian Project reaffirms its support to its DPL. > >The Debian Project does not object to the experiment named "Dunc-Tank", lead by >Anthony Towns, the current DPL, and Steve Mc Intyre, the Second in Charge. > However, this particular experiment is not the result of a decision of the >Debian Project. > >The Debian Project wishes success to projects funding Debian or helping >towards the release of Etch. Seconded. Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
On Mon, Sep 18, 2006 at 10:07:18PM -0700, Don Armstrong wrote: > == BEGIN PROPOSAL = > > The Free Software movement is about enabling users to modify the works > that they use on their computer; about giving users the same > information that copyright holders and upstream developers have. As > such, a critical part of the Free Software movement is the > availability of source (that is, the form of the work that a copyright > holder or developer would use to actually modify the work) to users. > This makes sure that users are not held hostage by the whims (or lack > of interest or financial incentive) of upstreams and copyright > holders. > > Different types of works have different forms of source. For some > works, the preferred form for modification may not actually be > digitally transferable.[1] For others, the form that originally was > preferred may have been destroyed at some point in time, and is no > longer available to anyone. However, to the greatest extent > possible,[2] the availability of source code to users is a critical > aspect of having the freedom to modify the software that is running > upon ones computer. > > Recognizing this, the Debian Project: > > A. Reaffirms that programmatic works distributed in the Debian > system (IE, in main) must be 100% Free Software, regardless of > whether the work is designed to run on the CPU, a subsidiary > processing unit, or by some other form of execution. That is, > works must include the form that the copyright holder or upstream > developer would actually use for modification. > > B. Strongly recommends that all non-programmatic works distribute > the form that the copyright holder or upstream developer would > actually use for modification. Such forms need not be distributed > in the orig.tar.gz (unless required by license) but should be > made available on upstream websites and/or using Debian project > resources. > > C. Reaffirms its continued support of users whose hardware (or > software) requires works which are not freely licensed or whose > source is not available by making such works available in > non-free and providing project resources to the extent that > Debian is capable of doing so. > > D. Requests that vendors of hardware, even those whose firmware is > not loaded by the operating system, provide the prefered form for > modification so that purchasers of their hardware can > exercise their freedom to modify the functioning of their > hardware. > > > 1: Consider film negatives, or magnetic tape in the case of audio >recordings. > > 2: Here it must be emphasized that we refer to "technically possible" >or "possible for some party" as opposed to "legally possible for >Debian". We also assume digital distribution, and do not attempt to >require the distribution of physical objects. > > = END PROPOSAL === Seconded. Anibal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
On Thu, Aug 24, 2006 at 11:51:51PM -0700, Don Armstrong wrote: >I'd like to propose the following option to the current GR process. > >As I will (starting late sunday PDT) be away for a week and a few days >at Burning Man,[i] I will be unable to appropriately respond to >corrections and suggested amendments during that time. However, I will >do so immediately at my return. Seconded, with or without clause D. >== > >The Free Software movement is about enabling users to modify the works >that they use on their computer; about giving users the same >information that copyright holders and upstream developers have. As >such, a critical part of the Free Software movement is the >availability of source (that is, the form of the work that a copyright >holder or developer would use to actually modify the work) to users. >This makes sure that users are not held hostage by the whims (or lack >of interest or financial incentive) of upstreams and copyright >holders. > >Different types of works have different forms of source. For some >works, the preferred form for modification may not actually be >digitally transferable.[1] For others, the form that originally was >preferred may have been destroyed at some point in time, and is no >longer available to anyone. However, to the greatest extent >possible,[2] the availability of source code to users is a critical >aspect of having the freedom to modify the software that is running >upon ones computer. > >Recognizing this, the Debian Project: > > A. Reaffirms that programmatic works distributed in the Debian > system (IE, in main) must be 100% Free Software, regardless of > whether the work is designed to run on the CPU, a subsidiary > processing unit, or by some other form of execution. That is, > works must include the form that the copyright holder or upstream > developer would actually use for modification. > > B. Strongly recommends that all non-programmatic works distribute > the form that the copyright holder or upstream developer would > actually use for modification. Such forms need not be distributed > in the orig.tar.gz (unless required by license) but should be > made available on upstream websites and/or using Debian project > resources. > > C. Reaffirms its continued support of users whose hardware (or > software) requires works which are not freely licensed or whose > source is not available by making such works available in > non-free and providing project resources to the extent that > Debian is capable of doing so. > > D. Requests that vendors of hardware, even those whose firmware is > not loaded by the operating system, provide the prefered form for > modification so that purchasers of their hardware are can > exercise their freedom to modify the functioning of their > hardware. > > >1: Consider film negatives, or magnetic tape in the case of audio > recordings. > >2: Here it must be emphasized that we refer to "technically possible" > or "possible for some party" as opposed to "legally possible for > Debian". We also assume digital distribution, and do not attempt to > require the distribution of physical objects. > >=== > > >Obvious points for discussion: > >1. I would really like to be able to commit to some form of > installation support for users who need to be able to use non-free > firmware to install their system; some more work is needed in d-i > land, though to make sure that this is separated out and that it's > trivial to have a Free system, and know that what you're > installing/using/distributing is Free Software. > >2. Distributing the huge source forms for non-programmatic works is > going to be a problem. I don't think they're needed in the > orig.tar.gz, because that would needlessly bloat the archive, and > it's probably not required unless the works are copylefted. > However, we should make an effort to encourage upstreams to make > them available and likewise make them available to our users. [Even > if it's just in people.debian.org/~you/ or similar and mentioned in > the copyright file, it'd be a good step.] > >3. If there is substantial objection to D, I will probably remove it; > however firmware, whether we happen to distribute it or not, is a > hazard to user's freedom to modify the functioning of their > computers. > >4. Finally, if in the context of the release of etch, we need to > compromise our ideals and accept programmatic works without source, > we should do so by specifically exempting them from DFSG 2 for the > purpose of releasing etch by a GR which needs to meet the 3:1 > requirement instead of attempting to define ourselves into such a > position, especially when source code is clearly a desirable thing > to have from our users and our perspective. > > >Don
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote: > > The application of DFSG#2 to firmware and other data > > >The Debian Project recognizes that access to source code for a work of >software is very important for software freedom, but at the same time >"source" is often not a well-defined concept for works other than those >traditionally considered "programs". The most commonly cited definition is >that found in version 2 of the GNU GPL, "the preferred form of the work for >making modifications to it," but for non-program works, it is not always >clear that requiring this "source" as a precondition of inclusion in main >is in the best interest of our users or advances the cause of Free Software: > > - 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. > - The preferred form for modification may be orders of magnitude larger >than the final "binary" form, resulting in prohibitive mirror space >requirements out of proportion to the benefits of making this source >universally available; e.g., some videos. > - The "binary" and "source" forms of a work may be interconvertible with no >data loss, and each may be the preferred form for modification by >different users with different tools at their disposal; e.g., some >fonts. > >While the Debian Free Software Guidelines assert that source code is a >paramount requirement for programs, they do not state that this is the case >for non-program works, which permits us to consider whether one of the above >points justifies a pragmatic concession to the larger context within which >Free Software operates. > >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. > >== Seconded. Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: Constitutional Amendment GR: Handling assets for the project
On Tue, Aug 22, 2006 at 11:46:54AM -0500, Manoj Srivastava wrote: > Hi, > > 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. Seconded. > Changes: > + Clarify developer powers to indicate that they can make as well as > override delegate decisions (of course, no one can be forced to do > any work, but the decisions can be made by GR). So actions can't be > prevented by a delegate deciding not to decide ... > + If the developers pass a GR about assets, the DPL need not be consulted > + Clarify that decisions about assets need not be discussed on a > mailing list, they just need to be communicated to the > developers. However, major expenditures should be proposed and > discussed n an electronic mailing list before funds are disbursed. > + Made editing the list of trusted organizations a DPL power, added a > 2 week discussion period before an organization is added to that > list. > + In case the DPL and ex-secretary can't agree on an candidate for new > secretary, the decision is made by the developers in a GR, and not by > the SPI board. > + Removed mention of SPI obligations and undertakings from the > constitution. > > manoj > Content-Description: draft GR > Hi, > > > manoj > > > 4. The Developers by way of General Resolution or election >4.1. Powers > Together, the Developers may: > > - 3. Override any decision by the Project Leader or a Delegate. > - 4. Override any decision by the Technical Committee, provided they > - agree with a 2:1 majority. > > -6. Together with the Project Leader and SPI, make decisions about > - property held in trust for purposes related to Debian. (See §9.1.) > > > 4. The Developers by way of General Resolution or election >4.1. Powers > Together, the Developers may: > + 3. Make or override any decision authorised by the powers of the Project > + Leader or a Delegate. > + 4. Make or override any decision authorised by the powers of the > Technical > + Committee, provided they agree with a 2:1 majority. > > +6. Make decisions about property held in trust for purposes > + related to Debian. (See §9.). > +7. In case of a disagreement between the project leader and in > + the incumbent secretary, appoint a new secretary. > - > > > 5. Project Leader >5.1. Powers > The Project Leader may: > - 10. Together with SPI, make decisions affecting property held in trust > - for purposes related to Debian. (See §9.) > > === > 5. Project Leader >5.1. Powers > The Project Leader may: > + 10. In consultation with the developers, make decisions affecting > + property held in trust for purposes related to Debian. (See > + §9.). Such decisions are announced on an electronic mailing > + list designated by the Project Leader or their Delegate(s), > + which is accessible to all developers. Major expenditures > + should be proposed and debated on the mailing list before > + funds are disbursed. > + 11. Add or remove organizations from the list of trusted > + organizations (see §9.3) that are authorized to accept and > + hold assets for Debian. The evaluation and discussion leading > + up to such a decision occurs on an electronic mailing list > + designated by the Project Leader or their Delegate(s), on > + which any developer may post. There is a minimum discussion > + period of twoo weeks before an organization may be added to > + the list of trusted organizations. > --- > --- > 7. The Project Secretary > 7.2. Appointment >If the Project Leader and the current Project Secretary cannot agree > - on a new appointment they must ask the board of SPI (see §9.1.) to > - appoint a Secretary. > === > 7. The Project Secretary > 7.2. Appointment >If the Project Leader and the current Project Secretary cannot agree > + on a new appointment, they must ask the Developers by way of > + General Resolution to appoint a Secretary. > --- > > > -9. Software in the Public Interest > > SPI and Debian are se
Re: -= PROPOSAL =- Release sarge with amd64
On Wed, Jul 14, 2004 at 12:36:35AM +0100, Scott James Remnant wrote: > I strongly suspect there are many others in Debian who also have no > problems communicating with James. During debconf4, I didn't have any problem communicating with him personally. He actively participated in one BOF session answering questions about the NM process. Those present cannot say there was a lack of communication. Anibal Monsalve Salazar -- .''`. Debian GNU/Linux | Building 28C : :' : Free Operating System | Monash University VIC 3800, Australia `. `' http://debian.org/| http://www-personal.monash.edu/~anibal/ `- | signature.asc Description: Digital signature
