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