Open Stack

On Tue, Nov 01, 2016 at 12:26:11AM -0400, Ben Swartzlander wrote:
> On 10/31/2016 02:23 PM, Sean McGinnis wrote:
> >Last Tuesday we had a cross-project session around the use of proprietary
> >code/libs/binaries in OpenStack drivers. The challenge we are running into
> >is where to draw the line with these drivers. What is the appropriate policy
> >to have in place to allow/disallow certain approaches.
> >
> > ..snip..
> >
> 
> 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:
> 1) Drivers have to match the license (GPLv2 in Linux's case) which
> guarantees the code is free software.
> 2) Drivers have to be in tree, which makes it easier for kernel developers
> to evolve the driver interfaces without breaking most drivers.
> 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.

I do think it's good to look at what is done with Linux as a well established
example. But I also think it's a little different, so we can't really compare
apples to apples here.

Linux is now a very mature installable OS that is well supported with vendors
devoting resources to making sure their hardware works well with it.

OpenStack is a configurable platform. Some assembly required, even if you go
with all of the defaults.

I think we're closer to the earlier days of Linux. I remember spending a lot
of time trying to get the right source directly from a Toshiba site to be able
to compile in support for my laptop's NIC to work with Red Hat (3?).

In the case of Linux, this was just early days and vendors were just catching
on. (Really, why would anyone want to run Linux on a laptop?? That's for
servers!) But in our case I don't think it's just a matter of maturity.
There will always be proprietary components that need to be installed and
configured for different options.
> 
> 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.
> 
> Regarding drivers that "cheat" and put all the important logic outside the
> open source driver code, I think we can safely ignore these. These drivers
> hurt nothing but themselves by hiding their logic. The chance of breaking
> them with a change to the driver interface is higher but this is a GOOD
> thing -- it discourages what we perceive to be bad behavior. The Linux
> community has already fought this battle and while some companies continue
> to supply out of tree drivers, the process is typically very painful for
> those maintainers and it motivates them to eventually open source their
> drivers and put them in the tree.
> 
> -Ben
>