Re: [legal-discuss] Why is marconi a queue implementation vs a provisioning API?
On 3/20/14, 8:22 AM, Richard Fontana wrote:
I'm no fan (personally) of AGPLv3, but taking a stance that there must be a way of deploying OpenStack in production without requiring any AGPLv3 code to be deployed is a significant policy decision for the project and I don't think we've ever articulated the reasons clearly for it. Such a policy would be unprecedented for any Apache License 2.0
On Thu, Mar 20, 2014 at 08:22:12AM +0000, Mark McLoughlin wrote: project as far as I am aware. For comparisons look at the legal policies of the Apache Software Foundation, which don't go this far.
Such a policy needs to be made on a project-by-project basis, as well, especially w/r/t AGPL code. MongoDB/10Gen has communicated very clearly where they consider their copyright boundary to exist, and I believe that legally that functions as a waiver/license if they would ever end up being wrong (which I don't think they would, as I believe a network communication creates a copyright boundary). Thanks, Van
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. 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 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. I would love to help see this kind of documentation get added to the Legal FAQ / references for OpenStack. What is the best set of actions to get there? Port the "LegalIssuesFAQ"[1] to a git report and start proposing changes in a Code Review? Thanks, Paul [1] - https://wiki.openstack.org/wiki/LegalIssuesFAQ
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
participants (2)
-
Paul Querna
-
Richard Fontana