<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 8, 2016 at 11:04 AM, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 2016-09-08 09:32:20 +0100 (+0100), Daniel P. Berrange wrote:<br>
> That policy is referring to libraries (ie, python modules that we'd<br>
> actually "import" at the python level), while the list above seems to be<br>
> referring to external command line tools that we merely invoke from the<br>
> python code. From a license compatibility POV there's no problem, as there's<br>
> a boundary between the open source openstack code, and the closed source<br>
> external program. Talking to a closed source external command over stdio,<br>
> is conceptually no different to talking to a closed source server over<br>
> some remote API.<br>
<br>
</span>The drawback to this interpretation is that someone can't ship a<br>
complete OpenStack solution that will "talk" to the devices in<br>
question without either obtaining permission to bundle and ship<br>
these proprietary software components or instructing the recipient<br>
to obtain them separately and assemble the working system<br>
themselves. If we go with an interpretation that the openness<br>
boundary for hardware "support" in OpenStack is at the same place<br>
where this proprietary hardware connects to the commodity system<br>
running OpenStack software (so communication over SSH, HTTP, SCSI,<br>
PCI/DMA, et cetera) we can perhaps avoid this.<br>
<br>
It's a grey area many free software projects struggle with, and from<br>
a pragmatic standpoint we need to accept that there will in almost<br>
every case be proprietary software involved in any system (after<br>
all, "firmware" is still software). Still, we can minimize<br>
complication for recipients of our software if we make it expected<br>
they should be able to simply install it and its free dependencies<br>
and get a working system that can communicate with "supported"<br>
hardware without needing to also download and install separate<br>
proprietary tools from the hardware vendor. It's not what we say<br>
today, but it's what I personally feel like we *should* be saying.<br>
<span class="gmail-HOEnZb"><font color="#888888">--<br>
Jeremy Stanley<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><div class="gmail_default" style="font-family:monospace,monospace">​</div><div class="gmail_default" style="font-family:monospace,monospace">Thanks for your input here Jeremy..</div><div class="gmail_default" style="font-family:monospace,monospace">​</div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span style="font-family:arial,sans-serif">complication for recipients of our software if we make it expected<br></span><span style="font-family:arial,sans-serif">they should be able to simply install it and its free dependencies<br></span><span style="font-family:arial,sans-serif">and get a working system that can communicate with "supported"<br></span><span style="font-family:arial,sans-serif">hardware without needing to also download and install separate<br></span><span style="font-family:arial,sans-serif">proprietary tools from the hardware vendor. It's not what we say<br></span><span style="font-family:arial,sans-serif">today, but it's what I personally feel like we *should* be saying.</span></blockquote><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif"><br></span></div><div class="gmail_default"><font face="monospace, monospace">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.</font></div><br></div></div>