On 2016-11-01 00:26:11 -0400 (-0400), Ben Swartzlander wrote: [...] > As usual I'd like to point to the Linux project as a good example > for how to handle such things. Linux is older than us and has been > dealing with drivers and proprietary code for a very long time. > > Linux does a few specific things that I like a lot: [...] > 3) Drivers which require proprietary stuff (typically called > "firmware" or "binary blobs" in the Linux world) can contribute > that stuff to the linux-firmware repo which supports closed-source > but freely-distributable software.
Note that the "proprietary stuff" here is generally opaque blobs the running kernel uploads into other parts of the system to run on or initialize different processors than the kernel itself is running within. I'm pretty sure the Linux devs wouldn't (and legally couldn't? but I am not a lawyer nor a kernel maintainer) allow drivers in tree that dynamically load proprietary external libraries into it the kernel's process space. This is the closest analogue we have to our drivers importing proprietary Python modules. > Personally I think the needs of the distros could be met with > something like the linux-firmware repo. It would create a way for > vendors that require proprietary stuff to make it available for > distros to do what they need to do. [...] This might be a solution to the case where drivers call proprietary local command-line utilities or load proprietary data for use in initializing some device, as long as those things are still freely redistributable on their own. I don't know, though, how many services have drivers in exactly this situation. It certainly doesn't change the legality of things like importing proprietary Python modules within drivers, and is also a suboptimal solution I think we should discourage in favor of providing _actual_ free drivers. I suppose it's worth a try, but I'm skeptical it will significantly alter the dynamics of the situation. -- Jeremy Stanley
signature.asc
Description: Digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
