- legal-discuss - lists.openstack.org

Re: [legal-discuss] Why is marconi a queue implementation vs a provisioning API?
by Paul Querna 31 Mar '14

31 Mar '14

> On 3/20/14, 8:22 AM, Richard Fontana wrote: > > On Thu, Mar 20, 2014 at 08:22:12AM +0000, Mark McLoughlin 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 > > 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

2 1

[Fwd: Re: [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API?]
by Mark McLoughlin 27 Mar '14

27 Mar '14

-------- Forwarded Message -------- > From: Matt Asay <matt.asay(a)mongodb.com> > Reply-to: "OpenStack Development Mailing List \(not for usage > questions\)" <openstack-dev(a)lists.openstack.org> > To: openstack-dev(a)lists.openstack.org > Subject: Re: [openstack-dev] [Marconi] Why is marconi a queue > implementation vs a provisioning API? > Date: Thu, 27 Mar 2014 10:26:46 -0600 > > In response to Gil Yehuda's comments on MongoDB and the AGPL > (here http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html) I understand the concern about the AGPL. But in this case it's completely, absolutely unfounded. As mentioned earlier, MongoDB Inc. wants people to use MongoDB, the project. That's why we wrapped the server code (AGPL) in an Apache license (drivers). Basically, for 99.999% of the world's population, you can use MongoDB under the cover of the Apache license. If you'd like more assurance, we're happy to provide it. > > > We want people using the world's most popular NoSQL database with the > world's most popular open source cloud (OpenStack). I think our track > record on this is 100% in the affirmative. > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

Re: [legal-discuss] [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API?
by Matt Asay 27 Mar '14

27 Mar '14

In response to this thread: http://lists.openstack.org/pipermail/legal-discuss/2014-March/000174.html As a general rule, MongoDB reads the AGPL generously and broadly to allow unfettered use of the database. See, for example, our licensing policy: http://www.mongodb.org/about/licensing/ I or our legal counsel would be happy to discuss this with the relevant parties at OpenStack. We'd love to see more organizations using MongoDB with OpenStack. Matt ------- { name : "matt asay", title : "vp, business development & marketing", twitter/skype : "@mjasay", website : "www.mongodb.com" }

1 0

License for design specifications (blueprints)
by Russell Bryant 24 Mar '14

24 Mar '14

The Nova project is looking to move the content of design specifications to a git repository for the Juno development cycle [1]. The contents of this repository will not be code. It will primarily be documentation. Right now we put the Apache 2 LICENSE file in the repository and have the same license header in the template used for specifications. http://git.openstack.org/cgit/openstack/nova-specs/tree/LICENSE http://git.openstack.org/cgit/openstack/nova-specs/tree/template.rst Is this licensing the proper choice here? If not, what should we use instead? Thanks, [1] http://lists.openstack.org/pipermail/openstack-dev/2014-March/030576.html -- Russell Bryant

6 10

[Fwd: Re: [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API?]
by Mark McLoughlin 21 Mar '14

21 Mar '14

-------- Forwarded Message -------- > From: Gil Yehuda <gyehuda(a)yahoo-inc.com> > Reply-to: "OpenStack Development Mailing List \(not for usage > questions\)" <openstack-dev(a)lists.openstack.org> > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev(a)lists.openstack.org> > Subject: Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi > a queue implementation vs a provisioning API? > Date: Thu, 20 Mar 2014 17:09:32 +0000 > > >To be clear, Marconi does not incorporate any AGPL code itself; pymongo is > Apache2 licensed. > > Understood, but here's the rub. Someone else is going to want to build on this (which it the point of this open source project). Whereas 'pymongo' is Apache licensed, since the copyright holder, MongoDB Inc. declared it as such, the authors of the other community drivers (for other language bindings and features of MongoDB, etc.) are also of releasing drivers under the Apache or BSD licenses too (thinking that's OK to do since no one is telling them otherwise). That community is unaware of their legal obligations when creating drivers to an AGPL database. Thus if one of those community drivers gets intertwined in a court case clarifying their license to be infringing on the AGPL terms, we've inadvertently impacted our community. This is a credible risk that is difficult for OpenStack to abate, since the problem lies with the way a different community chose to operate. > > There are three interconnected issues here: > 1. The confusion that MongoDB has created in Open Source licensing due to the asymmetric control they have on licensing terms. > 2. The diligence of Open Stack to remain careful with OpenStack's CLA compliance and Apache-friendly terms. > 3. The pragmatics of the effect MondgoDB would have onto OpenStack's economic viability and legal risks at large. > > The first problem is out of scope for this list. But I think people who rely upon Open Source for their business ought to understand what MongoDB is doing to open source software. The second is, to your point, the issue in this conversation. As long as Openstack only use Apache licensed code >>from MondgoDB Inc.<< and diligently avoids using any open source contributions from any community contributor to the MongoDB ecosystem, then you remain compliant the your CLA. But you will have to exclude the rest of the MongoDB community (which goes against the spirit of Open Source -- back to the problem #1, which is out of scope). As for #3, I think the foundation needs to weigh in on the pragmatics here, since this has an economic and legal impact to the entire endeavor, not just to persisting data in one component of the project. > > Gil Yehuda > Sr. Director Of Open Source, Open Standards > > -----Original Message----- > From: Kurt Griffiths [mailto:kurt.griffiths@rackspace.com] > Sent: Thursday, March 20, 2014 9:29 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API? > > > The incorporation of AGPLv3 code Into OpenStack Project is a > >significant decision > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

3 2

Re: [legal-discuss] License for design specifications (blueprints)
by Monty Taylor 20 Mar '14

20 Mar '14

++ On Mar 20, 2014 9:12 PM, Russell Bryant <rbryant(a)redhat.com> wrote: > > On 03/20/2014 01:06 PM, Russell Bryant wrote: > > The Nova project is looking to move the content of design specifications > > to a git repository for the Juno development cycle [1]. The contents of > > this repository will not be code. It will primarily be documentation. > > > > Right now we put the Apache 2 LICENSE file in the repository and have > > the same license header in the template used for specifications. > > > > http://git.openstack.org/cgit/openstack/nova-specs/tree/LICENSE > > http://git.openstack.org/cgit/openstack/nova-specs/tree/template.rst > > > > Is this licensing the proper choice here? If not, what should we use > > instead? > > > > Thanks, > > > > [1] > > http://lists.openstack.org/pipermail/openstack-dev/2014-March/030576.html > > > > To possibly answer my own question ... > > I found in a previous thread that the board officially approved using > CC-BY for documentation here: > > https://wiki.openstack.org/wiki/Governance/Foundation/15Oct2012BoardMinutes…. > > So perhaps we should be using that since this is effectively > documentation? I also expect that this content be used heavily when > developing the official project documentation based on the features > described in these specifications. > > -- > Russell Bryant > > _______________________________________________ > legal-discuss mailing list > legal-discuss(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss >

2 1

Re: [legal-discuss] [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API?
by Monty Taylor 20 Mar '14

20 Mar '14

Ianal, but I know there are some lawyers out there who are concerned that the mechanism of attachment is vague. If there is an issue (I'm not saying there is) I don't think mongodb's view is relevant, as they are quite likely to be bought by someone, say Oracle, who might not share and would not be bound by that opinion. That said, I don't think a mongo driver is an issue, as long as it's not the only driver... That way deployers can make an agpl call on their own. We've had mongo driver for ceilometer for a while. On Mar 20, 2014 7:28 AM, Richard Fontana <rfontana(a)redhat.com> wrote: > > Why not contact MongoDB to understand its viewpoint, if there's > concern? > > > > On Wed, Mar 19, 2014 at 09:38:53PM +0000, Fox, Kevin M wrote: > > Its my understanding that the only case the A in the AGPL would kick in is if the cloud provider made a change to MongoDB and exposed the MongoDB instance to users. Then the users would have to be able to download the changed code. Since Marconi's in front, the user is Marconi, and wouldn't ever want to download the source. As far as I can tell, in this use case, the AGPL'ed MongoDB is not really any different then the GPL'ed MySQL in footprint here. MySQL is acceptable, so why isn't MongoDB? > > > > It would be good to get legal's official take on this. It would be a shame to make major architectural decisions based on license assumptions that turn out not to be true. I'm cc-ing them. > > > > Thanks, > > Kevin > > ________________________________________ > > From: Chris Friesen [chris.friesen(a)windriver.com] > > Sent: Wednesday, March 19, 2014 2:24 PM > > To: openstack-dev(a)lists.openstack.org > > Subject: Re: [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API? > > > > On 03/19/2014 02:24 PM, Fox, Kevin M wrote: > > > Can someone please give more detail into why MongoDB being AGPL is a > > > problem? The drivers that Marconi uses are Apache2 licensed, MongoDB is > > > separated by the network stack and MongoDB is not exposed to the Marconi > > > users so I don't think the 'A' part of the GPL really kicks in at all > > > since the MongoDB "user" is the cloud provider, not the cloud end user? > > > > Even if MongoDB was exposed to end-users, would that be a problem? > > > > Obviously the source to MongoDB would need to be made available > > (presumably it already is) but does the AGPL licence "contaminate" the > > Marconi stuff? I would have thought that would fall under "mere > > aggregation". > > > > Chris > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev(a)lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > legal-discuss mailing list > > legal-discuss(a)lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss > > _______________________________________________ > legal-discuss mailing list > legal-discuss(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss >

5 10

Re: [legal-discuss] [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API?
by Fox, Kevin M 20 Mar '14

20 Mar '14

Its my understanding that the only case the A in the AGPL would kick in is if the cloud provider made a change to MongoDB and exposed the MongoDB instance to users. Then the users would have to be able to download the changed code. Since Marconi's in front, the user is Marconi, and wouldn't ever want to download the source. As far as I can tell, in this use case, the AGPL'ed MongoDB is not really any different then the GPL'ed MySQL in footprint here. MySQL is acceptable, so why isn't MongoDB? It would be good to get legal's official take on this. It would be a shame to make major architectural decisions based on license assumptions that turn out not to be true. I'm cc-ing them. Thanks, Kevin ________________________________________ From: Chris Friesen [chris.friesen(a)windriver.com] Sent: Wednesday, March 19, 2014 2:24 PM To: openstack-dev(a)lists.openstack.org Subject: Re: [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API? On 03/19/2014 02:24 PM, Fox, Kevin M wrote: > Can someone please give more detail into why MongoDB being AGPL is a > problem? The drivers that Marconi uses are Apache2 licensed, MongoDB is > separated by the network stack and MongoDB is not exposed to the Marconi > users so I don't think the 'A' part of the GPL really kicks in at all > since the MongoDB "user" is the cloud provider, not the cloud end user? Even if MongoDB was exposed to end-users, would that be a problem? Obviously the source to MongoDB would need to be made available (presumably it already is) but does the AGPL licence "contaminate" the Marconi stuff? I would have thought that would fall under "mere aggregation". Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

6 5

Contribution Snag
by Radcliffe, Mark 19 Feb '14

19 Feb '14

Kevin: To provide you with more context. The Legal Affairs Committee devoted an entire meeting to the issue of your contribution because it raises fundamental issues about the OpenStack policy on CLAs, including (1) fairness to members who have contributed under the existing CLAs (2) effect on future contributors who request "special treatment" and (3) administrative burden of managing multiple CLAs. As a matter of context, I am on the Legal Committee for the Apache Software Foundation and they only have the individual and corporate CLA: they do not have a government CLA and many significant government agencies, such as the NSA and JPL have executed the Corporate CLA. As an example of the problem which could arise if we granted an exception, we had a request the week prior to the Legal Affairs Committee meeting from a major multinational corporation for a special exemption from the CLA because of their unusual corporate structure. We rejected the request and noted that IBM and many other major corporations had executed the existing CLA: this response was very persuasive to them. If we provide an exception for PNNL, we will not be able to make that statement. After the discussion, the Legal Affairs Committee decided unanimously to recommend against adopting a new form of CLA and to ask PNNL to reconsider its position. I have spoken with the attorney for PNNL and he recognizes that this is part of a larger problem for PNNL as it gets more involved in open source projects (for example, the Apache Software Foundation would not even discuss any changes to the CLA). He is currently working on the issue. We hope that we can find a way for you to contribute to OpenStack and I will continue to work with him on the issue. Please consider the environment before printing this email. The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster(a)dlapiper.com. Thank you.

2 1

Contribution snag.
by Fox, Kevin M 10 Feb '14

10 Feb '14

Hello OpenStack Legal, I'm trying to contribute something and have run into some snags. See email below. Steve told me that the Foundation is the one needing to receive this. I tried but got no response so I'm forwarding it to the legal list. Thanks, Kevin ________________________________________ From: Fox, Kevin M Sent: Thursday, October 31, 2013 5:16 PM To: Steve Baker Subject: Heat contribution Hi Steve, I've been looking through the individual contributor level agreement and in section 7 it mentions contacting the project manager, which I think is you for heat? I have a contribution which is for a set of heat templates that make it possible to spawn a scalable, sharded mongodb cluster. It should be of great use to the Trove folks, as well as others. I've been trying to contribute code for a while and the contributor agreement has made this very difficult. Long story short: * I work for a national lab and while the contribution was created by us government funds and owned by the us government, we are operated by a corporation, Battelle and I am technically a Battelle employee. There really isn't an agreement that seems to cover this case other then the individual agreement with a contribution from others. * All parts of the work that aren't derived directly from existing heat-templates has been put in the public domain. * No one at the lab has the legal authority to sign a Corporate contributor level agreement. We can't sign a us government contributor agreement since we are technically not the us government. We are contractors that the government gave the code to under the public domain. Since the code is out there public domain, I believe an individual contributor agreement works via section 7 and I just need to figure out how to get the code to the right person. Is that you? The work history is: It started out as templates from here: https://mongodb-documentation.readthedocs.org/en/latest/ecosystem/tutorial/… "Chris Scheich"<chris(a)mongodb.com> from 10gen verified it was public domain. It was modified a bit here: https://github.com/andresdouglas/aws-cfn-mongostack By "Andres Douglas"<andres.douglas(a)gmail.com> whom I contacted and he also has public domained the work. I personally modified the templates including some code from the openstack/heat-templates repository and added some original code. Changes contributed by me has cleared legal and export controls and is under the public domain. So all licensing is accounted for and should be acceptable to the OpenStack community and being public domain, I should be able to contribute it. The code is located at the following link. It is Submitted on behalf of a third-party: US Government https://github.com/EMSL-MSC/heat-templates/commit/1d4ce302313f210ba5dc2a29f… Thanks, Kevin

11 37