Open Stack

On 9 September 2016 at 17:22, Ben Swartzlander <ben at swartzlander.org> wrote:

On 09/08/2016 04:41 PM, Duncan Thomas wrote:
>


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


So my issue is not with any of those things, it is that I believe anybody
should be able to put together a distribution of openstack, that just
works, which any supported backend, without needed to negotiate licensing
deals with vendors, and without having to have nasty hacks in their
installers that pull things down off the web on to cinder nodes to get
around licensing rules. That is one of the main 'opens' to me in openstack.

I don't care so much whether your CLI or API proxy in open or closed
source, but I really do care if I can create a distribution, even a novel
one, with that software in it, without hitting licensing issues. That is,
as I see it, a bare minimum - anything less than that and it does not
belong in the cinder source tree.


-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160909/923e999c/attachment.html>