Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161101/535299eb/attachment.pgp>