On 2016-10-31 13:23:48 -0500 (-0500), Sean McGinnis wrote: > Last Tuesday we had a cross-project session around the use of > proprietary code/libs/binaries in OpenStack drivers. The challenge > we are running into is where to draw the line with these drivers. > What is the appropriate policy to have in place to allow/disallow > certain approaches. [...]
Thanks for summarizing this! I desperately wanted to attend but ended up with other obligations for much of Tuesday and so could not. [some comments follow which could be confused as legal advice, so insert obligatory "I am not a lawyer" boilerplate here] > Option 1: > > - All libraries imported by the driver must be licensed such that > they are redistributable by package maintainers. Which means not just licensed for redistribution, but released under an Apache-compatible license (for example, the FSF does not consider the Apache License v2 combatible with GPLv2 so a driver library under the latter license would likely present a legal problem). See http://governance.openstack.org/reference/licensing.html for more. Also, I don't think this bullet is unique to option 1. We have an absolute need for software we produce to be legally redistributable, and if it actively imports (in the Python sense, or links against in the C sense) proprietary or otherwise incompatibly-licensed libraries we can't legally distribute what we're writing because it (according to general opinion on software copyright) would be a derivative work of software under that other license. > - Existing non-compliant driver code would need to be updated by > the Q release to stay in tree. > - Code that does not get imported into the driver at runtime > (CLIs, external binaries, remote application servers) are > acceptable to be not redistributable. I'd love if we could take it a step further and _recommend_ against drivers calling proprietary local tools, even if we state it's strictly acceptable to do so. Some vendors go this route because they have a strong preference for the model (e.g. they already have a non-free CLI tool for this and want to avoid costly code duplication), but others may be doing it simply because they're copying that pattern from an existing driver without realizing it's adding an unnecessary burden on users, operators and deployers. The idealist in me shudders at the idea of calling it acceptable, but my inner pragmatist says we should at least provide some guidance around this choice in favor of the open freeness valued by our community. > Issues: > > - The desire for having things redistributable was to have > everything fully functional "out of the box" no matter how the > deployer configured the system. Having not been there, I can't say for sure but this sounds like a mischaracterization of the position. At least for me, the desire for having things redistributable is so that downstream consumers of OpenStack are not beholden to the vendors just to be able to use our (free!) software with hardware they have: As a thought exercise, say I have a Gralpy brand Frobnule v3 widget in my environment and want to use it with OpenStack Plugh. The Frobnule driver for Plugh calls a proprietary `frobnitz` command line tool to do everything, but that tool has stopped supporting FrobOS <v4 and GralpyCo no longer distributes a version that will work with my hardware. Or maybe I'm annoyed by GralpyCo's extortionist support contracts which are required to be able to download that tool. Or maybe GralpyCo has folded entirely and their software site is now completely offline. While you might retort that operators should avoid using devices which are EOL, for which they can't afford a support contract, or whose vendors have gone out of business, there are lots of reasons why you might. I personally have lots of old hardware, the manufacturers of whom have not existed for years, but because the drivers for it are actually implemented as free software rather than openwashing proprietary tools with a "free" driver library I'm able to use them with the latest versions of my free software of choice. Another _very_ good reason to discourage drivers implemented as opaque proprietary utilities is that it severely complicates reverse-engineering of the actual interfaces being called, so in the Frobnule case above if GralpyCo doesn't want to support some feature of the hardware in the `frobnitz` utility then its nontrivial for someone else (say a non-Gralpy employee) in our community to extend the driver in OpenStack Plugh to do so. > I don't believe this is ever possible. With requirements of > setting up some type of application or management server to > enable some solutions, it is not possible to package all > required code and binaries for every configuration. I wish you'd refrained from editorializing within your summary, and instead stated your personal beliefs in a followup reply to yourself or something. It makes it harder to untangle your personal biases from your retelling of the opinions of others. > Option 2: > > - Remove all drivers that are not completely open source and contained in the > project repo. > > Issues: > > - This restricts things down to only the drivers that can currently be run in > gate. > - This would be a big issue for many Cinder drivers and I'm sure most Ironic > drivers. > - I strongly believe this would result in less vendor involvement in upstream > work. I agree here. I'd prefer if it could be free all the way from an OpenStack service to a standard protocol interface (network communication, USB, PCI, DMA, whatever) but in my opinion the only thing worse for operators than needing to get software from all over the Internet to get their hardware working is to provide no support for their hardware at all because the vendor has thrown its hands up at our hard-line stance on software freedom. It's a delicate balance, surely. > Option 3: > > - Require the majority of business logic is in the open source code. This seems like it would be very hard to police in practice. How easy do we expect it will be to untangle "business logic" from other implementation? And how much of a "majority" will be "required?" > - Allow third party, non-redistributable libraries and CLIs that > are used as more of an "RPC" type interface. [...] Can someone elaborate on what constitutes an "RPC" style interface here? Is this strictly communication over network/IPC/busses/pipes or was the proposal more nuanced than that? > The case that instigated this discussion for me was a proposal to > have a driver that did nothing more than make a one line call of > everything out to a library that handled all logic. In that case, > there is no benefit to the community of being able to review the > code and give some assurance that it is doing things correctly. > And the only benefit really it gives the vendor is they have an > out of tree driver that gets advertised as being in tree. [...] I expect we'd need to reject drivers that directly import proprietary third-party libs on legal grounds if nothing else. Or did you mean something else here by "library?" -- Jeremy Stanley
signature.asc
Description: Digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
