Re: Firmware & Social Contract: GR proposal
Perhaps, before we spend too many more years on trying to solve this
problem, we should agree on what "this problem" is?
One issue here is that we are trying to make a statement about what
direction we are heading. As M.J.Ray states:
The GPL is far closer to 100% free than a source-withheld
hard-to-edit blob of a program.
And, as http://lwn.net/Articles/196641/ states:
Adopting a policy which favors devices having their proprietary
software in ROM (where it can never, ever be changed) over those
which accept their firmware from the host (where, maybe, someday
it could be rebuilt and tinkered with) seems like a step in the
wrong direction.
Though, the other side of the story is that the ground keeps
shifting underneath us. (Which is hardly surprising. Tomorrow's
hardware is new, every month.)
The way I see it, we're drawing lines in the sand, and the sand
is drifting. We're trying to compensate for where the sand is
going to be next month, next year, and after that, but we're not
omniscient. On top of that, each of us has different concepts
about what's coming up.
We can agree roughly about where we are going, but even there we
often have little control: We did not design hardware which would
not function unless we distribute some essential (but non-free)
component, and we did not design the software which hard-wires
these components into itself.
If this is an accurate statement of the problem (is it? if not,
what's a more accurate statement? is there an "accurate statement"
of the problem which we can all agree on?), then either:
(a) our "lines in the sand" are going to get broken, or
(b) we are going to have to keep on drawing new "lines in the sand", or
(c) we are going to have to come up with some more resilient approach.
As a further note, compromise might be inevitable (it usually is,
when people can not agree on the details of what they are trying
to do -- and our project has long since exceeded the size where
complete agreement, let alone complete understanding, is possible),
but compromises that result in new "lines in the sand" are going to
suffer the same flaw -- the ground is going to keep shifting out from
underneath us.
As a further, further note, I can see the logic in including "the
firmware in the proposed etch release" in etch, for practical
reasons and because that firmware is far enough away from what
some people consider "the operating system and its applications".
On the flip side, I can also see the logic in considering that
firmware "an essential part of the operating system", and can
easily imagine a day when applications include components which
are downloaded onto auxiliary processors (OpenGL is probably
the best "today" example of this sort of thing).
So... we are going to see this problem get bigger in the future,
I think, no matter what we decide today. [But I'm cheating:
"this" is a variable.]
--
Raul
Reply to: