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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
