DFSG violations: non-free but no contrib

Hi Ben,

On Mon, Nov 03, 2008 at 09:17:56AM +1100, Ben Finney wrote:[color=blue]
> Anything which we propose to distribute as part of Debian must follow
> the DFSG rules; otherwise, we violate our promises in the Social
> Contract. There's nothing special about the *vendor-intended use* of a
> collection of bits that exempts it from the standard that we apply to
> the rest of the operating system.[/color]

I think you've made that point clear now, thanks.


Michael


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Aurelien Jarno <aurelien@aurel32.net> writes:[color=blue]
> On Mon, Nov 03, 2008 at 08:03:15AM +1100, Robert Collins wrote:[color=green]
>> On Sun, 2008-11-02 at 14:51 +0100, Aurelien Jarno wrote:[color=darkred]
>> > Everyone agrees that firmwares are a bit special[/color]
>> I don't think they are at all special.[/color]
> Bull****.[/color]

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Frank Lin PIAT <fpiat@klabs.be> writes:
[color=blue]
> On Thu, 2008-10-30 at 11:29 +0000, Robert Lemmen wrote:[color=green]
>> On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote:[color=darkred]
>> > Wrong. You can help Ben Finney testing his packages. That would be much
>> > more useful than useless babbling on mailing lists.[/color]
>>
>> if you are talking about these [0], i certainly do not own any of these
>> pieces of hardware...[/color]
>
> I would be very pleased to have a "Buyers guide" on the wiki (i.e list
> devices that are current, supported and dfsg-free).[/color]

the problem with those list is that they often become outdated and
incomplete (who know if this no-name cheap card is supported or not ?),
but if it is updated regularly, it can be good idea.

--
Rémi Vanicat


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Michael Banck <mbanck@debian.org> writes:
[color=blue]
> Hi Ben,
>
> On Mon, Nov 03, 2008 at 09:17:56AM +1100, Ben Finney wrote:[color=green]
> > Anything which we propose to distribute as part of Debian must
> > follow the DFSG rules; otherwise, we violate our promises in the
> > Social Contract. There's nothing special about the
> > *vendor-intended use* of a collection of bits that exempts it from
> > the standard that we apply to the rest of the operating system.[/color]
>
> I think you've made that point clear now, thanks.[/color]

I'd love it if that were true; then there wouldn't be fallacious
statements about “everyone agrees some bitstreams are special, so
deserve special standards of freedom�.

--
\ “It is far better to grasp the universe as it really is than to |
`\ persist in delusion, however satisfying and reassuring.� —Carl |
_o__) Sagan |
Ben Finney


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

On Mon, Nov 03, 2008 at 02:28:45AM -0600, Manoj Srivastava wrote:[color=blue]
> On Sun, Nov 02 2008, Aurelien Jarno wrote:
>
>[color=green]
> > This look complicated. Everyone agrees that firmwares are a bit
> > special in the world of software due to the fact they don't run on the
> > host CPU.[/color]
>
> Can you explain to me why it matters which processing unit the
> software runs on? Why does it matter whether the software being
> executed on the central unit matters, and that on the peripheral
> processing unit gets off scott free?
>
> Why should it matter that the software is executed on a
> processing unit that lives on a daughter board instead of the mother
> board?[/color]

I haven't say that because they are not executed on by the CPU they are
more free. What I mean is that we have those discussions because they
are not executed on the main CPU, which makes them different than other
non-DFSG compliant software. Then some people consider that acceptable,
some other not.

At least having a separate section kills the argument that moving all
firmwares to non-free means that a lot of people will then use non-free
and install non-free stuff by mistake.

It also allows more easily to put all firmwares on a separate media for
use by debian installer (AFAIK there is no other reason to use non-free
in d-i).

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


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Manoj Srivastava wrote:[color=blue]
> Can you explain to me why it matters which processing unit the
> software runs on? Why does it matter whether the software being
> executed on the central unit matters, and that on the peripheral
> processing unit gets off scott free?
>[/color]

I don't think it does matter.

On a related note though, compare to hardware vendors:

A) provides all firmware, in binary only form, without source code, on
board device ROM that cannot be changed.

B) provides all firmware on disk, in binary only form, without source
code, in form that must be downloaded to device after every boot.

A hardware is usable with Debian main. B is not.

Is this really a win? Have we gained anything for freedom? I suspect
not. In both cases the firmware cannot be modified. At least for B there
is some hope because the open source code to perform the downloading of
the firmware has been written, where as doing that for A that might be
harder.

The only benefit I see is a technical one - it is easy to draw the line
and say Debian must exclude all binary blobs that don't comply with the
DFSG. I can't see it helping in any practical manner achieve the goal of
the DFSG by increasing the freedoms we get with Debian. Users will still
have the same restrictions and not be able to make modifications. Not
until we can get open source hardware will this change.

I haven't heard a good answer to the problem that some types of firmware
can only be legally endorsed if the manufacturer ensures users can't
change it - e.g. firmware for wireless interfaces.

Brian May


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

On Mon, Nov 03, 2008, Robert Collins wrote:[color=blue]
> I don't think they are at all special. What interprets the software - be
> it a 'cpu', a 'vm' or a co-processor like many video cards, or something
> like an arduino doesn't alter the basic attributes - there is machine
> code for one or more machines, which is usually derived from some more
> editable source (more can be quite a range though) though compilation.[/color]

It's hard to define how they are special, but I think they are.

And I can think of other data bits in the grey area.

Consider SSL certificates for e.g. Verisign. It makes no sense to
change them and we don't have the ultimate source for them. These are
generated data files for which we have the tools to build them, but not
the ultimate source data (private key). And if we had the private key,
they would be worthless. These are effectively static data enabling
SSL communications with sites using these SSL certs providers.
I could make another argument about RFCs, it's even easier to change
them.

Firmwares can be considered somewhat the same: static data enabling the
use of your hardware. You can perhaps change them. Perhaps we have
the tools to change them. Perhaps we can change them usefully. But
they are useful as such and we don't need to fight for their freedom as
we fight for the freedom of the main OS.

With requiring the freedom of firmwares, we're putting our finger in a
completely new problem: the one of free hardware. To build an useful
firmware, we will need information about registers, the operation of
the hardware, it's hardware architecture, limits, caracteristics, test
results.

Perhaps someday we will port Debian to our graphics cards, just like
it's ported to wifi aps. This would be a new port, we don't need to
require Debian to be running on your ap to use it so why not enable the
distribution of useful data which doesn't taint the main OS if we have
the permissions to do so and it benefits our users?

I don't see Debian as a free harware and computers project. We need to
leave some hard problems to others to solve!

--
Loïc Minier


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Le lundi 03 novembre 2008 Ã* 10:12 +0100, Aurelien Jarno a écrit :[color=blue]
> I haven't say that because they are not executed on by the CPU they are
> more free. What I mean is that we have those discussions because they
> are not executed on the main CPU, which makes them different than other
> non-DFSG compliant software. Then some people consider that acceptable,
> some other not.[/color]

This case is very similar to non-free documentation, which is not
executed on any CPU at all. It sounds bogus to split firmware in a
specific archive and to not do it for documentation, data, etc.

If you want to make a specific distinction for software for which we
don’t have a source and which is executed on the host CPU, I’d prefer to
see the non-free rules updated to ban such software from our archive,
and to add restrictions to it such as:
* availability of source code (for binaries meant for the host
CPU);
* legal possibility to autobuild the package (for arch-any ones);
* legal possibility to add patches for security updates.

This way we could add the non-free archive to sources.list without
wondering whether installing stuff from it will introduce an unfixable
root security hole. If more and more systems need non-free because of
firmware, this is a move that I’d like to see.

--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBJDszcrSla4ddfhTMRAkc6AKC9odg7HatmtfdiN87BjuueSOOeXgCgvDmN
3CmMef75TdoDAfgUCkH0Fsg=
=aVL3
-----END PGP SIGNATURE-----

Le lundi 03 novembre 2008 Ã* 10:58 +0100, Loïc Minier a écrit:[color=blue]
> And I can think of other data bits in the grey area.
>
> Consider SSL certificates for e.g. Verisign. It makes no sense to
> change them and we don't have the ultimate source for them. These are
> generated data files for which we have the tools to build them, but not
> the ultimate source data (private key). And if we had the private key,
> they would be worthless. These are effectively static data enabling
> SSL communications with sites using these SSL certs providers.[/color]

Since SSL certificates are randomly generated data, they are not subject
to copyright law, so I don’t think they are in any grey area. We can
change them without any licensing issue, it’s just that they won’t
fulfill their job if we do.
[color=blue]
> Firmwares can be considered somewhat the same: static data enabling the
> use of your hardware. You can perhaps change them. Perhaps we have
> the tools to change them. Perhaps we can change them usefully. But
> they are useful as such and we don't need to fight for their freedom as
> we fight for the freedom of the main OS.[/color]

Firmware images are very different. They are binary code, only code not
meant for execution on the host CPU. They are similar to non-free data
for games: stuff that we cannot modify and with which we can live
without modifying, but it would be useful to be able to, and it is
impossible to distribute it in main.

Cheers,
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBJDs5frSla4ddfhTMRAvH+AKDaZra5UHGi1ja6YHBRPpAgvgk+mwCfayJ4
eNU1VLIObIWH6BU/nrJjijI=
=ev/B
-----END PGP SIGNATURE-----

On Mon, Nov 03, 2008, Josselin Mouette wrote:[color=blue][color=green]
> > Consider SSL certificates for e.g. Verisign. It makes no sense to
> > change them and we don't have the ultimate source for them. These are
> > generated data files for which we have the tools to build them, but not
> > the ultimate source data (private key). And if we had the private key,
> > they would be worthless. These are effectively static data enabling
> > SSL communications with sites using these SSL certs providers.[/color]
>
> Since SSL certificates are randomly generated data, they are not subject
> to copyright law, so I don’t think they are in any grey area. We can
> change them without any licensing issue, it’s just that they won’t
> fulfill their job if we do.[/color]

I'm not arguing about their copyright(-ability): just that we can't
usefully modify them; and still, the private key is the source to
create the certificate (even if it's random data), and we don't have it
in main. The same goes with firmware: we might have the right to
distribute modified binary firmwares, and they are sufficiently useful
as they are, even without accompanying ultimate source. Their form is
sufficient for a free OS, not for free hardware though; just like
certificates are sufficient for a free OS, not for an open
certification chain.
[color=blue][color=green]
> > Firmwares can be considered somewhat the same: static data enabling the
> > use of your hardware. You can perhaps change them. Perhaps we have
> > the tools to change them. Perhaps we can change them usefully. But
> > they are useful as such and we don't need to fight for their freedom as
> > we fight for the freedom of the main OS.[/color]
>
> Firmware images are very different. They are binary code, only code not
> meant for execution on the host CPU. They are similar to non-free data
> for games: stuff that we cannot modify and with which we can live
> without modifying, but it would be useful to be able to, and it is
> impossible to distribute it in main.[/color]

The non-free games data I know of is non-free because we may not modify
it because the license doesn't explicitely allow it; what specific
example did you have in mind? This is IMO different from firmware
binaries which we may well be allowed to change, but don't have the
tools/doc to do so.

--
Loïc Minier


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

On Mon, Nov 03, 2008, Josselin Mouette wrote:[color=blue]
> Le lundi 03 novembre 2008 à 10:12 +0100, Aurelien Jarno a écrit :[color=green]
> > I haven't say that because they are not executed on by the CPU they are
> > more free. What I mean is that we have those discussions because they
> > are not executed on the main CPU, which makes them different than other
> > non-DFSG compliant software. Then some people consider that acceptable,
> > some other not.[/color]
> This case is very similar to non-free documentation, which is not
> executed on any CPU at all. It sounds bogus to split firmware in a
> specific archive and to not do it for documentation, data, etc.[/color]

Which non-free documentation specifically? The GFDL has this invariant
sections concept which prevents us from modifying the doc, so you can
not e.g. fork a software and rename/update doc in the invariant
sections. However I wouldn't mind having modifiable documentation in a
format which isn't the ultimate source but is maintainable, e.g. html
format if that's maintainable over time, even if originally it was
built from docbook and we don't have the docbook source.

IOW, I don't mind with picking up autogenerated contents to include in
Debian if we can maintain it in this form.

--
Loïc Minier


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Le lundi 03 novembre 2008 Ã* 13:33 +0100, Loïc Minier a écrit:[color=blue]
> On Mon, Nov 03, 2008, Josselin Mouette wrote:[color=green]
> > Since SSL certificates are randomly generated data, they are not subject
> > to copyright law, so I don’t think they are in any grey area. We can
> > change them without any licensing issue, it’s just that they won’t
> > fulfill their job if we do.[/color]
>
> I'm not arguing about their copyright(-ability): just that we can't
> usefully modify them; and still, the private key is the source to
> create the certificate (even if it's random data), and we don't have it
> in main. The same goes with firmware: we might have the right to
> distribute modified binary firmwares, and they are sufficiently useful
> as they are, even without accompanying ultimate source.[/color]

Ah, firmwares without source but with a free (e.g. MIT) license are
another story. This is definitely a grey area, since I guess many
upstreams are working on the binary directly, but there are also some
who compile it from C sources or assembly. For some of them the tools
are available, for some of them they are in-house, for some of them the
tool is a hex editor. And I don’t think we can easily distinguish
between them.

Firmwares without a free license should go to non-free, regardless of
their format.
[color=blue][color=green]
> > Firmware images are very different. They are binary code, only code not
> > meant for execution on the host CPU. They are similar to non-free data
> > for games: stuff that we cannot modify and with which we can live
> > without modifying, but it would be useful to be able to, and it is
> > impossible to distribute it in main.[/color]
>
> The non-free games data I know of is non-free because we may not modify
> it because the license doesn't explicitely allow it; what specific
> example did you have in mind? This is IMO different from firmware
> binaries which we may well be allowed to change, but don't have the
> tools/doc to do so.[/color]

Yes, I didn’t understand you were talking about “free� firmware without
sources.

--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQBJDvT/rSla4ddfhTMRAruOAJ9L0SzkK5Oah41t0VBjasvD1bO3WgCfTrAs
I1C9Tcjqi6hKXVPvbozclEk=
=uuhu
-----END PGP SIGNATURE-----

On Mon, 2008-11-03 at 08:42 +0100, Rémi Vanicat wrote:[color=blue]
> Frank Lin PIAT <fpiat@klabs.be> writes:
>[color=green]
> > On Thu, 2008-10-30 at 11:29 +0000, Robert Lemmen wrote:[color=darkred]
> >> On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote:
> >> > Wrong. You can help Ben Finney testing his packages. That would be much
> >> > more useful than useless babbling on mailing lists.
> >>
> >> if you are talking about these [0], i certainly do not own any of these
> >> pieces of hardware...[/color]
> >
> > I would be very pleased to have a "Buyers guide" on the wiki (i.e list
> > devices that are current, supported and dfsg-free).[/color]
>
> the problem with those list is that they often become outdated and
> incomplete[/color]

Such buyer guide could list the supported-and-free chipsets (not laptop
model or device name).
Also, it should be limited to DebianLenny devices... Such page would
quiet "stable".

Depending on the device type, it could be either be a white-list or a
black list :
- All LAN adapter, except X,Y
- Only the X and Y Wifi adapter.

Franklin


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Loïc Minier dijo [Mon, Nov 03, 2008 at 10:58:16AM +0100]:[color=blue][color=green]
> > I don't think they are at all special. What interprets the software - be
> > it a 'cpu', a 'vm' or a co-processor like many video cards, or something
> > like an arduino doesn't alter the basic attributes - there is machine
> > code for one or more machines, which is usually derived from some more
> > editable source (more can be quite a range though) though compilation.[/color]
>
> It's hard to define how they are special, but I think they are.
>
> And I can think of other data bits in the grey area.
>
> Consider SSL certificates for e.g. Verisign. It makes no sense to
> change them and we don't have the ultimate source for them. These are
> generated data files for which we have the tools to build them, but not
> the ultimate source data (private key). And if we had the private key,
> they would be worthless. These are effectively static data enabling
> SSL communications with sites using these SSL certs providers.[/color]

The thing is, some things are simply not OK for us to distribute as
part of our project, because they don't meet our requirements. That
does not mean "don't use that device" - It means only that "if you are
going to use that device, you should get the firmware". And probably
that statement will be followed by "You can get the firmware in a
nice, packaged way at [url]http://nonfree-firmware.debian.net/yourfunnycard[/url]
or by adding non-free to your APT sources list, and installing
yourfunnycard-firmware".

What's the distinction regarding SSL certificates? Well, the
certificates are not the result of the creative process of a person
(unless you consider "creating just the right entropy for your
computer" as a creative process.
[color=blue]
> I could make another argument about RFCs, it's even easier to change
> them.[/color]

RFCs are, indeed, a very interesting case. I understand the motivation
of the IETF on requesting them to be distributed verbatim and
disallowing distribution of modified formats - Well then, even if it
is nice to have everything in your system and packaged for Debian, I
agree that the ultimate reference point for RFCs is ietf.org - so if I
need to study a given protocol, I'll go to their website and grab the
needed bytes.
[color=blue]
> Firmwares can be considered somewhat the same: static data enabling the
> use of your hardware. You can perhaps change them. Perhaps we have
> the tools to change them. Perhaps we can change them usefully. But
> they are useful as such and we don't need to fight for their freedom as
> we fight for the freedom of the main OS.[/color]

I agree with you. But we cannot see them as part of our system, which
is mostly defined by its freedom. We can adjust our system to allow
you to load the firmware (probably under the name "drivers", to which
many people are more used) in a painless and intuitive fashion. But I
have yet to see a real reason (besides the work that must go into
sweeping them out of the current and future kernel tree - Thanks to
everybody involved into that!) for Debian to make the needed
exceptions to distribute them as part of main.

Greetings,

--
Gunnar Wolf - [email]gwolf@gwolf.org[/email] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

On Mon, Nov 03, 2008, Gunnar Wolf wrote:[color=blue]
> I agree with you. But we cannot see them as part of our system, which
> is mostly defined by its freedom. We can adjust our system to allow
> you to load the firmware (probably under the name "drivers", to which
> many people are more used) in a painless and intuitive fashion. But I
> have yet to see a real reason (besides the work that must go into
> sweeping them out of the current and future kernel tree - Thanks to
> everybody involved into that!) for Debian to make the needed
> exceptions to distribute them as part of main.[/color]

Your post made me see the issue under a different light: I must agree
that this can't be considered on par with the rest of Debian so I wish
we would distribute it while making clear that these particular files
are not with accompanying source.


Why not come up with a new system which would be more convenient than
sections (or separate archives as you suggest)?


e.g. trivial but not very flexible: /lib/no-source-code/firmwares/blah
and a symlink /lib/firmware/foo -> /lib/no-source-code/firmwares/blah.

Or a list of "not fully-free" files, provided by the packages
themselves, e.g. /usr/share/doc/$pkg/btw-these-files-are-firmwares.

Or complex, but might be cleaner: a new type of dpkg meta-information,
just like we have conffiles, shlibs, we'd have "licensing" and would be
able to express that /lib/firmware/foo is free to distribute but
doesn't come with source code, and you probably don't care.


I'm not happy that people would enable non-free on most systems just
for the convenience of getting some files which most people will need
and for which providing a source is not critical. Fetching them
dynamically from $site isn't ok for live CDs, or when you actually try
to provide the firmware to get network to work. :-/

--
Loïc Minier


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Loïc Minier <lool@dooz.org> wrote:
[color=blue]
> On Mon, Nov 03, 2008, Josselin Mouette wrote:[color=green]
>> Le lundi 03 novembre 2008 à 10:12 +0100, Aurelien Jarno a écrit :[color=darkred]
>> > I haven't say that because they are not executed on by the CPU they are
>> > more free. What I mean is that we have those discussions because they
>> > are not executed on the main CPU, which makes them different than other
>> > non-DFSG compliant software. Then some people consider that acceptable,
>> > some other not.[/color]
>> This case is very similar to non-free documentation, which is not
>> executed on any CPU at all. It sounds bogus to split firmware in a
>> specific archive and to not do it for documentation, data, etc.[/color]
>
> Which non-free documentation specifically? [/color]

e.g. PDF files with a DFSG-free license to them, the document source
available as a LaTeX file, but LaTeX will typeset the document using a
non-free font.

Here, you can even modify the content as you like, you just can't
reproduce the original PDF, and it would maybe be hard to make sure that
the typesetting still looks nice and readable with a free replacement
font with different metrics.

Regards, Frank

--
Frank Küster
Debian Developer (TeXLive)
ADFC Miltenberg
B90/Grüne KV Miltenberg


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

On Mon, 2008-11-03 at 21:20 +0100, Loïc Minier wrote:
....[color=blue]
> for which providing a source is not critical. [/color]
....

I wish I understood the reasoning here - putting aside the fact that
most of the software in Debian is under a copyleft licence and so we
*must* provide the source. Why is the source for the radio on my wifi
card any *less* critical than the source for the driver for my wifi
card?

And please, no handwaving about 'different' or 'its hardware
enablement'.

And if the answer reduces down to 'firmware is made by proprietary
vendors and does something many people need and we don't have a
replacement yet' - well thats fine, but at various points we didn't have
a free kernel, or a free libc, or a free graphic desktop environment.

-Rob


--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBJD2p0hnv5qfvT644RAhSgAJ44iBJ/oTqWhiWOMZpZlBvl50zq9ACgl0O5
PGE3KhLRDsUOSRC88PJjmbs=
=yyIR
-----END PGP SIGNATURE-----

On Tue, Nov 04, 2008, Robert Collins wrote:[color=blue]
> I wish I understood the reasoning here - putting aside the fact that
> most of the software in Debian is under a copyleft licence and so we
> *must* provide the source. Why is the source for the radio on my wifi
> card any *less* critical than the source for the driver for my wifi
> card?[/color]

Because I can consider the wifi firmware a subsystem which doesn't
contaminate my main OS; there's a clear interface between the two
systems -- it's like talking to another computer, talking to your hard
disk, talking to your keyboard: something proprietary or free might
well be inside, I don't care as long as I can run a free OS on the main
CPU. I'd *prefer* if it was free, but I can start another project to
fulfill this goal. I don't want the freedom requirements for the main
OS to require using free hardware, just like I want the freedom
requirements to require talking to computers running free software.

Now if Debian can distribute a blob which allows my hardware to run as
indicated by a clear interface with my free OS, that's good enough for
me. If something breaks, I can look at the interface and fix the OS or
blame the hardware (+ firmware). I don't personally feel like I need
the freedom to fix the firmware more than the hardware.
(However, I acknowledge that we must make it clear that particular
files are only distributed as enablement tools, and don't come with
ultimate source, tools, and doc.)

And if we don't require the hardware to be freely modifiable, why
require the firmware to be so?
[color=blue]
> And if the answer reduces down to 'firmware is made by proprietary
> vendors and does something many people need and we don't have a
> replacement yet' - well thats fine, but at various points we didn't have
> a free kernel, or a free libc, or a free graphic desktop environment.[/color]

And we didn't have Debian or OpenMoko; and the glibc, linux, and
Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
projects to free more things up.

Google.com is run with software I don't have access to, but I use it
daily, as well as my microwave, or my wifi card.

--
Loïc Minier


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Loïc Minier dijo [Tue, Nov 04, 2008 at 03:11:18PM +0100]:[color=blue]
> (...)
> And if we don't require the hardware to be freely modifiable, why
> require the firmware to be so?[/color]

So we can ship it coherently with our policies?

Because users have expectations we have a way to give support to what
we ship? If it is a program, we can fix bugs. If it is documentation,
we can fix typos. If it is an image, we can deuglify it. If it is a
sound, we can make it sound... hmm... better? If it is
firmware... Well, we cannot do a thing to it.

It is better and more honest to our users to tell them, "that's not
ours and we cannot fix it. We cannot pledge to support it. Here it is,
it is a nice blob, but it is NOT ours, go bug your hardware
manufacturer for support".

It is not that I want Debian to ship a system with no hardware support
- But that I'd prefer it to be kept visibly separate. We might have a
nonfree-firmware file that can be just copied over at install time (as
Lenny's d-i already allows for) if your devices are needed for
installation. It is not -in my POV- antiethical to have non-free
hardware (i.e. hardware requiring non-free software), but shipping its
supporting firmware it does not allow us to keep our promises.
[color=blue][color=green]
> > And if the answer reduces down to 'firmware is made by proprietary
> > vendors and does something many people need and we don't have a
> > replacement yet' - well thats fine, but at various points we didn't have
> > a free kernel, or a free libc, or a free graphic desktop environment.[/color]
>
> And we didn't have Debian or OpenMoko; and the glibc, linux, and
> Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
> projects to free more things up.
>
> Google.com is run with software I don't have access to, but I use it
> daily, as well as my microwave, or my wifi card.[/color]

Nothing to argue there. I use Google every day, and I provide the
infrastructure for my users to run their non-free programs on every
day. Still, I do not advocate distributing them as part of Debian.

And not because they are inherently evil or anything, but because
Debian is not the right place to distribute them from. See what I
wrote regarding the RFCs - I agree with the IETF, the RFCs server much
better their purpose being non-free than if they were DFSG-free. But
that's not a reason to bend Debian's principles and ship IETF RFCs in
main.

--
Gunnar Wolf - [email]gwolf@gwolf.org[/email] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]

Lo+AO8-c Minier <lool@dooz.org> writes:
[color=blue]
> On Tue, Nov 04, 2008, Robert Collins wrote:[color=green]
> > I wish I understood the reasoning here - putting aside the fact
> > that most of the software in Debian is under a copyleft licence
> > and so we *must* provide the source. Why is the source for the
> > radio on my wifi card any *less* critical than the source for the
> > driver for my wifi card?[/color]
>
> Because I can consider the wifi firmware a subsystem which doesn't
> contaminate my main OS[/color]

It seems to me that you can only honestly consider it so if it
*actually does not* contaminate the main OS. The situation we're faced
with is that non-free works *do* contaminate the main OS; that's the
reason we're having these discussions about DFSG violation at all.
[color=blue]
> Now if Debian can distribute a blob which allows my hardware to run
> as indicated by a clear interface with my free OS, that's good
> enough for me.[/color]

The result can't be called free, though. So long as Debian is promised
to be free, I expect that promise to be met. It seems, from what you
say here, that you do not expect that promise to be met.
[color=blue]
> And if we don't require the hardware to be freely modifiable, why
> require the firmware to be so?[/color]

Because it's distributed in an operating system +IBQ- Debian +IBQ- that its
distributor +IBQ- the Debian project +IBQ- promises is freely modifiable
(among other freedoms).

When someone distributes hardware to me and promises it is freely
modifiable, I require *that* promise to be upheld also.

--
+AFw- +IBw-I don't like country music, but I don't mean to denigrate |
`+AFw- those who do. And for the people who like country music, |
_o__) denigrate means +IBg-put down+IBk-.+IB0- +IBQ-Bob Newhart |
Ben Finney


--
To UNSUBSCRIBE, email to [email]debian-devel-REQUEST@lists.debian.org[/email]
with a subject of "unsubscribe". Trouble? Contact [email]listmaster@lists.debian.org[/email]