On Tue, Nov 01, 2016 at 03:47:11PM +0000, Jeremy Stanley wrote: > 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.
You are totally right. I did consider deleting a couple of comments I made in the summary as soon as I wrote them. But I still stand behind the opinion. I don' think this is ever possible unless we want to severely limit user options. > > > 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. +1! > > > 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? What I meant by that is it should just be an interface for making calls to the system to execute the requested commands. > > > 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?" Is importing proprietary libs really a legal issue? If it happens at runtime based on how the user configured the system, and they have whatever licensing rights _they_ need to use that library/CLI, I don't see an issue with that. > -- > Jeremy Stanley Thanks for the good feedback! > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
