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

Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with

Sven Luther <sven.luther@wanadoo.fr> writes:

> On Thu, Aug 10, 2006 at 04:32:52PM +0200, Goswin von Brederlow wrote:
>> Sven Luther <sven.luther@wanadoo.fr> writes:
>> > I am not familiar enough with how library are run, but there is some very
>> > different way in which libraries called by programs work, and the way the main
>> > cpu interacts with a peripheral processor on a pci card, don't you think ? Or
>> > do you want also to declare that you can run GPLed Linux kernels only on
>> > hardware whose VHDL of every chip on it as well as schematics and gerbers are
>> > freely available, not counting that you would also need free PCB design tools
>> > which can read the format, as well as free tools running the manufacturing
>> > plant, and so on ...
>> _IF_ Debian would distribute the CPU in main then zes, I would require
>> that. But Debian is not a hardware vendor.
> Ah, again you are confused. We are not discussing the DFSG-freeness, but the
> violation of the GPL of the kernel here. Two totally separate matters, please
> read the debian-legal argumentation of last year about this issue in order to
> clarify your comprehension of this issue.

You misread me.

Debian is NOT distributing hardware. Therefore any license of software
included with the hardware is totaly irelevant to Debian.

If you want to buy only free hardware that is your problem and we are
all sorry that you won't be able to so. But it is not a problem with
the SC or DFSG that you can't. Hardware is also not included in any
GPL software including the linux kernel. Your "hardware is not free"
argument is totaly besides the issue. That is what I ment.

>> Where people buy their hardware or how free their hardware is has
>> little to do with Debian main. It is a problem for the linux upostream
>> authors to support the hardware with free source code and sometimes
>> they fail.
> Indeed. but when you mention GPL violation, it means that you are not allowed
> to distribute the whole linux kernel, even in non-free.

Hence the need to fix them.

>> >> multiarch. I have a hacked together cdebootstrap that first
>> >> concatenates the Packages files from multiple sources and then calls
>> >> libd-i. It is ugly but it works. This workaround is quite simple to
>> >> copy into D-I if you really want to work on it.
>> >
>> > Ah, nice, i would really be interested in that. Now, the problem is that it
>> > needs to be integrated into the main d-i work, and given their
>> > over-conservativeness and immobilism, it is way too late for etch, or didn't
>> > you hear that d-i was supposed to be frozen this week ?
>> Please stop making this into an attack. Better spend that energy into
> Why ? i am only stating facts, and they banned me of the d-i team for daring
> toeven mention some of the d-i fallacies like this one.

They are not facts but your opinion. What you call
over-conservativeness and immobilism others call carefullness and
stability. You might even be right but you are not helping the issue
nor yourself. We all know by now that you were kicked out, you don't
have to repeat it.

When you take the firmware out of the hardware and into debian / the
kernel then it can become an issue, not before.

>> writing a patch. You've done D-I work before so maybe you even looked
>> at libd-i source before.
> I do have, but that is beside the point.
>> > Nope, i keep pointing out the responsabilities of the current mess to where it
>> > belongs. I don't care about the d-i guys, the DPL clearly said i should expect
>> > nothing of them (well, of a few of them), and fork d-i, so ...
>> But finger pointing will get no work done. Just annoy people.
> It will not allow anyone to forget the issue and believe that everything is
> fine, indeed.

So you will keep the (rightious or wrongfull doesn't matter) hate
against you alive and bruning brightly. Do you believe that will help
your cause? (and no, don't answere that)

>> >> If the kernel is split up then D-I not handling non-free will be a
>> >> release blocker and will be solved. I don't think compromising ideals
>> >> because D-I doesn't yet handle non-free is the right thing to do. It
>> >> is not like implementing this will take more than a weekend.
>> >
>> > Maybe, but without me stepping up, and pointing the finger to this problem,
>> > nobody would have cared, probably they would have been afraid to suffer the
>> > same treatement i got at their hands for daring mention those problems.
>> You are not stepping up. So far you are just pointing fingers. And so
>> far I haven't seen anybody care that didn't care already.
> I am forbidden to do kernel/d-i related work by Frans who threatened me on irc
> about it.

You can always write patches and send them to the BTS. If you fear
retribution by Frans then go that way and get a fellow kernel team
member to commit the changes. I feel for you and know that that is
awkward but that is how it is currently. If your desire to help is
greater than the obstacles then stick with it.


Reply to: