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