Open Stack

On Sep 9, 2016 08:26, "Ben Swartzlander" <ben at swartzlander.org> wrote:
>
> On 09/08/2016 04:41 PM, Duncan Thomas wrote:
>>
>> On 8 September 2016 at 20:17, John Griffith <john.griffith8 at gmail.com
>> <mailto:john.griffith8 at gmail.com>> wrote:
>>
>>     On Thu, Sep 8, 2016 at 11:04 AM, Jeremy Stanley <fungi at yuggoth.org
>>     <mailto:fungi at yuggoth.org>> wrote:
>>
>>
>>
>>
>>         <snip>
>>
>>         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.
>>
>>
>> Despite the fact I've appeared to be slightly disagreeing with John in
>> the IRC discussion on this subject, you've summarised my concern very
>> well. I'm not convinced that these support tools need to be open source,
>> but they absolutely need to be licensed in such a way that distributions
>> can repackage them and freely distribute them. I'm not aware of any
>> tools currently required by cinder where this is not the case, but a few
>> of us are in the process of auditing this to make sure we understand the
>> situation before we clarify our rules.
>
>
> I don't agree with this stance. I think the Cinder (and OpenStack)
communities should be able to dictate what form driver take, including the
code and the license, but when we start to try to control what drivers are
allowed to talk to (over and API or CLI) then we are starting to
artificially limit what kinds of storage systems can integrate with
OpenStack.
>
> Storage systems take a wide variety of forms, including specialized
hardware systems, clusters of systems, pure software-based systems, open
source, closed source, and even other SDS abstraction layers. I don't see
the point is creating rules that specify what form a storage system has to
take if we are going to allow a driver for it. As long as the driver itself
and all of it's python dependencies are Apache licensed, we can do our job
of reviewing the code and fixing cinder-level bugs. Any other kind of
restrictions just limit customer choice and stifle competition.
>
I get it, like I said I realize that my view doesn't match others, and I
certainly seem to be in the minority.  I'm sure there's some things we can
hammer out and define clearly that makes everybody at least a 'little'
happy.

> Even if you don't agree with my stance, I see serious practical problems
with trying to define what it and is not permitted in terms of "support
tools". Is a proprietary binary that communicates with a physical
controller using a proprietary API a "support tool"? What if someone
creates a software-defined-storage system which is purely a proprietary
binary and nothing else?
>
> API proxies are also very hard to nail down. Is an API proxy with a
proprietary license not allowed? What if that proxy runs on the box itself?
What if it's a separate software package you have to install? I don't think
we can write a set of rules that won't accidentally exclude things we don't
want to exclude.
>
> -Ben Swartzlander
>
>> --
>> Duncan Thomas
>>
>>
>>
>>
__________________________________________________________________________
>> 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
>>
>
>
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160909/372b4eda/attachment.html>