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

[Steve Langasek]

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

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 firmware

[Sven Luther]

On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote:
> 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.
> 
> Andi Barth and I have discussed how we think the DFSG requirements apply to
> firmware and have fairly similar views on the subject, but we also know that
> there are other viewpoints within the project, so we're reluctant to make a
> unilateral decision about firmware handling for the etch release policy
> without finding out how the project as a whole feels about it.  In the
> meantime, the ongoing discussions within the kernel team and without have
> shed, as they say, more heat than light on the subject, so I feel it's time
> to answer this question so we can stop being paralyzed by these differences
> of opinion, agree to disagree, and move forward with the work that needs to
> be done for etch -- whichever set of work we decide that is.
> 
> So below is a proposal that I'm seeking seconds on to establish how DFSG#2
> should be understood to apply to firmware -- i.e., that for Debian's
> purposes firmware should be considered data, not programs, and along with

...

> 4. determines that for the purposes of DFSG #2, device firmware
> shall also not be considered a program.

Hello,

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), ranging from declaration on the LKML mailing list
by the drivers author, or when the peripheral processor holds a mips or arm or
whatever core. Sure, other firmware cases consist of only register dumps, but
my own involvement in hardware development shows me that the trend is more and
more for peripheral hardware with embedded processor cores, and the firmware
of those being actual processors, some of them could run some variant of linux
(or uclinux at least) in their own right. This is especially true for high-end
raid cards and wireless applications.

Trying to argue, as other did before you, that it is just data, because that
is more convenient, thus ignoring the facts, is kind of misleading and
dishonest, and furthermore is the wrong strategical choise for debian, who has
long stood for free software, and would thus compromise its ideals for the
sake of convenience.

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, then you take the first step down a road debian
doesn't want to go. You will have to consider cases like the unicorn driver
(currently in non-free), which includes a soft-adsl binary-only library, or
issues like tge miboot bootloader, which includes a half sector of m68k
instructions, copyrighted by apple, and very analogous to the firmware case,
and then from there, you have to go further, and if you are true to yourself,
end up allowing everything in main.

Notice also that in the social contract, we already claim to support our users
and free software equally, and that we furthermore agreed to keep non-free
around for exactly those users needing non-free components, like those
non-free drivers or firmware, and there only needs to be a relatively small
technical work to be done for this to work seamlessly for all users. 

So, if we of debian want to stay true to ourself, and not live in
self-deception just because it convenience us, then the right argumentation on
this should be of the following :

  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 alo

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

[Andreas Barth]

* Steve Langasek ([EMAIL PROTECTED]) [060823 00:18]:
>  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.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


signature.asc
Description: Digital signature

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

[Anthony Towns]

On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote:
> [Steve Langasek]
> > 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?
> The day Debian begins to distribute ROM chips, or devices containing
> ROM chips, I will expect those chips to come with source code.  Until
> then, this is a red herring.

Note that while Peter is currently in the n-m queue (on hold pending
further response to T&S checks apparently), he's not yet a developer,
and his expectations shouldn't be inferred to be those of the developers
as a whole.

Working out whether those expectations match those of the developers as
a whole is what this GR -- and the discussion preceeding it -- is about.
I'd strongly discourage people who participate in the discussion (whether
you've run the n-m gauntlet or not) from dismissing developers' concerns
about this as a "red herring": if you're right, you shouldn't be afraid to
discuss the reasons why you're right in detail when asked.

Cheers,
aj



signature.asc
Description: Digital signature

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

[Sven Luther]

On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote:
> On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote:
> > [Steve Langasek]
> > > 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?
> > The day Debian begins to distribute ROM chips, or devices containing
> > ROM chips, I will expect those chips to come with source code.  Until
> > then, this is a red herring.
> 
> Note that while Peter is currently in the n-m queue (on hold pending
> further response to T&S checks apparently), he's not yet a developer,
> and his expectations shouldn't be inferred to be those of the developers
> as a whole.
> 
> Working out whether those expectations match those of the developers as
> a whole is what this GR -- and the discussion preceeding it -- is about.
> I'd strongly discourage people who participate in the discussion (whether
> you've run the n-m gauntlet or not) from dismissing developers' concerns
> about this as a "red herring": if you're right, you shouldn't be afraid to
> discuss the reasons why you're right in detail when asked.

This is a commonly held believe, that many DDs have already used in the past,
and seems quite common sense to me :

  - a firmware hold in a rom or flash is in no way different that a firmware
hold in a driver binary, as far as DFSG and freeness goes, both are
usually non-free.

  - debian doesn't ship hardware, so the DFSG can hardly apply to some random
piece of hardware that the user may have, as it could not apply to let's
say a copy of the microsoft-office program a user or DD may have on the
same harddisk he installs debian on.

To add to that, if i where Peter, i may feel slightly offended by the tone of
your reply as well as the content of it. You are the DPL, and as thus speak
with the authority given by the whole project, and i think you should as such
be a more careful in your wording.

Friendly,

Sven Luther


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

Re: Constitutional Amendment GR: Handling assets for the project

[Adrian von Bidder]

2nd'd, also with Don's amendments.

Note that the 'in consultation' bit is still in - it could be still clearer 
that the DPL may on his own take the decisions.  But it's improved over the 
prev. version.

cheers
-- vbi

On Tuesday 22 August 2006 18:46, Manoj Srivastava wrote:
> 
>  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 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.
>
> -  9.1. Authority
> -
> -    1. SPI has no authority regarding Debian's technical or nontechnical
> -       decisions, except that no decision by Debian with respect to any
> -       property held by SPI shall require SPI to act outside its legal
> -       authority, and that Debian's constitution may occasionally use
> SPI -       as a decision body of last resort.
> -    2. Debian claims no authority over SPI other than that over the use
> -       of certain of SPI's property, as described below, though Debian
> -       Developers may be granted authority within SPI by SPI's rules.
> -    3. Debian Developers are not agents or employees of SPI, or of each
> -       other or of persons in authority in the Debian Project. A person
> -       acting as a Developer does so as an individual, on their own
> -       behalf.
>
> -  9.2. Management of property for purposes related to Debian
>
> 

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

[Josselin Mouette]

Le mercredi 23 août 2006 à 17:38 +1000, Anthony Towns a écrit :
> Note that while Peter is currently in the n-m queue (on hold pending
> further response to T&S checks apparently), he's not yet a developer,
> and his expectations shouldn't be inferred to be those of the developers
> as a whole.

And again, contempt before discussion. If you don't want the debate to
be public, you should ask the rules to be changed so that they are held
on a moderated mailing list. Otherwise, the rule is that anyone is free
to contribute to the discussion.

You are the project leader, and as such your are partly responsible for
the image of the project. I don't want (and I hope I'm not the only one)
the project to be associated with your deliberately obnoxious behaviour.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

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

[Enrico Zini]

On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote:

Hi Steve,

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.


Ciao,

Enrico

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


signature.asc
Description: Digital signature

Re: Constitutional Amendment GR: Handling assets for the project

[Kalle Kivimaa]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[-project dropped]

I second the proposal below.

Manoj Srivastava <[EMAIL PROTECTED]> writes:

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

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

[Bas Zoetekouw]

Hi Steve!

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?

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 


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

[Martin Zobel-Helas]

Hi,

i second this proposal.

On Wed, Aug 23, 2006 at 12:18:04AM CEST, Steve Langasek <[EMAIL PROTECTED]> 
wrote:

> 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.
> 
> Andi Barth and I have discussed how we think the DFSG requirements apply to
> firmware and have fairly similar views on the subject, but we also know that
> there are other viewpoints within the project, so we're reluctant to make a
> unilateral decision about firmware handling for the etch release policy
> without finding out how the project as a whole feels about it.  In the
> meantime, the ongoing discussions within the kernel team and without have
> shed, as they say, more heat than light on the subject, so I feel it's time
> to answer this question so we can stop being paralyzed by these differences
> of opinion, agree to disagree, and move forward with the work that needs to
> be done for etch -- whichever set of work we decide that is.
> 
> So below is a proposal that I'm seeking seconds on to establish how DFSG#2
> should be understood to apply to firmware -- i.e., that for Debian's
> purposes firmware should be considered data, not programs, and along with
> other data we should only encourage, not require, source code for firmware
> included in main.  This GR is a position statement, not an amendment to the
> foundation documents, which means a couple of things.  First, it's my
> understanding that there is no 3:1 supermajority requirement here; while the
> Project Secretary has the procedural authority to require a supermajority
> for the vote, I'm likely to consider a GR that fails with > 50% of the vote
> to be an endorsement by the project and proceed accordingly for etch. 
> Second, if developers disagree with this resolution, they are free to ignore
> it and follow the demands of their own conscience in their Debian work -- no
> one is ever *required* to ship a work in main that they believe is not free
> enough for Debian -- they'll just have a statement that the release team,
> and a majority of voting developers in Debian, disagree with them attempting
> to impose this opinion on others.
> 
> It's my hope that this strikes a reasonable balance between respecting the
> views of individual developers and advancing a viable policy for the project
> so that we can move forward together on the goal of making each Debian
> release a first-class, free operating system.
> 
> So, without further ado:
> 
>  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
> image

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

[Martin Zobel-Helas]

Hi,

i second this proposal.

(posted again, this time as signed eMail)

On Wed, Aug 23, 2006 at 12:18:04AM CEST, Steve Langasek <[EMAIL PROTECTED]> 
wrote:

> 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.
> 
> Andi Barth and I have discussed how we think the DFSG requirements apply to
> firmware and have fairly similar views on the subject, but we also know that
> there are other viewpoints within the project, so we're reluctant to make a
> unilateral decision about firmware handling for the etch release policy
> without finding out how the project as a whole feels about it.  In the
> meantime, the ongoing discussions within the kernel team and without have
> shed, as they say, more heat than light on the subject, so I feel it's time
> to answer this question so we can stop being paralyzed by these differences
> of opinion, agree to disagree, and move forward with the work that needs to
> be done for etch -- whichever set of work we decide that is.
> 
> So below is a proposal that I'm seeking seconds on to establish how DFSG#2
> should be understood to apply to firmware -- i.e., that for Debian's
> purposes firmware should be considered data, not programs, and along with
> other data we should only encourage, not require, source code for firmware
> included in main.  This GR is a position statement, not an amendment to the
> foundation documents, which means a couple of things.  First, it's my
> understanding that there is no 3:1 supermajority requirement here; while the
> Project Secretary has the procedural authority to require a supermajority
> for the vote, I'm likely to consider a GR that fails with > 50% of the vote
> to be an endorsement by the project and proceed accordingly for etch. 
> Second, if developers disagree with this resolution, they are free to ignore
> it and follow the demands of their own conscience in their Debian work -- no
> one is ever *required* to ship a work in main that they believe is not free
> enough for Debian -- they'll just have a statement that the release team,
> and a majority of voting developers in Debian, disagree with them attempting
> to impose this opinion on others.
> 
> It's my hope that this strikes a reasonable balance between respecting the
> views of individual developers and advancing a viable policy for the project
> so that we can move forward together on the goal of making each Debian
> release a first-class, free operating system.
> 
> So, without further ado:
> 
>  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 Re

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

[Josselin Mouette]

Le mercredi 23 août 2006 à 09:48 +0100, Enrico Zini a écrit :
> > 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.

I like the idea, but I think it could be better worded.

How about:
4. Determines that as a special exception to DFSG #2, source code for
device firmware will not be required until we have the technical means
to split them out in a convenient way for our users.

(Not perfect either :/ )
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Constitutional Amendment GR: Handling assets for the project

[Anibal Monsalve Salazar]

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: The DFSG do not require source code for data, including firmware

[Aurelien Jarno]

Josselin Mouette a écrit :

Le mercredi 23 août 2006 à 09:48 +0100, Enrico Zini a écrit :

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.


I like the idea, but I think it could be better worded.

How about:
4. Determines that as a special exception to DFSG #2, source code for
device firmware will not be required until we have the technical means
to split them out in a convenient way for our users.

(Not perfect either :/ )


Seconded.

This is a good proposition, as it does not allow firmwares already in 
non-free (eg madwifi) to go into main.



--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

[Andreas Barth]

* Enrico Zini ([EMAIL PROTECTED]) [060823 10:49]:
> On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote:
> > 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.

Though I understand your motivation, I prefer to have this GR
"executable" (hm, is this the right word?), i.e. a text that has as few
as possible disambiguties. If we say "until it will become practical",
anyone can jump up even next week to say "now it is practical". I
however want a statement from all developers "they are not (now)".

Of course, the developers can revisit their decisions later, and if it
has become practical, drop the 4. in another GR when the time has come.
(And frankly speaking, the best way to make changes like that is IMHO a
GR. We just need to learn how to survive GRs without making a flamefest
out of them. :P )



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

[Pierre Habouzit]

Le mer 23 août 2006 11:28, Aurelien Jarno a écrit :
> Josselin Mouette a écrit :
> > Le mercredi 23 août 2006 à 09:48 +0100, Enrico Zini a écrit :
> >>> 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.
> >
> > I like the idea, but I think it could be better worded.
> >
> > How about:
> > 4. Determines that as a special exception to DFSG #2, source code
> > for device firmware will not be required until we have the
> > technical means to split them out in a convenient way for our
> > users.
> >
> > (Not perfect either :/ )
>
> Seconded.
>
> This is a good proposition, as it does not allow firmwares already in
> non-free (eg madwifi) to go into main.

I agree, and I second that too.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpXZUObfvxMZ.pgp
Description: PGP signature

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

[Anthony Towns]

> On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote:
> > Note that while Peter is currently in the n-m queue (on hold pending
> > further response to T&S checks apparently), he's not yet a developer,
> > and his expectations shouldn't be inferred to be those of the developers
> > as a whole.
> > 
> > Working out whether those expectations match those of the developers as
> > a whole is what this GR -- and the discussion preceeding it -- is about.
> > I'd strongly discourage people who participate in the discussion (whether
> > you've run the n-m gauntlet or not) from dismissing developers' concerns
> > about this as a "red herring": if you're right, you shouldn't be afraid to
> > discuss the reasons why you're right in detail when asked.

On Wed, Aug 23, 2006 at 09:56:25AM +0200, Sven Luther wrote:
> To add to that, if i where Peter, i may feel slightly offended by the tone of
> your reply as well as the content of it. You are the DPL, and as thus speak
> with the authority given by the whole project, and i think you should as such
> be a more careful in your wording.

I was entirely careful in my wording. Peter is in the n-m queue, he
isn't a developer, and while he has every right to his personal views,
as do you and as do I, those views don't necessarily match those of the
majority of other developers or the project as a whole, and we should
be very careful not to accidently quash discussion of other points of
view by being so vehement in our own views that other people don't think
their view is welcome.

On Wed, Aug 23, 2006 at 10:28:03AM +0200, Josselin Mouette wrote:
> And again, contempt before discussion. If you don't want the debate to
> be public, you should ask the rules to be changed so that they are held
> on a moderated mailing list. Otherwise, the rule is that anyone is free
> to contribute to the discussion.

Indeed, and I specifically pointed that out in my mail. I hope you agree
that I'm also free to participate and point out Peter's participation
in the project isn't what people might assume from the authority with
which he imbues his views, if I think that's valuable.

People posting to Debian lists should be doing so on the strengths of
their arguments -- and if they are doing so, pointing out that they're
not a maintainer should have absolutely no effect on the success of their
arguments. If it emboldens developers to post about their opinions even
when they disagree with what appears to be consensus, then that will
only help avoid misunderstanding their views in future: because at the
end of the day it's the developers' views that determine Debian's view,
not any one else's.

> You are the project leader, and as such your are partly responsible for
> the image of the project. I don't want (and I hope I'm not the only one)
> the project to be associated with your deliberately obnoxious behaviour.

Then I would suggest you debate the issue on its merits, rather than
making the topic of debate be your views on my character. 

If you believe a comment on a list has no merit, it's very easy to deal
with it: just ignore it, and go on discussing the ideas that are worth
discussing.

Cheers,
aj



signature.asc
Description: Digital signature

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

[Andreas Barth]

* Aurelien Jarno ([EMAIL PROTECTED]) [060823 11:28]:
> Josselin Mouette a écrit :
> >Le mercredi 23 août 2006 à 09:48 +0100, Enrico Zini a écrit :
> >>>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.
> >
> >I like the idea, but I think it could be better worded.
> >
> >How about:
> > 4. Determines that as a special exception to DFSG #2, source code for
> >device firmware will not be required until we have the technical means
> >to split them out in a convenient way for our users.
> >
> >(Not perfect either :/ )
> 
> Seconded.
> 
> This is a good proposition, as it does not allow firmwares already in 
> non-free (eg madwifi) to go into main.

I heavily disagree to this change. It makes the text unpredictable.
Please keep the current way and, if we want to say something, make it
something like:
4. determines that for the purposes of DFSG #2, device firmware
shall also not be considered a program; the Debian project intends to
revisit this decision at a later time.

Also, we are currently converting firmware from the broken way (i.e.
included inside the kernel) to a better way. I don't think that it is a
good idea to make the requirements for the (technical and social) better
implementation tougher than for the old implementation (and also,
technical differenes shouldn't make an ethical difference).



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

[Josselin Mouette]

Le mercredi 23 août 2006 à 11:51 +0200, Andreas Barth a écrit :
> Also, we are currently converting firmware from the broken way (i.e.
> included inside the kernel) to a better way. I don't think that it is a
> good idea to make the requirements for the (technical and social) better
> implementation tougher than for the old implementation (and also,
> technical differenes shouldn't make an ethical difference).

The idea is to force the split as soon as a technical way is provided
for a driver. This way, we will not discourage people from providing
patches to split out firmwares, as the maintainer would then
(theoretically) be forced to accept the patch.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

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

[p2]

> Though I understand your motivation, I prefer to have this GR
> "executable" (hm, is this the right word?), i.e. a text that has as few
> as possible disambiguties. If we say "until it will become practical",
> anyone can jump up even next week to say "now it is practical". I
> however want a statement from all developers "they are not (now)".
> 

I'm only willing to give you : They are, but I'm willing to live with it
for now as I don't have a good idea yet on what is acceptable and what
not.

L & L

p2.

-- 
Goa is a state of mind


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

[Josselin Mouette]

Le mercredi 23 août 2006 à 19:19 +1000, Anthony Towns a écrit :
> If you believe a comment on a list has no merit, it's very easy to deal
> with it: just ignore it, and go on discussing the ideas that are worth
> discussing.

Why would I do that, when you are taking the opposite way? When you
believe a commend on a list has no merit, you explicitly ask other
people to ignore it, based on a stupid DD/non-DD segregation instead of
the merits of the comment.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

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

[Florian Weimer]

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

It seems the present language also covers CA certificates, which is
fine.

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.


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

[Matthew Garrett]

Aurelien Jarno <[EMAIL PROTECTED]> wrote:

> This is a good proposition, as it does not allow firmwares already in 
> non-free (eg madwifi) to go into main.

Madwifi contains non-free code that runs inside the kernel on the host 
processor. Whatever the project's opinion on firmware, madwifi is 
clearly non-free.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

[Sven Luther]

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)

Notice that the bios or other firmware used on most machines today is also
refered as firmware. The original definition is, i believe, any kind of code
provided by the vendor of said device, and on which he has full control, so
firmware was non-free by definition originally.

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

This is a moot point, since the communication protocol between the firmware
and the actual kernel driver is well established, or more precisely, the
driver never speaks with the firmware, but with the device it is uploaded to,
and there is no difference between a driver for a non-firmware peripheral and
a firmware peripheral in this sense.

> It seems the present language also covers CA certificates, which is
> fine.
> 
> 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.

Well, there are two issues here :

  1) we should always ask for a relicencing in a not-GPL like licence for
  firmware lacking source. It is almost always the case that there is indeed
  such a upper source (even a banal C code or shell script which transforms
  the register dump in hexdump), and in any case we should thus suppose by
  default that the firmware is not the prefered form of modification.

  2) given that the copyright holder is the one distributing the files under a
  messed up licencing, and that he is the only one who could sue us over it,
  the risk that he actually does so is pretty much limited, as is the risk
  that he actually wins in court if he where to do it. Other linux copyright
  holder have no right to sue, because the firmware in question consitutes a
  distinct agregated work just being transported inside the kernel, not a
  derivative work.

Friendly,

Sven Luther


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

[Nick Phillips]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Langasek wrote:

> So, without further ado:
>
> 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.
>
> ==
>
>
>

I think this is a well thought out and sensible proposal, and will
therefore second it.


Cheers,


Nick
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE7DNedZJIm8yYOSgRAnGaAJwK71Y+6ldX18nhZuJXWh9zenL0qACfY4yT
4pb+tkEEvzWLvDz7pQPMFcU=
=F13b
-END PGP SIGNATURE-


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

[Martin Wuertele]

* Steve Langasek <[EMAIL PROTECTED]> [2006-08-23 00:18]:

>  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

I agree up to this point, however

> 4. determines that for the purposes of DFSG #2, device firmware
> shall also not be considered a program.
 
I don't agree with this point.

However I am in favour of an exeption for firmware programs for the
upcoming etch release.

yours Martin
-- 
<[EMAIL PROTECTED]>  Debian GNU/Linux - The Universal Operating System
 weasel: wenn du typo3 auf die asteria gibt, dann lock ich dich
eigenhändig aus

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

[Loïc Minier]

On Wed, Aug 23, 2006, Matthew Garrett wrote:
> > This is a good proposition, as it does not allow firmwares already in 
> > non-free (eg madwifi) to go into main.
> Madwifi contains non-free code that runs inside the kernel on the host 
> processor. Whatever the project's opinion on firmware, madwifi is 
> clearly non-free.

 Yes, that's why we (including Aurélien) want to keep it in non-free.

-- 
Loïc Minier <[EMAIL PROTECTED]>


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

[Floris Bruynooghe]

On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote:
> On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote:
> > [Steve Langasek]
> > > 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?
> > The day Debian begins to distribute ROM chips, or devices containing
> > ROM chips, I will expect those chips to come with source code.  Until
> > then, this is a red herring.
> 
> Note that while Peter is currently in the n-m queue (on hold pending
> further response to T&S checks apparently), he's not yet a developer,
> and his expectations shouldn't be inferred to be those of the developers
> as a whole.

Interesting, is this why the discussion is on a public mailing list?
Personally I am not a DD either nor am I in the NM queu, however I was
always under the impression that my opinion as a users matters (and
should matter IMHO) to Debian anyway.

In contrast to Sven and Josselin I'm not going to blame you for doing
this statement as DPL as your From: address did not say so.  But
otherwise I wholehartedly agree with them.

As for the issue at hand here I must also agree with Peter and Sven:
Debian doesn't distribute chips with non-free firmware currently.  So
if Debian wants to distribute non-free binary-only firmware I do hope
it will do so in non-free and not in main.

Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.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

[Sven Luther]

On Wed, Aug 23, 2006 at 07:19:24PM +1000, Anthony Towns wrote:
> > On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote:
> > > Note that while Peter is currently in the n-m queue (on hold pending
> > > further response to T&S checks apparently), he's not yet a developer,
> > > and his expectations shouldn't be inferred to be those of the developers
> > > as a whole.
> > > 
> > > Working out whether those expectations match those of the developers as
> > > a whole is what this GR -- and the discussion preceeding it -- is about.
> > > I'd strongly discourage people who participate in the discussion (whether
> > > you've run the n-m gauntlet or not) from dismissing developers' concerns
> > > about this as a "red herring": if you're right, you shouldn't be afraid to
> > > discuss the reasons why you're right in detail when asked.
> 
> On Wed, Aug 23, 2006 at 09:56:25AM +0200, Sven Luther wrote:
> > To add to that, if i where Peter, i may feel slightly offended by the tone 
> > of
> > your reply as well as the content of it. You are the DPL, and as thus speak
> > with the authority given by the whole project, and i think you should as 
> > such
> > be a more careful in your wording.
> 
> I was entirely careful in my wording. Peter is in the n-m queue, he
> isn't a developer, and while he has every right to his personal views,
> as do you and as do I, those views don't necessarily match those of the
> majority of other developers or the project as a whole, and we should

Well, the only one who could claim that his views have some representativity
of the project as a whole is you, everyone else is just expressing his own
opinion, be he a DD or a guy from NM or some random poster.

> be very careful not to accidently quash discussion of other points of
> view by being so vehement in our own views that other people don't think
> their view is welcome.

Well. do we chip hardare, and as thus have the content of their ROMs covered
by the DFSG ? I am not aware of such a situation, and altough Peter may have
not said it in the best way, remember that for all those non-native english
speakers there is a language barrier there, which may not be visible
immediately, but which causes choice of non-perfectly-adequate wordings
because of lack of vocabulary, or missing the subltetlies of various wording
possibilities and misjudging the strength of them.

You on the other side don't have this excuse :)

Friendly,

Sven Luther


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

[Anthony Towns]

On Wed, Aug 23, 2006 at 12:03:17PM +0200, Floris Bruynooghe wrote:
> On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote:
> > Note that while Peter is currently in the n-m queue (on hold pending
> > further response to T&S checks apparently), he's not yet a developer,
> > and his expectations shouldn't be inferred to be those of the developers
> > as a whole.
> Interesting, is this why the discussion is on a public mailing list?
> Personally I am not a DD either nor am I in the NM queu, however I was
> always under the impression that my opinion as a users matters (and
> should matter IMHO) to Debian anyway.

Just to be clear: you're completely correct, users' opinions do matter,
and the opinions of people in the new-maintainer queue are pretty much
on a par with individual developers' opinions, except that they don't
actually get counted when it comes time to tally the votes.

Sometimes, some opinions won't be addressed because others will take
precedence -- such as "it'd be great if perl weren't essential" not
being addressed due to the complexity of doing so and the tradeoffs
that would involve; but that doesn't mean the opinion isn't valued,
or that it won't be addressed later if it becomes possible.

I didn't say Peter's take didn't matter, because personally I consider
it self-evident and unarguable that it does matter. The followup was
only intended to make sure it was clear that it *was* Peter's take,
and not necessarily the project's, and that debate is still appropriate.

And *this* one I will sign as DPL.

Cheers,
aj

-- 
Anthony Towns
Debian Project Leader


signature.asc
Description: Digital signature

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

[Anthony Towns]

On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote:
> Well, the only one who could claim that his views have some representativity
> of the project as a whole is you, everyone else is just expressing his own
> opinion, be he a DD or a guy from NM or some random poster.

Anyone can claim their views are representative of the project, and
everyone -- including myself -- would be wrong to do so. 

The project has procedures for establishing its views on subjects: be that
by package maintainers having opinions about their packages, discussions
on mailing lists, setting policies, decisions by delegates, the technical
committee or the project secretary, or having a vote about it.

There are a few people who are authorised to speak on behalf of the
project, including myself, Steve McIntyre as 2IC [0], and Joey Schulze as
press officer. But none of those people get to cast their own views as
the project's -- they simply have been entrusted by the project through
the appropriate means to put the project's views into words.

But Peter wasn't claiming that his views were the project's by any means
-- he simply stated them in a way that, in my opinion, is easily mistaken
for a statement of a pre-existing consensus on behalf of the project. 

There is no such consensus, however -- if there were, there would have
been no one to raise this GR in the first place -- and this process
of discussion and voting is how the project forms its opinion on the
subject, which may well end up being entirely different to Peter's
opinion, or yours, or mine.

> Well. do we chip hardare, and as thus have the content of their ROMs covered
> by the DFSG ? 

We choose to apply the DFSG both to the components that the Debian system
requires, and to what we use to provide debian.org services. It can be
reasonably argued that non-free firmware encoded in ROMs is involved in
both cases.

I'm reluctant to argue for or against either of those, since I don't
know what the project's view on these things is or will be, and I don't
want anyone to be confused into thinking that my personal view on this
is the project's.

I'm entirely comfortable in saying that it's an issue worth discussing
though, because that's both my personal view and, in my opinion, the
project's view.

> I am not aware of such a situation, and altough Peter may have
> not said it in the best way, remember that for all those non-native english
> speakers there is a language barrier there, [...]

TTBOMK, and according to whois, Peter is US based, and a native speaker...

Cheers,
aj

[0] http://lists.debian.org/debian-devel-announce/2006/04/msg00015.html



signature.asc
Description: Digital signature

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

[Marco d'Itri]

[EMAIL PROTECTED] wrote:

>Why is freedom of software only important for the central
> processing unit, but immaterial for other processing usints?
Who said it's not important? I believe it is, just that it's not a
battle which should be pursued by Debian by not distributing sourceless
firmwares.
It is clear that by banning firmwares from Debian we harm our users
(easily verifiable) much more than we help the cause of free software
(it's hard to prove that it would be of any help, and the burden of
proof lies on who supports it).

>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/ 
OK. Let's get back to this when it will be a problem.

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

>So, unless otherwise stated, the foundation document terms
> refer to commonly understood meanings of words; looking to
> dictionaries, encyclopedias, and common references.
I'd say that they refer to the meaning commonly accepted by developers.

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

[Marco d'Itri]

[EMAIL PROTECTED] wrote:

>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.
There is hardly a consensus on this, so I expect that the ftpmasters
will decide what to do (or decide nothing and continue as usual and as
other distributions who retain real laywers do).

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

[Marco d'Itri]

[EMAIL PROTECTED] wrote:

>On Wed, Aug 23, 2006, Matthew Garrett wrote:
>> > This is a good proposition, as it does not allow firmwares already in 
>> > non-free (eg madwifi) to go into main.
>> Madwifi contains non-free code that runs inside the kernel on the host 
>> processor. Whatever the project's opinion on firmware, madwifi is 
>> clearly non-free.
> Yes, that's why we (including Aurélien) want to keep it in non-free.
Like everybody else AFAIK, so it's not clear why this unrelated
package is being used as an example.

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

[Marco d'Itri]

[EMAIL PROTECTED] wrote:

>I heavily disagree to this change. It makes the text unpredictable.
I support your disagreement for the reasons you explained and also
because separating the firmwares from the kernel would not solve the
problem of making them available to Debian users.

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

[Matthew Wilcox]

Manoj wrote:
> Actually, I disagree, and, even worse, so does the common
> definition of the phrase computer program:  asking google about
> define: computer program gives:
> ,
> | * A computer program is a set of statements or instructions to be
> |   used directly or indirectly in a computer in order to bring
> |   about a certain result. 
> |
> www.tms.org/pubs/journals/JOM/matters/matters-9710.html

But Debian has a tradition of ignoring the common definition of phrases.
Have you tried asking google to define software, for example?

I think the key distinction (as far as I'm concerned) is that Debian
isn't producing a distribution for the microcontroller in my
fibrechannel card, it's producing a distribution for my computer.
In order to make my fibrechannel card work, it has to poke some bits
in a documented way.  Even if there happens to be an ARM onboard that
card that's running a program, that ARM isn't running Debian.

I second Steve's proposal (although I can't be bothered to go to the
hassle of signing this message right now.  If it becomes important to do
so, I shall.)


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

[Andreas Barth]

* Loïc Minier ([EMAIL PROTECTED]) [060823 13:37]:
> On Wed, Aug 23, 2006, Matthew Garrett wrote:
> > > This is a good proposition, as it does not allow firmwares already in 
> > > non-free (eg madwifi) to go into main.
> > Madwifi contains non-free code that runs inside the kernel on the host 
> > processor. Whatever the project's opinion on firmware, madwifi is 
> > clearly non-free.
> 
>  Yes, that's why we (including Aurélien) want to keep it in non-free.

But that doesn't get changed then anyways with Steve's proposal.



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

[Sven Luther]

On Wed, Aug 23, 2006 at 09:24:16PM +1000, Anthony Towns wrote:
> On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote:
> > Well, the only one who could claim that his views have some representativity
> > of the project as a whole is you, everyone else is just expressing his own
> > opinion, be he a DD or a guy from NM or some random poster.
> 
> Anyone can claim their views are representative of the project, and
> everyone -- including myself -- would be wrong to do so. 

So, why do you denigrate Peter in such a way ? What you said could apply as
well to you, no ? 

> The project has procedures for establishing its views on subjects: be that
> by package maintainers having opinions about their packages, discussions
> on mailing lists, setting policies, decisions by delegates, the technical
> committee or the project secretary, or having a vote about it.
> 
> There are a few people who are authorised to speak on behalf of the
> project, including myself, Steve McIntyre as 2IC [0], and Joey Schulze as
> press officer. But none of those people get to cast their own views as
> the project's -- they simply have been entrusted by the project through
> the appropriate means to put the project's views into words.

Ok.

> But Peter wasn't claiming that his views were the project's by any means
> -- he simply stated them in a way that, in my opinion, is easily mistaken
> for a statement of a pre-existing consensus on behalf of the project. 

I guess he never said so, he just worded his argumentation in such a way, that
he thought his position was comon sense. Also, since in the previous cases i
was involved in the non-free firmware issue, many people chose to use the same
argument, both in the debian-legal threads and elsewhere.

> There is no such consensus, however -- if there were, there would have



There is no such consensus that debian doesn't chip hardware ? I think we
don't need consensus, these are plain facts, and we even advertize them on our
web site, so i think there is some major misunderstanding about this going on.

> been no one to raise this GR in the first place -- and this process
> of discussion and voting is how the project forms its opinion on the
> subject, which may well end up being entirely different to Peter's
> opinion, or yours, or mine.

Indeed, so, why did you need to resort to such bass tactics as an ad-hominem
attack on Peter using his non-DD status ? 

> > Well. do we chip hardare, and as thus have the content of their ROMs covered
> > by the DFSG ? 
> 
> We choose to apply the DFSG both to the components that the Debian system
> requires, and to what we use to provide debian.org services. It can be
> reasonably argued that non-free firmware encoded in ROMs is involved in
> both cases.

 

huh ? 

That would be the first time i hear anyone say this with a straigth face or
really meaning it. If you would get look at the logs, i have used that same
argumentation in the debian-legal thread last year, but with a
proof-as-asburdum, or however it is called, way.

If we where really going to argue this, we could just as well stop shiping
debian, since there is no way to actually make use of any of the content we
ship without some piece of non-free firmware, the first of it being the
non-free bios you use on your system.

> I'm reluctant to argue for or against either of those, since I don't
> know what the project's view on these things is or will be, and I don't
> want anyone to be confused into thinking that my personal view on this
> is the project's.

Maybe, but then you don't make statements as you did, going away from arguing
about the non-free matter, and into polemics about if non-DDs are allowed to
post and comment, or if they should show due respect to the venerable DDs and
be silent, and not contradict one's better.

> I'm entirely comfortable in saying that it's an issue worth discussing
> though, because that's both my personal view and, in my opinion, the
> project's view.

So ? How does that excuse the comment you made. This is completely irrelevant
to the critic raised against your comment.

> > I am not aware of such a situation, and altough Peter may have
> > not said it in the best way, remember that for all those non-native english
> > speakers there is a language barrier there, [...]
> 
> TTBOMK, and according to whois, Peter is US based, and a native speaker...

So much for that then.

Friendly,

Sven Luther


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

[Sven Luther]

On Wed, Aug 23, 2006 at 09:35:30PM +1000, Anthony Towns wrote:
> I didn't say Peter's take didn't matter, because personally I consider
> it self-evident and unarguable that it does matter. The followup was
> only intended to make sure it was clear that it *was* Peter's take,
> and not necessarily the project's, and that debate is still appropriate.
> 
> And *this* one I will sign as DPL.

Aj, ...

I would be very interested in an explanation of you, explaining why this was
necessary in this case ? I don't think Peter claimed to represent the Debian's
consensus, and even if he did say his comment in a rather authoritative way,
this is common usage, and many transpose their strong opinion in such a way.

Friendly,

Sven Luther


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

[Sven Luther]

On Wed, Aug 23, 2006 at 02:11:39PM +0200, Marco d'Itri wrote:
> [EMAIL PROTECTED] wrote:
> 
> >Why is freedom of software only important for the central
> > processing unit, but immaterial for other processing usints?
> Who said it's not important? I believe it is, just that it's not a
> battle which should be pursued by Debian by not distributing sourceless
> firmwares.
> It is clear that by banning firmwares from Debian we harm our users
> (easily verifiable) much more than we help the cause of free software
> (it's hard to prove that it would be of any help, and the burden of
> proof lies on who supports it).

Indeed, but would it not make more sense, to aknowledge that the firmware is
non-free, and then argue that we should include it nonetheless, instead of
making obviously false claims like "firmware are not programs" ?

> >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. A majority of the DDs voted
that, and unless there is another GR reverting this, that opinion is binding
to the project.

That said, Steve's GR is not the most smart way to solve this issue.

Friendly,

Sven Luther


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

[Sven Luther]

On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote:
> Manoj wrote:
> > Actually, I disagree, and, even worse, so does the common
> > definition of the phrase computer program:  asking google about
> > define: computer program gives:
> > ,
> > | * A computer program is a set of statements or instructions to be
> > |   used directly or indirectly in a computer in order to bring
> > |   about a certain result. 
> > |
> > www.tms.org/pubs/journals/JOM/matters/matters-9710.html
> 
> But Debian has a tradition of ignoring the common definition of phrases.
> Have you tried asking google to define software, for example?
> 
> I think the key distinction (as far as I'm concerned) is that Debian
> isn't producing a distribution for the microcontroller in my
> fibrechannel card, it's producing a distribution for my computer.
> In order to make my fibrechannel card work, it has to poke some bits
> in a documented way.  Even if there happens to be an ARM onboard that
> card that's running a program, that ARM isn't running Debian.

One of the purposes of having access to the prefered form of modification, is
to be able to fix bugs.

If the firmware for your fibrechannel card has a bug, are you currently able
to fix it ? And if so, do you think the binary-only firmware you have
available is the prefered form of modification ?

Friendly,

Sven Luther


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

[Marco d'Itri]

On Aug 23, Sven Luther <[EMAIL PROTECTED]> wrote:

> Indeed, but would it not make more sense, to aknowledge that the firmware is
> non-free, and then argue that we should include it nonetheless, instead of
> making obviously false claims like "firmware are not programs" ?
"Firmwares are not programs *for the purpose of DFSG compliance*" is a
statement which may or may not be true, but will not obviously false
(or not) until we will known the outcome of this GR.
I do not mind either way anyway, my purpose it to make Debian an useful
and free (as-in-freedom) Linux distribution, not arguing about the
general definition of the word "firmware".

-- 
ciao,
Marco


signature.asc
Description: Digital signature

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

[Marco d'Itri]

[EMAIL PROTECTED] wrote:

>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?
Thank you for your proposal.
While I was thinking about a different proposal (both wider and narrower
in scope), I like this and fully support it.
I appreciate your attempt in verifying if the majority of developers
still believes in the DFSG as it used to be intended until the
DFSG-revisionists colonized [EMAIL PROTECTED]


It should be noted that this will still not allow distribution of
firmwares used by some popular devices which are freely distributable
but not modifiable. Nor will this solve the problem of the Firefox logo,
so looks like I will need to propose a new GR myself. But I will not be
able to work on it before the winter.

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

[Bernhard R. Link]

* Josselin Mouette <[EMAIL PROTECTED]> [060823 11:15]:
> Le mercredi 23 août 2006 à 09:48 +0100, Enrico Zini a écrit :
> > > 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.
> 
> I like the idea, but I think it could be better worded.
> 
> How about:
>   4. Determines that as a special exception to DFSG #2, source code for
> device firmware will not be required until we have the technical means
> to split them out in a convenient way for our users.

I'd rather suggest to give a direct hint in time. Like "until etch
releases", so that people wanting non-free firmware have to do the
techical stuff and not the people wanting control over what their
computer do.

Hochachtungsvoll,
Bernhard R. Link


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

[Jacobo Tarrio]

El miércoles, 23 de agosto de 2006 a las 21:24:16 +1000, Anthony Towns escribía:

> We choose to apply the DFSG both to the components that the Debian system
> requires, and to what we use to provide debian.org services. It can be

 No, the DFSG are applied to what's provided by Debian, not to what it's
required by it.

-- 
   Jacobo Tarrío | http://jacobo.tarrio.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

[Martin Schulze]

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.

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.

Regards,

Joey

-- 
Never trust an operating system you don't have source for!


signature.asc
Description: Digital signature

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

[Lars Wirzenius]

ke, 2006-08-23 kello 10:30 +0200, Bas Zoetekouw kirjoitti:
> > 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?

I would like that too.

-- 
Debian is a beast that speaks with many voices -- Richard Braakman


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

[Sven Luther]

On Wed, Aug 23, 2006 at 03:00:49PM +0200, Bernhard R. Link wrote:
> * Josselin Mouette <[EMAIL PROTECTED]> [060823 11:15]:
> > Le mercredi 23 août 2006 à 09:48 +0100, Enrico Zini a écrit :
> > > > 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.
> > 
> > I like the idea, but I think it could be better worded.
> > 
> > How about:
> > 4. Determines that as a special exception to DFSG #2, source code for
> > device firmware will not be required until we have the technical means
> > to split them out in a convenient way for our users.
> 
> I'd rather suggest to give a direct hint in time. Like "until etch
> releases", so that people wanting non-free firmware have to do the
> techical stuff and not the people wanting control over what their
> computer do.

Notice that we already did say so before the sarge release, and even had a GR
about it, and look where we are today.

Should we say until etch is released, just to have to go to another 
GR for etch+1 ? 

Friendly,

Sven Luther


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

[Sven Luther]

On Wed, Aug 23, 2006 at 07:14:03AM -0600, Matthew Wilcox wrote:
> On Wed, Aug 23, 2006 at 02:44:48PM +0200, Sven Luther wrote:
> > On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote:
> > > I think the key distinction (as far as I'm concerned) is that Debian
> > > isn't producing a distribution for the microcontroller in my
> > > fibrechannel card, it's producing a distribution for my computer.
> > > In order to make my fibrechannel card work, it has to poke some bits
> > > in a documented way.  Even if there happens to be an ARM onboard that
> > > card that's running a program, that ARM isn't running Debian.
> > 
> > One of the purposes of having access to the prefered form of modification, 
> > is
> > to be able to fix bugs.
> 
> Certainly, it's one of the purposes.  But I don't think we've *lost*
> anything by distributing binary firmware.  Consider the cases:
> 
> 1. Everything in hardware.  You're not able to fix anything without a
>soldering iron ... and good luck to you with that.
> 2. Unmodifiable firmware in EEPROM.  Need an EEPROM programmer, and a
>good deal of skill to fix anything.  Again, best of luck.
> 3. Binary-only firmware in the driver.  Slightly better chance of trying
>to figure out what's going on, but still low.
> 4. Firmware source in non-preferred form.  Modifications probably
>possible, but when the next round of changes come out from the
>vendor, you probably have to ditch your mods.
> 5. Firmware source in preferred form.  Can send changes back to vendor,
>everybody wins.
> 
> (and I'm sure people can think of other finer distinctions).

Notice that i don't disagree with you, i even have argued, altough maybe in a
more clumsy way, exactly the same thingas you.

My point is that if we believe the above, then we should say so, namely :

  firmware is non-free.

  but we chose to keep it, because it is globally more free than the
  firmware-less alternatives or other reasons.

This is what you claim, and what everyone thinks who support the "keep
firmware in main" way, so why not be open about it and say it so ? 

> You seem to want to disallow cases 3 and 4 which makes sense from a
> "here are the rules of data freedom, now i must follow them" point of
> view, but really don't make sense to the vendor, nor to the user.  It
> seems like an all-or-nothing approach.

I did say nothing of the sort.

> Actually, I can turn your argument on its head.  The point you're making
> is about ease of fixing bugs.  Given case 3, I can't fix the bug myself,
> but I have in the past been able to get the vendor to fix the bug.  In
> case 2 (which your argument would seem happy with), I can't fix the bug
> at all.  So cases 3 and 4 are *better* from a bug fixing point of view.

Nope, my argument is unrelated to this, it is related to calling things as
they are and not play word-games just because the reality inconveniences us.

Friendly,

Sven Luther


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

[Sven Luther]

On Wed, Aug 23, 2006 at 03:00:07PM +0200, Marco d'Itri wrote:
> In linux.debian.vote Sven Luther <[EMAIL PROTECTED]> wrote:
> 
> >On Wed, Aug 23, 2006 at 09:24:16PM +1000, Anthony Towns wrote:
> >> On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote:
> >> > Well, the only one who could claim that his views have some 
> >> > representativity
> >> > of the project as a whole is you, everyone else is just expressing his 
> >> > own
> >> > opinion, be he a DD or a guy from NM or some random poster.
> >> Anyone can claim their views are representative of the project, and
> >> everyone -- including myself -- would be wrong to do so. 
> >So, why do you denigrate Peter in such a way ? What you said could apply as
> >well to you, no ? 
> Why do you believe that remarking that somebody is not a debian
> developer is "denigration"?
> I think aj's post was very appropriate, considering how many
> non-developers like to explain to us what the DFSG "really means".

Well, i and at least 2 other people felt it like that, so if nothing else, the
wording of Anthony's comment sucked.

> >If we where really going to argue this, we could just as well stop shiping
> >debian, since there is no way to actually make use of any of the content we
> >ship without some piece of non-free firmware, the first of it being the
> >non-free bios you use on your system.
> Unpleasant consequences are not a very good way of refuting a logically
> sound argument.

No, but they show the consequences of what you are arguing, and ask the
question of if we really want to go this way, instead of just saying it for
the case that is of interest, and ignore the full consequences of it.

Friendly,

Sven Luther


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

[Matthew Wilcox]

On Wed, Aug 23, 2006 at 02:44:48PM +0200, Sven Luther wrote:
> On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote:
> > I think the key distinction (as far as I'm concerned) is that Debian
> > isn't producing a distribution for the microcontroller in my
> > fibrechannel card, it's producing a distribution for my computer.
> > In order to make my fibrechannel card work, it has to poke some bits
> > in a documented way.  Even if there happens to be an ARM onboard that
> > card that's running a program, that ARM isn't running Debian.
> 
> One of the purposes of having access to the prefered form of modification, is
> to be able to fix bugs.

Certainly, it's one of the purposes.  But I don't think we've *lost*
anything by distributing binary firmware.  Consider the cases:

1. Everything in hardware.  You're not able to fix anything without a
   soldering iron ... and good luck to you with that.
2. Unmodifiable firmware in EEPROM.  Need an EEPROM programmer, and a
   good deal of skill to fix anything.  Again, best of luck.
3. Binary-only firmware in the driver.  Slightly better chance of trying
   to figure out what's going on, but still low.
4. Firmware source in non-preferred form.  Modifications probably
   possible, but when the next round of changes come out from the
   vendor, you probably have to ditch your mods.
5. Firmware source in preferred form.  Can send changes back to vendor,
   everybody wins.

(and I'm sure people can think of other finer distinctions).

You seem to want to disallow cases 3 and 4 which makes sense from a
"here are the rules of data freedom, now i must follow them" point of
view, but really don't make sense to the vendor, nor to the user.  It
seems like an all-or-nothing approach.

Actually, I can turn your argument on its head.  The point you're making
is about ease of fixing bugs.  Given case 3, I can't fix the bug myself,
but I have in the past been able to get the vendor to fix the bug.  In
case 2 (which your argument would seem happy with), I can't fix the bug
at all.  So cases 3 and 4 are *better* from a bug fixing point of view.


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

[Matthew Garrett]

Jacobo Tarrio <[EMAIL PROTECTED]> wrote:
> El miércoles, 23 de agosto de 2006 a las 21:24:16 +1000, Anthony Towns 
> escribía:
> 
>> We choose to apply the DFSG both to the components that the Debian system
>> requires, and to what we use to provide debian.org services. It can be
> 
>  No, the DFSG are applied to what's provided by Debian, not to what it's
> required by it.

The DFSG apply to "The Debian system". The social contract doesn't 
define what "The Debian system" is. We could define it as "What's 
shipped by Debian", but we could also define it as "A system consisting 
of a computer and a Debian installation" or "Whatever is provided by 
Debian and run on the host processor".

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

[Jacobo Tarrio]

El miércoles, 23 de agosto de 2006 a las 14:59:37 +0100, Matthew Garrett 
escribía:

> >  No, the DFSG are applied to what's provided by Debian, not to what it's
> > required by it.
> The DFSG apply to "The Debian system". The social contract doesn't 
> define what "The Debian system" is. We could define it as "What's 

 No, but it says that Debian are "the producers of the Debian GNU/Linux
system" (should be fixed some day). So, the Debian system does not include
anything not "produced" (or provided) by Debian.

-- 
   Jacobo Tarrío | http://jacobo.tarrio.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

[Bernhard R. Link]

* Sven Luther <[EMAIL PROTECTED]> [060823 15:24]:
 > I'd rather suggest to give a direct hint in time. Like "until etch
> > releases", so that people wanting non-free firmware have to do the
> > techical stuff and not the people wanting control over what their
> > computer do.
> 
> Notice that we already did say so before the sarge release, and even had a GR
> about it, and look where we are today.
> 
> Should we say until etch is released, just to have to go to another 
> GR for etch+1 ? 

It's already getting better. Last time it also included things that
are not allowed to be modified. For most things it is only about things
to hard to modify (no source). And for the exception limited to firmware.
(Which I still do not know what it is exactly supposed to say.)

So I really prefer some automatically terminating rule, as most
arguments I have heard about firmware is that the infrastructure is said
to be not yes ready.

Hochachtungsvoll,
Bernhard R. Link


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

[Anthony Towns]

Followups set to -vote; why are we cc'ing this across multiple lists?

On Wed, Aug 23, 2006 at 03:01:52PM +0200, Jacobo Tarrio wrote:
> El mi?rcoles, 23 de agosto de 2006 a las 21:24:16 +1000, Anthony Towns 
> escrib?a:
> > We choose to apply the DFSG both to the components that the Debian system
> > requires, and to what we use to provide debian.org services. It can be
> No, the DFSG are applied to what's provided by Debian, not to what it's
> required by it.

The DFSG is Debian's definition of free, so it's applied to everything
we think should be free. That includes most of the contents of main and
contrib (one notable exception is license texts), everything that main
"requires", and generally what we run on our servers.

The middle one's the one of interest, it's expressed in the first point
of the social contract as:

"We will never make the system require the use of a non-free
 component."

(For reference, that replaced the following text from v1.0 of the social
contract:

"[...] we will never make the system depend on an item of non-free
 software."
)

Cheers,
aj



signature.asc
Description: Digital signature

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

[Manoj Srivastava]

On Wed, 23 Aug 2006 14:11:39 +0200 (CEST), Marco d'Itri <[EMAIL PROTECTED]> 
said: 

> [EMAIL PROTECTED] wrote:
>> Why is freedom of software only important for the central
>> processing unit, but immaterial for other processing usints?
> Who said it's not important? I believe it is, just that it's not a
> battle which should be pursued by Debian by not distributing
> sourceless firmwares.  It is clear that by banning firmwares from
> Debian we harm our users (easily verifiable) much more than we help
> the cause of free software (it's hard to prove that it would be of
> any help, and the burden of proof lies on who supports it).

I would have no problems with that, as long as we did not
 weasel around it by redefining words. Now, I would supporyt the
 decision if Debian actually was forthright about the opinion you
 express (I disagree, but that is just a difference of opinion).  If
 we want to express that some class of software can be in main despite
 there not being the source or preferred form of modification, then we
 should say so -- in the document that promises that programs, even
 code that is not executed by the primary processor -- will be free.

>> 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/
> OK. Let's get back to this when it will be a problem.

Firstly, general resolutions are expensive, and we should not
 do one just to turn arund almost immediately -- since the cell
 processor will be released within a year in the form of the PS3, and
 cell based PC's are just around the corner. We already have graphical
 processing units, physics processing unit, and various comminication
 units etc in production now.

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

Calling me silly for reading the social contract which was
 editorially changed by a supermajority of developers in the project
 to say that every bit in main shall be free does you little credit.

>> So, unless otherwise stated, the foundation document terms refer to
>> commonly understood meanings of words; looking to dictionaries,
>> encyclopedias, and common references.

> I'd say that they refer to the meaning commonly accepted by
> developers.

I would say that if the definition commonly accepted by the
 developers is at odds with textbooks, references, and technical
 dictionaries, then I think we should mention our "special" definition
 in the document where it is used, in order not to be deceptive?

manoj
-- 
A conservative is one who is too cowardly to fight and too fat to run.
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: The DFSG do not require source code for data, including firmware

[Manoj Srivastava]

On Wed, 23 Aug 2006 02:16:25 +0200, Raphael Hertzog <[EMAIL PROTECTED]> said: 

> Hi Manoj,
> On Tue, 22 Aug 2006, Manoj Srivastava wrote:
>> So, unless otherwise stated, the foundation document terms refer to
>> commonly understood meanings of words; looking to dictionaries,
>> encyclopedias, and common references.

> We're using the term program since the very first day of the DFSG
> and at that time the problematic of distributing firmware was not
> taken into account since firmware were generally in ROM and would
> not be installed dynamicly like today.

Anything Debian was not and is not distributing is not a
 problem. And, you know, technically, these non-free programs can
 still be shipped out of non-free -- which is not part of the Debian
 OS.

> So we could ask ourselves if the authors of the DFSG really meant to
> encompass the firmware or not, etc. But I find this game really
> stupid.  It's only semantic nitpicking in one side or in the other,
> and nobody wins by imposing his point of view using such methods.

As I recall it, it we wanted to define everything that was on
 the CD. Bruce and Alex Yukhimets represented the either end of the
 spectrum on that, and Alex's viewpoint lost out.

> Let's face it, we're leading Debian together and we must take a
> decision together. The only good way of getting a decision and
> having everybody stick to the decision is to have a decision taken
> with fair rules. And fair rules are "simple majority".

These are not our rules.  Our rules are the constitution --
 and legislating the value of Pi, which a couple of majority decisions
 did in the US in the past, demonstrates that a million people can
 still be wrong.

>> Calling firmware not programs is our own "special" definition of
>> firmware, and or program, and hence must be defined explicitly in
>> the DFSG.  If we want to state that we only consider certain
>> programs to be free, we ought to be upfront and clear about it in
>> our foundation document.

> I don't agree with your reasoning. I agree that firmware are special
> purpose programs.

It is not my reasoning. This is the result of a simple online
 search; but has been substantiated (but don't take my word for it) by
 reference libraries like the ACM and IEEE digital libraries as
 well.  Every single reference I found called firmware computrer
 programs -- special purpose, perhaps, but the DFSG does not
 distinguish between the purpose of the programs in Debian. It says
 uncategorically "programs".

> But the text of Steve is quite clear: "4. [The project] determines
> that for the purposes of DFSG #2, device firmware shall also not be
> considered a program.".

Well, we are of course free to add such clarifications and
 codicils to the DFSG.

> We know they are special subclass of programs, but for various
> reasons, we don't want to consider them as programs when applying
> our rules. A simple majority ought to be enough to determine
> that. Remember the G in DFSG, it stands for "guidelines"... we have
> the right to apply our guidelines in the way we think is best to
> achieve our goal (which is BTW defined in the social contract).

If we so believe, let us modify the DFSG to say so
 clearly. Anything less is confusing, and could deceive people into
 believing that the social contract can be read as it is written.

manoj
-- 
Swipple's Rule of Order: He who shouts the loudest has the floor.
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: The DFSG do not require source code for data, including firmware

[Manoj Srivastava]

On Wed, 23 Aug 2006 14:59:37 +0100, Matthew Garrett <[EMAIL PROTECTED]> said: 

> Jacobo Tarrio <[EMAIL PROTECTED]> wrote:
>> El miércoles, 23 de agosto de 2006 a las 21:24:16 +1000, Anthony
>> Towns escribía:
>> 
>>> We choose to apply the DFSG both to the components that the Debian
>>> system requires, and to what we use to provide debian.org
>>> services. It can be
>> 
>> No, the DFSG are applied to what's provided by Debian, not to what
>> it's required by it.

> The DFSG apply to "The Debian system". The social contract doesn't
> define what "The Debian system" is. We could define it as "What's
> shipped by Debian", but we could also define it as "A system
> consisting of a computer and a Debian installation" or "Whatever is
> provided by Debian and run on the host processor".

That would be acceptable -- as long as we define the "Debian
  system" this way in the social contract.

On Wed, 23 Aug 2006 15:40:49 +0100, Matthew Garrett
<[EMAIL PROTECTED]> said:  

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


While I disagree with this assessment, I think it would be
 reasonable to vote on amending the social contract to reflect
 this pragmatic compromise (I hope the proposal would lose, but there
 is nothing unethical about deciding to change our stance on freedom
 of firmware programs). 

But it would have to be done upfront, by modifying the social
 contract to reflect our newly determined views.

manoj
-- 
"The pathology is to want control, not that you ever get it, because
of course you never do."-- Gregory Bateson
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: The DFSG do not require source code for data, including firmware

[Matthew Garrett]

Bernhard R. Link <[EMAIL PROTECTED]> wrote:

> This is not true in either direction. Not every non-free application has
> a free counterpart[1]. And not every hardware needs firmware.

If you can find a single hard drive on the market that doesn't contain 
some sort of firmware, I'll be greatly impressed. Or, for that matter, a 
vaguely modern processor. Let alone bootstrapping a system (LinuxBIOS 
will suffice for a very small range of hardware), running a modern 
network card, using a graphics chip for any purpose other than 
unaccelerated 2D, or, well, pretty much any piece of hardware on the 
market today. For all practical purposes, it's impossible to obtain 
hardware that doesn't depend on firmware.


> Or which somes with no firmware at all. (Or where it makes no
> difference, I do not know if any IDE controler has firmware and
> I did not hear about IDE harddiscs able to replace it).

Yeah, motherboard chipsets are probably about the only thing on a modern 
system that isn't obviously microcoded. Shame that the drives you plug 
into them are - vendors often provide firmware upgrades for IDE drives.

> There also is still the non-free section (or split it into
> non-free-host-apps, non-free-periperical-apps, non-free-docs, )
> so that people can still get it working easily without pretending
> anything if free or can be part of a free operating system.

I'm entirely happy with us making it clear that firmware isn't 
free-as-in-DFSG. I'm not happy about us leaving it out of the default 
install images.

> I'm not saying we should refuse to ship non-free code. I've voted to
> keep non-free in the last GR about it. I'm against putting things in
> Debian which are not free. If it is in Debian, I want to be sure that
> I am allowed to modify it and get it working with some work. If I' bye
> stuff with ROMed firmware I know it is in there and what I have to
> expect. 

If you believe that you can buy hardware without ROM firmware, then I 
think it's pretty clear that you don't know it is in there.

> If I have to get in from the non-free section, I know I'll have
> no chance and try to buy something where the manufacturer gave specs
> and someone worked on them. If everything is in main I'm lured in a
> false feeling of security and have no easy way to distinguish and
> choose the vendor with a free firmware.

Or you'll go and buy some hardware with the firmware in eeprom where 
it's a pain to replace with free firmware.

> Would you also ask to include non-free drivers if they had stable
> interface and the kernel had a bochs included by default to run them?

No. There's plenty of hardware with free drivers, and I think that us 
refusing to provide the non-free ones does make a difference. I run no 
non-free drivers on any of my hardware. At the point where it's possible 
for me to run a machine without any non-free firmware, I'll be happy to 
drop it.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

[Anthony Towns]

On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote:
> So below is a proposal that I'm seeking seconds on to establish how DFSG#2
> should be understood to apply to firmware -- i.e., that for Debian's
> purposes firmware should be considered data, not programs, and along with
> other data we should only encourage, not require, source code for firmware
> included in main.  [...]

On Wed, Aug 23, 2006 at 02:28:30AM +0200, Frans Pop wrote:
> Seconded.

Could I get a clarification from either the RM or d-i teams on something?

Independent of whether it's required by the social contract or the
DFSG or whatever, I thought moving non-free firmware into non-free was
a release goal for etch, and if we're not going to meet it for etch,
I think we should definitely prioritise it for etch+1.

Was/is that right? Does it even make sense?

If it makes sense, what are the major difficulties/inconveniences/whatever
that were found in having this happen for etch, that will need to be
addressed to achieve an etch+1 release that's both useful and convenient
for both people who need/want non-free things, and those who want a
completely free system?

(FWIW, non-free udeb support should finally be working properly as of
next pulse)

Cheers,
aj


signature.asc
Description: Digital signature

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

[Manoj Srivastava]

On Wed, 23 Aug 2006 17:38:07 +1000, Anthony Towns  
said: 

> On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote:
>> [Steve Langasek]
>> > 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?
>> The day Debian begins to distribute ROM chips, or devices
>> containing ROM chips, I will expect those chips to come with source
>> code.  Until then, this is a red herring.

> Note that while Peter is currently in the n-m queue (on hold pending
> further response to T&S checks apparently), he's not yet a
> developer, and his expectations shouldn't be inferred to be those of
> the developers as a whole.

In that case, let me reiterate what Peter said -- and I have
 been a developer longer than you have, and I actually was around when
 the DFSG was crafted, so my expectations are not as easily dismissed
 as someone who has but recently joined our community.

manoj
-- 
Alas, I am dying beyond my means. Oscar Wilde [as he sipped champagne
on his deathbed]
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: The DFSG do not require source code for data, including firmware

[Manoj Srivastava]

On Tue, 22 Aug 2006 22:23:29 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

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

I am disagreeing that there is a genuine ambiguity.  

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

This is like legislating the value of Pi not to be
 irrational -- I mean, rationality is to be prized, no?


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

These are not just reasonable definitions -- they are the
 overwhelming majority of definitions found for the terms.  I searched
 the digital libraries of the ACM and of the IEEE, and I have yet to
 come across any mention of firmware that does not concede that it is
 software programs -- perhaps software programs that are read off
 non-volatile memory, instead of magnetic fields on a hard-drive
 platter, but in either case the storage media is some kind of (semi)
 persistent elecro-magnetic field, and the stored instructions are
 acted upon by a processing unit.  No textbook, no reference, no
 definition in dictionaries of electrical engineering, no online
 dictionaries, seem to be ambiguous or confused -- seems hard to
 imagine that people can be genuinely confused for long.  It is easy
 enough to correct ones understanding of the term firmware with a
 little research.

Now, I also understand the convenience factor -- it is vastly
 more convenient to just let this slide under the carpet, and let what
 is technically non-free under the DFSG into main by cleverly
 redefining words to suit -- the users want it, the hardware vendors
 want it, and the benefit of sticking to principles of freedom seem
 silly and appear to have little immediate benefit.

But pretending that firmware definition is somehow ambiguous is
 Clintonian ("it depends n what the meaning of the word 'is' is")  in
 nature. 

Oh, as to why we still have non-DFSG material in main, well,
 cleansing a distribution the size of Debian takes time, and we have
 been working towards this goal -- and it is not so long ago that an
 editorial change to the SC clarified the meaning of the SC for some
 people.

manoj
-- 
"Even the most boundless love can end." Rhett Butler, to Scarlet
O'Hara, _Gone With The Wind_
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: The DFSG do not require source code for data, including firmware

[Bernhard R. Link]

* Matthew Wilcox <[EMAIL PROTECTED]> [060823 15:46]:
> Certainly, it's one of the purposes.  But I don't think we've *lost*
> anything by distributing binary firmware.  Consider the cases:
> 
> 1. Everything in hardware.  You're not able to fix anything without a
>soldering iron ... and good luck to you with that.
> 2. Unmodifiable firmware in EEPROM.  Need an EEPROM programmer, and a
>good deal of skill to fix anything.  Again, best of luck.
> 3. Binary-only firmware in the driver.  Slightly better chance of trying
>to figure out what's going on, but still low.
> 4. Firmware source in non-preferred form.  Modifications probably
>possible, but when the next round of changes come out from the
>vendor, you probably have to ditch your mods.
> 5. Firmware source in preferred form.  Can send changes back to vendor,
>everybody wins.
> 
> (and I'm sure people can think of other finer distinctions).
> 
> You seem to want to disallow cases 3 and 4 which makes sense from a
> "here are the rules of data freedom, now i must follow them" point of
> view, but really don't make sense to the vendor, nor to the user.  It
> seems like an all-or-nothing approach.

That's not different at all to normal programs.
Perhaps it even becomes a bit clearer if you substitute 1) and 2) for
programs with "no software".

Having non-free software is - for the very single developer and any seen
locally[1] - better than having no program to do the task all together.
We (Debian project) acknowledge the need of users and distribute such
stuff in the non-free section in addition to our distribution, so that
people are not locked into totaly non-free systems but only have to
bear that much unfreeness as it necessary.

We are giving a promise here, that with the stuff in our distribution
you have the freedom to use it, to give it to others and to fix it.
This means the missing of legal obstacles and the possibility to do so.
For this discussion "preferred form of modification" is perhaps not the
best definition. It's good for licenses as it is not easily to work
around. I think here the difference is between the source being in
a form practical to edit or not. Without a practical form there is
no possibility to change it. And this is a limitation we have to
make clear to people and not lock them into by claiming all is good
and well and it could be part of our free operating system.

Hochachtungsvoll,
Bernhard R. Link

[1] having no software at all increases the pain and makes it more
likely someone writes something free, but for the single person that
cannot write it, this is too far reached.


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

[Matthew Garrett]

Bernhard R. Link <[EMAIL PROTECTED]> wrote:

> We are giving a promise here, that with the stuff in our distribution
> you have the freedom to use it, to give it to others and to fix it.
> This means the missing of legal obstacles and the possibility to do so.
> For this discussion "preferred form of modification" is perhaps not the
> best definition. It's good for licenses as it is not easily to work
> around. I think here the difference is between the source being in
> a form practical to edit or not. Without a practical form there is
> no possibility to change it. And this is a limitation we have to
> make clear to people and not lock them into by claiming all is good
> and well and it could be part of our free operating system.

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.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

[Bernhard R. Link]

* Matthew Garrett <[EMAIL PROTECTED]> [060823 16:40]:
> > We are giving a promise here, that with the stuff in our distribution
> > you have the freedom to use it, to give it to others and to fix it.
> > This means the missing of legal obstacles and the possibility to do so.
> > For this discussion "preferred form of modification" is perhaps not the
> > best definition. It's good for licenses as it is not easily to work
> > around. I think here the difference is between the source being in
> > a form practical to edit or not. Without a practical form there is
> > no possibility to change it. And this is a limitation we have to
> > make clear to people and not lock them into by claiming all is good
> > and well and it could be part of our free operating system.
> 
> 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.

This depends whom you ask. Some people will even instist that today a
computer without a working (i.e. non-free) flash-plugin is not
operational.

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

This is not true in either direction. Not every non-free application has
a free counterpart[1]. And not every hardware needs firmware.
Many hardware for PCs "needed" ROM-stored instructions in the past. But as
chips were expensive they were designed to run on the same processor,
then operating systems no longer running in real mode arrived and Linux
had to write drivers for almost everything themself. Where is the
difference to firmware? Other that the vendor might be unwilling to give
specs to write it on your own saying that there is that firmware.
(Last time they has the excuse that all is secret...)

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

Or which somes with no firmware at all. (Or where it makes no
difference, I do not know if any IDE controler has firmware and
I did not hear about IDE harddiscs able to replace it).

There also is still the non-free section (or split it into
non-free-host-apps, non-free-periperical-apps, non-free-docs, )
so that people can still get it working easily without pretending
anything if free or can be part of a free operating system.

> Ironically, this will actually make it harder for them to ever use free 
> firmware!

Where is the difference. If firmware is so free that even Debian
declares it free, who will write a free one?

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

I'm not saying we should refuse to ship non-free code. I've voted to
keep non-free in the last GR about it. I'm against putting things in
Debian which are not free. If it is in Debian, I want to be sure that
I am allowed to modify it and get it working with some work. If I' bye
stuff with ROMed firmware I know it is in there and what I have to
expect. If I have to get in from the non-free section, I know I'll have
no chance and try to buy something where the manufacturer gave specs
and someone worked on them. If everything is in main I'm lured in a
false feeling of security and have no easy way to distinguish and
choose the vendor with a free firmware.

I'm still waiting for a argument how this is in any way different
from any other driver for hardware. The only advantage of firmware is
that it does not hurt people with minority arches (But given Vancouver
that can not be a difference, because we do not care about arches not
used by everyone, do we) more than other people. And that it is not that
dependent on some interfaces often changing on Linux.

Would you also ask to include non-free drivers if they had stable
interface and the kernel had a bochs included by default to run them?

Hochachtungsvoll,
Bernhard R. Link

[1] Think of all that little programs speaking some "secret" protocol,
applications for special tasks and so on.


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

[Sven Luther]

On Wed, Aug 23, 2006 at 03:40:49PM +0100, Matthew Garrett wrote:
> Bernhard R. Link <[EMAIL PROTECTED]> wrote:
> 
> > We are giving a promise here, that with the stuff in our distribution
> > you have the freedom to use it, to give it to others and to fix it.
> > This means the missing of legal obstacles and the possibility to do so.
> > For this discussion "preferred form of modification" is perhaps not the
> > best definition. It's good for licenses as it is not easily to work
> > around. I think here the difference is between the source being in
> > a form practical to edit or not. Without a practical form there is
> > no possibility to change it. And this is a limitation we have to
> > make clear to people and not lock them into by claiming all is good
> > and well and it could be part of our free operating system.
> 
> 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.

I agree with you. But the point is on how you communicate about the fact.

What Steve and others who seconded him propose is to ship non-free firmware in
main, and declaring it as data, and thus disguising it as free software.

By moving the non-free firmware to non-free, we clearly renew our believe in
free software, and encourage effort to reverse engineer or convince vendors,
as aurelien and piotr and a few others are reimplementing the apple mac os
classic boot sector.

It is still relatively easily possible to design the whole non-free firmware
support in such a way that it is totally transparent to the user, apart of a
message in the installer or something, which will inform him that he needs
non-free firmware for its hardware, and asks if he wants to make use of it.

So, shiping non-free code because there is no choice is just fine, but shiping
it while insisting it is free is not.

Friendly,

Sven Luther


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

[Pierre Habouzit]

Le mer 23 août 2006 13:35, Anthony Towns a écrit :
> The followup was only intended to make sure it was clear that it *was*
> Peter's take, and not necessarily the project's, and that debate is
> still appropriate.

  d-vote@ is a discussion list, and nothing here that isn't a vote 
result can be taken as a project statement. And Peter didn't worded his 
mail as claiming to be representative of the debian project either.

  Peter even did not said the debate was inapropriate, he was defining 
what he thing beeing a boundary to it.


  PS: that mail is not an offician statement from the debian project.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpL29CHXzADl.pgp
Description: PGP signature

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

[Bernhard R. Link]

* Matthew Garrett <[EMAIL PROTECTED]> [060823 17:31]:
> If you can find a single hard drive on the market that doesn't contain 
> some sort of firmware, I'll be greatly impressed. Or, for that matter, a 
> vaguely modern processor. Let alone bootstrapping a system (LinuxBIOS 
> will suffice for a very small range of hardware), running a modern 
> network card, using a graphics chip for any purpose other than 
> unaccelerated 2D, or, well, pretty much any piece of hardware on the 
> market today. For all practical purposes, it's impossible to obtain 
> hardware that doesn't depend on firmware.

In case it was not clear I was discussing things where firmware is also
loadable.

I've never seen BIOSes being part of the Operating system, but you can get
hardware that runs with LinuxBios. I've not yet met a hard drive (as
opposed to all kind of Bus controlers) needing any firmware before
operating. I don't know about new graphic cards (all I really need is
2D), but looking at how ugly the drivers are and what a secret even
communicating with the hardware is for the vendors, I really doubt any
firmware on the card is involved. Network cards I never looked to
deeply, but most of them were so small I really doubt they are more than
plain hardware. WLan cards might be something different, but I never
used them.

> Yeah, motherboard chipsets are probably about the only thing on a modern 
> system that isn't obviously microcoded. Shame that the drives you plug 
> into them are - vendors often provide firmware upgrades for IDE drives.

OK, never saw that drives. But where is the problem with them. Works
without needing any non-free stuff being put in the operating systems
and people might be able to replace it. No good example.

> I'm entirely happy with us making it clear that firmware isn't 
> free-as-in-DFSG. I'm not happy about us leaving it out of the default 
> install images.


> > I'm not saying we should refuse to ship non-free code. I've voted to
> > keep non-free in the last GR about it. I'm against putting things in
> > Debian which are not free. If it is in Debian, I want to be sure that
> > I am allowed to modify it and get it working with some work. If I' bye
> > stuff with ROMed firmware I know it is in there and what I have to
> > expect. 
> 
> If you believe that you can buy hardware without ROM firmware, then I 
> think it's pretty clear that you don't know it is in there.

If it is direct hardware or a ROM, it does not matter that much in
there. If there is a ROM at all. In days where modems have no
modulator/demodulator chips any more, there are not that much things
where people would put processors in.

Put again, what part instead if my BIOS (which mostly runs in CPU so
some people might not call it firmware, and at least with PCs is never
needed to be shipped by a driver) and IDE drivers (which also always
come with some pre-installed firmware, so not relevant), is found in
every cheap box? (assuming to wireless).

> > If I have to get in from the non-free section, I know I'll have
> > no chance and try to buy something where the manufacturer gave specs
> > and someone worked on them. If everything is in main I'm lured in a
> > false feeling of security and have no easy way to distinguish and
> > choose the vendor with a free firmware.
> 
> Or you'll go and buy some hardware with the firmware in eeprom where 
> it's a pain to replace with free firmware.

As I said. As long as noone cares for free firmwares, what difference
does it make? I the vendor opens the specs, there should be a free one
and not problems. If it does not open the specs the eeprom version has
the advantage to work even when the firmware-binary gets lost and
the manufacturer might have tested it before. (Or introduced something
to replace the firmware, which again defeats your point).

Hochachtungsvoll,
Bernhard R. Link


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

[Moritz Muehlenhoff]

In gmane.linux.debian.devel.vote, you wrote:
> It's my hope that this strikes a reasonable balance between respecting the
> views of individual developers and advancing a viable policy for the project
> so that we can move forward together on the goal of making each Debian
> release a first-class, free operating system.

Excellent initiave. Thanks a lot.

I second the proposal quoted below.

>  The application of DFSG#2 to firmware and other data
>  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D
>
> 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.
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D
>
> Cheers,
> --=20
> 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

[Matthew Garrett]

Bernhard R. Link <[EMAIL PROTECTED]> wrote:
> * Matthew Garrett <[EMAIL PROTECTED]> [060823 17:31]:
>> If you can find a single hard drive on the market that doesn't contain 
>> some sort of firmware, I'll be greatly impressed. Or, for that matter, a 
>> vaguely modern processor. Let alone bootstrapping a system (LinuxBIOS 
>> will suffice for a very small range of hardware), running a modern 
>> network card, using a graphics chip for any purpose other than 
>> unaccelerated 2D, or, well, pretty much any piece of hardware on the 
>> market today. For all practical purposes, it's impossible to obtain 
>> hardware that doesn't depend on firmware.
> 
> In case it was not clear I was discussing things where firmware is also
> loadable.

Why?

> I've never seen BIOSes being part of the Operating system, but you can get
> hardware that runs with LinuxBios. I've not yet met a hard drive (as
> opposed to all kind of Bus controlers) needing any firmware before
> operating. I don't know about new graphic cards (all I really need is
> 2D), but looking at how ugly the drivers are and what a secret even
> communicating with the hardware is for the vendors, I really doubt any
> firmware on the card is involved. Network cards I never looked to
> deeply, but most of them were so small I really doubt they are more than
> plain hardware. WLan cards might be something different, but I never
> used them.

Several drivers load microcode to graphics chipsets on startup. Gigabit 
cards pretty much all run some sort of firmware. Wlan cards certainly 
do.

But anyway. Your computer depends on non-free firmware. It's basically
impossible to avoid that nowadays. From a practical viewpoint, I would 
prefer it if we encouraged hardware that was amenable to easy firmware 
replacement. You seem to prefer hardware where that's more difficult. I 
don't see how that's a win for freedom.

> OK, never saw that drives. But where is the problem with them. Works
> without needing any non-free stuff being put in the operating systems
> and people might be able to replace it. No good example.

Wait. So by "Non-free stuff being put in the operating systems", you 
mean "Non-free stuff lives on my filesystem"?

> Put again, what part instead if my BIOS (which mostly runs in CPU so
> some people might not call it firmware, and at least with PCs is never
> needed to be shipped by a driver) and IDE drivers (which also always
> come with some pre-installed firmware, so not relevant), is found in
> every cheap box? (assuming to wireless).

You mean "Other than these bits of hardware that require firmware, which 
bits of my hardware require firmware"? If you've got a laptop, the 
embedded controller will have some sort of firmware that runs it. As 
I've already noted, it's quite likely that your network card does if 
it's reasonably new. Your CPU probably has new microcode loaded by the 
BIOS. In other words, almost all of it.

Your argument seems to be "If I don't see it, it doesn't matter". 

>> Or you'll go and buy some hardware with the firmware in eeprom where 
>> it's a pain to replace with free firmware.
> 
> As I said. As long as noone cares for free firmwares, what difference
> does it make? I the vendor opens the specs, there should be a free one
> and not problems. If it does not open the specs the eeprom version has
> the advantage to work even when the firmware-binary gets lost and
> the manufacturer might have tested it before. (Or introduced something
> to replace the firmware, which again defeats your point).

Do you believe that hardware with the firmware in ROM is preferable 
(from a pure freedom point of view) to hardware with firmware loaded by 
the OS?

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

[Moritz Muehlenhoff]

Bernhard R. Link wrote:
>>  4. Determines that as a special exception to DFSG #2, source code for
>> device firmware will not be required until we have the technical means
>> to split them out in a convenient way for our users.
>
> I'd rather suggest to give a direct hint in time. Like "until etch
> releases", so that people wanting non-free firmware have to do the
> techical stuff and not the people wanting control over what their
> computer do.

None of the trolls demanding the removal of firmware from main has
ever done significant work to resolve this upstream. Plus, the GR
wouldn't stop them from doing so.


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

[Sven Luther]

On Wed, Aug 23, 2006 at 05:18:03PM +0100, Matthew Garrett wrote:
> > OK, never saw that drives. But where is the problem with them. Works
> > without needing any non-free stuff being put in the operating systems
> > and people might be able to replace it. No good example.
> 
> Wait. So by "Non-free stuff being put in the operating systems", you 
> mean "Non-free stuff lives on my filesystem"?

What about non-free stuff shipped by debian ? 

Friendly,

Sven Luther


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

[Sven Luther]

On Wed, Aug 23, 2006 at 06:17:00PM +0200, Moritz Muehlenhoff wrote:
> Bernhard R. Link wrote:
> >>4. Determines that as a special exception to DFSG #2, source code for
> >> device firmware will not be required until we have the technical means
> >> to split them out in a convenient way for our users.
> >
> > I'd rather suggest to give a direct hint in time. Like "until etch
> > releases", so that people wanting non-free firmware have to do the
> > techical stuff and not the people wanting control over what their
> > computer do.
> 
> None of the trolls demanding the removal of firmware from main has
> ever done significant work to resolve this upstream. Plus, the GR
> wouldn't stop them from doing so.

Err, i want to disagree on this.

  1) i think that Nerode has written some firmware removal patches which where
  rejected as broken or premature (upstream was not yet ready at that time
  with the infrastructure). The reply were pretty agressive back then, which
  explains why he didn't followup.

  2) in the same way, Larry did provide some useful audit, and did dig up some
  patch for tg3. Not sure of the quality of it though, and i don't think he
  really wrote it. Equally, his efforts were quite agressively greeted.

  3) Myself and later Andres and a few others, did contact broadcom and a few
  others hardware manufacturers, to get the non-free firmwares not being
  distributed under defacto GPL. We where laughed at from both some of the
  debian team as well as the LKML folk, but we continued nonetheless, and
  managed to clarify the issue, thus setting an useful precedent.

So, you may be right to some point, but should moderate your language and
affirmations. If we are going to go this way, and an effort is going to be
made, and not shouted at and rejected, then more people actually doing the
work and motivated for it may surface and help.

Friendly,

Sven Luther


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

[Sven Luther]

On Thu, Aug 24, 2006 at 01:37:21AM +1000, Anthony Towns wrote:
> (FWIW, non-free udeb support should finally be working properly as of
> next pulse)

 From the ftp archive architecture side, or from the internal d-i side, or both 
? 

Friendly,

Sven Luther


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

[Bernhard R. Link]

* Matthew Garrett <[EMAIL PROTECTED]> [060823 18:18]:
> > In case it was not clear I was discussing things where firmware is also
> > loadable.
> Why?

Because everything else has no relevancy to Debian at all.

> Several drivers load microcode to graphics chipsets on startup.

But most of them still work with vesafb without driver. And the graphics
drivers (though not that many, and perhaps two or three years old),
I looked only had some obscure start values for some ports, but nothing
long enough for real programs.

> Gigabit cards pretty much all run some sort of firmware.

Which is just a bit faster than 100Mb cards. Nothing where you cannot
live with free stuff alone if it has to be.

> But anyway. Your computer depends on non-free firmware. It's basically
> impossible to avoid that nowadays. From a practical viewpoint, I would 
> prefer it if we encouraged hardware that was amenable to easy firmware 
> replacement. You seem to prefer hardware where that's more difficult. I 
> don't see how that's a win for freedom.

I prefer hardware where all the specification is there and it can be
made to work. And not claim anything is free while it some
incomprehensible binary blob.

> > OK, never saw that drives. But where is the problem with them. Works
> > without needing any non-free stuff being put in the operating systems
> > and people might be able to replace it. No good example.
> 
> Wait. So by "Non-free stuff being put in the operating systems", you 
> mean "Non-free stuff lives on my filesystem"?

No, I mean operating system, more exactly my operating system, the
Debian distribution.

> > Put again, what part instead if my BIOS (which mostly runs in CPU so
> > some people might not call it firmware, and at least with PCs is never
> > needed to be shipped by a driver) and IDE drivers (which also always
> > come with some pre-installed firmware, so not relevant), is found in
> > every cheap box? (assuming to wireless).
> 
> You mean "Other than these bits of hardware that require firmware, which 
> bits of my hardware require firmware"? If you've got a laptop, the 
> embedded controller will have some sort of firmware that runs it. As 
> I've already noted, it's quite likely that your network card does if 
> it's reasonably new. Your CPU probably has new microcode loaded by the 
> BIOS. In other words, almost all of it.

Well, from what I saw, motherboards seem to be again more often 100Mbit
than gigabit like the year before. The Bios stuff is already in the
computer, so we do not have to discuss it. Embedded controlers I don't
know about.

> >> Or you'll go and buy some hardware with the firmware in eeprom where 
> >> it's a pain to replace with free firmware.
> > 
> > As I said. As long as noone cares for free firmwares, what difference
> > does it make? I the vendor opens the specs, there should be a free one
> > and not problems. If it does not open the specs the eeprom version has
> > the advantage to work even when the firmware-binary gets lost and
> > the manufacturer might have tested it before. (Or introduced something
> > to replace the firmware, which again defeats your point).
> 
> Do you believe that hardware with the firmware in ROM is preferable 
> (from a pure freedom point of view) to hardware with firmware loaded by 
> the OS?

I do not really know (though the more firmwarry it gets, the more crappy
it normaly gets as people tend to think they can fix it later but do not
allow be to fix it). And I do not care much. Things needing a firmware
and having a reprogrammable firmware in them are preferable to them
anyway. And still best is a specification which allows me to write the
firmware myself (or even better give me one I can change easily).

What I care it what we put in main. If you think you cannot live without
cheap (i.e. no prom) hardware you cannot modify (because of missing
specifications and/or sources), which will not change (because it is too
wide accepted that firmware is somehow magically special), that is a
important thing to support. But I do not think it makes it neccessary to
put non-free stuff into main any more than the need for a flash player
absolutely needed to view any modern website...

Hochachtungsvoll,
Bernhard R. Link
-- 
mozilla-thunderbird: It cannot read mail, it cannot send mail. It is the
victory of dialup over the internet.


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

[Joey Hess]

Anthony Towns wrote:
> If it makes sense, what are the major difficulties/inconveniences/whatever
> that were found in having this happen for etch, that will need to be
> addressed to achieve an etch+1 release that's both useful and convenient
> for both people who need/want non-free things, and those who want a
> completely free system?

From the d-i side, the major difficulties are:

1. The archive did not support a non-free section for udebs until today.
2. libd-i and anna do not support multiple udeb sources, but can only
   pull from one at a time; noone has yet fixed this
3. The Debian kernel does not currently have non-free firmware separated
   into different packages.
4. Numerous installation cases become much more complex assuming the
   above is all implemented. Examples:

   a. netboot install where the NIC needs non-free firmware.
  Possible solutions include:
  i. Ship a non-free installation image, either extra-debian (as is
 done for the nslu2), or in non-free. With the problems that:
 * Such an image will automatically become the image most users use
   to install, since it's more likely to work.
   (Example: the nslu2 install image)
 * So the free image won't be used or tested much.
 * So we've doubled our work and QA for no actual benefit.
  ii. Ship only a single free image, with some procedure (ie,
 cat firmware.cpio >> initramfs) that users can run to make it
 include the non-free firmware.
 * This limits the users who can use it to users competant to
   assemble it on their own.
  iii. Require that the user feed the machine some media with the
 firmware.
 * Assumes that the drivers for the media don't need non-free
   firmware.
 * Assumes that the machine supports removable media.
 * Removes most of the benefit of netbooting in the first place.
   b. CD install where the CD, disk, NIC, etc need non-free firmware.
  Possible approaches include:
  i. Provide some way for the user to remaster the CD.
 * Too hard for most users.
 * If the CD drive itself needs non-free firmware they will
   need to modify the initrd too, which gets into the really
   hard territory.
  ii. Allow some way for the user to add a new session to the CD
 containing the non-free firmware.
 * No idea how this could work, but it does prove that drunken
   late night discussions at DebConf are good for something.
 * Wouldn't address any firmware that needs to go in the initrd,
   ie, CD driver firmware.
  iii. Require additional media (floppy, usb key) or network.
 * Assumes that the drivers for the that don't need non-free
   firmware and that the machine supports floppy, usb or network.
  . Ship a separate non-free CD.
 * Which then becomes the one everyone uses because it works, as
   with the non-free netboot image above.
 * Does bad things to our CD/DVD disk space requirements.
  Also, in the case of a CD that needs non-free firmware, we have to
  provide the installer with a way to get not just udebs for the
  firmware, but debs for it, for the installed system. This
  complicates all of the above approaches significantly.
c. CD or network, etc install where the disk drive needs non-free
  firmware. If we have 1, 2, and 3 done, this isn't a large issue,
  but yet another complexifying case.
d. Install _from_ hard disk (internal or USB), where the disk needs
  non-free firmware.
  This is probably the easiest installation media for a user to
  modify to add non-free firmware, so it may be amoung the easier
  cases to handle.
5. Implementing anything in 5 is a lot of work. Implementing it all
   will be pretty atrocious. My guess is still 6 months of solid work to
   implent a credible subset of 5, just like it has been all along.
6. We have no clear idea as to which of these possibilities is feasable
   or the right way to go.
7. People seem to find it much more rewarding to work on fixing bugs in
   d-i and adding spiffy new features like hard drive encryption and GUI
   installers than on firmware splitting. And more power to them..
   (The work done for the nslu2 provides a small counterpoint to this.)

It's worth noting that all of the above also applies to including
non-free kernel modules in the installer, although AFAIK we don't have
many if any of those in a form suitable for d-i in the archive.

-- 
see shy jo


signature.asc
Description: Digital signature

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

[MJ Ray]

Matthew Garrett <[EMAIL PROTECTED]>
> 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.

The above argument seems to be "If I don't see it, it doesn't matter".  

Of course, evidence is unlikely to appear before the action is taken.  
I doubt any corporation will declare "if debian does this, we'll follow 
the DFSG instead".  Instead, we each get to make our best guesses.

I think the idea that refusing to ship non-free firmware in main will 
strengthen demand for free firmware is worthy of consideration.  Debian 
helps users to take control of their operating system.  Increasing the 
demand for free firmware might also help users to take control of their 
hardware, or at least highlight that there's this crap which their 
operating system uses to support their hardware but doesn't have its 
normal freedoms.

However, I'm undecided whether it's a good idea to exclude them from the 
distribution CDs and so on.  How big is the problem of vital hardware 
which won't work without firmware being copied to it?  Should we split 
non-free into non-free-hardware and non-free, allowing non-free-hardware 
packages onto the CDs?

Thanks for any answers,
-- 
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: The DFSG do not require source code for data, including firmware

[Kurt Roeckx]

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.

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.

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.

However, it doesn't say anything about other points of the DFSG.  So we
should still need a license that allows atleast derived works.  And I
don't see how we're going to make derived works of firmware without the
source for it.


Kurt


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

[Sven Luther]

On Wed, Aug 23, 2006 at 07:25:10PM +0100, MJ Ray wrote:
> Matthew Garrett <[EMAIL PROTECTED]>
> > 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.
> 
> The above argument seems to be "If I don't see it, it doesn't matter".  
> 
> Of course, evidence is unlikely to appear before the action is taken.  
> I doubt any corporation will declare "if debian does this, we'll follow 
> the DFSG instead".  Instead, we each get to make our best guesses.
> 
> I think the idea that refusing to ship non-free firmware in main will 
> strengthen demand for free firmware is worthy of consideration.  Debian 
> helps users to take control of their operating system.  Increasing the 
> demand for free firmware might also help users to take control of their 
> hardware, or at least highlight that there's this crap which their 
> operating system uses to support their hardware but doesn't have its 
> normal freedoms.
> 
> However, I'm undecided whether it's a good idea to exclude them from the 
> distribution CDs and so on.  How big is the problem of vital hardware 
> which won't work without firmware being copied to it?  Should we split 
> non-free into non-free-hardware and non-free, allowing non-free-hardware 
> packages onto the CDs?

I would indeed vote for a solution including a non-free hardware, or even
better an additional CD, which contained a non-free version of d-i (which need
to include certain non-free firmwares and drivers in the images), and all the
additional non-free firmware stuff.

This way, we could add a list of pci ids needding non-fre hardware, and do a
check pretty early in the installer, and if those non-free hardware is found,
inform the user about it, and use the non-free installer CD instead, and all
the rest would be taken care for him.

Friendly,

Sven Luther


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

[Matthew Garrett]

MJ Ray <[EMAIL PROTECTED]> wrote:

> However, I'm undecided whether it's a good idea to exclude them from the 
> distribution CDs and so on.  How big is the problem of vital hardware 
> which won't work without firmware being copied to it?  Should we split 
> non-free into non-free-hardware and non-free, allowing non-free-hardware 
> packages onto the CDs?

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. I'm 
entirely open to the creation of a new section for firmware-type 
material (I think I even proposed doing this some time ago), and I think 
there'd be an argument for including it on the CDs by default. At the 
very least, it'd make it possible for people to make a choice that they 
feel non-free firmware is acceptable without going so far as including 
non-free software in general.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

[Martin Schulze]

Sven Luther wrote:
> What Steve and others who seconded him propose is to ship non-free firmware in
> main, and declaring it as data, and thus disguising it as free software.

I guess that's a good statement, it's disquising firmware, not necessarily
as Free Software, but disguising it.  We should be honest enough to accept
that it {does,may} contain software that is run on processors and maybe
(to be decided by vote) decide to accept this for the time being and ship
it regardlessly (or not...).

Regards,

Joey

-- 
Never trust an operating system you don't have source for!


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

[Joey Hess]

Joey Hess wrote:
>   . Ship a separate non-free CD.
iv

> 5. Implementing anything in 5 is a lot of work. Implementing it all
  4
>will be pretty atrocious. My guess is still 6 months of solid work to
>implent a credible subset of 5, just like it has been all along.
  4

-- 
see shy jo, suprised some days he didn't fail kindergarten


signature.asc
Description: Digital signature

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

[Steve Langasek]

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

[Steve Langasek]

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

[Steve Langasek]

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

[Mark Brown]

On Wed, Aug 23, 2006 at 09:15:12AM -0500, Manoj Srivastava wrote:
> On Tue, 22 Aug 2006 22:23:29 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

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

> These are not just reasonable definitions -- they are the
>  overwhelming majority of definitions found for the terms.  I searched
>  the digital libraries of the ACM and of the IEEE, and I have yet to
>  come across any mention of firmware that does not concede that it is
>  software programs -- perhaps software programs that are read off

Within a Debian context people normally seem to use the term "firmware"
to mean any binary blob that gets programmed into hardware.  This could
include things like register settings or FPGA images as well as programs
to execute on embedded processors.  I'm not sure if there are any
instances of these other types in the upstream kernel, though.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

[Peter Samuelson]

[Sven Luther]
> To add to that, if i where Peter, i may feel slightly offended by the
> tone of your reply as well as the content of it.

I wasn't offended.  AJ's tone wasn't derogatory - he made some
observations and offered some advice.  He's quite right that my views
are not those of a developer, and that when I say I will "expect"
something to happen, this is a user expectation, no more.

It is also true that saying something is a red herring, without
explaining why, is probably negligent.  What I meant is this: the
status of software which Debian does not ship (the software embedded in
hardware) is outside the scope of the Social Contract, and thus it's
not meaningful to argue about the status of software Debian ships by
comparing the two.  And if a comparison is not meaningful, introducing
it into an argument constitutes a red herring.

> You are the DPL, and as thus speak with the authority given by the
> whole project

He didn't use the [EMAIL PROTECTED] address.  It was clear to me that
he was speaking as a developer, not as the DPL.


signature.asc
Description: Digital signature

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

[Mike Hommey]

On Wed, Aug 23, 2006 at 01:38:41PM -0700, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> 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.

But it explicitely replaced all occurences of "program" by "work" in the
social contract.

It is a strange the DFSG itself didn't get the same change in the same GR...

Mike


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

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

[Steve Langasek]

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

[Steve Langasek]

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

[p2]

Hi,

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

That's mostly wrong. In case of the DAC960 for example the driver does
talk to the firmware, same for the fore ATM cards or USB devices which
have downloadable firmware.

L & L

p2.

-- 
Goa is a state of mind


-- 
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 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: Proposal: The DFSG do not require source code for data, including firmware

[Sven Luther]

On Wed, Aug 23, 2006 at 05:39:43PM -0500, Peter Samuelson wrote:
> 
> [Sven Luther]
> > To add to that, if i where Peter, i may feel slightly offended by the
> > tone of your reply as well as the content of it.
> 
> I wasn't offended.  AJ's tone wasn't derogatory - he made some
> observations and offered some advice.  He's quite right that my views
> are not those of a developer, and that when I say I will "expect"
> something to happen, this is a user expectation, no more.

Ok.

> It is also true that saying something is a red herring, without
> explaining why, is probably negligent.  What I meant is this: the
> status of software which Debian does not ship (the software embedded in
> hardware) is outside the scope of the Social Contract, and thus it's
> not meaningful to argue about the status of software Debian ships by
> comparing the two.  And if a comparison is not meaningful, introducing
> it into an argument constitutes a red herring.

Well, it was evident from your post that that was what you meant. 

> > You are the DPL, and as thus speak with the authority given by the
> > whole project
> 
> He didn't use the [EMAIL PROTECTED] address.  It was clear to me that
> he was speaking as a developer, not as the DPL.

he doesn't use the leader@ address even on issues related to his DPL role, as
i well know, so this is no guarantee.

Friendly,

Sven Luther





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

[Sven Luther]

On Wed, Aug 23, 2006 at 01:38:41PM -0700, Steve Langasek wrote:
> 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.

The discussion leading to it did clearly and numerously mention the firmware
issues, together with the GFDL documentation, the fonts, and a couple of
others maybe i don't remember.

The first GR was the one where we decided to keep non-free, and there already
non-free drivers and firmware where mentioned as one of the reason to keep
non-free. The second GR was the cosmetic change one, which left us with a
(new to some) interpretation including fonts, documentation and firmware as
software needing source. The third was a reaction to this one, where we
decided to waive this requirement for sarge, in order to get sarge out in a
timely fashion.

Now, you are, in disrespect of the decision taken back then, and with lot of
sugary wrapping to make it pass easier, trying to go back over those
decisions.

I don't care about word play, or nit picking, it is only the plain fact which
counts, and nothing you will say will change what was decided back then and
what you are trying to decide now.

Friendly,

Sven Luther


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

[Sven Luther]

On Wed, Aug 23, 2006 at 03:17:27PM -0700, Steve Langasek wrote:
> 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'.

Whateve, it uses the word program, so please stop nit picking, and replace
code by program or whatever word you where using. The meaning of it is the
same, and everyone is able to see that.

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

Maybe, but you take the first step toward this, so when will you stop ? Also,
there are currently stuff in non-free, or even which was rejected in non-free,
which could arguably be using the same kind of permissibility as the firmware
code, like the miboot apple copyrighted boot sector, which is only 256 bytes
of m68k assembly doing some apple rom traps, which it is doubtful can be
written in another way, where the source code was probably m68k assembly to
start with (and there is a deterministic 1-1 mapping between asm and machine
code), and in any case is probably lost in some long forgotten apple box, as
it was probably not compiled since 10+ years.

Yet, this one was refused to go even in non-free, and if i remember well, even
you were of that opinion.

The miboot boot sector is needed to boot those oldworld apple machines, and as
thus are in the same category as the firmware which enable usage of the
hardware piece they are for.

So, consistency or hypocrisy ? 

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

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 ?

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

I will do so. I will even go beyond and pro