On 09/09/2016 11:12 AM, Duncan Thomas wrote:
On 9 September 2016 at 17:22, Ben Swartzlander <[email protected] <mailto:[email protected]>> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
