Re: Proposal: The DFSG do not require source code for data, including firmware

[Marc 'HE' Brockschmidt]

Heya,

I second the proposal quoted below.

Steve Langasek <[EMAIL PROTECTED]> writes:
>  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.

Marc
-- 
BOFH #57:
Groundskeepers stole the root password


pgpnJizxpl83L.pgp
Description: PGP signature

Re: Proposal: The DFSG do not require source code for data, including firmware

[MJ Ray]

Steve Langasek <[EMAIL PROTECTED]> wrote: [...]
> 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.

If you think the Debian voting system handles compound resolutions badly,
then why did you propose one?  Hadn't you noticed that thread before?

I want to read the Debian Voting System (J.Voss?) again before saying
whether or not this is the case, but *if* you have harmed the chances of
your proposal by unnecessarily making it a compound resolution instead
of two independent simple resolutions, then I think that's justice.

Best wishes,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Pierre Habouzit]

Le ven 25 août 2006 08:51, Don Armstrong a écrit :

I second that proposition

> =
>
> 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:
> […]
> 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.

I've none, but would second a proposal without it as well if that's 
needed.

> 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.

and I also feel that's needed.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpZCqTX5y4KL.pgp
Description: PGP signature

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Don Armstrong]

On Thu, 24 Aug 2006, Don Armstrong wrote:
>   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

This should read 'hardware can exercise'; I had 'are able' here
originally and didn't complete its deletion.

>  exercise their freedom to modify the functioning of their
>  hardware.


Don Armstrong

-- 
America was far better suited to be the World's Movie Star. The
world's tequila-addled pro-league bowler. The world's acerbic bi-polar
stand-up comedian. Anything but a somber and tedious nation of
socially responsible centurions.
 -- Bruce Sterling, _Distraction_ p122

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Alexander Wirt]

Don Armstrong schrieb am Donnerstag, den 24. August 2006:

> I'd like to propose the following option to the current GR process.
I second this proposal. 
> 
> 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.
> 
> 
> ==
> 
> 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 

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[René van Bevern]

Hello,

I second this proposal independently of the presence of the D clause,
although I prefer it being not removed.

Don Armstrong <[EMAIL PROTECTED]> writes:
> 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.
>
>
> ==
>
> 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 ourselv

Re: Proposal: The DFSG do not require source code for data, including firmware

[Peter Samuelson]

[Matthew Garrett]
> The biggest area which is likely to bite us is with network cards, 
> though we'll probably lose some degree of SCSI support as well.

Fortunately, at least with SCSI, users have a choice.  They can buy
Adaptec or LSI 53c* and they get _truly free_ firmware (in the case of
Adaptec, the kernel includes firmware source and a matching assembler;
for LSI, the firmware is augmented with byte-code "scripts" apparently
assembled by the driver at runtime).  Perhaps coincidentally, between
aic7xxx, aic79xx and sym53c8xx_2, the most popular commodify SCSI chips
are covered.  (Well, there's the megaraid family, but those don't
_appear_ to need to load firmware at runtime either.)

Incidentally, the aic7xxx / aic79xx drivers in particular are a great
thing to point out to people who are inclined to be lenient toward
vendors on the theory that it is inherently not practical for them to
ship open source firmware for their devices.  Adaptec figured out how
to do this a _long_ time ago:

  $Id: aic7xxx.reg,v 1.4 1997/06/27 19:38:39 gibbs Exp $
  $Id: aic7xxx.seq,v 1.77 1998/06/28 02:58:57 gibbs Exp $


signature.asc
Description: Digital signature

Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)

[Marco d'Itri]

[EMAIL PROTECTED] wrote:

>My understanding is that upstream has not been entirely receptive
>to patches that remove non-free firmware from it.  Maybe that's
>because they don't have an established firmware-nonfree project
>(like Debian does) into which to move that firmware? 
No, it's because they really do not believe this to be a problem, like
everybody else but a few people polluting debian-legal.

>A consensus of DD that "firmware is not software" carries no
>legal weight.  44 of the sourceless-firmware-contaminated
>files in the Linux kernel are claimed to be covered by the GPL.
>There is no legal way for Debian to redistribute those files,
>since we can't provide that source to people who attempt to
>exercise their GPL-mandated rights.
Other distributions disagree, and they have actual lawyers who are
payed to care about such things.

>http://lists.debian.org/debian-vote/2006/08/msg00166.html
>> >  I think we should learn from OpenBSD on this front.
>> I agree. Indeed, the OpenBSD project not only distributes
>> sourceless firmwares, but also sourceless firmwares with a
>> license which forbids modifications and reverse engineering.
>Care to back up that statement?  It runs 180 degrees counter
>to my understanding of OpenBSD.
Feel free to dig in the OpenBSD mailing lists archives if you care.

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Proposal: Apologize for releasing etch with sourceless/non-free firmware

[Daniel Ruoso]

Hi,

As I understand Debian's view on Free Software did not change, and as
the firmware split is, indeed, an unsolved question, I think a more
honest position would be to accept that we couldn't deal with the
firmware issue in the timeframe for etch.

As the question itself seems quite immature (including the question
about the freeness of sourceless firmware), and, as we want to release
etch in time, I think the most sane thing to do is to say: "Hey, we
couldn't deal with this issue but we do want to release etch in time"
and mature the question without the time pressure for releasing etch.

I propose the following option to the GR:


The Debian Project reaffirms its commitment of providing a 100% free
operating system, and reaffirms the decisions taken by GR 2004-03, but
some technical issues regarding firmware couldn't be solved in the
timeframe to release etch, and, therefore, the next Debian release,
codename etch, will still contain sourceless/non-free firmwares. The
Debian Project apologize for this, and will continue to work on finding
a way to solve this issue.


I think this needs a 3:1 majority...

Daniel



signature.asc
Description: Esta é uma parte de mensagem	assinada digitalmente

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Frank Küster]

René van Bevern <[EMAIL PROTECTED]> wrote:

> Hello,
>
> I second this proposal independently of the presence of the D clause,
> although I prefer it being not removed.

Same for me; with or without "are"

Regards, Frank

>
> Don Armstrong <[EMAIL PROTECTED]> writes:
>> 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.
>>
>>
>> ==
>>
>> 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 sou

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Enrico Zini]

On Thu, Aug 24, 2006 at 11:51:51PM -0700, Don Armstrong wrote:

> 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.

Thanks Don.  I like the proposal, however I'm not seconding it.

My position is: "sourceless firmware sucks, but at the moment we happen
to need it, just like sourceless BIOSes".

In this view, I see two problems with your GR:

 1. It needs a separate vote to affirm "we happen to need it".
 2. It would make the exception etch-specific, just like we previously
made a sarge-specific exception, and now we have to vote on the same
issue again.

I understand that the urgent issue is "are we ok in having sourceless
firmware in etch?", and I think it's a waste of time to vote a GR that
doesn't address that.

Then, if an exception is to be defined, I'd it to be defined not in
terms of some future release we can't predict, but in term of "until we
can't possibly do without".  Unfortunately, my attempt[1] at wording
this latter point didn't get it right, and I can't come out with
anything better.


[1] http://lists.debian.org/debian-vote/2006/08/msg00053.html

Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Sven Luther]

On Fri, Aug 25, 2006 at 01:20:19PM +0100, Enrico Zini wrote:
> On Thu, Aug 24, 2006 at 11:51:51PM -0700, Don Armstrong wrote:
> 
> > 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.
> 
> Thanks Don.  I like the proposal, however I'm not seconding it.
> 
> My position is: "sourceless firmware sucks, but at the moment we happen
> to need it, just like sourceless BIOSes".
> 
> In this view, I see two problems with your GR:
>  1. It needs a separate vote to affirm "we happen to need it".

Enrico :

  ruoso made a first proposal for such a 'we need it' GR, and the kernel team,
  associated with maybe a part of the RM and d-i team, have another more full
  fledged proposal about this in preparation.

>  2. It would make the exception etch-specific, just like we previously
> made a sarge-specific exception, and now we have to vote on the same
> issue again.

Yep.

> I understand that the urgent issue is "are we ok in having sourceless
> firmware in etch?", and I think it's a waste of time to vote a GR that
> doesn't address that.
> 
> Then, if an exception is to be defined, I'd it to be defined not in
> terms of some future release we can't predict, but in term of "until we
> can't possibly do without".  Unfortunately, my attempt[1] at wording
> this latter point didn't get it right, and I can't come out with
> anything better.

If the etch+1 release schedule is again 18month, this would leave us with
approximately two year to solve the issue, which should be plentiful, my guess
is that it will take us approximately 6 month to a year, depending on how we
do it, and how things go with licence clarification with upstream.

But the etch freeze started almost a month ago, and it is now too late for
etch.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Kari Pahula]

I second this proposal.

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.
> 
> 
> ==
> 
> 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 c

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Sven Luther]

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.

I like your proposal too. As for D, maybe we could word it a bit differently,
as it will be a arduous task, with little success chances in the general case.

Maybe we can arrive to some kind of agreement with manufacturer to have them
free the source of their firmwares after some time or something.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Alexander Wirt]

Alexander Wirt schrieb am Freitag, den 25. August 2006:

> Don Armstrong schrieb am Donnerstag, den 24. August 2006:
> 
> > I'd like to propose the following option to the current GR process.
> I second this proposal. 
I have to say a few mores word to it. It would be fully ok for me if we
release etch with this non-free firmware, but this problem should be
adressed with etch+1. 

Alex



signature.asc
Description: Digital signature

Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)

[MJ Ray]

Marco d'Itri <[EMAIL PROTECTED]> posted from wonderland.linux.it:
> No, it's because they really do not believe this to be a problem, like
> everybody else but a few people polluting debian-legal.

I note that several of those supporting the current source code
requirement for main don't post much to debian-legal (and certainly don't
pollute it with claims like "the DFSG does not addrss patents. This means
that there is no point in arguing that patent restrictions violate thit"
http://lists.debian.org/debian-legal/2006/08/msg00106.html ).

[... [EMAIL PROTECTED] wrote: ]
> >http://lists.debian.org/debian-vote/2006/08/msg00166.html
> >> >  I think we should learn from OpenBSD on this front.
> >> I agree. Indeed, the OpenBSD project not only distributes
> >> sourceless firmwares, but also sourceless firmwares with a
> >> license which forbids modifications and reverse engineering.
> >Care to back up that statement?  It runs 180 degrees counter
> >to my understanding of OpenBSD.
> Feel free to dig in the OpenBSD mailing lists archives if you care.

Searching OpenBSD mailing list archives for mails matching both keywords
firmware and source found nothing.  Are you sure it's in there?

Thanks,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Frank Küster]

Frank Küster <[EMAIL PROTECTED]> wrote:

> René van Bevern <[EMAIL PROTECTED]> wrote:
>
>> Hello,
>>
>> I second this proposal independently of the presence of the D clause,
>> although I prefer it being not removed.
>
> Same for me

Ah, yes, and to make things clear:  While I second this proposal, I
still think that resolving the firmware issue can be delayed until
etch+1, even if it hurts.  

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)


pgp0rp5DqhIKN.pgp
Description: PGP signature

Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)

[Marco d'Itri]

[EMAIL PROTECTED] wrote:

>Searching OpenBSD mailing list archives for mails matching both keywords
>firmware and source found nothing.  Are you sure it's in there?
Well, probably there is a reason if you have not found anything by
looking for "source"... With a two minutes google search of
"de Raadt firmware" I have found:

http://www.theage.com.au/articles/2004/10/29/1098992287663.html

De Raadt said that when a request was made to a vendor to 'open' their
firmware, "it just means we want clear distribution/redistribution
rights. We don't need the 'source code' to their firmware. There are no
intellectual property concerns."

(I do not understand why he received an award from FSF for this, BTW.)


And http://kerneltrap.org/node/6550:

Jeremy Andrews: What is it about binary firmware that you're willing to
ship it, versus binary blobs? How can you trust the firmware binary to
do what it should do? And what if the firmware has a bug?

Theo de Raadt: [...] But in the end, if we wish to support any such
devices, we must be practical. We must accept the risk that there is a
flaw in the firmware. [...] Of course, also note that we don't want to
become Hermes (the architecture of the Lucent/Prism/Symbol chip)
assembly language programmers... we have more than enough to do. Just a
specific example. Please, people, don't load us up with more tasks ;)

-- 
ciao,
Marco


-- 
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

[Kurt Roeckx]

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.  The DFSG says we need the source, and
I understand that as the best possible form for modification.

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.

> > 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?

No, I would insist on having it.

> > > 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?

The DFSG doesn't say that the toolchain should be available for it to be
free, and it shouldn't.  But I understand the SC as requiring it to be
included in main.  It's also one of the reasons we have such a thing as
contrib.

There was a time when alot of java applications were in contrib because
there wasn't anything in main we could use them with.  But those were
free software.  You just needed non-free software for it to be useful.
And now most, if not all, have moved to main.

> > 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
> .  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.

So, from that list:
 * 46 source files that already use request_firmware() or
   mod_firmware_load()
 * 18 already removed from Debian (linux-2.6_2.6.17.orig.tar.gz)
 * 47 apparently nondistributable
 * 12 apparently ok for non-free
 * 14 free

So, we have a total of 137 drivers that require firmware.  We have
14 that are free and can stay in main in any case.

I'm not sure ab

Re: Proposal: Apologize for releasing etch with sourceless/non-free firmware

[Mike Hommey]

On Fri, Aug 25, 2006 at 11:03:47AM +0100, Daniel Ruoso <[EMAIL PROTECTED]> 
wrote:
> Hi,
> 
> As I understand Debian's view on Free Software did not change, and as
> the firmware split is, indeed, an unsolved question, I think a more
> honest position would be to accept that we couldn't deal with the
> firmware issue in the timeframe for etch.
> 
> As the question itself seems quite immature (including the question
> about the freeness of sourceless firmware), and, as we want to release
> etch in time, I think the most sane thing to do is to say: "Hey, we
> couldn't deal with this issue but we do want to release etch in time"
> and mature the question without the time pressure for releasing etch.
> 
> I propose the following option to the GR:
> 
> 
> The Debian Project reaffirms its commitment of providing a 100% free
> operating system, and reaffirms the decisions taken by GR 2004-03, but
> some technical issues regarding firmware couldn't be solved in the
> timeframe to release etch, and, therefore, the next Debian release,
> codename etch, will still contain sourceless/non-free firmwares. The
> Debian Project apologize for this, and will continue to work on finding
> a way to solve this issue.
> 

I'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.

Mike


-- 
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

[Steve Langasek]

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

[Manoj Srivastava]

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?

manoj
-- 
A morsel of genuine history is a thing so rare as to be always
valuable. Thomas Jefferson
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
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

[Mike Hommey]

On Fri, Aug 25, 2006 at 01:16:28PM -0700, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> 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?

Why? Because there was one GR before sarge for the exact same thing
saying we would postpone the requirement for etch. Now that etch is
supposed to be released, you want to postpone until etch+1. The thing
is that at that pace, it will never be fixed.
Either we make a binding promise that we *will* fix the issue for the
next release, or we just change the social contract to fit the fact
we're not going to fix it. Oh wait, the SC just got changed the other
way around. Well, then, let's keep the promises and stop postponing.

Mike


-- 
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

[Sven Luther]

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 we could just as well hold a vote some time in the future, to say that
finally, we are not going to make it for etch+1 and revert that decision.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones

[Anibal Monsalve Salazar]

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: Apologize for releasing etch with sourceless/non-free firmware

[Steve Langasek]

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

[Steve Langasek]

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