Open Stack

On 2016-09-08 09:32:20 +0100 (+0100), Daniel P. Berrange wrote:
> That policy is referring to libraries (ie, python modules that we'd
> actually "import" at the python level), while the list above seems to be
> referring to external command line tools that we merely invoke from the
> python code. From a license compatibility POV there's no problem, as there's
> a boundary between the open source openstack code, and the closed source
> external program. Talking to a closed source external command over stdio,
> is conceptually no different to talking to a closed source server over
> some remote API.

The drawback to this interpretation is that someone can't ship a
complete OpenStack solution that will "talk" to the devices in
question without either obtaining permission to bundle and ship
these proprietary software components or instructing the recipient
to obtain them separately and assemble the working system
themselves. If we go with an interpretation that the openness
boundary for hardware "support" in OpenStack is at the same place
where this proprietary hardware connects to the commodity system
running OpenStack software (so communication over SSH, HTTP, SCSI,
PCI/DMA, et cetera) we can perhaps avoid this.

It's a grey area many free software projects struggle with, and from
a pragmatic standpoint we need to accept that there will in almost
every case be proprietary software involved in any system (after
all, "firmware" is still software). Still, we can minimize
complication for recipients of our software if we make it expected
they should be able to simply install it and its free dependencies
and get a working system that can communicate with "supported"
hardware without needing to also download and install separate
proprietary tools from the hardware vendor. It's not what we say
today, but it's what I personally feel like we *should* be saying.
-- 
Jeremy Stanley