On 2016-11-01 14:10:44 -0400 (-0400), Ben Swartzlander wrote: > On 11/01/2016 12:03 PM, Jeremy Stanley wrote: [...] > > into it the kernel's process space. This is the closest analogue we > > have to our drivers importing proprietary Python modules. > > I'm not talking about python code here. I'm talking about non-python > binaries, which were a large part of the discussion at the summit. [...]
Thanks--from Sean's summary and some of the in-person recounting I've gotten from others who attended the session, it seemed like there might have been some fuzziness on that point. This could simply be due to terminology mismatches or lack of specificity. > I think we're saying the same thing. Python code can and should be 100% > Apache licensed. External C/C++/Java tools required to interact with a > storage controller could be treated similarly to Linux firmware and allowed > only if those tools could be made available under a freely distributable > license. From the conversations I've had I believe this would address the > major sticking point with Sean's "Option 3". Yes, I concur. I suggest however that we should make it clear this is not the preferred implementation model for drivers, and then supply guidance/recommendations on alternative designs that result in a completely open driver for those willing and able to provide one. -- Jeremy Stanley
signature.asc
Description: Digital signature
__________________________________________________________________________ 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
