[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DFSG violations: non-free but no contrib



Loïc Minier dijo [Mon, Nov 03, 2008 at 10:58:16AM +0100]:
> > 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.
> 
>  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.

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 http://nonfree-firmware.debian.net/yourfunnycard
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.

>    I could make another argument about RFCs, it's even easier to change
>  them.

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.

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

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 - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


Reply to: