Ottawa Linux Symposium day 4: Andrew Morton's keynote address (NewsForge)
Posted Jul 27, 2004 2:14 UTC (Tue) by mmarq (guest, #2332)
[Link]
Fighting GPL violations
Belive that the procedures described by Herald Welte, are correct but very expensive even to the more 'richest' of the independent developers... that is if he only was thinking of corporate money and lawyers, now in control, that have under work contract the majority of the more relevant kernel contributers.
A better and much much cheaper alternative is to harden the kernel against the possibility of externel modules insertion, that is, all relevant kernel code must appear in one of the many open source kernel trees. The proprietary driver code could be sent to ring 1 of the processor, where it clearly will not be a derivative work, and where it will be forced to communicate to a API/ABI or a communication stack ala I2O, and that way be perfectly monitorized and controled in terms of what that driver code is supposed to do... and it even as the bonus of transforming the virtual adress space of the kernel to 2Gygas, in an eventual 1/1/2 mapping relation for 32-bits systems, and that way helping to end the starvation of big 32-bit systems with lots of RAM, in a elegant fashion.
Ottawa Linux Symposium day 4: Andrew Morton's keynote address (NewsForge)
Posted Jul 27, 2004 3:57 UTC (Tue) by dmantione (guest, #4640)
[Link]
Apart from that it'll be hard to enfore such a solution and it is a lot of work to build, binary modules are not the problem here. Sitecom did redistribute (afaik) unmodified netfilter code without source, which is not allowed by the GPL.
Ottawa Linux Symposium day 4: Andrew Morton's keynote address (NewsForge)
Posted Jul 27, 2004 14:36 UTC (Tue) by mmarq (guest, #2332)
[Link]
"... binary modules are not the problem here."
Allow me to desagree here. Binary modules are a problem because by the very nature of the Linux kernel and it's method, you end up not really nowing for sure where a binary module begins and where it ends!... and what is added for sure (until you reverse-engineer). And if every hardware vendor starts to flud the market with pseudo non-derivative 'binary works' for the Linux kernel (a later excuse and present the source), it could be a mess worst than hell. That is *not* the kind of defferentiation that is desirable,... it could be orders of magnitude worst than the old Unix wars.
It would be much more sensible to add a first time to market protection clause into the license,... and try to contain the mess somehow...
I really dont know to what extend the solution i point above, because i dont have the knowledge of the most inner working of the kernel, is feseable... but it hell seams a good and elegant one... and binary only code is allowed better, because it will have no "gray areas", and no lawyer expenses...