On Thu, Sep 8, 2016 at 11:04 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> 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 > Thanks for your input here Jeremy.. > 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. Your view on what you feel we *should* say, is exactly how I've interpreted our position in previous discussions within the Cinder project. Perhaps I'm over reaching in my interpretation and that's why this is so hotly debated when I do see it or voice my concerns about it.
__________________________________________________________________________ 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