- legal-discuss - lists.openstack.org

Trivial contributions and CLAs
by Stefano Maffulli 23 Apr '14

23 Apr '14

I have been notified of another very small patch that is left in a limbo, with the author not allowed to sign the CLA and the developers stuck in unknown legal territory. You can read more about it on https://bugs.launchpad.net/bugs/1308984 >From what I can see, the patch is trivial and shouldn't even be copyrightable but the person spotting the issue and fixing it is not comfortable signing the CLAs. Can any other developer copy the patch and put it into our trunk? Until when is this sort of behaviour safe? We're getting more of these small blockers and I think it's already a problem. Having to sign a Corporate CLA and Individual CLA for a trivial patch, from an operator (whose job is to run clouds, resulting in small and rare patches, not to develop large features) can conflict with our effort to get more operators involved in OpenStack. I'm not sure what solutions are available. If we can't change the CLA processes easily, what else can we do to get small contributions like these? thanks, /stef -- Ask and answer questions on https://ask.openstack.org

15 39

Using OpenStack logo in a general presentation
by Lukas Korous 16 Apr '14

16 Apr '14

Hello, I have a question about using the OpenStack logo in a presentation about OpenStack for University students. We have several upcoming presentations about our product (UltiCloud) and OpenStack as well and I would like to ask if it is possible to use OpenStack's logo for that purpose. I am attaching one of the new presentations we would like to use and I would also like to check with you on the usage of other images from openstack.org which we use in the presentation (most of them are downloaded and polished a bit) - I list openstack.org as the source (on the last slide), is that okay? Thank you very much, Best Regards, Lukas Korous Ultimum Technologies s.r.o. http://www.ultimumtechnologies.com https://ulticloud.com

2 2

[Fwd: [OpenStack-DefCore] Revised Bylaws]
by Mark McLoughlin 13 Apr '14

13 Apr '14

Hey I figure these proposed amendments are relevant to this list too. Thanks, Mark. -------- Forwarded Message -------- > From: Radcliffe, Mark <Mark.Radcliffe(a)dlapiper.com> > To: Thierry Carrez <thierry(a)openstack.org> > Cc: Eileen Evans Esq. (eileen.evans(a)hp.com) <eileen.evans(a)hp.com>, > defcore-committee(a)lists.openstack.org > <defcore-committee(a)lists.openstack.org>, Roay, Leslie > <Leslie.Roay(a)dlapiper.com> > Subject: [OpenStack-DefCore] Revised Bylaws > Date: Mon, 7 Apr 2014 19:03:01 +0000 > > I am enclosing the current version of the Bylaws marked to show > differences to the existing version (v15 to v.18) and marked to show > the changes to the initial revised draft (v.17 to v.18). This second > set of changes reflects comments raised at the last meeting of the > committee, particularly by Mark McLoughlin on behalf of the Technical > Committee. Version 18 has not yet been approved by the committee. > These changes are meant to reflect the need to move from a “module” > based method of determining when the trademark can be used to a more > flexible method which can be agreed upon by the Technical Committee > and the Board. As I said to Mark and I think that he passed on to the > Technical Committee, the reasons for the DefCore and these revisions > are as follows: > > > > > I appreciate your comments at the Bylaws committee meeting. We > don’t want to have the TC misunderstand the reasons for the bylaws > change or > > > their consequences. These changes are focused solely on determining > how and when the trademark can be used. We want to ensure that the > TC > > > has an active role in the decisions. Consequently, we will shift > back to the use of “core” for these procedures being set up. > However, as > > > I noted, a number of members of DefCore Committee have expressed a > desire to use a word other than “core” for this concept so we may > see > > > an additional change in the name . > > > > > 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. > _______________________________________________ > Defcore-committee mailing list > Defcore-committee(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

2 2

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

30 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