Re: [DRAFT] resolving DFSG violations
On Sun, Oct 26, 2008 at 07:27:24PM -0700, Jeff Carr wrote:
> On Sat, Oct 25, 2008 at 11:19, Robert Millan <rmh@aybabtu.com> wrote:
>
> > Is there a reason why those interested in supporting blob-dependant hardware
> > can't make a release that includes those blobs? As per SC #1 they can't refer
> > to it as "Debian", but they can use the project's resources to build and
>
> Because you are discriminating against hardware manufacturers if they
> chose to not put flash,cpld,etc chips onboard. You aren't "helping"
> freedom in any way. All you are doing is just pretending it doesn't
> exist. Pretending everything is fine by hiding anything not free in a
> black hole doesn't help freedom. Especially since you then banish from
> debian anyone that tries to expose the non-free stuff you've been
> trying to hide.
>
> Let me understand your position: only buy hardware where the
> manufacturer hides the firmware on an onboard flash otherwise you
> can't run debian.
This has nothing to do with the core problem, which is we're telling our users
that these blobs are free software (i.e. we're liing to them), and in some
cases even exposing them to legal risk by having them accept the GPL when they
can't comply with it (since they don't have the source code).
Nevertheless, I'll give you my personal opinion.
When that software is in a ROM, what prevents the user from modifiing it is not
a matter of freedom, it's purely technical. Understanding how the device works
(including, but not limited to, by reading firmware) is IMO a freedom issue,
but it has nothing to do with Debian. You might as well consider it a freedom
issue if you can't read the source code in your NAS, but just because a Debian
box is connected to the same network it doesn't mean it's Debian's bussiness.
When that software is in writable memory, it means the vendor retained its
ability to modify it, but it didn't want others to have this ability. Therefore,
although they have to ship the firmware, they rely on obfuscation to prevent
end users from having those rights. This has more implications that it might
seem. It turns out, that they'll tend to consider the unified firmware+driver
combo a derived product, and the interface between them is blurred. They might
adjust this interface anytime they want, and it's very likely they'll find it
useful to restrain our freedom by moving complexity from the free side to the
obfuscated one (Intel has likely done this with the iwl driver).
Also, your argument assumes that vendors are uncapable of fixing the problem,
and only able to move it from one way to the other. I disagree; I think
pressure can push them in the right direction, which is telling users how
their own devices work.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
Reply to: