Open Stack

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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev