On Apr 13, Anthony Towns <aj@azure.humbug.org.au> wrote: > GPL incompatability otoh, is something we tend to take seriously. We've > known about this issue for ages [0] and to the best of my knowledge, the > kernel guys agreed that the proper approach is to remove the firmware from > the .c files, and instead add a way of loading the firmware at runtime > (an ioctl or a /proc or /dev file/API of some sort) [1]. Really? I will quote from [0]: Kernel developers, as a whole, seem unconcerned about proprietary firmware. There can be specific problematic cases (i.e. where binary-only firmware is marked as being licensed under the GPL), but most firmware is seen as being OK. and Linus stated that moving firmware into user space is "technically incredibly stupid" and "a sign of mental disorder." Nobody really challenged that claim. In the end, this question was pushed back to the Debian legal community, which seems to have more time to debate such issues. Just when is it permissible to have proprietary firmware for a device mixed in with GPL code? We look forward to their answer. The last paragraph is just a nicer way to say "let them discuss this to death, nobody else cares". request_firmware() is useful when you will probably modify/change your firmware more often than you will recompile the driver or when you do not want to waste not-swappable RAM for some data which will not be needed after the device will have been initialised. > If folks believe the above legal reasoning is implausible or incorrect, > the easiest way to convince me otherwise is to get Eben Moglen or someone > similar who both knows the law, and understands the GPL to say otherwise. Given that: - the driver authors do not care - Linus does not care - distributions like Red Hat and Suse, which have much better lawyer than we do, do not care I'd say that the burden of proof lies on you. -- ciao, | Marco | [5716 apgASoFUuX/BY]
Attachment:
signature.asc
Description: Digital signature