Open Stack

On Sun, Mar 30, 2014 at 06:34:33PM -0700, Paul Querna wrote:
> The ASF has been dealing with optional dependencies and their license
> interactions with the Apache License for a long time.  They have
> formed at the least more "in depth" documentation on how all of it
> interacts, specifically as it relates to the issues presented here, I
> think it is reasonable to refer to:
> 
> http://www.apache.org/legal/resolved.html#optional
> 
> "Will the majority of users want to use my product without adding the
> optional components?"
> 
> This is clearly false in the case of Marconi as it stands today.
> MongoDB might be "optional", but it is the only realistic choice.

You have only quoted the end of that question and answer. The full
text is this:

== begin == 

  Can Apache projects rely on components whose licensing affects the
  Apache product?

  Apache projects cannot distribute any such components. However, if
  the component is only needed for optional features, a project can
  provide the user with instructions on how to obtain and install the
  non-included work. Optional means that the component is not required
  for standard use of the product or for the product to achieve a
  desirable level of quality. The question to ask yourself in this
  situation is:

    "Will the majority of users want to use my product without adding
    the optional components?"

== end == 

I also think that in reading that question and answer something is
lost without reading the preceding one:

  "Can Apache projects rely on components under prohibited licenses?

  Apache projects cannot distribute any such components. As with the
  previous question on platforms, the component can be relied on if
  the component's licence terms do not affect the Apache product's
  licensing. For example, using a GPL'ed tool during the build is OK."

I agree (based on my understanding of the current situation with
Marconi) that MongoDB is not really "optional" at present, and so,
yes, the answer to the question at the end of the first-quoted FAQ,
taken out of context, is probably "no", leaving aside my uncertainty
about the meaning of 'product' (see below).

But to take that question in the context of those FAQs:

If you are taking the position that a practical requirement to deploy
MongoDB to use Marconi means that MongoDB's licensing "affects" the
licensing of Marconi, then and only then is that ASF FAQ about
"optional" components even relevant. To take that position you'd have
to at least explain why MongoDB's licensing has that effect after
MongoDB, Inc.'s VP of Marketing and Business Development appeared to
indicate on this list and openstack-dev that it wouldn't and seemed to
be willing to have his company make a formal representation concerning
that issue.

Arguably a more relevant ASF FAQ is the one that answers "Does it
matter what platform an Apache product is created to work with?".
 
> An additional document that hasn't quite moved all the way through the
> ringer, and hence still "proposed" at the ASF is this one:
> 
> https://www.apache.org/legal/3party.html
> 
> The contents of the Guiding Principles seem perfectly aligned with OpenStack.

I am not sure about 'perfectly' but I do think this is very useful to
look at as a model for OpenStack. However, I have never been clear on
what the ASF means by the term "Apache product" -- I gather that it's
an ASF term of art as I do not commonly encounter its use in other
open source projects -- and I don't know if that "product" concept
would be relevant to OpenStack. Is the product/project distinction
essentially binary/source? Or are they considered synonymous?

> I think it also does a good job of laying out both groups of licenses
> based on their properties, and how projects can depend on or build
> modules with mixed license dependencies.  Things like classifying
> "System Requirements" are a good fit for projects like Nova, which
> have many plugins for restricted licensed Hypervisors for example.

A general concern I have is that the details of ASF legal policy seem
to have grown up particularly around legal issues peculiar to Java
development (especially as those legal issues were understood about a
decade ago) and the practice of ASF projects distributing "convenience
binaries". Does the term "system requirement" as used in the proposed
ASF document even mean the same thing that "system requirement" would
intuitively mean for OpenStack developers?

 - RF