> Hi,
>
> > But the code itself hasnīt been altered, there is just an "enhancement"
> > to the compilation result for which we donīt have the source...?
>
> You need to be able to provide the sources for those enhancements.
>
> > So, would the following scenario work?
It's a chicken and egg situation. I feel for the people who can't binary
compile the
DiskOnChip drivers in then distribute it, as that's annoying, but think
about it....
If Linus changes the kernel's license from GPL to a GPL with exceptions,
where you can distribute a linux kernel with static modules for which there
is no source code, then suddenly hardware companies will have less impetus
to provide source for their kernel modules, and the hardware world will once
again begin to close in on the Linux kernel.
We need to keep the ideal of open hardware specifications as part of Linux,
or Linux will not survive. It's that important! So, hardware with
binary-only-drivers will always seem less desirable, and that's good, as it
should give M-SYstems (and other offenders) time to think about their
actions. A nice proprietary niche M-Systems has, but COmpactFlash is eating
their lunch, and fast. Evolution doesn't play nice, and M-Systems is toast
if they can't keep up with it.
I for one will actively avoid using DiskOnChip technology on any Linux
systems until such time as a reliable totally-open-source driver set is
provided.
CompactFlash is comparable in price (cheaper, actually) and emulates IDE.
It's M-Systems that should be sweating this, not us.
Warren
--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.
