Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161101/b49e8172/attachment.pgp>