Open Stack

On Thu, Sep 8, 2016 at 11:04 AM, Jeremy Stanley <fungi at 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-request at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160908/c14d3f77/attachment.html>