Open Stack

On 09/06/2016 11:27 AM, Alon Marx wrote:
> I want to share our plans to open the IBM Storage driver source code.
> Historically we started our way in cinder way back (in Essex if I'm not
> mistaken) with just a small piece of code in the community while keeping
> most of the driver code closed. Since then the code has grown, but we
> kept with the same format. We would like now to open the driver source
> code, while keeping the connectivity to the storage as closed source.
> I believe that there are other cinder drivers that have some stuff in
> proprietary libraries. I want to propose and formalize the principles to
> where we draw the line (this has also been discussed in
> https://review.openstack.org/#/c/341780/) on what's acceptable by the
> community.
> Based on previous discussion I understand that the rule of thumb is "as
> long as the majority of the driver logic is in the public driver" the
> community would be fine with that. Is this acceptable to the community?

NetApp went through this about a year ago with our driver. There was a 
desire to have our cinder driver depend on a proprietary-licensed python 
library. This was soundly rejected by the community, and I personally 
think the policy is clear -- all libraries imported by cinder and cinder 
drivers must have OSI-approved licenses, period.

There is no concept of a "majority of the code" being open. It's all 
open or it violates the policy.

Where things get more grey is when external components are involved, 
such as API proxies or management tools which run in a separate process 
or over the network. The community has traditionally tolerated these 
these things. What the community doesn't like is when the driver is just 
a few lines of python code that calls out to an external binary or 
service to do all the work. Personally, I have no issue whatsoever with 
that approach, but that's where the debate exists.

IMO, there is no debate about proprietary python libs. You can't use 
them. Your choices are:
1) Take the driver out of tree
2) Release the library under and OSI-approved license
3) Refactor the driver to not import the proprietary library

-Ben Swartzlander


> Regards,
> Alon
>
>
> 	
> 	
>
>
>
>
>
>
> __________________________________________________________________________
> 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
>