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

Differing standards of freedom for different bitstreams (was: call for seconds: on firmware)



Ben Finney <ben+debian@benfinney.id.au> writes:

> This gives no argument for why such bitstreams should be held to
> different standards of freedom for its recipients. The properties
> “not code that is run on the host CPU” is mentioned, but seems to
> be irrelevant to the argument.
> 
> Can you re-write this so it's clear why this particular class of
> bitstream should not be held to the same freedom standards as
> everything else in Debian?

I've seen quite a number of seconds for Peter Palfrader's proposal,
yet have not seen an answer to my question above. If this proposal
passes, it seems to me that the result is the establishment of a
contradiction between:

|  a) firmware in Debian does not have to come with source.  While we do
|     prefer firmware that comes with source and documentation we will not
|     require it,
|  b) we however do require all other freedoms that the DFSG mandate from
|     components of our operating system, […]

versus SC §1:

    1. Debian will remain 100% free
       […] We promise that the Debian system and all its components
       will be free according to [the DFSG] […] We will never make the
       system require the use of a non-free component.

Those two cannot, by my reading, be simultaneously true.

Surely some significant number of those who second the proposal must
have a rational way to reconcile “Debian will remain 100% free” with
the differing standards of freedom proposed by Peter?

-- 
 \     “Oh, I realize it's a penny here and a penny there, but look at |
  `\      me: I've worked myself up from nothing to a state of extreme |
_o__)                                          poverty.” —Groucho Marx |
Ben Finney


Reply to: