Open Stack

On 09/09/2016 11:12 AM, Duncan Thomas wrote:
> On 9 September 2016 at 17:22, Ben Swartzlander <ben at swartzlander.org
> <mailto: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.

I don't understand how you can have this stance while tolerating the 
existence of such things as the VMware driver. That software (ESXi) 
absolutely requires a license to use or distribute.

-Ben

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