Open Stack

On 11/01/2016 12:03 PM, Jeremy Stanley wrote:
> 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.

I'm not talking about python code here. I'm talking about non-python 
binaries, which were a large part of the discussion at the summit.

>> 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.

I think we're saying the same thing. Python code can and should be 100% 
Apache licensed. External C/C++/Java tools required to interact with a 
storage controller could be treated similarly to Linux firmware and 
allowed only if those tools could be made available under a freely 
distributable license. From the conversations I've had I believe this 
would address the major sticking point with Sean's "Option 3".

-Ben