On 09/08/2016 04:41 PM, Duncan Thomas wrote:
On 8 September 2016 at 20:17, John Griffith <john.griffi...@gmail.com <mailto:john.griffi...@gmail.com>> wrote:On Thu, Sep 8, 2016 at 11:04 AM, Jeremy Stanley <fu...@yuggoth.org <mailto:fu...@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.
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
